LDAP / 2.80.00 about bastillion

[nox-do]

Hey Peter,

I'm not used to JAAS but I'll take a look. Sounds promising.
In common, from a system architectures perspective I suggest to use a load
balancer for fail over or simply DNS failover.
Most software does not support multiple (and) similar backends for
authentication.

Related to your requirements of a DN Substitution: Would it work if you can
specify a search filter for the bind?

2015-02-27 15:35 GMT+01:00 Peter Broadhurst [email protected]:

Hi,
I notice you've stared some work on LDAP support in the upcoming 2.80
release.
I had a requirement for this recently, and implemented a quick and crude
crowbar to put LDAP support into KeyBox in a fork here:
https://github.com/peterbroadhurst/KeyBox
I'll be pleased to throw away my patched version in favour of 2.80 when it
arrives, but I did want to pass on a couple of things about what I did in
case it helps:

• I chose instead of putting in an LDAP specific auth mechanism, to
  put in a JAAS auth mechanism and then simply configure the JAAS plugin
  provided in my JVM. This felt like the most extensible option, as other
  JAAS plugins (including custom) could be put in. The plugin in my case is
  com.ibm.security.auth.module.LdapLoginModule, but there's a LDAPLoginModule
  supplied with most/all flavours of JVM I believe.
• In my use case, I need to be able to specify multiple LDAP servers
  for redundancy. For the JAAS plugin of my JVM, I can just space seaprate
  the URIs. Hopefully that could be factored into the official KeyBox
  solution (wasn't clear from the draft readme on the 2.80 ).
• In my use case, I need to be able to specify which field fo the DN
  is substituted (UID, CN etc.). This is all catered for by the JAAS plugin,
  so hopefully it would also be in KeyBox (wasn't clear from the readme).

—
Reply to this email directly or view it on GitHub
#57.

[peterbroadhurst]

Hi Daniel,
A colleague of mine just gave the new KeyBox code a try, and it turns out it works out-of-the-box for us... almost.
We had to change the code that looks up 'givenName' to grab CN instead, as givenName doesn't exist in our LDAP records.
I was concerned it would be using CN as the key for the user, but you use UID, and that's actually fine for us. So it looks like we'll be able to throw away our little JAAS hack straight away :-)
I take your point on the HA part. We'll look into other options. The multiple space-separated URLs for LDAP replicas was an easy option for us, due to where this particular piece fits into the overall solution architecture.
Thanks, Peter

[skavanagh]

@peterbroadhurst - I should be able to make the LDAP attributes configurable... but anyway... CRAP!!!

I wish I would seen your JAAS fork earlier. That's probably a better way to go. Specifying the config is nice and may make it easier AD folks too (see #17 (comment)) .

Have you tried JAAS with x509 authentication?? Think smart cards!! Basically just need to authenticate and pull the username/uid, first name, last name and email. Then check if the user exists and insert if it doesn't. The most configurable way of doing it is the best option (x509, SAML, LDAP, etc..)!!

[skavanagh]

I updated what is on the branch to use JAAS and I used your implementation as a guide (hope you don't mind). I'd like to be able to pull name and email so it can be set when creating the user acct on the keybox side (haven't figured that out yet). Other than that everything works great! Thanks @peterbroadhurst

[peterbroadhurst]

Hi Sean, I'm really glad the fork was helpful.
If you use the loginContext.getSubject() call after the logic, you should get a subject with some principal objects in it.
The content is specific to the JAAS implementation, but hopefully there's consistency that one of the principals you get back contains the full DN that was authenticated (in the LDAP case of JAAS at least). Then that could be parsed with an LdapName object to extract the field the admin wants to map... or a regex could be generally applied to the toString() of any principal that comes back.

[skavanagh]

When i do that I only see the uid and the dn. I was thinking there needs to be something in the config, but not sure what (or it could be my ldap - kind of just thrown together so I can develop)

[peterbroadhurst]

I think the best you get is authzIdentity config parameter of the JAAS plugin.
This lets you choose one field to be returned from the LDAP server in a UserPrincipal.
Sadly I don't think you can get multiple non-DN fields. But you could map the UID from the DN into e-mail, and then get the surname name using authzIdentity.

[skavanagh]

That is a good idea! A lot of times uid isn't an email, but I could probably look for an "@" and set it if it is there.

Isn't 'cn' usually the full name? I could maybe return that from authzIdentity and set it if it looks like a full name. All this is just a nice to have (don't really need any of it to work).

[peterbroadhurst]

I'm definitely not an expert in the inetOrgPerson schema (or LDAP administration), but I believe 'CN' can be multi-valued and doesn't have to be a part of the DN. So you could have an entry with multiple different CN names, but none represented in the DN. Not sure what happens with authzIdentity in that case.

However, I'm with you that cn should be the full name.

As you say, UID might not be the e-mail address, in fact it might not even exist.
I believe the only required attributes are 'cn' (although could be multi-valued) and 'sn' for surname.

... I suspect starting with a simple case (UID==email and CN==full-name?) is the best, and let others with more complex LDAP setups make suggestions.

[skavanagh]

Yeah I know displayName is used too sometimes.. The nice thing is they can set it to whatever "Full Name" is in the config. I should be set and thanks again for the help!