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

On Friday, 30 July 2021 at 06:00:50 UTC+8 William Jojo wrote:

> 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
>
>
>
> On Thu, Jul 29, 2021 at 1:55 PM William Jojo <joj...@gmail.com> wrote:
>
>> 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
>>
>>
>>
>> On Wed, Jul 28, 2021 at 6:52 PM William Jojo <joj...@gmail.com> wrote:
>>
>>> 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
>>>
>>> -- 
>>> - 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
>>>  
>>> <https://groups.google.com/a/apereo.org/d/msgid/cas-user/41fec87d-5c75-40e1-8df6-6154201c5112n%40apereo.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>>

-- 
- 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+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/5e1e1b2e-35aa-46c7-b379-b1ad890d7279n%40apereo.org.

Reply via email to