Hi Jae,
Thank you very much for your email. That is a good work-around/fix for the
issue. I removed the `scopes` key in the service definition file completely
and in the `cas.properties` removed all of the
`cas.authn.oidc.core.claims-map` entries.
I used the following attribute release policy in my service definition to
do the mappings (had tried this before, but it doesn't work with the
`scopes` set):
"""
"attributeReleasePolicy" : {
"@class": "org.apereo.cas.services.ReturnMappedAttributeReleasePolicy",
"allowedAttributes": {
"@class": "java.util.TreeMap",
"mail": "email",
"cn": "name",
"sn": "family_name",
"givenName": "given_name"
}
}
"""
With those changes (using CAS v6.5.0), now the correct names (email, name,
family_name, given_name) appear in both the IDToken and userinfo endpoint.
Thanks again,
John
On Tue, Mar 15, 2022 at 12:03 AM Jae Liu <[email protected]> wrote:
> Hi John,
>
> I removed the claims-map in config and following are my
> attributeReleasePolicy
>
> attributeReleasePolicy:
> {
> @class: org.apereo.cas.services.ChainingAttributeReleasePolicy
> policies:
> [
> java.util.ArrayList
> [
> {
> @class:
> org.apereo.cas.services.ReturnAllowedAttributeReleasePolicy
> principalAttributesRepository:
> {
> @class:
> org.apereo.cas.authentication.principal.DefaultPrincipalAttributesRepository
> mergingStrategy: REPLACE
> ignoreResolvedAttributes: false
> }
> order: 0
> allowedAttributes:
> [
> java.util.ArrayList
> [
> mail
> displayName
> sAMAccountName
> userPrincipalName
> ]
> ]
> }
> {
> @class:
> org.apereo.cas.services.ReturnMappedAttributeReleasePolicy
> allowedAttributes:
> {
> @class: java.util.TreeMap
> email: groovy { return attributes[ 'mail' ].get(0)
> }
> email_verified: groovy { if(!attributes[ 'mail'
> ].isEmpty() && attributes[ 'mail' ].get(0).endsWith('@xxxx.com')){ return
> true } else { return false } }
> name: groovy { return attributes[ 'displayName'
> ].get(0) }
> nickname: groovy { return attributes[
> 'sAMAccountName' ].get(0) }
> preferred_username: groovy { return attributes[
> 'userPrincipalName' ].get(0) }
> }
> principalAttributesRepository:
> {
> @class:
> org.apereo.cas.authentication.principal.DefaultPrincipalAttributesRepository
> mergingStrategy: REPLACE
> ignoreResolvedAttributes: false
> }
> order: 1
> }
> ]
> ]
> mergingPolicy: REPLACE
> order: 0
> }
>
> *also removed the scopes*
>
> scopes:
> [
> java.util.HashSet
> []
> ]
>
>
> 在2022年3月9日星期三 UTC+8 23:47:15<John Wagenleitner> 写道：
>
>> Hi Jae,
>>
>> Thanks for the reply, are you able to share any of your config?
>>
>> In my case both the IDToken and the userinfo endpoint contain claims such
>> as `mail` and `cn`. But the `claims-map` only seems to work for the
>> userinfo endpoint, which returns both claims `mail` and `email` and `cn`
>> and `name`, though I would have not expected it to include both the
>> original CAS attribute (from LDAP such as cn) and the mapped claim (such as
>> email) and think in versions prior to v6.4 it returned only `email` as a
>> claim name for that particular value.
>>
>> so the attributes in your claims-map do not have value, so the IDToken
>>> does have value.
>>
>>
>> In my claim-map I'm mapping `cn` to `name`. The IDToken we receive does
>> include `cn` as a claim. Based on my mapping settings, I would have
>> expected the claim name to be `name` and not `cn` both in the IDToken and
>> in the userinfo endpoint and this is how it worked prior to v6.4.
>>
>> John
>>
>> On Tue, Mar 8, 2022 at 5:55 PM Jae Liu <[email protected]> wrote:
>>
>>> I used CAS v6.4 it's ok for me.
>>>
>>> I think there something wrong with your configuration. You defined the
>>> scopes (scopes=openid,profile,emai), CAS will use these as attributes
>>> release policy, the scopes email will only release attributes email and
>>> email_verified, profile will release name, given_name. family_name, so the
>>> attributes in your claims-map do not have value, so the IDToken does have
>>> value.
>>>
>>> 在2022年1月11日星期二 UTC+8 12:28:01<John Wagenleitner> 写道：
>>>
>>>> In CAS v6.3 (up to and including v6.3.7.4) we used the
>>>> `cas.authn.oidc.claims-map` properties to map our LDAP attribute names to
>>>> the standard claim names. This mapping worked for both the ID Token and the
>>>> UserInfo (`/profile`) endpoint.
>>>>
>>>> Here are the relevant properties we have set:
>>>>
>>>> ```
>>>> cas.authn.oidc.discovery.scopes=openid,profile,email
>>>> cas.authn.oidc.discovery.claims=sub,name,family_name,given_name,email
>>>> cas.authn.oidc.core.claims-map.email=mail
>>>> cas.authn.oidc.core.claims-map.name=cn
>>>> cas.authn.oidc.core.claims-map.family_name=sn
>>>> cas.authn.oidc.core.claims-map.given_name=givenName
>>>> ```
>>>>
>>>> This mapping is no longer working in CAS v6.4 (and also tested in the
>>>> latest v6.4.4.2) for the generated ID Token. Our ID Token claims no longer
>>>> contain the mapped names but instead contain the LDAP attribute names such
>>>> as `mail`, `cn`, etc. The UserInfo endpoint does correctly contain the
>>>> mapped claim names.
>>>>
>>>> As a possible workaround, I tried using a service definition that
>>>> included an `attributeReleasePolicy` using the
>>>> `ReturnMappedAttributeReleasePolicy` class but that had no affect on the ID
>>>> Token claim names.
>>>>
>>>> I have reviewed all the OIDC settings and didn't spot anything that
>>>> looks like it would address this issue.
>>>>
>>>> Any help/advice would be appreciated,
>>>> John
>>>>
>>>>
--
- 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAON9TV2cXu3htvTeu%3D%2BAh06j83b2KSNejjduNV_ZYJMLngUDtw%40mail.gmail.com.
