CAS 6.3.5-Azure AD Delegation-OIDC-JDBC-LDAP

[William Jojo]

Hello,

I will try to keep this to the point.

CAS is using the subject claim from AzureAD Delegation upon return from auth and setting it as the username regardless of the setting of:

cas.authn.pac4j.oidc[0].azure.principal-attribute-id=email

I can use email, upn, does not matter, it is always the subject (sub) claim from AzureAD. Even when I tried generic:

cas.authn.pac4j.oidc[0].generic.principal-attribute-id=email

I am getting all the way through the delegation, completing the authentication, completing the MFA on the account and returning to the app only to have the username be the subject (sub) claim. 

Even if I set the usernameAttributeProvider it does not change anything.

Anyone have an idea of what is going on?

Bill

[William Jojo]

To anyone who is familiar with the username (user) value being set by the claims of OIDC in Azure AD Delegation. CAS is setting the username to the subject (sub) claim. This totally trashes the ability to use JDBC attribute resolution like:

2021-07-29 13:47:18,371 DEBUG [org.springframework.jdbc.core.JdbcTemplate] - <Executing prepared SQL query>
2021-07-29 13:47:18,372 DEBUG [org.springframework.jdbc.core.JdbcTemplate] - <Executing prepared SQL statement [SELECT username BANNER_LDAP, udc_id BANNER_UDC_ID, s_id BANNER_SID, banner_id BANNER_OID, dob BANNER_DOB, last4 BANNER_LAST4  FROM idmap WHERE username = ?]>
2021-07-29 13:47:18,377 DEBUG [org.springframework.jdbc.datasource.DataSourceUtils] - <Fetching JDBC Connection from DataSource>
2021-07-29 13:47:18,727 TRACE [org.springframework.jdbc.core.StatementCreatorUtils] - <Setting SQL statement parameter value: column index 1, parameter value [oASsZI-izB_hpkO3eXXXXXXXXXRqxY6uh6BkvzYNkY], value class [java.lang.String], SQL type unknown>

This is not the username. The UPN and other values look perfect - except this. I cannot find anything in the CAS docs or with Azure AD that allows me to compensate for this. Since the JDBC argument injection is so primitive there is no way for me to adjust and substitute another value at the time this gets invoked for additional attributes.

Can anyone shed light on this?

Thank you!

Bill

--
- 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+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/41fec87d-5c75-40e1-8df6-6154201c5112n%40apereo.org.

[William Jojo]

Hmmm, well this gets more interesting as I cannot seem to get CAS to Stop doing this:

2021-07-29 17:41:09,855 DEBUG [org.apereo.cas.integration.pac4j.authentication.handler.support.AbstractPac4jAuthenticationHandler] - <Authentication indicates usage of client principal attribute [upn] for the identifier [w.j...@hvcc.edu]>
2021-07-29 17:41:09,856 DEBUG [org.apereo.cas.integration.pac4j.authentication.handler.support.AbstractPac4jAuthenticationHandler] - <Final principal id determined based on client [...]

[successful auth]

2021-07-29 17:41:09,863 DEBUG [org.apereo.cas.authentication.principal.resolvers.PersonDirectoryPrincipalResolver] - <CAS will NOT be using the identifier from the resolved principal [SimplePrincipal(id=w.j...@hvcc.edu, attributes={access_token=[PAQABAAA [...] unique_name=[w.j...@hvcc.edu], upn=[w.j...@hvcc.edu], uti=[brPdbjEuO0KNgcIU456FAA], ver=[1.0]})] 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 [oASsZI-izB_hpkO3eSE_2Mg6rkWRqxY6uh6BkvzYNkY], for principal resolution>
2021-07-29 17:41:09,863 DEBUG [org.apereo.cas.authentication.principal.resolvers.PersonDirectoryPrincipalResolver] - <Extracted principal id [oASsZI-izB_hpkO3eSE_2Mg6rkWRqxY6uh6BkvzYNkY]>

I have been going over the docs for how the principal resolver and person directory works, but I am not getting any closer. 

Any insight would be most helpful. I cannot be the only person using the feature.

Bill

[Andy Ng]

Hi William,

A shot in the dark here, since not sure if my suggestion would work.

But in your service, have you tried setting principalIdAttribute to email and see if it would be effective?

https://apereo.github.io/cas/6.3.x/integration/Attribute-Release-Policies.html

Cheers,

- Andy

[Chia-Ying Yang]

I spent more time debugging the principal ID issue (see https://groups.google.com/a/apereo.org/g/cas-user/c/JVyjb_go1yQ), and was finally able to get it to behave by setting cas.person-directory.principal-resolution-conflict-strategy=first (default is last).  This allows the principal ID to be overridden by an attribute during attribute resolution.

What I don't fully understand is delegate authentication took place first, and attribute resolution via REST took place thereafter.  But while executing the strategy to resolve the multiple principals, the principal object returned by delegate authentication is actually second in the list, while the attribute resolution principal is first in the list.  This is totally counterintuitive -- I'm still trying to pinpoint how this happened and decide whether there is a bug somewhere.  The property above at least let me overcome this counterintuitive behavior and achieve what I want.

William maybe you want to give that a try to see if that helps in your case?

Chia-Ying