Re: FW: Question about restrictions on username in SASL authorization

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 12:00 PM 11/16/00 -0800, Howard Chu wrote:
>When I first wrote up the code to extract the DN from a client certificate, in our in-house slapd code
>base, I reversed the X.500 DN (put into LDAP format) so that it could be used directly as an authentication
>DN. I still believe this is the most useful way to behave. The code that I committed to OpenLDAP does not
>do this transformation. Kurt still has a valid point that we can get into trouble making assumptions about
>externally obtained identifiers, but it strikes me that most people who will want to use this feature are
>already setting up their own CAs and are already generating certificate DNs in parallel with their LDAP
>DN hierarchy. Opinions, anyone?

First, we must realize that the lower level authentication identity
can be in any number of forms.  With TLS/X.509 that form is a DN
which can be represented in the traditional X.500 format or the
LDAP format.  However, note that TLS is not the only lower level
in which we can support and X.509are not the only form of credential
one could use with TLS.  I hope to be able to use Kerberos based
credentials with TLS.  This implies we need some mechanism which
can support multiple forms.

The current mechanism is for the authentication identity
to be the X.509 DN (in traditional form).  Per the 4 steps I
outlined in my recent post, the authentication identity

a) authcid to uAuthzid (hard code)
  /DC=COM/DC=EXAMPLE/CN=USER/ ->
       u:/DC=COM/DC=EXAMPLE/CN=USER/
b) uAuthzId to dnAuthzId (hard code)
   u:/DC=COM/DC=EXAMPLE/CN=USER/ ->
       dn:uid=/DC=COM/DC=EXAMPLE/CN=USER/,cn=EXTERNAL,cn=AUTHZ
c) dnAuthzId to dnAuthzId (regex)
   dn:uid=/DC=COM/DC=EXAMPLE/CN=USER/,cn=EXTERNAL,cn=AUTHZ ->
       dn:uid=USER,dc=EXAMPLE,dc=COM
d) dnAuthzId to SubjectDN
   dn:uid=USER,dc=EXAMPLE,dc=COM ->
        uid=USER,dc=EXAMPLE,dc=COM

Note that the input to the regex is not a valid dnAuthzId,
but the output MUST be.

Alternatively, we could instead use the LDAP DN form of the
DN instead of the X.500 form.  This would imply:

a) authcid to uAuthzid (hard code)
  CN=USER,DC=EXAMPLE,DC=COM ->
       u:CN=USER,DC=EXAMPLE,DC=COM
b) uAuthzId to dnAuthzId (hard code)
   u:CN=USER,DC=EXAMPLE,DC=COM ->
       dn:uid=CN=USER,DC=EXAMPLE,DC=COM,cn=EXTERNAL,cn=AUTHZ
c) dnAuthzId to dnAuthzId (regex)
   dn:uid=CN=USER,DC=EXAMPLE,DC=COM,cn=EXTERNAL,cn=AUTHZ ->
       dn:uid=USER,dc=EXAMPLE,dc=COM
d) dnAuthzId to SubjectDN
   dn:uid=USER,dc=EXAMPLE,dc=COM ->
        uid=USER,dc=EXAMPLE,dc=COM

Again note the input to the regex is not a valid dnAuthzId.
However, note that designing a regex to match former input
is easier than the latter input.  That is, I suggest we
continue to use X.500 form for input to the regex.

An alternative would be implement some sort of mechanism
that would, depending on the form of the input authcid
and configuration information, would use the LDAP DN
as an authcid, map (hardcode) to an dnAuthzId instead
of uAuthzId and pass this to the step regex.  That is:

If SASL/EXTERNAL w/ TLS/X.509, authentication identity
of CN=USER,DC=EXAMPLE,DC=COM:

a) CN=USER,DC=EXAMPLE,DC=COM ->
        dn:CN=USER,DC=EXAMPLE,DC=COM

b) if input is dnAuthzId, null mapping

c) regex as above

d) subject DN as above

This requires a number of special cases to be implemented.
I would prefer to update the HEAD per my previous post
prior to attempting to implement the above....

Kurt