Same domain SSO could be easily achieved by setting the domain
property of the forms authentication cookie to the root domain and configuring the same machine keys for both applications.
Cross domain SSO is more challenging. There are different techniques to implement it. For example StackExchange uses HTML5 Local Storage. Their mechanism is described in this blog post.
Here are some of the basic steps:
- Setup a master domain for users to logon. For example logon.com
- When a non-authenticated user attempts to access a protected resource on some of the 2 applications he is redirected to the logon domain for authentication.
- The user authenticates and the logon domain generates a session identifier containing the username of the logged in user. This session id is encrypted using symmetric algorithm with a shared secret between the 3 domains. The logon domain also sets a forms authentication cookie to indicate that the user is already authenticated there.
- The logon domain redirects back to the protected resource passing along the session identifier.
- The application holding the protected resource decrypts the session id to extract the username and set a forms authentication cookie on its domain.
- The user requests a protected resource on the second domain.
- Since he is not yet authenticated he is redirected to the logon domain.
- The user is already authenticated on the logon domain and a session identifier using the same technique is generated and passed back
- The second domain decrypts the session identifier to extract the username and emit a forms authentication cookie for the second domain.
As an alternative to encrypting the username into the session identifier, the logon domain could simply store this information into a shared (between the 3 domains) data store and the session identifier will simply be an identifier of this record so that the other domains could retrieve the username from this shared data store.