[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Identity equivalence in draft-ietf-ldapext-acl-model-04.txt
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content='"MSHTML 4.72.3110.7"' name=GENERATOR>
</HEAD>
<BODY bgColor=#ffffff
style="FONT: 10pt Arial; MARGIN-LEFT: 2px; MARGIN-TOP: 2px">
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>Consider the following:</DIV>
<DIV> </DIV>
<DIV>dn: o=IMC, c=US<BR>o: IMC<BR>objectclass: top<BR>objectclass:
organization<BR>aci: 1.2.3.4:#subtree#grant;r,w,s,c;[all];#access-id#o=IMC,
c=US</DIV>
<DIV>aci: 1.2.3.4:#subtree#grant;a,d,m,u,g,s,e;[entry];#access-id#o=IMC,
c=US</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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,</DIV>
<DIV> </DIV>
<DIV>cn=BJarvis, ou=Software, ou=Engineering, o=IMC, c=US is identity equivalent
to</DIV>
<DIV> ou=Software, ou=Engineering, o=IMC, c=US</DIV>
<DIV> ou=Engineering, o=IMC, c=US </DIV>
<DIV> ouo=IMC, c=US </DIV>
<DIV> c=US </DIV>
<DIV> </DIV>
<DIV>Since BJarvis is identity equivalent to each of these objects, any rights
given to them are also given to him.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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".</DIV>
<DIV> </DIV>
<DIV>--the walrus</DIV>
<DIV>a.k.a. Brian Jarvis</DIV>
<DIV><A href="mailto:bjarvis@novell.com";>bjarvis@novell.com</A></DIV>
<DIV> </DIV>
<DIV>>>> "Subbu K. K." <KKSUBRAMANIAM@novell.com>
10/15/1999 04:02:19 >>><BR>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.<BR><BR>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.<BR><BR>Subbu K. K.<BR><BR>>>> "David
Ward" <DSWARD@novell.com> 10/13/99 04:40AM >>><BR>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:<BR><BR>
aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ,
c=US<BR>
aci: 1.2.3.4#subtree#deny;r;attribute1#group#cn=Dept XYZ, c=US<BR><BR>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.
<BR><BR><BR>David<BR><BR></DIV></BODY></HTML>
BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Brian Jarvis
TEL;WORK:801-861-3856
ORG:;NDS Administration
TEL;PREF;FAX:801-861-2292
EMAIL;WORK;PREF;NGW:BJARVIS@novell.com
N:Jarvis;Brian
TITLE:Engineer
ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F221;122 E 1700 S;Provo;UT;84606;USA
LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Brian Jarvis=0A=
PRV-F221=0A=
122 E 1700 S=0A=
Provo, UT 84606=0A=
USA
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Brian Jarvis=0A=
PRV-F221=0A=
122 E 1700 S=0A=
Provo, UT 84606
TEL;HOME:801-226-6636
TEL;PREF:801-861-3856
X-GWUSERID:BJARVIS
END:VCARD