CAS 7.1.1 - OIDC issue -> no information sent to redirect_uri

465 views
Skip to first unread message

Pierre Driutti

unread,
Nov 22, 2024, 11:06:15 AM11/22/24
to CAS Community

Hello,

 

I am using a test CAS 7.1.1 server running inside docker, using the below settings:

 

info:

  description: CAS Configuration

 

cas:

  service-registry:

    core:

      init-from-json: true

    json:

      location: file:/etc/cas/services

       

  http-web-request:

    cors:

      enabled: false

  server:

    name: http://cas:cas_port

    prefix: http://cas:cas_port/cas

  authn:

    accept:

      enabled: false

    authentication-attribute-release:

      enabled: true

    attribute-repository:

      ldap[0]:

        bind-dn: cn=rouser,dc=atih,dc=sante,dc=fr

        bind-credential: ldap_rouser_password

        base-dn: ou=agents,dc=atih,dc=sante,dc=fr

        search-filter: uid={user}

        ldap-url: ldap://openldap:ldap_port

        allow-multiple-entries: true

    ldap[0]:

      bind-dn: cn=admin,dc=atih,dc=sante,dc=fr

      bind-credential: ldap_admin_password

      base-dn: ou=agents,dc=atih,dc=sante,dc=fr

      search-filter: uid={user}

      password-encoder:

        type: NONE

      ldap-url: ldap://openldap:ldap_port

      use-start-tls: false

      type: AUTHENTICATED

    oauth:

      access-token:

        crypto:

          signing:

            key: 8PdeTwu4j0thSopZgFvg-oa5GR8GBTzzcmiIMo7Vh0EmoVdWK5yRw4U7bWyOFdI53CU0exVZQCtQlLwMWaJ_og

          encryption:

            key: JzJ51l362rOPDZLwhtRY3p0SJUUx5sf8ZEDAKDIkdeY

      crypto:

        signing:

          key: meT8P7qpaN6bH3Bq-MsbMYQEL0iwZirR-XE-WAJFJHWfFsEOWq57sOfeG5DJXkBIdjd5RfRT3jX6QCOAkrh99g

        encryption:

          key: R3i5XWWsA9WWFhLkkQFGaOprYeYt8FGTbiTmgQkkmxEv6wbN-9YUjiPkM0Gezw_T377ORjM31JG0QNkLwXA8PQ

      session-replication:

        cookie:

          crypto:

            signing:

              key: 8C59Wtz_K_NKozYZ7G5fBZ83II0MBBI702ZmEqdOzXIPAI5B1MDUSVmm8w4YYzaBRjsGwG9fZBPWf-JS4yW_QQ

            encryption:

              key: 50kNxo6EKFQk9KOUAm0UXWhS-52Xtw_yWatSRkBT3GVzvS5cCPr3VH9_TmyJu91isRTjc2fjEiAD0idV00CBLQ

    oidc:

      core:

        issuer: http://cas:cas_port/cas/oidc

      discovery:

        grant-types-supported:

          - authorization_code

          - "urn:ietf:params:oauth:grant-type:uma-ticket"

          - "urn:ietf:params:oauth:grant-type:token-exchange"

          - "urn:ietf:params:oauth:grant-type:device-code"

          - refresh_token

        token-endpoint-auth-methods-supported: client_secret_basic

        introspection-supported-authentication-methods: client_secret_basic

        response-types-supported:

          - code

          - token

          - id_token

          - id_token token

          - device_code

        prompt-values-supported:

          - none

          - login

          - consent

 

  logout:

    followServiceRedirects: true

    redirectParameter: service

    confirmLogout: true

  slo:

    disabled: false

  monitor:

    endpoints:

      endpoint:

        defaults:

          access: ANONYMOUS

 

  ticket:

    st:

      time-to-kill-in-seconds: PT3600S

 

server:

  port: cas_port

  ssl:

    enabled: false

    keyStore: file:/etc/cas/thekeystore

    keyStorePassword: changeit

    keyPassword: changeit

  servlet:

    context-path: /cas

  #

logging:

  level:

    org.apereo.cas: DEBUG

    org.springframework: INFO

 

management:

  endpoints:

    web:

      exposure:

        include: "*"

    enabled-by-default: true

  security:

    enabled: false

 

 

 

I am trying to contact it using OIDC. As such, I’ve defined statically an OidcRegisteredService as follows:

 

