application defined permission

[Bruce Greenblatt <bgreenblatt@directory-applications.com>]

After discussions on the list, and private discussions with Rob Byrne, here 
is a slightly modified proposal.  There was some discussion of using a 
separate attribute type name to hold application defined permissions.  I 
didn't put that in the modified proposal, but I'm OK with doing that, even 
though it doesn't seem to make much difference.  I also got several 
questions about why couldn't you just map application defined permissions 
into the existing permissions defined in the ACL model.  Just because you 
are giving a user the right to do something in an application does not 
necessarily mean that you want to give that user any rights to read or 
modify the entry in the directory that represents that application.

Bruce

==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com

Here's the modified BNF for permissions to include application defined permissions.

permission = "a" / ; add
              "d" / ; delete
              "e" / ; export
              "i" / ; import
              "n" / ; renameDN
              "b" / ; browseDN
              "t" / ; returnDN
              "r" / ; read
              "s" / ; search
              "w" / ; write (mod-add)
              "o" / ; obliterate (mod-del)
              "c" / ; compare
              "m" / ; make
              "xap:" oidstring ; application defined permission /
              "xep:" oidstring ; other extended operation permission

oidstring = digit ("." digit)*

digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

Here's the modified ASN.1 for permissions to include application defined permissions.


   SimplePermission ::= ENUMERATED {
      add        (0),
      delete     (1),
      export     (2),
      import     (3),
      renameDN   (4),
      browseDN   (5),
      returnDN   (6),
      read       (7),
      search     (8),
      write      (9),
      obliterate (10),
      compare    (11),
      make       (12) }

   ExtendedPermission ::= OID

   Permission ::= CHOICE {
     simple             [0] SimplePermission,
     applicationdefined [1] ExtendedPermission,
     extendedoperation  [2] ExtendedPermission
   }

   Permissions ::= SEQUENCE OF PERMISSION

Add a new section 4.2.2.1 Application Defined Permissions and Extended Operation Permissions

Application defined permissions are not intended to restrict the ability of any subject to perform LDAP operations against any LDAP entry.  Application defined permissions are defined to allow LDAP applications to store their access control information within LDAP entries.  For example, an electronic commerce application may make use of LDAP to store access control information about which customers have the ability to purchase various items that the electronic commerce application provides.  This application can create an OID to represent the "purchase" permission.  Then the application can create entries in the DIT representing the inventory items which are under access control.  Finally, the application can assign rights to purchase these items, by creating ACI attributes to the inventory item entries, using other DIT entries as the subject of the ACI attribute.  

Extended operation permissions are similar to Application Defined permissions, in that they define new permissions in the directory.  The difference is that extended operation permissions are defined to go hand in hand with extended operations defined as enhancements to the LDAP protocol.

Once the DIT has been set up, the GetEffectiveRights operation and controls can be used to determine which users have rights to purchase various inventory items.

Add a new example to section 8.3:

Example #7

 dn: o=XYZ, c=US
 ldapACI: subtree#grant:5.4.3.2.1#attr2
            #group:cn=G1,ou=ABC,o=XYZ,c=US
 
This is an example of an application defined permission.  Assume that the OID 5.4.3.2.1 (which is not a legal OID), defines the "purchase" permission.  This means that for the entire subtree rooted at "o = XYZ, c=us", all members of the named group have the permission to purchase all entries in the subtree.