Hi Enrique,

On 3/1/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
Hi, Directory developers,

I have time this weekend so I'm looking at adding SASL\GSSAPI\Kerberos
V5 to LDAP binds.  

Excellent!

After reading some RFCs and ApacheDS internals, I
have a couple questions:

1)  The Authenticator.authenticate() method requires an LdapDN.

Yep.

GSSAPI returns a Kerberos principal name.  What's the best way to map
this to a DN?  We could use a regex, like OpenLDAP, but since we have
access to the Kerberos attributes, we can also search directly for the
principal name by specifying a baseDN.  This means an extra lookup,
but it may mean easier config.  Do we want to require that the
principal name map to a DN with a regex?

For example:

GSSAPI returns:   hnelson@EXAMPLE.COM
Desired DN:      uid=hnelson,ou=users,dc=example,dc=com

With OpenLDAP you specify mappings using the format:

uid=<username>,cn=<realm>,cn=<mech>,cn=auth

A resulting regex for our typical example LDIF would be:

sasl-regexp
          uid=(.*),cn=example.com,cn=gssapi,cn=auth
          uid=$1,ou=users,dc=example,dc=com

I'm having a bit of a problem understanding this.  It seems you're matching
for some UID value in one DN (the first) and using that to map to another DN
(2nd one in your example).

I'm probably being a bit near sighted here and missing something.  Did we
not want to use the regex to map a krb5 principal name to an LDAP DN?

BTW is this example an OpenLDAP thing or a convention used to organize
krb principal entries?

The alternative would be to specify a baseDN, like we do for other
lookups.  We then search for the principal name and use the found DN.
Our configuration could be:

gssapiBaseDn = ou=users,dc=example,dc=com

Do you think not using a regex for KRB5 principal to LDAP entry DN mappings
will limit the flexibility of the server?  Might also be nice to support both mechanisms
but that might be a little too much to grok for just getting something out the door.

Sounds to me like the use of the base dn configuration parameter is much
easier to implement, understand and convey to our users.

2)  If the best way from #1 is a lookup on Kerberos principal name at
a baseDN, where is the best place to invoke that lookup?  I think I
have to do the lookup in the LDAP protocol provider, since the
Authenticator.authenticate () method requires an LdapDN.  

I guess you're going to have to add the work flow for managing the SASL bind
within the PP.  The standard authentication pathway which uses these Authenticators
may be useless to you.

It's been a while since I've been in this code so bear with me.  I guess I can give
a better answer if I started fishing around in the code to get reacclimated.  If you
need me to do that just let me know and I can make some time.

If I set env
property Context.SECURITY_PRINCIPAL to the Kerberos principal name
from GSSAPI, is there any way to do a lookup and convert that prior to
calling Authenticator.authenticate(), but in the backend, not the
protocol provider?  

We could setup code withing the authentication service (interceptor) to detect
sasl binds and automatically map the Krb5 principal name to an LDAP name. 

Would we gain anything?  FWIW, the Kerberos
provider currently does lookups in the protocol provider.

You could do that or alter the LDAP infrastructure between the pp and the
partition (the interceptors) to handle sasl binds.

BTW, the regex is sounding easier and probably more performant.

Oh? Why do you think?

2)  Any opinion on the 'authenticatorType' to use?  Doco seems to
indicate that the choices are "none," "simple," and "strong."
However, it might be better (ie more modular) to have an authenticator
for each SASL type, eg "sasl-gssapi" and "sasl-digest-md5."  Even with
2 SASL mechanisms supported we could be looking at one large
Authenticator.  Would that be a pain for embedders, in which case we
could use "strong" and have a separate env property if we decide to
have multiple authenticators?

Hmmm I think adding strong type specifiers for specific SASL mechanisms
might require a little refactoring in how Authenticators work.  I just need
to take a better look at the code again.

3)  I'm planning on adding GSSAPI.  What other SASL types are actually used?

I think that's the most useful and most expected of mechanisms.  However md5
is also popular.

<dreaming>
It would be cool would be to at some point implement the SASL mechanism for utilizing OTPs.
</dreaming>

I think I need to dive back into this code to be more useful to you.  Furthermore it's not
in the best shape it could be in.

Alex