CODEWITHSUNDEEP
asp.net-mvc-4cross-domainsingle-sign-on
Jolly Tri
Jolly Tri

Reputation: 79

How to Implement Single Sign On in MVC4

How to implement Singel Sign On (SSO) in cross domain MVC4 Web Applications

Upvotes: 4

Views: 9099

Answers (2)

Jolly Tri
Jolly Tri

Reputation: 79

Finally, I am able to implement. Following are the steps I have done

  • Login in App1
  • Get Option to Login with App2
  • Click on “Login with App2”
  • Redirects to the Login screen of App2
  • On click of Login button of App2 that redirects to the SSOInMVCWcfService. Here, method Login calls the method Authenticate of the service of App1 i.e. SSOAuthService. If authenticated then generates token for this username and also retrieves the userid from the service of App1.
  • Once token generated and user id retrieved for this Authenticated user, these values are entered in the table say ‘SessionDetails’ in database.
  • Then send the userid and token for the current user to App2.
  • Now App2 sends the returnurl i.e. the authenticated page url of app1 alongwith the userid and token to the login page of App1 by adding these values as cookies in the Response Object.
  • Now on the App1 login page, these cookies are retrieved and on the base of the userid the current username is retrieved from the “SessionDetails” table.

Upvotes: 1

Darin Dimitrov
Darin Dimitrov

Reputation: 1039408

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:

  1. Setup a master domain for users to logon. For example logon.com
  2. 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.
  3. 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.
  4. The logon domain redirects back to the protected resource passing along the session identifier.
  5. The application holding the protected resource decrypts the session id to extract the username and set a forms authentication cookie on its domain.
  6. The user requests a protected resource on the second domain.
  7. Since he is not yet authenticated he is redirected to the logon domain.
  8. The user is already authenticated on the logon domain and a session identifier using the same technique is generated and passed back
  9. 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.

Upvotes: 13

Related Questions