Using an attribute returned by the authentication process to query an attributeRepository

[Scott H]

Hello,

I am extremely new to CAS and I have an issue that I have not been able to find a solution for. Simple question, how do you use an attribute returned using LDAP authentication in a query from the attributeRepository?

I am using CAS 6.1.2 overlay project.

Here is my authentication properties.

cas.authn.ldap[0].type=AUTHENTICATED

cas.authn.ldap[0].ldapUrl=XXXXX

cas.authn.ldap[0].poolPassivator=NONE

cas.authn.ldap[0].baseDn=DC=example,DC=com

cas.authn.ldap[0].searchFilter=(|(sAMAccountName={user})(userPrincipalName={user}))

cas.authn.ldap[0].subtreeSearch=true

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

cas.authn.ldap[0].principalAttributeList=sn,cn,givenName,mail,title,sAMAccountName,userPrincipalName,displayName

cas.authn.ldap[0].allowMissingPrincipalAttributeValue=true

This allows a person to log in using either their sAMAccountName or userPrincipalName (which for us is their email). This works correctly and in the logs I can see where the SimplePrincipal is created and the id is assigned to sAMAccountName. This creates a SimplePrincipal correctly no matter if they enter their sAMAccountName or userPrincipalName with the id of their sAMAccountName.

<Created LDAP principal for id [{sAMAccountName}] and [8] attributes>

2019-12-13 16:01:33,929 DEBUG [org.apereo.cas.authentication.principal.resolvers.ChainingPrincipalResolver] - <Resolved principal [SimplePrincipal(id={sAMAccountName}, attributes={mail=[mail], sAMAccountName=[username], displayName=[displayName], givenName=[firstname], cn=[cn], sn=[lastname], title=[title], userPrincipalName=[UPN]})]>
2019-12-13 16:01:33,929 DEBUG [org.apereo.cas.authentication.principal.resolvers.ChainingPrincipalResolver] - <Resolved principal [SimplePrincipal(id={login crediential from form}, attributes={})]>
2019-12-13 16:01:33,929 DEBUG [org.apereo.cas.authentication.principal.resolvers.ChainingPrincipalResolver] - <Resolved principal [SimplePrincipal(id={sAMAccountName}, attributes={mail=[mail], sAMAccountName=[username], displayName=[displayName], givenName=[firstname], cn=[cn], sn=[lastname], title=[title], userPrincipalName=[UPN]})]>
2019-12-13 16:01:33,929 DEBUG [org.apereo.cas.authentication.principal.resolvers.ChainingPrincipalResolver] - <Adding attributes [{mail=[mail], sAMAccountName=[username], displayName=[displayName], givenName=[firstname], cn=[cn], sn=[lastname], title=[title], userPrincipalName=[UPN]}] for the final principal>
2019-12-13 16:01:33,929 DEBUG [org.apereo.cas.authentication.CoreAuthenticationUtils] - <Merged attributes with the final result as [{mail=[mail], sAMAccountName=[username], displayName=[displayName], givenName=[firstname], cn=[cn], sn=[lastname], title=[title], userPrincipalName=[UPN]}]>
2019-12-13 16:01:33,929 DEBUG [org.apereo.cas.authentication.principal.resolvers.ChainingPrincipalResolver] - <Principal resolvers produced [2] distinct principal IDs [[{email from login form}, {sAMAccountName}]]; last resolved principal ID will be the final principal ID>
2019-12-13 16:01:33,929 DEBUG [org.apereo.cas.authentication.principal.resolvers.ChainingPrincipalResolver] - <Final principal constructed by the chain of resolvers is [SimplePrincipal(id={sAMAccountName}, attributes={mail=[mail], sAMAccountName=[username], displayName=[displayName], givenName=[firstname], cn=[cn], sn=[lastname], title=[title], userPrincipalName=[UPN]})]>
2019-12-13 16:01:33,929 DEBUG [org.apereo.cas.authentication.PolicyBasedAuthenticationManager] - <[ChainingPrincipalResolver(principalFactory=org.apereo.cas.authentication.principal.DefaultPrincipalFactory@1, chain=[PersonDirectoryPrincipalResolver(attributeRepository=org.apereo.services.persondir.support.CachingPersonAttributeDaoImpl@47ab92a6, principalFactory=org.apereo.cas.authentication.principal.DefaultPrincipalFactory@1, returnNullIfNoAttributes=false, principalNameTransformer=org.apereo.cas.authentication.principal.resolvers.PersonDirectoryPrincipalResolver$$Lambda$25176/0x000000010e0c5440@17f5fe, principalAttributeNames=sAMAccountName,mail, useCurrentPrincipalId=false, resolveAttributes=true, activeAttributeRepositoryIdentifiers=[]), EchoingPrincipalResolver()])] resolved [SimplePrincipal(id={sAMAccountName}, attributes={mail=[mail], sAMAccountName=[username], displayName=[displayName], givenName=[firstname], cn=[cn], sn=[lastname], title=[title], userPrincipalName=[UPN]})] from [RememberMeUsernamePasswordCredential(super=UsernamePasswordCredential(username={email from form}, source=null, customFields={}), rememberMe=false)]>
2019-12-13 16:01:33,929 DEBUG [org.apereo.cas.authentication.PolicyBasedAuthenticationManager] - <Final principal resolved for this authentication event is [SimplePrincipal(id={sAMAccountName}, attributes={mail=[mail], sAMAccountName=[username], displayName=[displayName], givenName=[firstname], cn=[cn], sn=[lastname], title=[title], userPrincipalName=[UPN]})]>

