11:35 a.m.
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
4:09 p.m.
New subject: LDAP Verify Credentials operation
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?
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.
7:04 p.m.
New subject: LDAP Verify Credentials operation
On Jan 3, 2011, at 4:09 PM, masarati(a)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
7:09 p.m.
New subject: LDAP Verify Credentials operation
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
1:39 a.m.
New subject: LDAP Verify Credentials operation
On Jan 3, 2011, at 4:09 PM, masarati(a)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.
2:03 a.m.
New subject: LDAP Verify Credentials operation
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.
4719
days inactive
4721
days old
5 comments
3 participants
participants (3)
-
Kurt Zeilenga -
Kurt Zeilenga
-
masarati＠aero.polimi.it