We are building a set of web applications which all utilize their own unique role providers using sql server and utilizing Windows Identity Foundation to provide a Secure Token service to handle the membership using Active Directory. This solution also provides the benefit of single sign on. One oversight was only allowing users a single session. Tracking if the user already has an active session seems easy enough to implement, it’s what and how to deal with a user’s session if it’s determined they are already logged on elsewhere .
My question is what is the recommended approach for killing an existing user session if the user attempts to spawn an additional session? Would also like to advise the user that an existing session has been detected and by continuing, that existing session will be terminated. (This part also seems trivial…)
Example Scenario with 2 web apps and a STS Identity app:
- User attempts to access application A:
- STS Identity extension determines user is not already logged on, provides a claim and caches a user/session identifier.
- User attempts to access application B on different computer. (they can access application B if using the same session)
- STS Identity determines user has active session and denies logon.
There seem to be some other issuer to overcome, for example….
- How to update the logged on user cache from the application A if the user is actively keeping their session alive.
- How would you deal with the user not explicitly logging off, say by closing the browser or the session timing out.
- Other problems???
Any guidance would be appreciated.
We have opted to handle concurrency at the application level, using a simple table that stores the users session id. If a new session for the application is created elsewhere, the existing session is terminated with the use being redirected back to the STS with a message (carried in the query string) the reason why they’ve been redirected back to the login page.