Documentum : ACL template, Permission Set Template with Alias Set (PART 1 : theory)

Problem:
Imagine you are the systems administrator for Documentum implementation. You have been told that all documents should have security permissions that satisfy this requirement:

1) Any user for a specific department can update documents that are owned by that the document; everyone else can only read the document

Lets say that there are 10 different departments (eg contracts), so the total number of ACLs you would need to create is 10. An example of this ACL would be:

contracts_acl:
dm_world – READ
contracts_dept – WRITE

This gets more complicated when you implement security in conjunction with lifecycle states. Lets say there is 3 lifecycle states – draft, approved, archived. Then, the number of ACLs you would need to create has jumped to 30 (10 depts x 3 lifecycle states = 30). An example of this would be:

contracts_draft_acl:
dm_world – READ
contracts_dept – WRITE

contracts_approved_acl:
dm_world – READ
contracts_dept – READ

contracts_archived_acl:
dm_world – NONE
contracts_dept – READ

You just spent hours creating these 30 ACLs, when you are told that

2) Any user for a specific department can update documents that are owned by that the document; everyone else cannot see it until the document is approved

3) Once a document is archived, no one (except system admins) should be able to see/search for the document – this includes users that own the document.

Arrgh! – this would require you to make changes to 20 ACLs. You would need dept_draft_acl and dept_archived_acl for each of the 10 departements (2×10=20).

 
 
Solution:
Permission set templates used in conjunction with alias sets simplifies the management of ACLs. PSTs are basically ACLs with placeholders for the accessor name – hence, thats why PSTs are sometimes called Template ACLs. These placeholders are resolved when you associate an alias set to be used with PST. The result of this is a normal ACL that the Content Server manages:

PST + Alias Set = Normal ACL

So instead of creating 30 normal ACLs for our example, you would need to create 3 PST and 10 alias sets for a total of 13 objects. An example of PST would be:

draft_acl:
dm_world – READ
%dept – WRITE

An example of alias set would be:

contracts_alias_set:
%dept – contracts_dept

When you assign alias set and PST to a document, you end up with a system managed ACL:

draft_acl:
dm_world – READ
%dept – WRITE
+
contracts_alias_set:
%dept – contracts_dept
=
system acl:
dm_world – READ
contracts_dept – WRITE

Now if you understand what I have described so far, then you can see the management advantages of PSTs. Given the new requirement #2 and #3, instead of needing to update 20 ACLs, you only need to update 2 PST. Also, if you need to add a new department, you dont have to create 3 new acls. All you need to do is create 1 new alias set.

Now that you have seen the power of PSTs, the next question you probably have is when should PST be used (vs regular ACLs).

Based on my experience, PSTs should be used when the following conditions exist – especially if ALL the conditions are true:

• Your company/organization has well defined groups/roles. Examples of groups are departments and contractors. Examples of roles are content authors, managers, and vice presidents.
• You plan on implementing lifecycle security. This means that permissions on documents will change over the lifecycle of the document.
• You want to actively manage permissions at an enterprise level. This is important from an application support perspective. Typical end users are not knowlegable enough about Documentum security to properly dictate what permissions should be assigned to documents.

PSTs should not be used (or used sparingly) in the following situations:

• Your organization is not well defined. Without some level of organization, defining meaningfull alias sets becomes very difficult.
• Your organization is small and/or you do not plan to use lifecycle security. The number of PSTs or alias sets is limited, so the additional layer of complexity outweighs the benefit of PST.
• Your business processes are not well defined and your security requirements are ad-hoc in nature. If the user requires the ability to grant/revoke permissions on documents at will, then you cannot manage security at a central level.
• There are probably other circumstances where PSTs can be a “great friend” or an “evil foe“. I am definitely interested to hear how other architects use PSTs or have tried to use PSTs and failed given the environment they were working in.

• NONE (1): A user with NONE access will never know that the document exists. They won’t see it in a folder, and if they query for it, it will not be returned in the result list. This is one of the most unique and powerful features of Documentum’s security sub-system.
• BROWSE (2): A user with BROWSE access will be able to see the attributes of a document, but can not view the content. The user will see the document within the folder in which it lives, and the user can query for it.
• READ (3): A user with READ access can view the attributes and content of a document, but can not annotate it, version it or edit it.
• RELATE (4): A user with RELATE access can view the attributes and content and can annotate the content.
• VERSION (5): A user with VERSION access can read, annotate, and create new versions of a document, but can not overwrite the current version of the document. If a user with VERSION access wants to modify the attributes of a document, he must check it out, modify the attributes, then check it in.
• WRITE (6): A user with WRITE access can read, annotate, version, and overwrite the current document, but can not delete it. A user with WRITE access can modify the attributes of a document without checking it out.
• DELETE (7): A user with DELETE permission can do all these things, plus delete the document. DELETE permission is the highest level of permission that a user can have on a document.

• dm_owner for the current owner of the document
• dm_world for all of the users in a docbase.
• dm_dbo to represent the docbase owner