Ando and I have been discussing off-list the need for this op's request and response to carry additional fields. The discussion started with a separate error code to distinguish errors which might be communicated back to authenticating entity (as opposed to the LDAP client submitting the VC request).
My current proposal is:
/* * LDAP Verify Credentials operation * * The request is an extended request with OID 1.3.6.1.4.1.4203.666.6.5 with value of * the BER encoding of: * * VCRequest ::= SEQUENCE { * cookie [0] OCTET STRING OPTIONAL, * name LDAPDN, * authentication AuthenticationChoice * controls [3] Controls OPTIONAL * } * * where LDAPDN, AuthenticationChoice, and Controls are as defined in RFC 4511. * * The response is an extended response with no OID and a value of the BER encoding of * * VCResponse ::= SEQUENCE { * resultCode ResultCode, * diagnosticMessage LDAPString, * cookie [0] OCTET STRING OPTIONAL, * serverSaslCreds [1] OCTET STRING OPTIONAL * authzid [2] OCTET STRING OPTIONAL * controls [3] Controls OPTIONAL * } * * where ResultCode is the result code enumeration from RFC 4511, and LDAPString and Controls are as * defined in RFC 4511. */
The use of controls here is to allow both the request/return of password policy information to the authenticating entity (as opposed those used on the extended operation itself to request/return password policy information about the LDAP client submitting the VC request).
Comments?
-- Kurt
Ando and I have been discussing off-list the need for this op's request and response to carry additional fields. The discussion started with a separate error code to distinguish errors which might be communicated back to authenticating entity (as opposed to the LDAP client submitting the VC request).
My current proposal is:
/*
- LDAP Verify Credentials operation
- The request is an extended request with OID 1.3.6.1.4.1.4203.666.6.5
with value of
- the BER encoding of:
- VCRequest ::= SEQUENCE {
cookie [0] OCTET STRING OPTIONAL,
name LDAPDN,
authentication AuthenticationChoice
controls [3] Controls OPTIONAL
- }
- where LDAPDN, AuthenticationChoice, and Controls are as defined in RFC
- The response is an extended response with no OID and a value of the BER
encoding of
- VCResponse ::= SEQUENCE {
resultCode ResultCode,
diagnosticMessage LDAPString,
cookie [0] OCTET STRING OPTIONAL,
serverSaslCreds [1] OCTET STRING OPTIONAL
authzid [2] OCTET STRING OPTIONAL
controls [3] Controls OPTIONAL
- }
- where ResultCode is the result code enumeration from RFC 4511, and
LDAPString and Controls are as
- defined in RFC 4511.
*/
The use of controls here is to allow both the request/return of password policy information to the authenticating entity (as opposed those used on the extended operation itself to request/return password policy information about the LDAP client submitting the VC request).
Comments?
The code client and server side works now according to the above specs for simple bind with request and response controls.
I note that you moved authzid retrieval to RFC 3829 authzid control. Are you going to implement its support server-side? Otherwise I might have time to look at it, maybe not immediately.
p.
On Jan 3, 2011, at 4:09 PM, masarati@aero.polimi.it wrote:
The code client and server side works now according to the above specs for simple bind with request and response controls.
I note that you moved authzid retrieval to RFC 3829 authzid control.
Yeah, figured I might as well use it here.
Are you going to implement its support server-side? Otherwise I might have time to look at it, maybe not immediately.
I have no plans to implement this in slapd(8). Might be a good starter project for someone.
-- Kurt
On Jan 3, 2011, at 7:04 PM, Kurt Zeilenga wrote:
I note that you moved authzid retrieval to RFC 3829 authzid control.
Yeah, figured I might as well use it here.
Are you going to implement its support server-side? Otherwise I might have time to look at it, maybe not immediately.
I have no plans to implement this in slapd(8). Might be a good starter project for someone.
I also have no plans to implement the general support for this control in the client side. We use LDAP Who Am I? in the general case.
-- Kurt
On Jan 3, 2011, at 7:04 PM, Kurt Zeilenga wrote:
I note that you moved authzid retrieval to RFC 3829 authzid control.
Yeah, figured I might as well use it here.
Are you going to implement its support server-side? Otherwise I might have time to look at it, maybe not immediately.
I have no plans to implement this in slapd(8). Might be a good starter project for someone.
I also have no plans to implement the general support for this control in the client side. We use LDAP Who Am I? in the general case.
Quick comment (don't want to interfere too much with your development): in ldapvc.c you added -a (authzid) and -b (ppolicy) switch.
Client-wise they are currently available as -e [!]bauthzid, -e ppolicy.
VC exop-wise controls could be grouped similarly, e.g. with a -a [!]<name>[=<value>] switch, to avoid quickly running out of switches.
Moreover, since some of these controls only apply at bind, some only apply during the specific operation(s) that client is supposed to do, some always apply, we could move control parsing and creation to separate helpers/switches, or add an optional field that indicates when the control is supposed to be used. This way, the -e switch could also be used to indicate control specific for the vc operation. Something like
-e [!][<when>:]<name>[=<value>]
<when> ::= {xadmrwcsre}+ x ; bind a ; add d ; delete m ; modify r ; nename w ; "write": same as "admn" c ; compare s ; search r ; "read": same as "cs" b ; unbind u ; unbind e ; exop C ; cancel P ; passmod V ; vc W ; whoami
If no specifier is given, the same control is used for all operations it applies to. So ldapvc could use, for example
-e !xV:bauthzid -e V:ppolicy -e xV:sessiontracking
to use authzid and session tracking for bind, and authzid, ppolicy and session tracking for vc.
p.
On Jan 3, 2011, at 4:09 PM, masarati@aero.polimi.it wrote:
The code client and server side works now according to the above specs for simple bind with request and response controls.
I note that you moved authzid retrieval to RFC 3829 authzid control.
Yeah, figured I might as well use it here.
Are you going to implement its support server-side? Otherwise I might have time to look at it, maybe not immediately.
I have no plans to implement this in slapd(8). Might be a good starter project for someone.
I have a quick, little intrusive server-side implementation (as a module) for single-op bind operations. For multi-op (SASL) it needs to be a bit more intrusive, since the connection structure needs some memory of the initial control request.
Perhaps we could use some ConnExtra along the lines of OpExtra; for example, PagedResultsState could move there as well...
Not sure whether I want to commit it as it is now...
p.