LDAP attribute hell

Skip to first unread message

Curtis Ruck

Jul 31, 2018, 9:29:57 PM7/31/18
to CAS Community
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

we do ldapattribute=outputattribute

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


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

Jul 31, 2018, 11:34:24 PM7/31/18
to cas-...@apereo.org
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.


- 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

Aug 1, 2018, 12:16:35 AM8/1/18
to CAS Community
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.

Reply all
Reply to author
0 new messages