Documentum : ACL, Permit Type, Trusted Content Services, TCS, Access Restriction, Required Group Set

Hello,

The Trusted Content Services is a product of EMC which adds some security options on the Content Server. I had only the opportunity to use the feature concerning the additional types of entries in an ACL, so, I explain this feature in this post. Unfortunately, the others security features like Encrypted file store storage areas, Digital Shredding and Electronic signatures are still unknown for me.

Below, a simple example of API script for public ACL creation:

…. so, the result is an ACL with an important information r_permit_type:

 
 
Documentum (Via the product “Trusted Content Services”) provides an ability to restrict the basic permissions and extended permissions via the Permit types : AccessRestriction and ExtendedRestriction. The permit_type argument identifies which type of entry is added. In the below example, the permit type used r_permit_type=0 is the basic/standard permit type AccessPermit.
 
There possible types of entries are:

• AccessPermit (0): An AccessPermit entry grants the base permissions. Creating, modifying, or deleting AccessPermit entries is supported by all Content Servers.
• ExtendedPermit (1): An ExtendedPermit entry grants the extended permissions. Creating, modifying, or deleting ExtendedPermit entries is supported by all Content Servers.
• AccessRestriction (3): An AccessRestriction entry identifies a user or group and restricts the user or group’s access to the level specified in the entry even though that user or group may be granted a higher access level by another entry. An access restriction entry denies a user the right to the base object-level permission level specified in the entry.
  This restriction is EXCLUSIVE/EXCLUDING : a AccessRestriction entry with the VERSION (5) permission will allow a maximum permission RELATE (4).
• ExtendedRestriction (4): An extended restriction entry denies a user or the members of a specified group the specified extended object-level permission.
  For example, if a user would otherwise have Change Permission rights as a member of a particular group, an extended restriction would remove that right.
• RequiredGroup (6): A RequiredGroup entry requires a user requesting access to an object governed by the permission set to be a member of the group identified in the entry. If there are entries for multiple groups, the user must be a member of all the groups before Content Server allows access to the object.
• RequiredGroupSet (7): A RequiredGroupSet entry requires a user requesting access to an object governed by the permission set to be a member of atleast one group in the set of groups.
• ApplicationPermit (2): An ApplicationPermit entry identifies a user or group and a user-defined permission level granted to that user or group. Application permits are interpreted only by user applications. Content Server does not enforce application permits.
• ApplicationRestriction (5): An ApplicationRestriction entry identifies a user or group and restricts that user or group from exercising the specified application permit. Application restrictions are interpreted only by user applications. Content Server does not enforce application restrictions.

The Content Server with a Trusted Content Services license is necessary to grant the permit types AccessRestriction, ExtendedRestriction, RequiredGroup, RequiredGroupSet, ApplicationPermit, and ApplicationRestriction. The below attributes of ACL (PST and instances of PST) are set if these permit types are used:

 
 
In order to illustrate the utility of these restriction feature, here are some examples:

Example 1: Restriction access to sub group
The following example of an ACL on a document belonging to the HR department in an organization :
HR_ACL:
+ Groupe Name = HR_Department ; Permit Type = AccessPermit ; Permission Level = Delete
+ Groupe Name = HR_Department_subgroup ; Permit Type = AccessRestriction ; Permission Level = Write

This HR_ACL generically provides “Delete” access to the HR department group, but does not allow a particular subgroup within this HR department to update or delete the document.
By using AccessRestriction permit type with basic permission WRITE, the system allows this subgroup to only BROWSE, READ, RELATE and VERSION the document (not “WRITE”!!!!).

 
 
Example 2: Archiving document
An other typic concret application of this restriction access is the archiving of documents. So, we could create 2 ACLs : HR_ACL and HR_ACL_ARCHIVED using the following 2 groups:
+ huo_grp_no_body is a group containing no user.
+ huo_grp_all_users is a group containing all users.
HR_ACL:

HR_ACL_ARCHIVED:

By using AccessRestriction permit type with basic permission VERSION (5):

• with the HR_ACL, the system dosen’t restrict explicitly users to access and modify the document,
• with the HR_ACL_ARCHIVED, the system restricts all users to only BROWSE, READ, and RELATE the document (not “VERSION ”!!!!)

 
 
Example 3: Best Practice ACL / Group
A best practice for ACL is to create several groups for the main accesses : DELETE, WRITE, RELATE and BROWSE. Theses groups must be granted with AccessPermit and RequiredGroupSet permit types.

Result:

 
 
Example 4: Use of RequiredGroup / RequiredGroupSet
To have visibility on the document, the user must belong to the group “my_restricted_required_grp” (via RequiredGroup) and to one of the groups “% RestrictedQuarantineUsersGroup, technical users, users_all” (via RequiredGroupSet). The level of the BROWSE / READ / WRITE / DELETE persmission will be set by the other entries in the ACL.

To gain visibility into the document, the user will need to belong to one of the other groups “% CompanyUsersGroup, technical users, users_all” (via RequiredGroupSet). The level of the BROWSE / READ / WRITE / DELETE persmission will be set by the other entries in the ACL.

 
 
That’s all !!!

Huseyin OZVEREN