{

  "@class" : "org.apereo.cas.services.OidcRegisteredService",

  "serviceId" : "^https?://oidc-client-demo.*",

  "name": "OIDC Client Example",

  "id": 10,

  "evaluationOrder" : 10, 

  "clientId" : "demo-client",

  "clientSecret" : "demo-client-secret",

  "signIdToken" : false,

  "encryptIdToken" : false,

  "bypassApprovalPrompt" : false,

  "supportedGrantTypes" : [ "java.util.HashSet", [ "authorization_code"] ],

  "supportedResponseTypes" : [ "java.util.HashSet", [ "code" ] ],

  "supportedPromptValues": [ "java.util.HashSet", [ "consent" ] ],

  "scopes" : [ "java.util.HashSet", [ "openid","profile","email","address","phone" ] ],

  "attributeReleasePolicy": {

        "@class": "org.apereo.cas.services.ReturnAllAttributeReleasePolicy"

   }

}

 

However, my oidc client fails to work with it.

 

When it send an authentication request, I am prompted to enter credentials in a browser. Then, the following POST request is sent to my CAS server,

 

POST /cas/login?service=http%3A%2F%2Fcas%3A8080%2Fcas%2Foauth2.0%2FcallbackAuthorize%3Fclient_id%3Ddemo-client%26scope%3Dopenid%2520profile%2520email%26redirect_uri%3Dhttp%253A%252F%252Foidc-client-demo%252Fanything%252Fcallback%26re,

 

The authentication is successful, but then I do not see any approval popup being displayed, nor can I see in network traces that when it reaches my setup  redirect_uri any parameters are provided.

 

image.png


Thus, the process fails at this point…

 

Would you know if I did something wrong while setting up my CAS server and service ?

 

Of course, in the CAS logs,  I cannot see any error message during the process of the request…

 

Thanks in advance

 

Best regards,


Pierre

Ray Bon

unread,
Nov 22, 2024, 1:28:24 PM11/22/24
to cas-...@apereo.org

Pierre Driutti

unread,
Nov 25, 2024, 8:12:42 AM11/25/24
to cas-...@apereo.org
Hello Ray,

I thank you for your reply. As a matter of fact, I also have a GET request done to oidcAuthorize before I authenticate through the POST login request...

The issue I described occurs after the login is made, while the grants are checked on the CAS side. All grants are OK, I just don't have any parameter sent together with the redirect_uri...

Thanks in advance

Best regards,
Pierre
--
- Website: https://apereo.github.io/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to a topic in the Google Groups "CAS Community" group.
To unsubscribe from this topic, visit https://groups.google.com/a/apereo.org/d/topic/cas-user/Ra1X88kvSwE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cas-user+u...@apereo.org.
To view this discussion visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/425834a5514597cb3f844783661d967b24a660de.camel%40uvic.ca.

Karel Alvarez

unread,
Feb 4, 2025, 7:44:19 AMFeb 4
to CAS Community, Pierre Driutti
Hi, 
I am having the same problem, did you get a solution?
thanks!

John Wagenleitner

unread,
Mar 10, 2025, 5:57:32 PMMar 10
to CAS Community
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 `/oauth2.0/callbackAuthorize` there's an additional redirect to `/oidc/authorize` before the final redirect back to the service (redirect_uri) which includes the needed query parameters.

Jérôme LELEU

unread,
Mar 11, 2025, 5:16:59 AMMar 11
to cas-...@apereo.org
Hi,

The behavior is the following: after the callback has been performed, the originally requested URL (generally /oidc/authorize) is called.

If the originally requested URL cannot be found in the OIDC session, the redirect URI is called instead. I guess this is what happens here.

Generally, the OIDC session is held by the DISSESSIONOauthOidcServerSupport cookie. You should check it: is it defined on the right path? does it change during the login process (which should not happen)? ...

Thanks.
Best regards,
Jérôme



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 visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/819b60ab-636e-4713-8471-2b7e09b46a54n%40apereo.org.

John Wagenleitner

unread,
Mar 12, 2025, 11:12:45 AMMar 12
to cas-...@apereo.org
Hi Jérôme,

Thank you for the reply. In our case it does look like the cookie is changing during the process.

I see the `DISSESSIONOauthOidcServerSupport` cookie being set in the response to the initial request for `/oidc/authorize` (with settings of `Path=/; SameSite=None; Secure; HttpOnly`). On the next request for `/login` the cookie is sent in the request but not returned in the response (assuming this is expected). The next request is for `/oauth2.0/callbackAuthorize` where the cookie is sent in the request but a different cookie value is returned in the response (same settings of `Path=/; SameSite=None; Secure; HttpOnly` for the new value). And from there it redirects back to the service url with no parameters.

I tested this on a single instance running v7.1.5 and we use the Hazelcast ticket registry. The only configuration change we made when updating from v7.0.10 to v7.1.5 was to `cas.tgc.crypto.encryption.key`, we had to use a larger key size.

John

Reply all
Reply to author
Forward
0 new messages