Re: Identity equivalence in draft-ietf-ldapext-acl-model-04.txt

[Jim Sermersheim <JIMSE@novell.com>]

If I read it correctly, David C. brought up the notion of splitting the dnType "group" into "group" and "subtree". "subtree" would address this idea of "everyone" below this point has security equivalence.

Jim

>>> "Brian Jarvis" <BJARVIS@novell.com> 10/19/99 6:05:11 PM >>>
Regarding grant/deny precedence, the consensus here seems to be that all else being equal (see my previous posting) deny should override grant.  Nevertheless, Subbu (below) is right in asserting that public directories and private directories would prefer to use different paradigms.  A public directory grants everything to everyone, except as given in the (mostly deny) ACIs.  A private directory denies everything from everyone, except as given in the (mostly grant) ACIs.

The problem is that with our current model we have no way to express "grant to everyone" nor "deny from everyone".  If we could express "everyone" in an ACI, both the public and private paradigms could be easily supported using only ACIs.  Everyone in this case is a dn-type--it names the subject of the aci.  Adding a new dn-type is an obvious, but limited solution.

Consider the following:

dn: o=IMC, c=US
o: IMC
objectclass: top
objectclass: organization
aci: 1.2.3.4:#subtree#grant;r,w,s,c;[all];#access-id#o=IMC, c=US
aci: 1.2.3.4:#subtree#grant;a,d,m,u,g,s,e;[entry];#access-id#o=IMC, c=US

My intent above, is to grant all rights, to all objects in the o=IMC, c=US subtree, in other words, everyone.  The advantage this has over a new dn-type "everyone" is that we can specify any arbitrary subtree.  My industry experience shows that users and administrators consider this an extremely useful and valuable way to grant rights.

An object should be given all the rights given to the objects that comprise his DN.  In other words, an object has "identity equivalence" to all the objects in his lineage.  For example,

cn=BJarvis, ou=Software, ou=Engineering, o=IMC, c=US is identity equivalent to
    ou=Software, ou=Engineering, o=IMC, c=US
    ou=Engineering, o=IMC, c=US 
    ouo=IMC, c=US 
    c=US 

Since BJarvis is identity equivalent to each of these objects, any rights given to them are also given to him.

Some will undoubtedly consider this a form of inheritance.  It is.  But I want to make it clear that the inheritance in "scope" is related to the target object(s) while identity equivalence relates to the subject object(s).  It will be easy to confuse these two.

Though it does not fit the inheritance view, it is useful to note that every object named using access-id is identity equivalent to the special dn, "public".

--the walrus
a.k.a. Brian Jarvis
bjarvis@novell.com 

>>> "Subbu K. K." <KKSUBRAMANIAM@novell.com> 10/15/1999 04:02:19 >>>
There are fair reasons for either possibility and this would be specific to an instance of a directory. In public directories, deny takes precedence over grant ('grant everyone except x....) while in private or secure directories grant takes precedence ("restrict access to all except for ..") over deny list.

The suggestion to have it as an attribute in Root DSE ("accessPolicy = Public | Restricted") is a good one, but should this be restricted to the Root DSE only. Why not have it at sub-tree level with the default flowing down the tree from the Root DSE? This would facilitate regional adminstration of large multinational trees.

Subbu K. K.

>>> "David Ward" <DSWARD@novell.com> 10/13/99 04:40AM >>>
Is there a precedence for the grant / deny actions?  If there are two identical ACI values except for the action, which one takes precedence?  An example would be:

             aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ, c=US
             aci: 1.2.3.4#subtree#deny;r;attribute1#group#cn=Dept XYZ, c=US

Is this server implementation dependent?  I don't think it should be.  However, if it must be for some reason I haven't considered, a server should at least advertise its precedence.  This information could be put in the Root DSE object.  Without this information, different ldap implemenations may not be able to interoperate and maintain desired access control behaviors.  


David