directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <>
Subject [SASL] SASL questions
Date Fri, 02 Mar 2007 00:24:15 GMT
Hi, Directory developers,

I have time this weekend so I'm looking at adding SASL\GSSAPI\Kerberos
V5 to LDAP binds.  After reading some RFCs and ApacheDS internals, I
have a couple questions:

1)  The Authenticator.authenticate() method requires an LdapDN.
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:


A resulting regex for our typical example LDIF would be:


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

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.  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?  Would we gain anything?  FWIW, the Kerberos
provider currently does lookups in the protocol provider.

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

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?

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



View raw message