This result in the correct SimplePrincipal being created even though the second SimplePrincipal that was created with the email that was entered on the form was discarded because it did not match and it had not attributes.

Here are my properties for the person directory.

cas.personDirectory.principalAttribute=sAMAccountName,mail

cas.authn.attributeRepository.merger=ADD

cas.authn.attributeRepository.defaultAttributesToRelease=sn,cn,givenName,mail,title,sAMAccountName,userPrincipalName,displayName,Tech_ID,uid

cas.authn.attributeRepository.jdbc[0].driverClass=com.microsoft.sqlserver.jdbc.SQLServerDriver

cas.authn.attributeRepository.jdbc[0].dialect=org.hibernate.dialect.SQLServerDialect

cas.authn.attributeRepository.jdbc[0].sql=SELECT ID FROM dataStore WHERE {0}

cas.authn.attributeRepository.jdbc[0].username=UserName

When the user signs the attributeRepository ignores the SimplePrincipal id and uses the account name that was used to sign in to CAS. This works if the user uses their sAMAccountName and the data returns correct and then is matched with the SimplePrincipal id and the attribute is merged. When the user user their email I need the ability to use the either an attribute return from the LDAP authentication (sAMAccountName) or the SimplePrincipal id. The current process always uses the data entered into the login form which does not match to pull data.

Here is the logs that show this.

2019-12-13 16:01:33,929 DEBUG [org.apereo.cas.authentication.principal.resolvers.PersonDirectoryPrincipalResolver] - <CAS will NOT be using the identifier from the resolved principal [SimplePrincipal(id={sAMAccountName }, attributes={mail=[ma...@example.com], sAMAccountName=[{UserName}], displayName=[displayName], givenName=[FirstName], cn=[CN], sn=[LastName], title=[title], userPrincipalName=[UPN]})] as it's not configured to use the currently-resolved principal id and will fall back onto using the identifier for the credential, that is [{user login which is email}], for principal resolution>
2019-12-13 16:01:33,929 DEBUG [org.apereo.cas.authentication.principal.resolvers.PersonDirectoryPrincipalResolver] - <Extracted principal id [{user login which is email}]>
2019-12-13 16:01:33,929 DEBUG [org.apereo.cas.authentication.principal.resolvers.PersonDirectoryPrincipalResolver] - <Creating principal for [{user login which is email}]>
2019-12-13 16:01:33,929 DEBUG [org.apereo.cas.authentication.principal.resolvers.PersonDirectoryPrincipalResolver] - <Principal id [{user login which is email}] did not specify any attributes>
2019-12-13 16:01:33,929 DEBUG [org.apereo.cas.authentication.principal.resolvers.PersonDirectoryPrincipalResolver] - <Returning the principal with id [{user login which is email}] without any attributes>
2019-12-13 16:01:33,929 DEBUG [org.apereo.cas.authentication.principal.resolvers.ChainingPrincipalResolver] - <Resolved principal [SimplePrincipal(id={user login which is email}, attributes={})]>

And the merge fails because the two SimplePrincipal id do not match but this does not matter until I am able to return attributes using the sAMAccountName attribute instead of what the user entered into the form.

I hope I have provided enough information for you to understand the issue.

Thank you

Scott