Sounds great It is a pleasure to assist. On Monday, November 20, 2023 at 10:32:41 AM UTC+3:30 Udo Einspanier wrote:
> 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 > > On Friday, November 17, 2023 at 7:21:45 PM UTC+1 Meysam Shirazi wrote: > >> 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. >> >> On Friday, November 17, 2023 at 5:30:02 PM UTC+3:30 Udo Einspanier wrote: >> >>> 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 ...). >>> [image: logout.png] >>> 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? >>> >>> On Thursday, November 16, 2023 at 10:18:57 PM UTC+1 Meysam Shirazi wrote: >>> >>>> 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*). >>>> >>>> On Thursday, November 16, 2023 at 11:00:30 PM UTC+3:30 Meysam Shirazi >>>> wrote: >>>> >>>>> 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 >>>>> <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 >>>>> <https://apereo.github.io/cas/6.6.x/protocol/CAS-Protocol-Specification.html#23-logout> >>>>> >>>>> endpoint with a service parameter. >>>>> >>>>> On Wednesday, November 15, 2023 at 4:44:19 PM UTC+3:30 Udo Einspanier >>>>> wrote: >>>>> >>>>>> 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? >>>>>> >>>>>> >>>>>> On Tuesday, November 14, 2023 at 8:06:28 PM UTC+1 Meysam Shirazi >>>>>> wrote: >>>>>> >>>>>>> About the logoutUrl I said that based on this parts of code: >>>>>>> [image: Untitled 2.png] >>>>>>> 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. >>>>>>> On Tuesday, November 14, 2023 at 5:25:48 PM UTC+3:30 Udo Einspanier >>>>>>> wrote: >>>>>>> >>>>>>>> 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://..."; >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Friday, November 10, 2023 at 8:56:25 AM UTC+1 Meysam Shirazi >>>>>>>> wrote: >>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Friday, November 10, 2023 at 10:29:33 AM UTC+3:30 Udo >>>>>>>>> Einspanier wrote: >>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> On Friday, November 10, 2023 at 3:41:42 AM UTC+1 Meysam Shirazi >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> 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. >>>>>>>>>>> On Thursday, November 9, 2023 at 4:20:04 PM UTC+3:30 Udo >>>>>>>>>>> Einspanier wrote: >>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- - 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/b3122836-0a20-48ce-92cc-d4fce4ead7f3n%40apereo.org.
