Re: Suggestion for scope of ACI

[Rob Byrne - Sun Microsystems <Robert.Byrne@france.Sun.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  ?  What about other components of the aci, should they be exposed
too ?

One effect of moving this way would be to put the draft closer to being
able to put acis (of both kinds) into subentries.  The reason is that once
you put acis into subentries, you need some way to control access to the
subentries themselves, and this could be done with the entryACI.

>
>
> 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.

>
>
> 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
>
> ***************************************************