Subject: Re: Suggestion for scope of ACI

From: Rob Byrne - Sun Microsystems <[email-masked]>
Date: Tue, 18 Jul 2000 12:35:17 +0200

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 [email-masked]
> 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
>
> ***************************************************

---

From: "David Chadwick" <[email-masked]>
Date: Tue, 18 Jul 2000 18:21:07 +0100

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 
<[email-masked]>
Organization:   	Sun Microsystems
To:             	[email-masked]
Copies to:      	[email-masked], ietf-
[email-masked]
Subject:        	Re: Suggestion for scope of ACI
Forwarded by:   	[email-masked]

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