[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Typos, bugs, clarifications for ACI draft (ii, vii)

From:           	Ellen Stokes <stokes@austin.ibm.com> 
Subject:       
	Re: Typos, bugs, clarifications for ACI draft (ii, vii) 
Forwarded by:
  	ietf-ldapext@netscape.com

> David,
> 
> Much of the power / ease of use provided in the access
> control model is by granting large numbers of people a
> given set of permission based on a single ACI. 'public'
> is a good example of this. The second thing that is very
> powerful is the ability to give someone permission to
> their own entry by placing a single ldapACI value using
> 'this' in the tree.

Absolutely agree

> 
> So, when we look at the subject precedence order we must
> include 'this' and 'public' and define where they fit.
> We've stated that more specific takes precedence over less
> specific, processing stops when ldapaci values for a given
> specificity level. 

this is where you have an omission in your processing model. It 
should read
processing stops when an ldapaci value for a sought permission is
found in the highest specificity level. You seem to stop when ANY
permission is hit, regardless of whether it is the correct one or not.

Thus specificity should be 

ipAddress>authzID>role>this>group>subtree>public. 

I will show you how this works in the examples below


>'This' applies to a single DN at a time
> ( that which matches the entry DN ) and therefore, fits in
> well with authzID which also applies to a single logical DN.
> Different from a group which is many member DNs )
> 
> 
> In order to take full advantage of the pseudo-DNs they need
> to apply to multiple levels. An example using 'this' :
> ldapACI: group RegDeptMembers has rs perms to telephone and
>               rs to secureDocs.
>              THIS has w perm telephone
>              authzID guest has rs to telephone
> 
> Where we have an organization, and this ACI is on the dept
> node, and each person in the dept is a child of the dept node.
> We want all dept members to be able to read each other's
> telephone numbers, but only update their own. We also have a
> visiting guest for the month who is not a dept member but
> should have access to telephone numbers.
> 
> If 'this' is the same precedence as authz-ID;
> User guest would come in a receive permission to read
> everything and have write access to his own entry.
> However, the rest of the dept would be able to read
> everything on each other's entries, but processing
> for their own entry would not be as desired. They would
> receive 'w' for telephone by virtue of 'this' but
> processing would stop because 'this' is a higher precedence
> then group. So, they could change their phone number,
> but not read it.
> 

This is where the bug in your processing model hits you. As a group
member is authorised, and you move down the precedence list you hit
"this" first which gives you w access. But it says nothing about r
access  so if the operation is a read or search, you must move down
the precedence list until you come to group, and then you get your r
access. Then you stop.

> If 'this' is the same precedence as group, then the
> opposite happens. All dept members can read everyone's
> phone number and update their own. However, the guest
> can not update his phone number. Processing would stop
> after finding that he matched on the authz level for
> guest, and he would not receive the permission to update
> his own phone number, since that is granted by 'this'
> which is at the group level.
> 

Same bug again. If Guest is doing a read, then processing stops on
authz as this covers read, but if he is doing a write access authz has
nothing to say about this, so you go to the next level "this" which
says he can write. Then you stop processing.

> So, really, in order to really use the power that comes
> with the concept of 'this' it really needs to be combined
> with either groups or authZids and that by itself, it
> should not stop processing due to precedence.
> 

this should stop processing if it contains the relevant permission,
otherwise it should not stop it. The other problem you have is that
you are treating the omission of some permission as a deny i.e. I
grant r, so I am automatically denying everything else. True, but this
deny is at the lowest precedence of all, since it is implicit.
Explicit grants must always override implicit denies, no matter what
the precedence level of the grant.

David


> The same type of thing is true with the 'public' pseudoDN.
> 
> ellen
> 
> 
> 
> At 10:59 PM 7/17/00 +0100, David Chadwick wrote:
> >Ellen
> >
> >could you clarify a few points for me please
> >
> >ii) 4.3 precedence of subjects has public in the bottom 2 levels
> >and this in the middle two levels. Can you explain this to me
> >please.
> >
> >vii) section 4.3, step 2. what does 'this may also be combined with
> >group to use the power of "this"' mean. Sorry to be dumb.
> >
> >
> >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
> >
> >***************************************************
> 
> 


------- End of forwarded message -------
***************************************************

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

***************************************************