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 cas-user+unsubscr...@apereo.org. 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.
