David,
Here's a mapping I proposed in another note:
3) Mapping of LDAP rights to operations :
> 9) A major omission from the document is that nowhere could I find the
mapping
> from required rights to LDAP operations. This should be included for each
LDAP
> operation (even if in some cases it is simply that one right is needed
for a
> particular operation e.g. delete an entry). The complex one is obviously
the search
> operation. I suggest you need read rights for every attribute returned
and search
> rights for every attribute in the filter.
Here's my suggested mapping:
LDAP Op Right Req.
Add entry add ( on parent entry )
Delete entry delete ( on entry )
Modify an attribute write ( on attribute )
- includes adding, deleting or replacing values.
Search ( ret. attributes only ) search on attribute
Search ( ret attr + values ) search and read on attribute
Compare compare
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