On 3/3/07, Alex Karasulu <[EMAIL PROTECTED]> wrote:
On 3/1/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote:
> ...
> 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?
This is OpenLDAP config. While we do, ultimately, want to map a
Kerberos principal to a DN, Kerberos (GSSAPI) is only one
authentication mechanism. For example, users may also use DIGEST-MD5.
The first DN is sort of a "virtual DN" where the root
"cn=gssapi,cn=auth" says the mechanism is GSSAPI. It could also be
"cn=digest-md5,cn=auth", giving you a layer of indirection. This
"virtual DN" format is:
uid=<username>,cn=<realm>,cn=<mech>,cn=auth
This allows you to have different mappings based on mechanism type.
For example, perhaps machine accounts must use GSSAPI while user
accounts can use GSSAPI or DIGEST-MD5 and machines and users are in
separate OU's?
> 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.
I do think the regex is important for flexibility. 1..n "base DN"s
would be easier, but we certainly can do regex. Also, if
per-mechanism mapping is desirable then we need to figure out how to
allow that.
One thing I think we should be adamant about from the beginning with
this LDAP+Kerberos integration is that we must have multiple realm
support. You must be able to have, for example, users under
ou=users,dc=apache,dc=org AND ou=users,dc=example,dc=com where the
realms are, respectively, APACHE.ORG and EXAMPLE.COM. Plus, as Quanah
pointed out, you'll have user, machine, and service principals in
separate subtrees, as well. I found it interesting that your
ApacheCon tutorial talks about how the core Partition Nexus performs
"call routing based on namespace." Multi-realm is a no-brainer to
implement; in fact, the old OSGi build allowed this. The limitation
today is only that there's no config support for it; we allow one base
DN.
I don't want to complicate the 1st round of this, but ... this
multi-base lookup applies to multiple zones for DNS and multiple
subnets for DHCP. The DNS RFCs call this a "catalog." Again, maybe a
core service (or two) will work for pre-processing everything for
everybody.
As you noted, it's best to get something out the door, but I wanted to
get some awareness going.
> 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.
Yeah, the PP will handle workflow, but it will also coordinate with a
MINA filter that handles wrapping and unwrapping data, once the Bind
has completed.
Inbound -> SaslFilter (off) -> decoder -> BindHandler <-> backend 1, 2
Outbound <- SaslFilter (off) <- encoder <--------'
All subsequent LDAP operations:
Inbound -> SaslFilter (on) -> decoder -> SearchHandler <-> backend
Outbound <- SaslFilter (on) <- encoder <-------'
#1 is a user lookup to authenticate. Should be an Authenticator, once
we figure out how to derive a DN for the user based on principal w/
realm.
#2 is an LdapContext establishment for that user and stored in the session.
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.
Cool, thanks. I'll get some code committed and we can start to review
the more hairy integration issues. BTW, where should I start putting
work? I'm thinking the server-sasl module but I think longer term it
will just roll into the PP. From the server-sasl or protocol-ldap
modules we can review the touchpoints with the core. server-sasl
seemed to me to be an effort to segregate SASL since it was a JDK 1.5
thing. Also, FYI, I don't think I'll be able to make this a drop-in
MINA subproject, like SSL, since there is a handler that must talk to
a user store. Anyway, we can review it later.
> 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.
Cool, makes sense. As I mentioned above, a common way to map
zones/realms/subnets and handled in a common place would be very
powerful.
> 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?
Hmm, a misstatement on my part. I was thinking the regex would be
more performant as you would build a DN and look directly for it,
while a lookup at a baseDN would mean a broader search. And I have
lookup code from Kerberos but nothing for regex's so regex support
would be a new effort, and thus "harder." Mostly my own lack of
experience with regex's.
> 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.
OK, I'll wait.
> 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 looked at that while reviewing SASL doco. IIUC, it isn't a generic
mechanism for any type of OTP, but rather a specific OTP algorithm.
We couldn't reuse it for HOTP, if that's what you're thinking. HOTP
or HOTP+PIN would be great to add with Binds, though.
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.
It's been a great exercise for getting familiar with the core.
Enrique
