We have a few services that rely on being able to get the CAS ticket POST'd
back. When those services redirect the user to the CAS login page they
include the query string parameter `method=POST` in addition to the service
parameter.
This works with Duo in a frame (or if MFA is bypassed) but is
Upgrading from 6.1.7 to the 6.2.x release and noticing that once a custom
theme is displayed, that theme is displayed from that point on no matter
what theme the service definition specifies and it happens for all
browsers/users and not just on the browser that first requested the service
with
fixed it by disabling Spring thymeleaf
> caching. Performance testing shows no difference so seems like an OK fix.
> Try adding this to cas.properties:
>
> spring.thymeleaf.cache=false
>
> Jonathon
>
> On Wed, Oct 21, 2020 at 3:12 PM 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.aut
ims into the ID token without considering the response type. The
> behavior of this setting may change and it may be removed in future CAS
> releases.
>
> On Tue, Jan 11, 2022 at 5:28 AM John Wagenleitner <
> joh...@mail.fresnostate.edu> wrote:
>
>> In CAS v6.3 (up to and
gt; Hi,
>> I noticed the same behavior.
>> Version : 6.4.4.2
>>
>> `cas.authn.oidc.core.include-id-token-claims=true` allows to get the
>> claims in the token, but with the wrong name.
>>
>> Rodolphe
>>
>>
>> Le mardi 11 janvier 2022 à 20
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`
s.ReturnMappedAttributeReleasePolicy",
> "allowedAttributes" : {
> "@class" : "java.util.TreeMap",
> /*in : out */
> "email" : "mail",
> "name": "displayname"
> }
> },
> ```
> I do not know if this c
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
Hi Jae,
Yes, after the changes I checked both the IDToken and user profile
endpoint. What I noticed is that the IDToken only contains the mapped name
whereas the user profile endpoint contains both the original names and the
mapped names, both with values. But in our case that is ok.
Here is what
Just wanted to mention we see the same issue with v7.1.1 and consistently
happens with a load of 3 or more concurrent requests/users.
On Friday, October 11, 2024 at 8:37:46 AM UTC-7 Nathan Cailbourdin wrote:
Hi,
I am facing the exact same issue during my load testing since I upgraded
CAS to ve
We are also experiencing this same problem when moving from CAS v7.0.10 to
v7.1.5. In v7.1.5, after completing the login it goes to
`/oauth2.0/callbackAuthorize` and from there a 302 redirect to the service
(redirect_uri) is made with no query parameters.
In v7.0.10 where it is working, after `
right path? does it change during the login process (which
> should not happen)? ...
>
> Thanks.
> Best regards,
> Jérôme
>
>
>
> Le lun. 10 mars 2025 à 22:57, 'John Wagenleitner' via CAS Community <
> cas-user@apereo.org> a écrit :
>
>> We are
13 matches
Mail list logo
