top-image

LATEST ARTICLES

Hello,

After my first post concerning the theoretic aspects of Permission Set Template (ACL Template/PST) coupled with Alias Set (AS) Documentum : ACL template, Permission Set Template with Alias Set (PART 1 : theory), in this post, I would like to illustrate this theory, via a simple use of AS and PST in security of “documents archiving”. The documents archived will have a READONLY restriction for all database users.

 


 
Creation of Template ACL or Permission Set Template (acl_class=1)
 
So, first, we can modify an existing PST or create a new PST MY_ACL_TEMPLATE with a new accessor entry for an alias %ReaderRestrictAccess:

API> begintran,c
...
OK
API> create,c,dm_acl
...
45xxxxxxx951
API> set,c,l,object_name
MY_ACL_TEMPLATE
...
OK
API> set,c,l,owner_name
dm_dbo
...
OK
API> set,c,l,acl_class
1
...
OK
API> set,c,l,description
Desc 4 MY_ACL_TEMPLATE
...
OK
API> grant,c,l,dm_world,AccessPermit,,3
...
OK
API> grant,c,l,dm_owner,AccessPermit,,3
...
OK
API> grant,c,l,%AS4MyGroup,AccessPermit,,6
...
OK
API> grant,c,l,%AS4SuperUser,AccessPermit,,7
...
OK
API> save,c,l
...
OK
API> commit,c
...
OK

Adding of an new accessor using the alias %ReaderRestrictAccess in PST:

