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

Re: Please review proposals for LDAP controls

Kurt D. Zeilenga wrote:

whoops, I meant 5.1.2.
   Controls which are sent as part of a request apply only to
   that request and are not saved.

That is, the request control needs to be part of each bind request
but only needs the last bind response needs the response control.



  OK


- You note control should not be returned on failure, it
 shouldn't be returned with resultCode is not success.

A bind request that does not return a resultCode of success has failed.


A referral resultCode does not indicate failure. 


  OK


 "Identities presented by a client as part of the authentication
 process may be mapped by the server to an arbitrary authorization
 identity.  The bind response control can be used to retrieve that
 AuthzID.

 For example, during client authentication with certificates...."


Identies presented .... mapped to ... arbitrary authorization identities.
                                                                     ^^^^
One of these is returned upon request.  [See below]



  How about returning potentially more than one identity in the response control? That could be done by placing the authzId or authzIds in a sequence in the value part of the response control.

  I have yet to see an example of that, while I have seen many cases where the response control with a single DN-valued authzId is extremely useful, but at least the control would allow for the possibility of multiple authzIds.


Anyways, in regards to the your proxy I-D, I do have a couple
of quick comments:
- Can a client distinguish between "user not allowed to
 assume asserted authzid" and "authzid has no rights to
 perform operation"?

No


I can see cases where it would be useful to distinguish
these cases, for example when used by an administrative
clients in testing access controls.



  A server can support that by returning different human-readable result strings (but the same result code). You're talking about debugging, not about a production environment.


I suggest stating
  "Anonymous" users SHOULD NOT be allowed to assume the identity of others.



  OK

Rob