Hi Ray, > I assume you have seen >https://apereo.github.io/cas/6.1.x/installation/Logout-Single-Signout.html#redirecting-logout-to-serviceYes, > that's exactly what I'm using (but at first I didn't understand it completely >- I know OIDC but I'm a newbie in CAS) > Is myapp.com different from mysite.com or is that a typo? I meant; myapp (available at https://app1.mysite.com) will send the user to the portal logout page.
hence the app1 application will redirect the user to https://cas.mysite.com/cas/oidc/logout?id_token_hint=xxx&post_logout_redirect_uri=https%3A%2F%2Fportal.mysite.com%2Fauth%2Flogout This means that :1. app1 needs to clean up its local session (in browser sessionStorage) (since we have multiple apps we can will have app1, app2, etc...)2. app1 redirects to CAS for logout3. CAS cleans up the CAS Session4. CAS redirects the end-user to the portal app (ie https://portal.mysite.com/auth/logout?local=true)5. Portal will clean up its local session6. Portal will redirect the user to a a logout success page (i.e. https://portal.mysite.com/auth/logout-success) And so after reading your answer, I now have a working solution - without requiring any regex in the logoutUrls (thanks !!!) Solution A: (CAS 6.1.5) In this solution, appX doesn't send any post_logout_redirect_uri parameter (requires CAS 6.1.5, it fixes an issue in OIDC logout).When CAS receives a OIDC logout request without post_logout_redirect_uri, it will redirect the user to the first element in logoutUrl. this matches the > 3. app1.myapp.com goes to cas/logout with no post_logout_redirect_url, cas/logout calls app1.myapp.com with a logout request which gets forwarded to myapp.com/auth/logout And we have this corresponding configuration (important parts are logoutUrl value that needs to match the Portal serviceId): ```# one section for each appX{ "@class": "org.apereo.cas.services.OidcRegisteredService", "clientId": "appX", "clientSecret": "secret", "name": "App X", "serviceId" : "^https://appX.mysite.com", "logoutUrl" : "https://portal.mysite.com/auth/logout?local=true", "jwtAccessToken": true, "bypassApprovalPrompt": true, "signIdToken": true, "id": 10}# single declaration for portal page{ "@class": "org.apereo.cas.services.OidcRegisteredService", "clientId": "portal", "clientSecret": "secret", "name": "Portal", "serviceId" : "^https://portal.mysite.com/.*", "logoutUrl" : "https://portal.mysite.com/logout-success", "jwtAccessToken": true, "bypassApprovalPrompt": true, "signIdToken": true, "id": 1}``` Solution B:Same configuration but doesn't require CAS 6.1.5? The client app needs in the initial OIDC mlogout request the post_logout_redirect_uri parameter to https://portal.mysite.com/auth/logout?local=true Thanks for your help once more Ray ! Cheers, Adrian Le jeudi 12 mars 2020 à 01:02:23 UTC+1, Ray Bon <[email protected]> a écrit : Adrian, I have not used OIDC in cas so there may be some bits that I am unaware of.I assume you have seen https://apereo.github.io/cas/6.1.x/installation/Logout-Single-Signout.html#redirecting-logout-to-service Is myapp.com different from mysite.com or is that a typo? If I understand correctly, you want cas to send a logout request to the generic logout page (myapp.com/auth/logout)? Here are some possible scenarios that may meet your requirement(s):1. add myapp.com/auth/logout as a service in the registry2. app1.myapp.com goes to myapp.com/auth/logout which cleans app1 session and redirects to cas/logout with no post_logout_redirect_url3. app1.myapp.com goes to cas/logout with no post_logout_redirect_url, cas/logout calls app1.myapp.com with a logout request which gets forwarded to myapp.com/auth/logout With CAS protocol single logout, when one application hits cas/logout, cas sends logouts to all applications in that TGC's session. For those logouts, the login URL is used unless a logoutUrl is set in the service, which is used instead. If this is the case with OIDC, you can not control which other endpoints will be targeted. Is the post_logout_redirect_url for performing logout or is it for user experience (e.g., some generic landing page) (not clear in the link above)? Note: needFrontSlo most likely refers to front or back channel logout, not the type of application. Ray On Wed, 2020-03-11 at 18:51 +0000, 'Adrian Gonzalez' via CAS Community wrote: Hi Ray, Sorry for not having replied earlie, I'm a bit ashamed :( (I was working on other topics, but still my fault I was asking the question in the first place) The use case for having this regex is that I'm using the same client for multiple applications. Hence:- I'm using the same clientId for multiple front end apps (i.e. app1.mysite.com, app2.mysite.com, etc...).- so atm, I have a serviceId like "serviceId": "http://.+\.mysite.com/.*"; - I'd have liked to use a similar logoutUrl "logoutUrl": "http://.+\.mysite.com/.*"; And I'm using OIDC implicit flow and the OIDC front end logout mechanism for all this - hence my client is a front end app. And when my client initiated a OIDC logout request, the client app could do something like this URL:https://cas.local/cas/oidc/logout?id_token_hint=xxx&post_logout_redirect_uri=https%3A%2F%2Fmyapp.com%2Fauth%2Flogout That is the OIDC client can send a particular logoutUrl.CAS can then check that this particular URL is one of the registered logoutUrls and can then redirect back to this particular Url. Looking at the current implementation in CAS, I see that 2 CAS components are involved in the logout process: OidcLogoutEndpointController and LogoutAction. And LogoutAction is being used by SAML, CAS and OIDC protocols.Hence not so easy to fit the logoutUrl as a feature without impacting the other protocols. >From what I see in the code, OidcLogoutEndpointController retrieves the asked >logoutUrl from post_logout_redirect_uri and checks that it correspond one of >the logoutUrl of the registered client (it uses id_token_hint to retrieve the >client).It then propagates the asked logoutUrl as the 'service' parameter to >LogoutAction.LogoutAction uses this parameter as serviceId to retrieve check >that the client is registered (btw, it implied that the logoutUrl matches the >serviceId - I don't get the rationale).If it matches, then it redirects to the >asked logoutUrl.btw, using the debugger I see that needFrontSlo=false in the >LogoutAction (I would have expected it to be true since my client is a front >end). So all in all, I don't see an elegant way to implement this corner case feature atm :( Thanks,Adrian Le jeudi 5 mars 2020 à 20:30:33 UTC+1, Ray Bon <[email protected]> a écrit : Adrian, If logout URL is not set in service definition, the one passed to cas during login is used.How would cas know where to send the logout request with a regex? What is the use case with regard to OIDC that a regex might be useful? Perhaps allow for a list of URLs. I am not familiar enough with other CAS clients but the java cas client uses filters to check incoming requests. Thus, the actual target URI does not matter (path, parameters, etc). Ray On Thu, 2020-03-05 at 09:26 -0800, gonzalad na wrote: Hello, I'm a new CAS User (CAS 6.1.4), I'm using OIDC for logout. Is there a way to use a regex as logoutUrl (in the same way it's possible to use a regex for the serviceId ?) If not is it possible to contribute to have this feature in CAS ? I suspect a simple change in OidcLogoutEndpointController (https://github.com/apereo/cas/blob/d8552017af435e5894006efb64922f50e107349a/support/cas-server-support-oidc-core-api/src/main/java/org/apereo/cas/oidc/web/controllers/logout/OidcLogoutEndpointController.java#L70-L75) should do the trick. But this would impact existing CAS users. wdyt ? Thanks very much,Adrian -- Ray BonProgrammer AnalystDevelopment Services, University Systems2507218831 | CLE 019 | [email protected] I respectfully acknowledge that my place of work is located within the ancestral, traditional and unceded territory of the Songhees, Esquimalt and WSÁNEĆ Nations. -- - 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/62e1a4c4d205153d1dce433fec283405c15fd1e0.camel%40uvic.ca. -- Ray BonProgrammer AnalystDevelopment Services, University Systems2507218831 | CLE 019 | [email protected] I respectfully acknowledge that my place of work is located within the ancestral, traditional and unceded territory of the Songhees, Esquimalt and WSÁNEĆ Nations. -- - 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/d82c02d6ba84647d0fe7a340f24fb85edd764540.camel%40uvic.ca. -- - 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/1110238859.1389694.1584016207516%40mail.yahoo.com.
