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

[David Ward <DSWARD@novell.com>]

Comments for questions below:

1) I agree, remove 'level' option

2) I am not clear what you mean by "partial propagation".  Is this the case where servers don't support inheritance of aci information and will have to manually stamp each subordinate object with the aci value?  

4) I agree there needs to be a right that can block a user for evening knowing an object exists.  Earlier, I proposed this be done by bringing "Search" up to the entry level.  By doing this, you can effectively grant/deny the search operation which allows administrators the ability to block sections of the directory from being discovered.  If you want to maintain the ability to restrict attributes that can be used in the search filter, you could extend the "Compare" right to include testing for =, <, >, <=, >=.  If I don't have the right to compare an attribute's value, I can't include it in the search filter.  Or you could leave search at the attribute level and define a new entry level right.  Something like "browse" or "discover".  I don't like "readDN" because I don't think the meaning is obvious.  This right grants/denies the ability for people to search or browse the directory at a specified point.

5) It sounds like you want to mechanism to say "at this point in the hierarchy there are no rights".  Instead of coming up with a strange aci, "#subtree##group#public", or a valueless attribute ( which I strongly oppose ), how about a filter mechanism that could be used to stop or block the inheritance of rights down the hierarchy.  The filter could be another type of aci that is applied at the entry scope (block the inheritance of rights only at this object), or subtree scope (block the inheritance of rights from here down).


David Ward
dsward@novell.com

>>> <djbyrne@us.ibm.com> 10/19/99 5:30:55 PM >>>



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 )