[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Comments on aci-model-04
>
>
> Here's my suggested mapping:
>
> LDAP Op Right Req.
>
> Add entry add ( on parent entry )
OK
> Delete entry delete ( on entry )
OK
> Modify an attribute write ( on attribute )
> - includes adding, deleting or replacing values.
I would prefer add on attribute to add an attribute and delete on
attribute to delete an attribute. To replace you would need both
permissions. There may be times when you are happy for someone
to add information, but not remove it. Hence separate permissions
for adding and removing.
> Search ( ret. attributes only ) search on attribute
I think this should be read on attribute in order to return it
and search on attribute in order to use it in a filter (presence in a
filter without search permission will yield undefined)
> Search ( ret attr + values ) search and read on attribute
See above. We might also require read on the entry in order to
return the entry. Without this the entry would be omitted from the
Search results.
> Compare compare
Compare on attributes. Attributes without this permission would
return false.
David
>
> The search ( as David mentions ) is complex. There needs to be
> multiple levels of access control checks; on both the filter
> attributes and on the returned attributes. The filter check is
> crucial so that search operations such as userpassword=secret do not
> return data where the person does not have permission to know the
> value of userpassword.
>
> I suggest a two pass access control check on the search. The first
> pass is over the attributes listed in the search filter. The second
> pass is over the attributes that are to be returned to the client.
> Say objectA matches the search criteria. In the first pass, if the
> user does not have both read, and search on the attribute, the search
> can not return objectA's DN. If the user has permission to the filter,
> then evaluate the second pass and return the DN + whatever attributes
> are allowed based on whether the user is asking for the attribute
> only, or the attribute and value. ( ReadDN is in the next point )
>
> 4) ReadDN
>
> > 10) A possible missing right is readDN for an entry. This cannot be
> > fully
> covered by
> > read attribute rights, as the latter will only give rights to the
> > RDN,
> not the DN.
>
> The algorithm in #3 could have another step where the model evaluates
> whether the user has permission to know that the DN even exists. This
> would be the 'ReadDn' which David brought up. We could overload
> 'search' to apply to both the object and the attribute. In the case of
> the object, it would grant permission to read the DN. In order to
> reduce confusion, I think I would prefer a separate permission, even
> though our permission set is becoming somewhat lengthy.
>
>
> INet: djbyrne@us.ibm.com
> Lotus Notes : djbyrne@ibmus
> Phone: (512)838-1930 ( T/L 678 )
>
>
> "David Chadwick" <d.w.chadwick@salford.ac.uk> on 10/25/99 07:32:57 AM
>
> Please respond to d.w.chadwick@salford.ac.uk
>
> To: "Jim Sermersheim" <JIMSE@novell.com>, Debora
> Byrne/Austin/IBM@IBMUS,
> "Bob Blakley" <blakley@dascom.com>
> cc: stokes@austin.ibm.com, ietf-ldapext@netscape.com
> Subject: Re: Comments on aci-model-04
>
>
>
>
> >
> > However semantically they may be different. The underlying
> > implementation of the access decision function (which looks at ACL
> > entries and compares them against the subject's credentials to
> > render a yes/no decision about a particular access request) may
> > treat "group" entries differently from "role" entries. For example,
> > it might implement "union semantics" for groups but "intersection
> > semantics" for roles. Thus if an ACL contained 4 entries:
> >
>
> Bob
> This is another example of the lack of precise definition that worries
> me. There is too much vagary (vagueness?) in the acl model as it
> stands. I have already commented previously that nowhere is it stated
> which permissions are needed (i.e. which grants are needed) for which
> operations, in order for them to be successfully performed. Now we
> also seem to have a variable ACDF in which different implementations
> use the same ACI and derive different results. So without a fixed and
> clearly defined ACDF, and fixed permissions per operation, it seems
> pointless to talk about precedences of various ACIs (which we have
> been doing) , since by extension, each ACDF can determine its own
> precedence rules.
>
> Comments?
> 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
>
> ***************************************************
>
>
>
>
>
***************************************************
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
***************************************************