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:
######## Creation of an ACL via API begintran,c create,c,dm_acl set,c,l,object_name TEST_ACL_HUO_1 set,c,l,description ACL TEST HUO set,c,l,owner_name dm_dbo set,c,l,r_is_internal FALSE set,c,l,globally_managed FALSE set,c,l,acl_class 3 ### ACCESSOR 1 append,c,l,r_accessor_name docu append,c,l,r_is_group TRUE append,c,l,r_accessor_permit 7 append,c,l,r_permit_type 0 ### ACCESSOR 2 append,c,l,r_accessor_name gedadm append,c,l,r_is_group FALSE append,c,l,r_accessor_permit 6 append,c,l,r_permit_type 0 save,c,l commit,c
…. so, the result is an ACL with an important information r_permit_type:
USER ATTRIBUTES
object_name : TEST_ACL_HUO_1
description : ACL TEST HUO
owner_name : MYDOCBASE
globally_managed : F
acl_class : 3
SYSTEM ATTRIBUTES
r_object_id : 45xxxxxxxxx2
r_is_internal : F
r_accessor_name [0]: dm_world
[1]: dm_owner
[2]: docu
[3]: gedadm
r_accessor_permit [0]: 1
[1]: 1
[2]: 7
[3]: 6
r_accessor_xpermit [0]: 0
[1]: 0
r_is_group [0]: F
[1]: F
[2]: T
[3]: F
r_has_events : F
r_permit_type [0]: 0
[1]: 0
[2]: 0
[3]: 0
r_application_permit [0]:
[1]:
[2]:
[3]:
r_template_id : 0000000000000000
r_alias_set_id : 0000000000000000</sql>
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:
i_has_required_groups : T i_has_required_group_set : T i_has_access_restrictions : T
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:
retrieve,c,dm_acl where object_name='HR_ACL' grant,c,l,huo_grp_no_body,AccessRestriction,,5 save,c,l
HR_ACL_ARCHIVED:
retrieve,c,dm_acl where object_name='HR_ACL_ARCHIVED' grant,c,l,huo_grp_all_users,AccessRestriction,,5 save,c,l
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.
retrieve,c,dm_acl where object_name like 'MY_HUO_ACL' # grant,c,l,dm_world,1, grant,c,l,dm_owner,7,CHANGE_LOCATION,CHANGE_PERMIT # # BROWSE - AccessPermit grant,c,l,access-browse-my-huo-acl,AccessPermit,,2 revoke,c,l,access-browse-my-huo-acl,ExtendedPermit,,EXECUTE_PROC revoke,c,l,access-browse-my-huo-acl,ExtendedPermit,,CHANGE_LOCATION # # RELATE - AccessPermit grant,c,l,access-relate-my-huo-acl,AccessPermit,,4 revoke,c,l,access-relate-my-huo-acl,ExtendedPermit,,EXECUTE_PROC revoke,c,l,access-relate-my-huo-acl,ExtendedPermit,,CHANGE_LOCATION # # WRITE - AccessPermit grant,c,l,access-write-my-huo-acl,AccessPermit,,6 revoke,c,l,access-write-my-huo-acl,ExtendedPermit,,EXECUTE_PROC grant,c,l,access-write-my-huo-acl,ExtendedPermit,,CHANGE_LOCATION grant,c,l,access-write-my-huo-acl,ExtendedPermit,,CHANGE_PERMIT # # DELETE - AccessPermit grant,c,l,access-delete-my-huo-acl,AccessPermit,,7 revoke,c,l,access-delete-my-huo-acl,ExtendedPermit,,EXECUTE_PROC grant,c,l,access-delete-my-huo-acl,ExtendedPermit,,CHANGE_LOCATION grant,c,l,access-delete-my-huo-acl,ExtendedPermit,,CHANGE_PERMIT # # RequiredGroupSet grant,c,l,access-browse-my-huo-acl,RequiredGroupSet grant,c,l,access-relate-my-huo-acl,RequiredGroupSet grant,c,l,access-write-my-huo-acl,RequiredGroupSet grant,c,l,access-delete-my-huo-acl,RequiredGroupSet save,c,l
Result:
object_name : MY_HUO_ACL
r_accessor_name
[0]: dm_world
[1]: dm_owner
[2]: access-browse-my-huo-acl
[3]: access-relate-my-huo-acl
[4]: access-write-my-huo-acl
[5]: access-delete-my-huo-acl
[6]: access-browse-my-huo-acl
[7]: access-relate-my-huo-acl
[8]: access-write-my-huo-acl
[9]: access-delete-my-huo-acl
r_accessor_permit
[0]: 1
[1]: 7
[2]: 2
[3]: 4
[4]: 6
[5]: 7
[6]: 0
[7]: 0
[8]: 0
[9]: 0
r_accessor_xpermit
[0]: 3
[1]: 131073
[2]: 3
[3]: 3
[4]: 131073
[5]: 131073
[6]: 0
[7]: 0
[8]: 0
[9]: 0
r_is_group
[0]: F
[1]: F
[2]: T
[3]: T
[4]: T
[5]: T
[6]: T
[7]: T
[8]: T
[9]: T
r_permit_type
[0]: 0
[1]: 0
[2]: 0
[3]: 0
[4]: 0
[5]: 0
[6]: 7
[7]: 7
[8]: 7
[9]: 7
r_application_permit
[0]:
[1]:
[2]:
[3]:
[4]:
[5]:
[6]:
[7]:
[8]:
[9]:
i_has_required_groups : F
i_has_required_group_set : T
i_has_access_restrictions : T
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.
r_accessor_name ... [ 7]: %RestrictedQuarantineUsersGroup [ 8]: technical users [ 9]: users_all [10]: my_restricted_required_grp r_permit_type ... [ 7]: 7 = RequiredGroupSet [ 8]: 7 = RequiredGroupSet [ 9]: 7 = RequiredGroupSet [10]: 6 = RequiredGroup
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.
r_accessor_name ... [ 7]: %CompanyUsersGroup [14]: technical users [15]: users_all r_permit_type ... [ 8]: 7 = RequiredGroupSet [14]: 7 = RequiredGroupSet [15]: 7 = RequiredGroupSet
That’s all !!!
Huseyin OZVEREN