[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Suggestion for scope of ACI
Date forwarded: Tue, 18 Jul 2000 03:36:01 -0700 (PDT)
Date sent: Tue, 18 Jul 2000 12:35:17 +0200
From: Rob Byrne - Sun Microsystems
<Robert.Byrne@france.Sun.COM>
Organization: Sun Microsystems
To: d.w.chadwick@salford.ac.uk
Copies to: ietf-ldapext-acm@OpenLDAP.org, ietf-
ldapext@netscape.com
Subject: Re: Suggestion for scope of ACI
Forwarded by: ietf-ldapext@netscape.com
> David Chadwick wrote:
>
> > Ellen and co.
> >
> > I have a suggestion to make for the scope of ldapACI attributes.
> >
> > Remove it, and replace it with 2 attribute types: EntryACI and
> > SubtreeACI. This simplifies the syntax of the attribute values by
> > removing the first element, but more importantly, it allows you to
> > have separation of responsibilities. Because we do not have
> > attribute value level ACI, then we currently have no way of allowing
> > different people to administer entry aci and subtree aci, since they
> > are attribute values in the same attribute. But by having two
> > attribute types we can can give permissions to different people to
> > adminster the different tattribute types.
> >
> > The functionality remains exactly the same as now, and both
> > attributes will have the same syntax, but different semantics will
> > be applied to them, one having the existing meaning of entry scope,
> > the other the existing meaning of subentry scope.
>
> I can see that gives more granularity but could you motivate the need
> for this ?
Sure.
Firstly it is in line with existing LDAP practices, for example
language codes did not add tags to values (even though this was
the original proposal like the X.500 model of contexts) but rather
they qualify the attribute type to say what language the value is in.
Secondly it simplifies the syntax of the aci attribute by removing an
element.
Thirdly it allows different administrators/users to be have different
access rights to subentry and entry aci (you cant do this with the
current scheme as value level permissions dont exist)
Fourthly it means that partial delegation no longer needs to be
supported
Fifthly I think it simplifies the model, as entry aci now apply to the
entry only and to one level down for creation - this will simplify the
text when describing the various permissions. Subtree aci will then
apply only to subtrees, and this will give people permission to
create entries to any arbitrary depth in the tree (not just to children).
This actually makes the model more powerful but again simplifies
the description of the permissions, since we do not need to mix up
the different cases of entry and subtree aci as in the current text.
Sixth, entry aci can be used to protect subtree aci in the entry in
which the latter exist
Seventh, subtree aci can be used to protect entry aci in a whole
subtree.
Eight, if you wanted you could move subtree aci to subentries,
although this is not essential to the model. Remember that
subentries as originally conceived were conceptually part of the
admin points, and were a way of grouping attributes together - just
like the new model of families of entries. It is still helpful sometimes
to think of subentries as not whole entries but as part of their
superior entry.
Is that enough for now?
> What about other components of the aci, should they be
> exposed too ?
I dont think so. I see the remaining components as a tuple that stick
together, whereas subtree/entry was a difference in semantics that
applied to the remaining components.
> >
> > A related Question. Is there a bug in the current specification
> > (either description or semantics). Consider this, I set a subentry
> > scope on ldapACI, I give add permission with a subject of "this",
> > meaning that I want to allow people or applications to create >
>their
> > own entries. However, with the text as it now reads it seems to
> > allow clients to create subordinate entries beneath their own >
> entry,
> > as the definition of add reads "add an entry below this entry". Is
> > this a correct interpretation.
>
> I would interpret it the latter way--that way it's consistent with the
> other operations (ie. the permission is granted to the entry defined
> by the bindDN (what if it's an authzID ?)). Seems like it's a
> choice--either it allows you to create your own entry (only
> interesting in the case where you bind to one server and it chains
> the
> add on to another ?) or it allows you to create entries under your
> own
> entry (only interesting in the case where your own entry already
> exists). We will at least clarify the meaning.
Now splitting up the aci into entry and subtree aci solves this
problem. Entry aci give permission to create entries subordinate to
this one. Subtree aci give permission to create any entry. So "this"
in the latter case would mean the DN of the entry being created,
whilst in the former case would mean the DN of the superior.
David
***************************************************
David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@salford.ac.uk
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J
***************************************************