[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: please publish (draft-ietf-ldapext-acl-model-05.txt)
Ellen
Please find attached my comments on model-05
David
***************************************************
David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@salford.ac.uk
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J
***************************************************
Comments on ACL model 05
i) I think it is extra clutter to have familyOID as the first component of the
ldapACI attribute type, and does not buy us anything. If you want to define
another set of permissions, then simply give them a new attribute type (e.g.
ldapACIv2) which is itself an OID. It serves no good purpose to have one OID
for the ldapACI attribute then another OID for the family. You might as well
have just one OID that means precisely one set of permissions and access
control information.
ii) I made a comment on 04 about ReadDN that I don't believe has been
addressed yet. There is a difference between letting someone have access to an
entry they know exists, and ones they don't know exist. I.e. there is a
difference in permissions needed for the base object of a Search and the entries
beneath the base object (the latter is a greater permission than the former). At
the moment BrowseDN gives the latter permission, but there is not the lesser
permission of accessing an entry whose name you already know. This would
call for a ReadDN permission I believe. Comments please on this.
iii) Precedence of privilege dnTypes. I would argue that role comes higher than
group as it is more specific. By this I mean that group membership is usually
conferred on more people than are roles (and as you said in October, roles can
be regarded as groups with permissions). I would expect my role of abc
administrator to have more weight than simply a member of the IETF LDAP
group.
iv) On the same vein, can you explain why IP address should be higher than
access-id, when the former can be used by multiple people, the latter by only
one. It is the issue of specificity again. The more specific a dnType the higher
its precedence should be.
v) In my comments to version 4, I mentioned that delete permission for attribute
values could be needed, as with Modify Entry you both add values and delete
values and replace values (I took your write values permission to mean add).
With separate permissions you can allow some people to add, some to delete,
and some to do both. You said you would look into it, but I don't remember
your reply to this. I would suggest changing "write" to "add", and adding
"delete".
vi) Why can an acl entry only confer multiple rights on a single attribute name. I
would have expected <attr> to allow multiple attribute names within it.
(Version 4 allowed this.) Your later example shows the ldapACI being
repeated in order to give SysAdmins access to attr2 and attr3. Why was the
restriction introduced?
vii) Section 9 introductory paragraph talks about manipulating access rights and
getting and setting them. But as I read it, the section only provides a
mechanism to read them, not to update, set or manipulate them. Can you alter
the wording please.