1

While using a SSO to integrate between disparate "web applications", the user might switch back and forth between these applications. As the user navigates between these applications, a local session gets created on each of the applications in addition to a session created at the Identity Provider that is used for sso.

So, the issue is when applications have different session timeouts, leading to a broken user experience. Session timeout occurs in one application while the user is working on another application. When navigating back into the application the user had visited previously, an error occurs. This is confusing to the user, since they are not aware that they are working on different applications.

One way to avoid the problem is to have a "global session" object that every application has access to. While the user is accessing any protected resource, the application checks if the global session exists and updates its timestamp before processing the request. The local sessions will never expire (or have a very long timeout). However, when the user logs out, global session object is evicted and the sign out happens on all the applications.

This seems to be a bit heavy handed due to:

  • Global session object becomes single point of failure
  • The performance to make a "out of process" check for the global session object and update the timestamp on access of every protected request

Any other thoughts on how to make this work?

Kiran
  • 376
  • 4
  • 12

1 Answers1

0
When navigating back into the application the user had 
visited previously, an error occurs.

I don't think that would be an error. The application will redirect the request to SSO provider and as the user is already have a valid SSO session it will be a successful SSO operation and the application can re establish a new/expired session.

Ankur
  • 33,367
  • 2
  • 46
  • 72
  • Not if there is some context information stored in the session to serve the request. Like the user hits the back button to a different platform, but it uses the context id stored in the session (rather than picking it up from the URL) to serve the request – Kiran Feb 16 '12 at 00:45