application defined permissions

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

As promised, attached are my proposed modifications to the ACL draft to 
support application defined permissions.

Bruce

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
              oidstring ; application defined 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) }

   ApplicationDefinedPermission ::= OID

   Permission ::= CHOICE {
     simple              SimplePermission,
     applicationdefined  ApplicationDefinedPermission
   }

   Permissions ::= SEQUENCE OF PERMISSION

Add a new section 4.2.2.1 Application Defined 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.

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.