Hi Rodolphe, Thank you for sharing the information, this is really helpful. This work-around may be something we look into implementing.
John On Thu, Mar 10, 2022 at 12:46 AM Rodolphe Prin <[email protected]> wrote: > 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/CAON9TV1EscU_BV-U_Hq%3DTU9zNekc9XK4dsU%2B7Vfjhb2w-_jbog%40mail.gmail.com.
