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/2f75b994-2e73-4b2c-864f-b275cd0fe6d6n%40apereo.org.

Reply via email to