draft-ietf-ldapext-acl-model-04.txt comments

[djbyrne@us.ibm.com]

After reviewing the comments sent by many, there are a few changes we are
planning to make to the acl draft. Please review the following and send your
thoughts / opinions.

1)  Removal of the 'level' option on scope.   Currently, the 'scope' in the BNF
includes "entry" "subtree" or level where level is a numerical string indicating
how deep the aci should apply.   LDAP really doesn't have any concept of
something going to a particular level beyond base, one, and subtree. Creating an
arbitrary level for aci attributes seems to be somewhat of a deviation which we
can due without for the time being.

2) Default of the scope option.  The behavior is not well defined in the case of
conflicting scope on different aci's of a single object.  For instance on
objectA, I have aci:... entry ... DN1 and aci: .... subtree....DN2  etc.   Not
all servers will allow partial aci propagation. We need to explicitly state the
expected behavior if aci propagation is all or nothing.   If the server chooses
not to implement partial propagation,  then, the server should default to
'entry' if both entry and subtree are specified.  ( An alternative to this is
that the server rejects the request as can not perform. This could lead to some
replication problems between unlike servers.  )

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.

5) Empty ACI values

There is a difference between having an aci with no values and having no aci
attribute on the object. In the first case, an aci exists on the entry, but does
not have any definitions for granting ( or denying ) permissions. In this case,
the default deny would say that no one has access to the object ( except perhaps
the policy owner or administrator ).  In the second case, where an aci does not
exist on the entry, the aci is instead inherited from somewhere up the directory
tree.   What is needed is a method to say 'no one has access'.

There are two possibilities; define a aci such as aci: 1.2.3.4
#subtree##group#public which essentially says no one has permission, or to allow
the aci attribute to exist, but not to contain any values. However, representing
this with simply a null value could be problematic since removing the last value
of an attribute in LDAP is supposed to remove the attribute from the object.


Debbie Byrne

INet: djbyrne@us.ibm.com
Lotus Notes : djbyrne@ibmus
Phone: (512)838-1930 ( T/L 678 )