API> begintran,c
...
OK
API> retrieve,c,dm_acl where object_name='MY_ACL_TEMPLATE'
...
45xxxxxxx951
API> grant,c,l,%ReaderRestrictAccess,AccessRestriction,,5
...
OK
API> save,c,l
...
OK
API> commit,c
...
OK

 
Some explanations:

  • The documents archived will have a READONLY restriction for all database users. This READONLY restriction feature is possible due to Trusted Content Services independently of use of ACL, PST and AS :
    Documentum : ACL, Permit Type, Trusted Content Services, TCS, Access Restriction.
  • A reminder of “dm_acl.r_permit_type” attribute:
    • Defines the kind of entry, some basic valid values: AccessPermit and ExtendedPermit
    • With a Trusted Content Services license, the following values are also valid entries: ApplicationPermit, AccessRestriction, ExtendedRestriction, ApplicationRestriction, RequiredGroup and RequiredGroupSet
    • Constant definitions for types of permits exist also in DFC interface com.documentum.fc.client.IDfPermitType for (IDfPermit):
      public static final int ACCESS_PERMIT = 0;
      public static final int EXTENDED_PERMIT = 1;
      public static final int APPLICATION_PERMIT = 2;
      public static final int ACCESS_RESTRICTION = 3;
      public static final int EXTENDED_RESTRICTION = 4;
      public static final int APPLICATION_RESTRICTION = 5;
      public static final int REQUIRED_GROUP = 6;
      public static final int REQUIRED_GROUP_SET = 7;
      
  • dm_world and dm_owner have an access PERMIT (r_permit_type=0 : IDfPermitType.ACCESS_PERMIT) with READ permission (r_accessor_permit=3 : IDfACL.DF_PERMIT_READ).
  • The alias %AS4MyGroup has an access PERMIT (r_permit_type=0 : IDfPermitType.ACCESS_PERMIT) with WRITE permission (r_accessor_permit=6 : IDfACL.DF_PERMIT_WRITE).
  • The alias %AS4SuperUser has an access PERMIT (r_permit_type=0 : IDfPermitType.ACCESS_PERMIT) with DELETE permission (r_accessor_permit=7 : IDfACL.DF_PERMIT_DELETE).
  • The alias %ReaderRestrictAccess has an access RESTRICTED (r_permit_type=3 : IDfPermitType.ACCESS_RESTRICTION) with VERSION permission (r_accessor_permit=5 : IDfACL.DF_PERMIT_VERSION).
    • The exclusive VERSION permission is assigned “%ReaderRestrictAccess=5” (IDfACL.DF_PERMIT_VERSION) to restrict users to RELATE “4” permission (IDfACL.DF_PERMIT_RELATE)
    • The permission type “3” corresponds to “IDfPermitType.ACCESS_RESTRICTION” available with the Trusted Content Services license.
    • The permission type IDfPermitType.ACCESS_RESTRICTION imposes that the permission to be EXCLUSIVE. For example, the “VERSION permission (r_accessor_permit=5)” => ALLOWING => “RELATE permission (r_accessor_permit=4)”.
  • No extended permission
  •  
    Dump of created Template ACL or Permission Set Template:

    API> dump,c,45xxxxxxx951
    ...
    USER ATTRIBUTES
      object_name                : MY_ACL_TEMPLATE
      description                : Desc 4 MY_ACL_TEMPLATE
      owner_name                 : MYDOCBASEDEV
      globally_managed           : F
      acl_class                  : 1
    
    SYSTEM ATTRIBUTES
      r_object_id                : 45xxxxxxx951
      r_is_internal              : F
      r_accessor_name         [0]: dm_world
                              [1]: dm_owner
                              [2]: %AS4MyGroup
                              [3]: %AS4SuperUser
                              [4]: %ReaderRestrictAccess
      r_accessor_permit       [0]: 3
                              [1]: 3
                              [2]: 6
                              [3]: 7
                              [4]: 5
      r_accessor_xpermit      [0]: 0
                              [1]: 0
                              [2]: 0
                              [3]: 0
                              [4]: 0
      r_is_group              [0]: F
                              [1]: F
                              [2]: F
                              [3]: F
                              [4]: F
      r_has_events               : F
      r_permit_type           [0]: 0
                              [1]: 0
                              [2]: 0
                              [3]: 0
                              [4]: 3
      r_application_permit    [0]: 
                              [1]: 
                              [2]: 
                              [3]: 
                              [4]: 
      r_template_id              : 0000000000000000
      r_alias_set_id             : 0000000000000000
    
    APPLICATION ATTRIBUTES
    
    INTERNAL ATTRIBUTES
      i_has_required_groups      : F
      i_has_required_group_set   : F
      i_has_access_restrictions  : T
      i_partition                : 0
      i_is_replica               : F
      i_vstamp                   : 1
    

     


     
    Creation of Alias Set (dm_alias_set)
     

    Assuming that we have the following 2 groups:

    • my_grp_no_body is a group containing no user
    • my_grp_all_users is a group containing all users

    .. we are creating 2 AliasSets MY_ALIASSET and MY_ALIASSET_ARCHIVED using the above 2 groups:

    • MY_ALIASSET/ReaderRestrictAccess = my_grp_no_body
    • MY_ALIASSET_ARCHIVED/ReaderRestrictAccess = my_grp_all_users
    API> begintran,c
    ...
    OK
    
    
    API> create,c,dm_alias_set
    ...
    66xxxxxd41
    API> set,c,l,object_name
    MY_ALIASSET
    ...
    OK
    API> set,c,l,owner_name
    dm_dbo
    ...
    OK
    API> set,c,l,object_description
    Desc 4 MY_ALIASSET
    ...
    OK
    API> append,c,l,alias_name
    AS4MyGroup
    ...
    OK
    API> append,c,l,alias_value
    my_grp_all_users
    ...
    OK
    API> append,c,l,alias_category
    2
    ...
    OK
    API> append,c,l,alias_usr_category
    -1
    ...
    OK
    API> append,c,l,alias_description
    Entry for a group alias (my_grp_all_users)
    ...
    OK
    API> append,c,l,alias_name
    AS4SuperUser
    ...
    OK
    API> append,c,l,alias_value
    myuser001
    ...
    OK
    API> append,c,l,alias_category
    1
    ...
    OK
    API> append,c,l,alias_usr_category
    -1
    ...
    OK
    API> append,c,l,alias_description
    Entry for a user alias (myuser001)
    ...
    OK
    API> append,c,l,alias_name
    ReaderRestrictAccess
    ...
    OK
    API> append,c,l,alias_value
    my_grp_no_body
    ...
    OK
    API> append,c,l,alias_category
    1
    ...
    OK
    API> append,c,l,alias_usr_category
    -1
    ...
    OK
    API> append,c,l,alias_description
    Entry for a user alias (my_grp_no_body)
    ...
    OK
    API> save,c,l
    ...
    OK
    
    
    API> create,c,dm_alias_set
    ...
    66xxxxxxd42
    API> set,c,l,object_name
    MY_ALIASSET_ARCHIVED
    ...
    OK
    API> set,c,l,owner_name
    dm_dbo
    ...
    OK
    API> set,c,l,object_description
    Desc 4 MY_ALIASSET_ARCHIVED
    ...
    OK
    API> append,c,l,alias_name
    AS4MyGroup
    ...
    OK
    API> append,c,l,alias_value
    my_grp_all_users
    ...
    OK
    API> append,c,l,alias_category
    2
    ...
    OK
    API> append,c,l,alias_usr_category
    -1
    ...
    OK
    API> append,c,l,alias_description
    Entry for a group alias (my_grp_all_users)
    ...
    OK
    API> append,c,l,alias_name
    AS4SuperUser
    ...
    OK
    API> append,c,l,alias_value
    myuser001
    ...
    OK
    API> append,c,l,alias_category
    1
    ...
    OK
    API> append,c,l,alias_usr_category
    -1
    ...
    OK
    API> append,c,l,alias_description
    Entry for a user alias (myuser001)
    ...
    OK
    API> append,c,l,alias_name
    ReaderRestrictAccess
    ...
    OK
    API> append,c,l,alias_value
    my_grp_all_users
    ...
    OK
    API> append,c,l,alias_category
    1
    ...
    OK
    API> append,c,l,alias_usr_category
    -1
    ...
    OK
    API> append,c,l,alias_description
    Entry for a user alias (my_grp_all_users)
    ...
    OK
    API> save,c,l
    ...
    OK
    
    
    API> commit,c
    ...
    OK
    

     
    Dump of created Alias Sets MY_ALIASSET:

    API> dump,c,66xxxxxd41
    ...
    USER ATTRIBUTES
      owner_name                 : dm_dbo
      object_name                : MY_ALIASSET
      object_description         : Desc 4 MY_ALIASSET
      alias_name              [0]: AS4MyGroup
                              [1]: AS4SuperUser
                              [2]: ReaderRestrictAccess
      alias_value             [0]: my_grp_all_users
                              [1]: myuser001
                              [2]: my_grp_no_body
      alias_category          [0]: 2
                              [1]: 1
                              [2]: 1
      alias_usr_category      [0]: -1
                              [1]: -1
                              [2]: -1
      alias_description       [0]: Entry for a group alias (my_grp_all_users)
                              [1]: Entry for a user alias (myuser001)
                              [2]: Entry for a user alias (my_grp_no_body)
    
    SYSTEM ATTRIBUTES
      r_object_id                : 66xxxxxd41
    
    APPLICATION ATTRIBUTES
    
    INTERNAL ATTRIBUTES
      i_is_replica               : F
      i_vstamp                   : 0
    

     
    Dump of created Alias Sets MY_ALIASSET_ARCHIVED:

    API> dump,c,66xxxxxxd42
    ...
    USER ATTRIBUTES
      owner_name                 : dm_dbo
      object_name                : MY_ALIASSET_ARCHIVED
      object_description         : Desc 4 MY_ALIASSET_ARCHIVED
      alias_name              [0]: AS4MyGroup
                              [1]: AS4SuperUser
                              [2]: ReaderRestrictAccess
      alias_value             [0]: my_grp_all_users
                              [1]: myuser001
                              [2]: my_grp_all_users
      alias_category          [0]: 2
                              [1]: 1
                              [2]: 1
      alias_usr_category      [0]: -1
                              [1]: -1
                              [2]: -1
      alias_description       [0]: Entry for a group alias (my_grp_all_users)
                              [1]: Entry for a user alias (myuser001)
                              [2]: Entry for a user alias (my_grp_all_users)
    
    SYSTEM ATTRIBUTES
      r_object_id                : 66xxxxxxd42
    
    APPLICATION ATTRIBUTES
    
    INTERNAL ATTRIBUTES
      i_is_replica               : F
      i_vstamp                   : 0
    

     


     
    Creation of instances of Template ACL (acl_class=2)
     
    An instance of an ACL template is created when an AliasSet and PST are associated to a document. It is not possible to create directly manually an instance of PST.
    The error DM_ACL_E_CANT_CHANGE_INSTANCE occurs if the user tries to modify a instance of PST (acl_class=2). To modify the instances of PST, it is necessary to modify the PST or PST/AliasSet associated to theses instances.

     
    We are creating 2 documents (dm_document) using the previous PST and AS :

    • a document named Test DOC HUO WITH AS AND PST not ARCHIVED associated to PST MY_ACL_TEMPLATE and AS MY_ALIASSET in order to generate/use an ACL MY_ACL having r_accessor_name (ReaderRestrictAccess) = my_grp_no_body (permission exclusive VERSION “5”)
       
    • a document Test DOC HUO WITH AS AND PST ARCHIVED associated to PST MY_ACL_TEMPLATE and AS MY_ALIASSET_ARCHIVED in order to generate/use an ACL MY_ACL_ARCHIVED having r_accessor_name (ReaderRestrictAccess) = my_grp_all_users (permission exclusive VERSION “5”)

    Actually, the association between document, AliasSet and Templace ACL generates an instance of Templace ACL (acl_class=2) with name like dm_450xxxxxxx94_xxxxd3e. This instance is created only if its is not already exist.
     
    The unique difference between MY_ACL and MY_ACL_ARCHIVED will be the read-only right of people having already access to documents. By using AccessRestriction permit type with basic permission VERSION (5):

    • with the MY_ACL, the system dosen’t restrict explicitly users to access and modify the document because the my_grp_no_body group contains no user,
    • with the MY_ACL_ARCHIVED, the system restricts all users to only BROWSE, READ, and RELATE the document (not “VERSION”!!!!) EVENT IF these users belong to groups which have more permissive rights.

     

    API> begintran,c
    ...
    OK
    
    
    API> create,c,dm_document
    ...
    09xxxxxxxxx88
    API> set,c,l,object_name
    Test DOC HUO WITH AS AND PST not ARCHIVED
    ...
    OK
    API> set,c,l,a_content_type
    pdf
    ...
    OK
    API> setfile,c,l,C:\temp\test.pdf
    ...
    OK
    API> link,c,l,'/Temp'
    ...
    OK
    API> set,c,l,r_alias_set_id
    66xxxxxd41
    ...
    OK
    API> set,c,l,acl_domain
    dm_dbo
    ...
    OK
    API> set,c,l,acl_name
    MY_ACL_TEMPLATE
    ...
    OK
    API> save,c,l
    ...
    OK
    
    
    API> create,c,dm_document
    ...
    09xxxxxxxxxx89
    API> set,c,l,object_name
    Test DOC HUO WITH AS AND PST ARCHIVED
    ...
    OK
    API> set,c,l,a_content_type
    pdf
    ...
    OK
    API> setfile,c,l,C:\temp\test.pdf
    ...
    OK
    API> link,c,l,'/Temp'
    ...
    OK
    API> set,c,l,r_alias_set_id
    66xxxxxxd42
    ...
    OK
    API> set,c,l,acl_domain
    dm_dbo
    ...
    OK
    API> set,c,l,acl_name
    MY_ACL_TEMPLATE
    ...
    OK
    API> save,c,l
    ...
    OK
    
    
    API> commit,c
    ...
    OK
    

     
    Dump of created document Test DOC HUO WITH AS AND PST not ARCHIVED:

    API> dump,c,09xxxxxxxxx88
    ...
    USER ATTRIBUTES
      object_name                : Test DOC HUO WITH AS AND PST not ARCHIVED
      acl_domain                 : MYDOCBASEDEV
      acl_name                   : dm_45xxxxxxx951_xxxxxd41
    
    SYSTEM ATTRIBUTES
      r_object_id                : 09xxxxxxxxx88
      r_object_type              : dm_document
    

     

    Dump of created document Test DOC HUO WITH AS AND PST ARCHIVED:

    API> dump,c,09xxxxxxxxxx89
    ...
    USER ATTRIBUTES
      object_name                : Test DOC HUO WITH AS AND PST ARCHIVED
      acl_domain                 : MYDOCBASEDEV
      acl_name                   : dm_45xxxxxxx9511_xxxxxd42
    
    SYSTEM ATTRIBUTES
      r_object_id                : 09xxxxxxxxxx89
      r_object_type              : dm_document
    

     
     
    So, the instances of PST used for these new documents are:
    The document Test DOC HUO WITH AS AND PST not ARCHIVED uses the instance of Template ACL (acl_class=2) dm_45xxxxxxx951_xxxxxd41:

    DQL> select r_object_id from dm_acl where object_name IN('dm_45xxxxxxx951_xxxxxd41','dm_45xxxxxxx9511_xxxxxd42')
    ...
    r_object_id
    45xxxxxx952
    45xxxxxx953
    
    API> dump,c,45xxxxxx952
    ...
    USER ATTRIBUTES
      object_name                : dm_45xxxxxxx951_xxxxxd41
      description                : dm_45xxxxxxx951_xxxxxd41
      owner_name                 : MYDOCBASEDEV
      globally_managed           : F
      acl_class                  : 2
    
    SYSTEM ATTRIBUTES
      r_object_id                : 45xxxxxx952
      r_is_internal              : T
      r_accessor_name         [0]: dm_world
                              [1]: dm_owner
                              [2]: my_grp_all_users
                              [3]: myuser001
                              [4]: my_grp_no_body
      r_accessor_permit       [0]: 3
                              [1]: 3
                              [2]: 6
                              [3]: 7
                              [4]: 5
      r_accessor_xpermit      [0]: 0
                              [1]: 0
                              [2]: 0
                              [3]: 0
                              [4]: 0
      r_is_group              [0]: F
                              [1]: F
                              [2]: T
                              [3]: F
                              [4]: T
      r_has_events               : F
      r_permit_type           [0]: 0
                              [1]: 0
                              [2]: 0
                              [3]: 0
                              [4]: 3
      r_application_permit    [0]: 
                              [1]: 
                              [2]: 
                              [3]: 
                              [4]: 
      r_template_id              : 45xxxxxxx951
      r_alias_set_id             : 66xxxxxd41
    
    APPLICATION ATTRIBUTES
    
    INTERNAL ATTRIBUTES
      i_has_required_groups      : F
      i_has_required_group_set   : F
      i_has_access_restrictions  : T
      i_partition                : 0
      i_is_replica               : F
      i_vstamp                   : 1
    

     
    The document Test DOC HUO WITH AS AND PST ARCHIVED uses the instance of Template ACL (acl_class=2) dm_45xxxxxxx9511_xxxxxd42:

    API> dump,c,45xxxxxx953
    ...
    USER ATTRIBUTES
      object_name                : dm_45xxxxxxx9511_xxxxxd42
      description                : dm_45xxxxxxx9511_xxxxxd42
      owner_name                 : MYDOCBASEDEV
      globally_managed           : F
      acl_class                  : 2
    
    SYSTEM ATTRIBUTES
      r_object_id                : 45xxxxxx953
      r_is_internal              : T
      r_accessor_name         [0]: dm_world
                              [1]: dm_owner
                              [2]: my_grp_all_users
                              [3]: myuser001
                              [4]: my_grp_all_users
      r_accessor_permit       [0]: 3
                              [1]: 3
                              [2]: 6
                              [3]: 7
                              [4]: 5
      r_accessor_xpermit      [0]: 0
                              [1]: 0
                              [2]: 0
                              [3]: 0
                              [4]: 0
      r_is_group              [0]: F
                              [1]: F
                              [2]: T
                              [3]: F
                              [4]: T
      r_has_events               : F
      r_permit_type           [0]: 0
                              [1]: 0
                              [2]: 0
                              [3]: 0
                              [4]: 3
      r_application_permit    [0]: 
                              [1]: 
                              [2]: 
                              [3]: 
                              [4]: 
      r_template_id              : 45xxxxxxx951
      r_alias_set_id             : 66xxxxxxd42
    
    APPLICATION ATTRIBUTES
    
    INTERNAL ATTRIBUTES
      i_has_required_groups      : F
      i_has_required_group_set   : F
      i_has_access_restrictions  : T
      i_partition                : 0
      i_is_replica               : F
      i_vstamp                   : 1
    

    Important note: any modification of PST and/or AS will impact all instances of PST (ACL) associated with these elements..

    Best regards,

    Huseyin OZVEREN

    This content is password protected. To view it please enter your password below:

    Hello,

    I would like expose here some explanations concerning the Extended Permissions or Xpermit or r_accessor_xpermit of ACL.
     
    For example, below the détails of an dm_ACL:

    r_accessor_name         [0]: dm_world 	[1]: dm_owner	[2]: grp_adm	[3]: docu
    r_accessor_permit       [0]: 3		[1]: 1		[2]: 6		[3]: 7
    r_accessor_xpermit      [0]: 1048576	[1]: 3		[2]: 0		[3]: 0
    r_is_group              [0]: F		[1]: F		[2]: T		[3]: T
    r_permit_type           [0]: 0		[1]: 0		[2]: 0		[3]: 0
    r_application_permit    [0]: 		[1]: 		[2]: 		[3]: 
    

     
    Reminder:

    • dm_world = This is an alias for all of the users in a docbase.
    • dm_owner = This is an alias for the current owner of the document.
    • ACL is a regular ACL (acl_class=0 ; case of ‘dm_45%’), a template (acl_class=1) or an instance of a template (acl_class= 2). The default is zero.
    • ACLs owned by users other than the repository owner are called user ACLs. User ACLs can be public (acl_class=3) or private (acl_class=0).
    • Private ACLs can only be used by the ACL owner. User ACLs are managed by the object owner (repository owner) or superusers.


     

    Presentation of Extended permissions
    Extended permissions are a feature only available in version 4i and later. They greatly enhance the security capabilities of the server by letting certain users access admin functions on a per-document basis. For example, in pre-4i docbases, only two types of users could change the permissions on a document: the owner of that document and a superuser. In 4i, you can use the extended permissions to allow certain normal users to change the permissions.
    For example, an ACL for the Marketing department might allow the marketing_managers group to change the permissions on the document.

     
    The extended permissions are described below:

    • execute_proc: Allows the user to execute the procedure (if it is a procedure)
    • change_location: Allows the user to change the location of the document.
    • change_state: Allows the user to change the state of the document using the document lifecycle.
    • change_permit: Allows the user to change the object’s permissions.
    • change_owner: Allows the user to change the owner of the object.
    • delete_object: Delete permission. Delete Object extended permission does not grant Browse, Read, Relate, Version, or Write permission.
    • change_folder_links: Allows the user to create a document in a folder without having the write right on this folder.

     
    More the Extended permissions are stored in the r_accessor_xpermit attribute of an dm_ACL. The value of this attribute is an integer that has been converted from a 4-bytes binary number (or 32-bits binary number) to a decimal number. Each permission is governed by the value of a bit in a particular place: 1 : signifies the permission is granted, 0 : signifies it is not.
    Warning : For some reason, execute_proc and change_location are reversed, “1” signifies the permission is not granted and “0” signifies it is granted.
     
    The bit locations of the extended permissions are defined like this (from right):

    • bit 01 : execute_proc
    • bit 02 : change_location
    • bit 17 : change_state
    • bit 18 : change_permissions
    • bit 19 : change_owner
    • bit 20 : extended_delete
    • bit 21 : change_folder_links

     
    For conversion decimal<->binary, use the site http://www.binaryhexconverter.com/decimal-to-binary-converter.
     
     
    Examples
    dm_acl.r_accessor_xpermit=0:

    0 => 00000000 -> 32 bits : 00000000000000000000000000000000
    	- bit 01 : execute_proc ("0" warning : reverse for this permission)
    	- bit 02 : change_location ("0" warning : reverse for this permission)
    

     
    dm_acl.r_accessor_xpermit=3:

    3 => 00000011 -> 32 bits : 00000000000000000000000000000011
    	- none
    

     
    dm_acl.r_accessor_xpermit=1048576:

    1048576 => 100000000000000000000 -> 32 bits : 00000000000100000000000000000000
    	- bit 01 : execute_proc ("0" warning : reverse for this permission)
    	- bit 02 : change_location ("0" warning : reverse for this permission)
    	- bit 21 : change_folder_links ("1")
    

     
    dm_acl.r_accessor_xpermit=1048579:

    1048579 => 100000000000000000011 -> 32 bits : 00000000000100000000000000000011
    	- bit 21 : change_folder_links ("1")
    

     
     

    That’s all!!!

    Huseyin OZVEREN

    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

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


     
    User permissions and extended permissions

     


     

    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

    Page 1 of 48:1 2 3 4 »Last »
    bottom-img
    Copyright ® 2012 Huseyin Ozveren. No reproduction, even partial, can be used from this site and all its contents including text, documents, images, etc.. without the express permission of the author.