[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: I-D ACTION:draft-ietf-ldapext-acl-model-00.txt
Some comments
1. It is unclear (however I think discussed @ ietf) if the acl list apply to the
subtree
or not ?
2. Page 6 -- You talk about the case where not all the SSAI is not send to client
if the authentication system validated by client is not trusted ? In that
case should the
server send any information at all or the server should should refuse to do
any operation.
3. Section 2.4 No ssai appear in more than one access control list. ?
Why that restriction ? In one case it is nice to do a union of acls but this
might
become a burden to the acl creator as s/he has go through all the acls for
that
object. For example, an application may create a temp acl do some
operation and then delete that acl. the client doesn't have to make sure that
an acl already exits for that ssai.
4. section 2.4 A group maybe a collection of static subjects or dynamic subjects
5. section 3.3 page 11 line 1 -- Add "access-id" as it is referred sometime later
and it's not clear if it means that.
6. Section 3.4.2 page 13
<subjectsecurityAttribytevalue> Why it has to be a DN. I would like more
flexibility i.e. I should be able to define a filter or something to a
select based
on certain criteria.
7. section 4.1.1 -- The word "aclEntry" very much confuses (to me at least) with
a
a real entry. I understand it as an attribute of an object. A different word
like
"acllist" or ... might be more clearer
8. section 4.1.2 "aclowners have full permission to that object". If A can create
an
ACL on object O, does that in directly gives A as the administrative owner of
O.
If A and B created 2 aclEntries on object O. Since A and B are now owner of
object O, can A modify B's aclEntry ? If not why not.
I think that aclowner means owner of that aclEntry.
9. section 4.1
Are "aclOwner" and "aclEntry" are multi-values attribute ?
If Yes, then it may be difficult to figure out who is the owner ? It might be
a better idea to include the aclowner name somewhere in the aclentry. The only
other way to figure out is via indexing the values.
If NO ? then how would I create multiple acls for that entry with different
ssai.
10. Section 4.1.3 -- Let's say I am an ISP serving multiple domains
(ex: coke & pepsi). Since attributes are statically grouped, an attribute
may be in a sensitive class to coke but not for pepsi.
Also, if the Coke decides to change an attr to a different class, then it has
side effects to pepsi users.
It was not clear to me what problem are we trying to solve by grouping
attributes
in classes ? I think the finer granularity of able to create acl on a
single attribute is
a better choice.
11. type: page 16 line #3 "controlling"
12. Page 16: It's not clear what the permission "Use" is for . An example might be
better
13. I would like for support for extension of access permissions. It may not be
inter operable but we should have that flexibility to define your own
specific access permissions.
14. section 4.2 typo's (should be)
aclowner: cn=IETF,c=us#access-id#...
aclEntry: ...#cn=Eveybody#...
15. section 4.3
Why <accesslist> has to <objectaccessclas> and <attributeaccessclass>
has to be 2 different definition ? I understand that one is applicable to
the whole object and one is for an attribute.
16. Section 4.5 Not very clear for a separate syntax for the LDIF. Can you put
the LDIF format of the example used in section 4.4
17. Back for a moment.
- group contain subjects
- subject's ssai may contain group names
- object's "aclOwner' and "aclEntry" may contain group name
Now if group is dropped and renamed (similarly DN), we need to talk about
the referential integrity part. This become much more important as now the
name
is all over the place.
18. I didn't see ( sorry if I missed) how I would support access to an object
based on
the authentication type ( Strong vs simple or base don the SASL plugin)
19. ANy thought on support for timeofday or dayofweek ?
20. Although in the requirements doc, we discussed about acls based on
ip and DNS (section s6). It says SHOULD NOT. If one want to support it,
then how he would s/he ?
I think aclEntry syntax need to support extension which may not be
inter-operable but make sense. Without that support if one want to support
19 and/or 20, the current model doesn't provide that flexibility. In general,
we
need to provide a flexibility to be able to extend the the model like the
controls
in V3. This I think is a MUST.
That's all for now.
/prasanta
-------------------------------------------------------------------------
Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the LDAP Extension Working Group of the IETF.
>
> Title : Access Control Model for LDAP
> Author(s) : B. Blakley, E. Stokes, D. Byrne
> Filename : draft-ietf-ldapext-acl-model-00.txt
> Pages : 27
> Date : 07-Apr-98
>
> This document describes the access control list (ACL)
> model for the Lightweight Directory Application Protocol
> (LDAP) directory service. It includes a description of
> the model, the LDAP controls, and the extended operations
> to the LDAP protocol. A separate document defines the
> corresponding application programming interfaces (APIs).
> RFC2219 [Bradner97] terminology is used.
>
> Internet-Drafts are available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-ietf-ldapext-acl-model-00.txt".
> A URL for the Internet-Draft is:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ldapext-acl-model-00.txt
>
> Internet-Drafts directories are located at:
>
> Africa: ftp.is.co.za
>