directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [SASL] SASL questions
Date Sat, 03 Mar 2007 08:44:39 GMT
Hi Enrique,

On 3/1/07, Enrique Rodriguez <> wrote:
> 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:
> uid=<username>,cn=<realm>,cn=<mech>,cn=auth
> A resulting regex for our typical example LDIF would be:
> sasl-regexp
>           uid=(.*),,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
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
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.

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

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.


View raw message