Hi, this is what I did to deal with that problem : in my case I was retrieving attributes from the authentication source (LDAP) with the following configuration ``` cas.authn.ldap[0].principal-attribute-list=displayName,givenName,mail,sn cas.authn.ldap[0].additional-attributes=memberOf ``` and then trying to map these attributes to standard OIDC claim names ``` cas.authn.oidc.core.claims-map.name=displayName cas.authn.oidc.core.claims-map.given_name=givenName cas.authn.oidc.core.claims-map.email=mail cas.authn.oidc.core.claims-map.family_name=sn cas.authn.oidc.core.claims-map.groups=memberOf ``` With this configuration I had wrong claim names in the token (for example givenName instead of name), as mentionned in this thread.
I changed my configuration to resolve attributes with the attribute repository method, wich allows mapping attributes directly from the attibute source. It seems though that this is not the recommended way when the authentication source is the same as the attribute source, as mentionned here (https://apereo.github.io/cas/6.4.x/integration/Attribute-Resolution.html#person-directory) So my new configuration is ``` # cas.authn.ldap[0].principal-attribute-list= # cas.authn.ldap[0].additional-attributes= cas.person-directory.active-attribute-repository-ids=ldapRepository cas.authn.attribute-repository.ldap[0].order=0 cas.authn.attribute-repository.ldap[0].ldap-url=xxxxxxxxx cas.authn.attribute-repository.ldap[0].base-dn=xxxxxxx cas.authn.attribute-repository.ldap[0].search-filter=xxxxxxxxxx cas.authn.attribute-repository.ldap[0].bind-dn=xxxxxxx cas.authn.attribute-repository.ldap[0].bind-credential=xxxxxxxxx cas.authn.attribute-repository.ldap[0].attributes.cn=name cas.authn.attribute-repository.ldap[0].attributes.givenName=given_name cas.authn.attribute-repository.ldap[0].attributes.mail=email cas.authn.attribute-repository.ldap[0].attributes.sn=family_name cas.authn.attribute-repository.ldap[0].attributes.memberOf=groups ``` This way the "CAS" attributes are directly matching standard OIDC claim names, so no need to define OIDC attributes mappings, and I bypass the "seems to be a" bug. This impacts however every attributes release, not only OIDC services. So for every other services that needs releasing attributes I formely mapped, I was forced to map them at the service level so that they get their original "LDAP" name, for instance : ``` "attributeReleasePolicy": { "@class": "org.apereo.cas.services.ReturnMappedAttributeReleasePolicy", "allowedAttributes" : { "@class" : "java.util.TreeMap", /*in : out */ "email" : "mail", "name": "displayname" } }, ``` I do not know if this can apply to your case, but I hope it helps... Rodolphe Le mercredi 9 mars 2022 à 16:47:15 UTC+1, John Wagenleitner a écrit : > 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/c3b61db7-0abf-4c65-9c1f-a5afdc2388ddn%40apereo.org.
