Permission Set Templates – Friend or Foe? Part 1

Permission set templates (PSTs) feature has been available in Documentum for a long time now. However, it is rarely used, probably due to developers lack of understanding and the complexity of designing security model that takes advantage of PSTs and alias sets. Before deciding whether PSTs are our friend or foe (Part 2), lets review the purpose of PST (Part 1).

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.

Do you see the power now?
In Part 2, I will discuss when PSTs should/should not be used.

Advertisements

6 responses to “Permission Set Templates – Friend or Foe? Part 1

  1. Hi Johnny,
    Good to see your view on the PSTs. I was a fan from the day I learned about them.
    I’ve however not managed to map it into process based setup where your ‘role’ (reader, writer, browser) defines what you can do.
    Image a folderstrcuture where every folder is a (sub)proces and the location (thus which process) where you store the document decides what permissions are assigned. If I store a document in folder A because it belongs to proces A, the folder ACL is inherited to the document. What department I’m in is not relevant. Two people from two departments can belong to one process.
    The problem I couldn’t solve was that, to resolve the alias, it looks at the user (a.o). In the process based approach it should look at the folder. If that was the case, a handful generic PSTs would do.
    Maybe I’m overlooking something. Any thoughts?

  2. There is a “pecking order” with regards to alias set resolution. This resolution order can be confusing at times. To get around this, I manually set the r_alias_set_id directly against the object that I am assigning the PST to. So in your scenario, you could assign the alias set and PST on the root process folder and it should create the appropriate ACL.

  3. Pingback: Aliases! The Dream Begins! « ♪ उत्त्कर्ष

  4. Pingback: Aliases! 2: Living the Dream « ♪ उत्त्कर्ष

  5. Pingback: Aliases! 3: The Dream « ♪ उत्त्कर्ष

  6. Pingback: JavaBlog.fr / Java.lu - Documentum : ACL template, Permission Set Template with Alias Set (PART 1 : theory)

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s