CAS 6.6 no automatic redirect after OIDC logout

[Udo Einspanier]

Hi,

we have CAS 6.6 as OIDC provider. When our client initiates logout, it goes to https://.../cas/oidc/oidcLogout?post_logout_redirect_uri=https:/...

In the YAML configuration we have:

cas:

logout:
followServiceRedirects: true
removeDescendantTickets: true

I would expect CAS to redirect to the URL in parameter post_logout_redirect_uri, but instead

shows a logout page titled "Logout successful" where the user can click on the logout URL

specified in the logout request.

Is there some additional setting required for OIDC, or are we missing something to allow automatic

redirect without user interaction?

Thanks and best regards,

Udo

[Meysam Shirazi]

It needs idToken in id_token_hint url parameters) that contains clientId, it can be the same id token that be retrieved in login process.

[Udo Einspanier]

Hi Meysam,

thanks for the quick reply. Yes, id_token_hint is part of the URL, I just left it out for brevity but should have included it. So here is the URL from CAS OIDC logout page with all parameters:

https://.../cas/oidc/oidcLogout?id_token_hint=...&post_logout_redirect_uri=https://...

But still no redirect from CAS to post_logout_redirect_uri.

Any other ideas?

Thanks,

Udo

[Meysam Shirazi]

Hi Udo

Change cas.log.level  to debug or make org.apereo.cas.oidc log level to trace to see what happening. 

common reason is post_logout_redirect_uri does not match service, means post_logout_redirect_uri is not define as logoutUrl or matching service id in your service definition.

[Udo Einspanier]

Thanks again for the suggestions. My understanding of logoutUrl was that this is used by CAS to send the SLO request to, but is not related to the redirect after logout. I would understand if the redirect has to match the serviceId, though.

I checked the logs and found this message, which sounds like CAS is trying to find the SSO session based on the id_token_hint, but does not succeed. Probably because the token is not stored as a session key, but I don't know what some of the ticket types mean:

2023-11-14T13:08:31,304Z [http-nio-8080-exec-2] ERROR o.a.c.t.DefaultTicketCatalog:37 eup.sso.cas {"message": "Ticket definition for [here comes my id_token] cannot be found in the ticket catalog which only contains the following ticket types: [[TGT, ST, RT, AT, PT, TST, OC, SART, ODUC, PGT, SATQ, ODT]]"}

Any other suggestions?

[Udo Einspanier]

I also tried to always redirect to the same URL using redirect-url in the configuration, but this does not work eithr and shows the some logout page as before:

cas:

logout:
followServiceRedirects: false
removeDescendantTickets: true
redirect-url: "https://..."

[Meysam Shirazi]

About the logoutUrl I said that based on this parts of code:

The ticket catalog error needs more details, so set cas.log.level to debug or trace for more details.

The configuration is cas.logout.follow-service-redirects, and the default value is false, but I think it's working if you send the request to default /logout url.

[Udo Einspanier]

Thanks again. Agreed, that actually that looks like the redirect URI and logout URI must match.
I found that the error in the logs appears not in the request to /oidcLogout, but to /revoke. Our client revokes the access token it received during login before sending the logout request, and that is where the error happens. So probably it is not related to the redirect problem (but still if you know why it happens would be good to know).
I attached the debug log output for the revoke and succeeding logout request (replaced id_toke, access_token and host with dummy values). During logout I see at least this line which sounds like the post_logout_redirect_uri is fine:

2023-11-15T09:49:04,667Z [http-nio-8080-exec-1] DEBUG o.a.c.o.w.c.l.OidcLogoutEndpointController:107 eup.sso.cas {"message": "Requested logout URL [https://cas.server/profile] is authorized for redirects"}

Not sure what you mean with "if you send the request to default /logout url". Shouldn't the OIDC logout request always be sent to the end_session_endpoint advertised in .well-known metadata?

[Meysam Shirazi]

As you stated, the logout redirect is working:

2023-11-15T09:49:04,668Z [http-nio-8080-exec-1] DEBUG o.a.c.o.w.c.l.OidcLogoutEndpointController:145 eup.sso.cas {"message": "Final logout redirect URL is [https://cas.server/profile?client_id=test_jan]"}

Regarding the issue with revoking the access token, it appears that the token is incorrect. Is there an access token (AT-5-QAnGNlAgqS-HC5e0KuklngTKvA-ugvk5) that was erased following a request for a logout, but the client sent the incorrect token that begins with (access_tokensnkL58fGsQSM1f...) and is therefore not listed in the ticket catalog because it does not begin with any of these ticket prefixes? (TGT, ST, RT, AT, PT, TST, OC, SART, ODUC, PGT, SATQ, ODT).

/logout endpoint, not /oidc/logout or /oidcLogout, is the default logout url. It is the typical  logout in CAS protocol endpoint with a service parameter.

[Meysam Shirazi]

Edit: ? --> :

prefixes? (TGT, ST, RT, AT, PT, TST, OC, SART, ODUC, PGT, SATQ, ODT). --> prefixes: (TGT, ST, RT, AT, PT, TST, OC, SART, ODUC, PGT, SATQ, ODT).

[Udo Einspanier]

Thanks for patience and ongoing support.

The redirect is not working as I expect. Expected behavior: the browser is redirected automatically to the URL specified in post_logout_redirect_uri. Actual behavior: CAS shows this page, where the user has to manually click on the logout link that was supplied by the client (GO TO ...).

Is automatic redirect supported? If yes, do you know the required configuration?

No, the client does not receive an access token of the form "AT-...". We have specified the access tokens to be encoded as JWT, via "jwtAccessToken": true in the service definition. So the client sends the JWT as "token" parameter to /revoke endpoint, which should be according to the protocol specification. But my assumption is that CAS does not handle JWT access tokens correctly during revoke. The  access_tokensnkL58fGsQSM1f that you mention is because I wanted to replace the JWTs (id/acces_token) in the log with dummy values, because they contain the server URL.

Yes, I am aware that /logout is the endpoint to use for the CAS protocol. But our client uses OIDC and not CAS protocol. So, it sends the logout request to "end_session_endpoint" defined in https://cas.server/cas/oidc/.well-known. Why would we require another protocol just for the logout?

[Meysam Shirazi]

It appears that CAS displays the logout request on the logout page when using front channel logout. For auto redirect logout, use "logoutType": "BACK_CHANNEL" in the service definition.

Yes, it appears that revoking by jwt token is not yet implemented.

Concerning the logout endpoint, I just realized that the cas.logout.follow-service-redirects setting is being used for the CAS protocol with the /logout endpoint rather than the oidc protocol with the /oidcLogout endpoint.

[Udo Einspanier]

Yes, switching to BACK_CHANNEL solved the problem! I think I configured it as FRONT_CHANNEL initially because the client is a UI without any server-side components, so back channel did not make much sense. I did not think about the redirect.

The unsupported token revocation is currently no problem for our app, because the token is correctly removed during SLO. I don't think we have a use case where the access token has be revoked separately. But still good to know that this is a limitation for now.

Thanks again for your help,

Udo

[Meysam Shirazi]

Sounds great 

It is a pleasure to assist.