[Date Prev][Date Next] [Chronological] [Thread] [Top]

re: ACL Requirements document - version 01

Editorial comments:

Section 1.   Introduction

..."Currently LDAP does not define an access control model, but _one_ is needed ..." - insert the word "one" to give the phrase a subject.
..."The _agreement on_ requirements for access control..." - the requirements themselves aren't critical, as much as agreement on what
we'll all do about 'em.

Content comments:

S5 - do I read this to mean that reference to entries, or subjects, that are defined outside the administrative authority of the administrator SHOULD NOT be used?  I'd really like to allow subjects from outside the "local" namespace to be allowed in access control lists, through some mechanism, probably making use of some locally defined external reference, and other various relationship management mechanisms as innovation and the marketplace may provide.  Is S5 intended to discourage that?

U11 and S13 still seem to have conflicting objectives to me.  I know we've talked about this in regard to the Security Equivalence mechanism that NDS implements.  And, I think, the same can be said for group and role entries being used as subjects.  In particular, S13 says "Granting a privilege attribute to one subject MUST NOT implicitly grant the same privilege attribute to any other subject." - which would, it seems to me, be exactly what U11 mandates - "Administrator MUST be able to aggregate users (for example, by assigning them to groups or roles) to simplify administration."  The administrator grants a privilege to a role, and IMPLICITLY, all occupants of that role have granted to them the same privilege.  Are these two in conflict, or do I misunderstand the intent of one or the other?

U3 and U14 - in our experience, if you permit, in U14, that "it MUST also be possible to prohibit [user traversal of the DIT]", then it is devilishly hard to insure [U3], that "[i]t SHOULD NOT be possible via ACL administration to lock all users, including all administrators, out of the directory."  If you allow even traversal to be withheld from users, including (especially) administrators, you've effectively locked them out of the namespace, especially for "loggin into" the tree, where unauthenticated access to the user's entry may be required to perform something as simple as password verification (traversing to the user entry is required prior to user authentication).  We had to settle for supporting U14, and cautioning customers about the dangers of indiscriminant use of "inherited rights filters", which are the "deny" mechanism we support.

Thanks,
Ed

-------------------
Ed Reed, Technologist
Novell, Inc.
+1 801 861 3320