[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Comments to draft-ietf-ldapext-acl-model-02.txt (April 15th version).
Hi Ellen, Bob and Debbie
Here's my comments to the April 15th version of
draft-ietf-ldapext-acl-model-02.txt.
---
page 12:
7. Access Control Information (ACI) Controls
The access control information controls provide a way to
manipulate access control information in conjunction with
an LDAP operation such as ldap_add, ldap_modify, or
ldap_search.
This led to believe that the controls could be used with any ldap
operation. But of the 3 controls defined after, 2 are for searches
operation
only and the last one (specifyCredentials) is for ldap_bind.
I think ldap_add and ldap_modify shouldn't be mentioned if the controls
cannot
be applied to them.
----
pages 14 and 18:
Sections 7.1.2, 7.2.2:
Redefinition of SearchResultEntry.
In both sections 7.1.2 and 7.2.2 the SearchResultEntry structure is
redefined
with a different ASN1 definition from RFC 2251. I don't think it is a
good
idea. This will lead to confusion and may implies some deep changes in
the
decoding parts of the clients.
pages 14 and 18.
Although this extends the search operation, there are no
incompatibilities between versions. LDAPv2 cannot send a
control, hence the above structure cannot be returned to
a LDAPv2 client. A LDAPv3 client cannot send this
request to a LDAPv2 server. A LDAPv3 server not
supporting this control cannot return the additional
data.
Though this paragraph is correct, the fact that LDAP Application 4
structure
(searchResultEntry) may be different depending on a control sent on the
request implies some strong changes in the client code. The client must
know
which request has been sent to be able to correctly decode the
SearchResultEntry. This forces the client to correlate responses to
requests
and forbid asynchronous management of LDAP requests.
One possibility is to say that the PartialEffectiveRightsList structure
(or
PartialSubjRightsAttributeList for the listSubjectRights Control) is to
be returned as the control value in each LDAPMessage containing a
SearchResultEntry, and to mandate that the PartialAttributeList of the
SearchResultEntry be empty.
RFC 2251 defines the LDAPMessage as:
LDAPMessage ::= SEQUENCE {
messageID MessageID,
protocolOp CHOICE {
bindRequest BindRequest,
bindResponse BindResponse,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
modifyRequest ModifyRequest,
modifyResponse ModifyResponse,
addRequest AddRequest,
addResponse AddResponse,
delRequest DelRequest,
delResponse DelResponse,
modDNRequest ModifyDNRequest,
modDNResponse ModifyDNResponse,
compareRequest CompareRequest,
compareResponse CompareResponse,
abandonRequest AbandonRequest,
extendedReq ExtendedRequest,
extendedResp ExtendedResponse },
controls [0] Controls OPTIONAL }
This means that controls could be send along SearchResultEntry as well.
---
page 21:
7.3.2 Response Control
This control is included in the ldap_search message as
part of the controls field of the LDAPMessage, as defined
in Section 4.1.12 of [LDAPv3].
May be a copy/paste error, but this should apply to an ldap_bind
message.
page 22:
Although this extends the bind operation, there are no
incompatibilities between versions. LDAPv2 cannot send a
control. A LDAPv3 client cannot send this request to a
LDAPv2 server. A LDAPv3 server not supporting this
control cannot return the additional data.
May be a copy/paste mistake, but this paragraph doesn't make any sense
here. The BindResponse ASN1 definition wasn't changed.
page 22: 7.3.3 Client-Server Interaction
The specifyCredentialsRequest control specifies the
credentials that the client was the server to use for
^^^^^
wants
access control in subsequent ldap operations. The server
...
page 23:
The client application is assured that the correct
credentials are used by the server when specified by the
client for subsequent ldap operations if and only if the
specifyCredentialResponse is successful. If the server
omits the specifyCredentialResponse control from the
searchResponse message, the client SHOULD assume that the
control was ignored by the server.
May be a copy/paste mistake, but this control is to be part of a
bindResponse
not a searchResponse.
---
page 33:
Globally, several aci examples don't respect the BNF as specified in
section
10.4:
Similarly, the aci
aci: 1.2.3.4#subtree#group#cn=Dept XYZ, c=US simply
means that no permissions have been defined for this
The aci should be aci: 1.2.3.4#subtree##group#cn=Dept XYZ, c=US
The BNF is section 10.4 specifies that <rights> may be empty but not the
it's
optional in the aci_syntax.
...
page 33:
aci: 1.2.3.4#subtree#group#grant;r,w;[all]#cn=Dept XYZ
aci: 1.2.3.4#subtree#group#grant;r;attribute1#cn=Dept
XYZ
The <dnType> "goup" should be after the rights and before the subject
dn:
aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ
aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept
XYZ
...
page 33:
is the equivalent of
aci:
1.2.3.4#subtree#group#grant;r,w;[all];r,attribute1#cn=Dept
XYZ
should be:
aci:
1.2.3.4#subtree#grant;r,w;[all]$grant;r;attribute1#group#cn=Dept
XYZ
...
page 34:
attribute1 and attribute2. For servers that do not
support attribute grouping, "r,w ; attribute1,
attribute2" results in the same operations as " r,w;
attribute1; r,w; attribute2 "
This does not conformed to the BNF. It should be:
...results in the same operations as "grant;r,w;
attribute1$grant;r,w; attribute2 "
...
page 34:
aci:
1.2.3.4#subtree#deny;r,w;[all];grant;rsc;attirbute2#group#cn=Dept
ABC
aci:
1.2.3.4#subtree#grant;r,;[all];grant;rsc;attirbute1#group#cn=Dept
XYZ
Permissions should be separated by commas:
aci:
1.2.3.4#subtree#deny;r,w;[all];grant;r,s,c;attribute2#group#cn=Dept
ABC
aci:
1.2.3.4#subtree#grant;r,;[all];grant;r,s,c;attribute1#group#cn=Dept
XYZ
...
page 35:
aci does exist, then add the specified values to the
given aci. For example a given aci:
aci: 1.2.3.4#subtree#group#grant;r,w;[all]#cn=Dept XYZ
with a modification:
dn: cn=someEntry
changetype: add
add: aci
aci: 1.2.3.4#subtree#group#grant;r;attribute1#cn=Dept
XYZ
The <dnType> "group" should be after the <rights>:
aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ
with a modification:
dn: cn=someEntry
changetype: add
add: aci
aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept
XYZ
...
page 35:
would yield an aci value of:
aci:
1.2.3.4#subtree#group#grant;r,w;[all];r,attribute1#cn=Dept
XYZ
Same as previous but the rights should be separated by $ signs. So the
result
should be:
aci:
1.2.3.4#subtree#grant;r,w;[all]$grant;r;attribute1#group#cn=Dept
XYZ
...
page 35:
Interpretation 1.
aci: 1.2.3.4#subtree#group#cn=Dept XYZ
would delete the entire aci for the group cn=Dept XYZ
The rights are mandatory though they can be empty. But there should be 2
consecutive # signs:
aci: 1.2.3.4#subtree##group#cn=Dept XYZ
...
page 35:
Interpretation 2.
aci:
1.2.3.4#subtree#grant;rsc;attribute1#group#cn=Dept XYZ
would delete the 'grant;rsc;attribute1' portion of the
Permissions should be separated by commas according to the BNF:
aci:
1.2.3.4#subtree#grant;r,s,c;attribute1#group#cn=Dept XYZ
...
page 36:
before ldapmodify - delete:
aci:
1.2.3.4#subtree#group#grant;r,w;[all];grant;rsc;attribute1#cn=Dept
XYZ
after ldapmodify - delete of attribute1
aci: 1.2.3.4#subtree#group#grant;r,w;[all];#cn=Dept
XYZ
should be:
aci:
1.2.3.4#subtree#grant;r,w;[all]$grant;r,s,c;attribute1#group#cn=Dept
XYZ
after ldapmodify - delete of attribute1
aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept
XYZ
...
page 36:
is deleted,
aci: 1.2.3.4#subtree#grant;[attribute2]#group#cn=Dept
XYZ
the resulting aci would still be
aci: 1.2.3.4#subtree#group#grant;r,w;[all];#cn=Dept
XYZ
should be:
is deleted,
aci: 1.2.3.4#subtree#grant;;[attribute2]#group#cn=Dept
XYZ
the resulting aci would still be
aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept
XYZ
----
page 37:
10.4 BNF:
...
<permission> : "a" | "d" | "r" | "s" | "w" | "c"
| "g" | "s" | "m" | "u"
These are the permissions defined for
the IETF family OID.
I suggest that the document clearly explain which permission is
specified by
which letter. "a" for Add...
---
page 37:
10.5 Examples
...
The next example shows an aci attribute where a group
"cn=Dept XYZ, c=US" is being given permissions to read,
search and compare attribute1. The permission should
apply to the entire subtree below the node containing
this aci.
aci: 1.2.3.4#subtree#group#grant;r,s,c;attribute1#cn=Dept
XYZ, c=US
The aci should be:
aci: 1.2.3.4#subtree#grant;r,s,c;attribute1#group#cn=Dept
XYZ, c=US
...
page 38:
aci:
1.2.3.4#subtree#role#grant;a;[entry]$grant;r,s,c;attribute2,attribute3#cn=SysAdmins,o=Company
should be, according to the BNF:
aci:
1.2.3.4#subtree#grant;a;[entry]$grant;r,s,c;attribute2,attribute3#role#cn=SysAdmins,o=Company
--
Ludovic Poitou
Sun Microsystems Inc.
Sun-Aol Alliance - Directory Group - Grenoble - France