[no subject]

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





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 )