CAM 1841- Redirecting to session after SSO login

In my case, if am not logged in previously, user is redirected to cockpit page instead of the specific process page

1 Like

Odd that you’re not able to reproduce the same behavior… what browser? What idp?

I may create a new bug report on this one. The more I think about it, the less I think Spring is involved here. Inspecting the session on the Spring side of things, I was reminded that the hash fragment wouldn’t make it to the server, so there’s nothing there to store. It would be up to the client side application to store it or the idp to propagate it. I’m not sure if storing that as part of the state is even part of the oauth spec. Might be worth getting Camunda’s feedback on this one. I’ll poke around a bit more this weekend.

1 Like

sure @jgigliotti. One more bug I found is, once the user is logged out from cockpit and tried to log back in with same URL, he is redirected to Camunda login page instead of SSO. If we delete the cookie or restart the browser only then user is redirected to SSO.

Even though user session is inactive, user have to either delete the cookies or restart the browser inorder to be redirected to SSO login page instead user is redirect to Camunda login page by default

I really appreciate you taking time on this to help @jgigliotti. thank you

No problem, caught my curiosity…

You’re probably going to have to implement a logout handler. I think the Camunda login page is going to essentially be the fallback. So your logout handler would have to first redirect you back to the idp’s logout url to invalidate the cookie and then potentially redirect you to a better place.

You can see something similar in the Keycloak example:

@jgigliotti I implemented this already. It really didn’t help resolve the issue.

Hi @jgigliotti, @abhilashk6303,

in order to make the logout work properly and trigger the configured LogoutHandler, you’ll have to intercept the logout functionality within Camunda’s WebApp as well. See e.g. https://github.com/camunda/camunda-bpm-identity-keycloak/tree/master/examples/sso-kubernetes/src/main/resources/META-INF/resources/webjars/camunda/app/cockpit for the Cockpit part, other app directories (for admin, tasklist, …) are parallel to that.

2 Likes

Hi @abhilashk6303,

besides some details for logout etc. - back to your original problem: “redirecting back to the original URL after login” in an SSO scenario is part of the SSO security stack and has not much todo with Camunda itself. When using Spring Boot with Spring Security 5 you’ll find some answers on how to achieve this here: https://www.baeldung.com/spring-security-redirect-login

Hope this helps.
Gunnar

Hey @VonDerBeck,

That’s the direction I was headed originally, but after thinking about it, I don’t think there’s anything you can do on the backend without some additional cooperation on the frontend. The fragment portion of the URL isn’t making it to the server, so Spring Security never knows about it. AFAIK, the best you can do is redirect to the base (which it is).

Thanks for all your inputs @VonDerBeck but like @jgigliotti spring Security redirect isn’t resolving the issue. I tried this approach and it didn’t help.

Hi @jgigliotti & @abhilashk6303

indeed you’re right. Spring Security can do a lot for us, when we e.g. get a complete URL to a single process and type or copy that directly to our browser. When it comes to expired sessions things might be different, depending on the front end technology. I had overlooked somehow this detail from the first post.

1 Like

can you please elaborate the issue in terms of front end technology, which component should I refer to, because we are just using a springboot-customized-webapp-webjar.jar from camunda.

@abhilashk6303 I created a ticket in JIRA. Feel free to follow along and add any relevant data I may have left out, we’ll see if we get any traction.

2 Likes

Thanks Justin, I’ll follow up on JIRA. I’ll post the solution, if I resolve it.

Hello, @jgigliotti @VonDerBeck !
I have the same issue (while not being logged in, the request’s hash-part is losing, e.g. taskId), can you tell, please, was there some solution found by this time?