LDAP attribute hell

[Curtis Ruck]

So, LDAP attributes.  I've got the initial retrievals working, <frustrated>but i've found issue another trying to squash everything into a properties file issue.</frustrated>

So if you have a property like principalAttributeList that takes a list of comma delimited attributes.  But then you overloaded the comma delimiting to support renaming the attributes with a colon.  Now, the fun part here is that LDAP query syntax supports colons inside attribute queries and result attribute lists.  So, when i add memberOf:1.2.840.113556.1.4.1941: as an attribute to lookup, it only searches for memberOf, and renames the output attribute name to 1.2.840.113556.1.4.1941.

Requesting that in an attribute result should (in Active Directory LDAP parlance) return recursive group memberships, instead i'm now going to need to create a new ldap authentication handler to create a different multiMapAttributes object.

We could just swap out the colon for another separator character, but I don't want to read through LDAP RFCs for the next year trying to find invalid ldap syntax that could be used in cas.properties

In theory to address this, I should just able to copy+paste the @Configuration LdapAuthenticationConfiguration class and modify it slightly, and setup a custom property structure for it... custom.authn.ldap[0], and then maintain it every time the apereo/cas upstream changes.

Long term, I can think of two possibilities to create the flexibility necessary for my organization.

instead of

cas.authn.ldap[0].principalAttributeList=sn:lastname,cn:commonname,givenName:firstname,mail,sAMAccountName:uid,sAMAccountName,memberOf:1.2.840.113556.1.4.1941:,principalGroupId

we do ldapattribute=outputattribute

cas.authn.ldap[0].principalAttributes.sn=lastname

cas.authn.ldap[0].principalAttributes.cn=commonname

cas.authn.ldap[0].principalAttributes.givenName=firstname

cas.authn.ldap[0].principalAttributes.mail=mail

cas.authn.ldap[0].principalAttributes.sAMAccountName=uid

cas.authn.ldap[0].principalAttributes.sAMAccountName=sAMAccountName

cas.authn.ldap[0].principalAttributes.memberOf:1.2.840.113556.1.4.1941:=memberOf

Nope that won't work as I can't have the same input attribute twice... what about this in outputattribute=ldapattribute

cas.authn.ldap[0].principalAttributes.lastname=sn

cas.authn.ldap[0].principalAttributes.commonname=cn

cas.authn.ldap[0].principalAttributes.firstname=givenName

cas.authn.ldap[0].principalAttributes.mail=mail

cas.authn.ldap[0].principalAttributes.uid=sAMAccountName

cas.authn.ldap[0].principalAttributes.sAMAccountName=sAMAccountName

cas.authn.ldap[0].principalAttributes.groups=memberOf:1.2.840.113556.1.4.1941:

I honestly like the compile time "correctness" aspect of @Configuration, but this is where the logic fails.  It was really easy to do this in Spring Bean XML.

[Ganesh and Sashi Prasad]

Some unsolicited advice:

Don't use LDAP to store anything other usernames and passwords. Use a relational database to store all other attributes. Multi-valued attributes are more naturally modelled through a table.

CAS can do authentication against LDAP and collect attributes from a variety of user stores, including a relational database. It'll be transparent how it's done. Your final token created by CAS will have everything in it.

Ganesh

--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+unsubscribe@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/afe5f28e-77d9-4d39-9e59-1d0cc3521634%40apereo.org.

[Curtis Ruck]

I've inherited our CAS usage model, where we extend windows/active directory group permissions into the web app space. It let's us have a single account that can authenticate and authorize users anywhere.

Storing role/group membership (and additional attributes) outside of LDAP would increase our account management headaches, where as right now each user just gets their AD account and it works anywhere.