JavaBlog.fr / Java.lu API DCTM,Documentum,DQL DCTM Documentum : ACL template, Permission Set Template with Alias Set (PART 1 : theory)

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

Hello,

This post is relating to Permission Set Template (PST) or ACL Template available in Documentum. This feature is naturally coupled with Alias Set.
 
Summary: PST + Alias Set = Normal ACL
 
Concerning the theoretic aspects, I advise an excellent article highlighting that the PST feature 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.
 


 
A review concerning the purpose of PST and the solution with use of PSTs for a common problem (Part 1) : https://johnnygee.wordpress.com/2006/09/12/permission-set-templates-friend-or-foe-part-1/
 
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.

 


 
When should PST be used (vs regular ACLs) (Part 2): https://johnnygee.wordpress.com/2006/09/14/permission-set-templates-friend-or-foe-part-2/
Permission Set Templates – Friend or Foe? Part 2

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.


 


 
What are the Attributes of the ACL object?
An ACL object has the following important attributes:

  • object_name: The name of the ACL which must be unique for all ALCs with the same owner_name.
  • owner_name: The owner of the ACL. System ACLs are owned by the docbase owner, while User ACLs are owned by normal docbase users.
  • r_accessor_name: A repeating attribute that lists all of the users and groups that have access.
  • r_accessor_permit: A repeating attribute that lists the level of access for each user and group defined in the accessor_name attribute.
  • r_accessor_xpermit: A repeating attribute that specifies the extended permissions for each user and group defined in the accessor_name attribute.
  • acl_class: The class of the ACL. The ACL is a regular ACL with value 0, a template ACL with value 1 (or PST), an instance of a template ACL (or PST) with value 2 or Public ACL with value 3.

 


 
Some definitions:

  • Public ACLs (acl_class=3) are available for use by any user in the repository. Public ACLs created by the repository owner are called system ACLs. System ACLs can only be managed by the repository owner. Other public ACLs can be managed by their owners or a user with Sysadmin or Superuser privileges.
  • So, a System ACL (acl_class=3 owned by repository owner) is an ACL that is created by a the repository owner and is available for all users to use. The only thing that makes it a “system” ACL is that the owner of the ACL is the same as the docbase owner. Most ACLs in a docbase should be System ACLs.
  • Private ACLs or Regular ACLs (acl_class=0) are created and owned by a user other than the repository owner. However, unlike public ACLs, private ACLs are available for use only by their owners, and only their owners or a superuser can manage them.
  • A User ACL (acl_class=0) is an ACL that is owned by a user in the docbase. It can only be used by that user. Bob can not create a document and set its permissions to one of Fred’s User ACLs. Bob can only use his own User ACLs or a System ACL.
  • An internal ACL (acl_class=0) is an ACL created on-the-fly by the server, rather than being created explicitly by a user or system administrator. An internal ACL is easy to spot because of its name which starts with “dm_45….” in the format “dm_<object_id>” like “dm_45xxxxxxxxxx108”.
  • Template ACLs or Permission Set Template (acl_class=1) are used to make applications, workflows, and lifecycles portable.For example, an application that uses a template ACL could be used by a variety of departments within an enterprise because the users or groups within the ACL entries are not defined until the ACL is assigned to an actual document.
  • Instances of Template ACL (acl_class=2) are instances of Template ACLs used with AliasSet. An instane of template ACL is easy to spot because of its name which starts with “dm_45…._800…” in the format “dm_<object_id_of_template_acl>_<suffix_of_aliasset_object_id>“. Example for instance of template ACL:
    r_object_id : 450xxxxxxxxxxx8aa
    object_name : dm_450xxxxxxxx102_800yyyyy
    acl_class : 2
    r_template_id : 450xxxxxxxx102
    r_alias_set_id : 660220c5800yyyyy

 


 

Client Capability

 
User privileges & extended privileges

 
User permissions and extended permissions

  • 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.


 


 

Special Aliases
There are some special aliases :

  • 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

These aliases are used to make ACLs more flexible and easier to administer.

Best regards,

Huseyin OZVEREN

Leave a Reply

Your email address will not be published.

Time limit is exhausted. Please reload CAPTCHA.

Related Post