Subject: Client Assertion of Authorization Identity
Author: authen
In response to: TLS Connection Establishment Effects
Posted on: 07/02/2007 09:01:00 PM
A client MAY either implicitly request that its LDAP authorization
identity be derived from its authenticated TLS credentials or it MAY
explicitly provide an authorization identity and assert that it be
used in combination with its authenticated TLS credentials. The
former is known as an implicit assertion, and the latter as an
explicit assertion.
Implicit Assertion
An implicit authorization identity assertion is accomplished after
TLS establishment by invoking a Bind request of the SASL form using
the "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL NOT include
the optional credentials octet string (found within the
SaslCredentials sequence in the Bind Request). The server will derive
the client's authorization identity from the authentication identity
supplied in the client's TLS credentials (typically a public key
certificate) according to local policy. The underlying mechanics of
how this is accomplished are implementation specific.
Explicit Assertion
An explicit authorization identity assertion is accomplished after
TLS establishment by invoking a Bind request of the SASL form using
the "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL include the
credentials octet string. This string MUST be constructed as
documented in section 9 of "Authentication Methods for LDAP", RFC 2829.
>
> On 07/02/2007 08:57:05 PM authen wrote:
Upon establishment of the TLS connection onto the LDAP association,
any previously established authentication and authorization
identities MUST remain in force, including anonymous state. This
holds even in the case where the server requests client
authentication via TLS -- e.g. requests the client to supply its
certificate during TLS negotiation (see [TLS]).
References:
