Single sign-on (SSO) is a session/user authentication process that permits a user to enter one name and password in order to access multiple applications. There are a few ways to achieve this and our choice was to implement the following approach.
Single sign-out will log out user from the all systems where he/she is logged in.
The authentication works by using authentication cookie on the domain. When there’re multiple domains by logging into domain1 only domain1 authentication cookie will be created and it’s impossible to create domain2 authentication cookie at the same time. Hence, new site is introduced SSO. There, on log in the user is redirected to SSO and on SSO the cookies are created with the keys that reflect domain1 and domain2. These cookies will mean that the user is authenticated on the domain even if on that domain there’s no authentication cookie. E.g. user logged in to domain1 and domain1 authentication cookie is created and also SSO cookies with the keys for domain1 and domain2. Then, the user navigates to domain2. There is no domain2 authentication cookie but the user is redirected to the SSO. There the SSO cookie with the key for domain2 is found meaning the user is validated on domain2. The user is redirected to domain2. The authentication cookie on domain2 is created and the user is logged in to domain2 and goes to the requested page.
For the implementation we have used http handlers. They allow us to enhance the functionalities of the host domain without changing its code by simple dll deploy and web.config update. Let’s consider following scenarios.
1. An authenticated request (the request for a page that requires authentication) is sent for the Domain1. There is no authentication cookie on Domain1.
2. The request is redirected to the SSO application by the setting in the web.config of Domain1 application in the authentication element.
Domain parameter of the query string is used for the return domain after the authentication is performed.
3. The request is redirected to the SSO application. The SSO cookie with the key equal to the calling domain (passed by the query string) is searched for.
4. The cookie is not found meaning the user is not authenticated on the domains that he is allowed to yet.
5. The user is redirected to the SSO login page.
6. User fills the username/password and after clicking submit is redirected to the login http handler – LoginHandler.
7. The request is processed by the login http handler – LoginHandler using Membership Provider method ValidateUser.
8. Each domain that use this http handler must implement a class that inherits Membership Provider class and override the above method.
9. The username/password validity is retrieved by the LoginHandler and the request is redirected to the SSO.
10. If the username/password are invalid the SSO login page is rendered with the appropriate error message.
11. If the username/password is valid then for each domain for which the user has the account the cookie is created on SSO where the cookie’s key is the domain name. This step is the key because at this time the cookies are created on SSO for the user on all domains although he/she has just sent the request for one domain. Using these cookies the user will be able to log in to different domains without logging in again which will be described later.
12. The user is redirected to another http handler implemented – AuthenticationHandler.
13. AuthenticationHandler sets the cookie for the originally requested domain (domain1) and redirects user to the originally requested url.
14. The result of this scenario is:
14.1 User is logged in into all the domains where he is allowed to access and he is redirected to the originally requested page.
14.2 The authentication cookie for originally requested domain is created. E.g. if domain1 was requested authentication cookie for domain1. On SSO the cookies are created for each domain where the user can access with the domain name as the cookie key.
1. An authenticated request (the request for a page that requires authentication) is sent for the Domain1. There is already an authentication cookie on the requested domain.
2. The user is redirected to the requested page without need to log in again.
1. An authenticated request (the request for a page that requires authentication) is sent for the Domain 2. There is no authentication cookie on Domain2 but the user is logged in to the domain1 thus cookies were created on SSO with the keys for both domain1 and domain2 assuming the user is allowed to access them both.
2. The same as Scenario 1 steps 2 and 3.
3. The cookie is found meaning the user is authenticated on the domains that he/she is allowed to already.
4. Scenario1 step 11 is performed here with the difference that the SSO cookies are not created here but only refreshed i.e. their expiration date is extended.
5. The user is redirected to the http handler – AuthenticationHandler and Scenario1 steps 12,13,14 are performed. The result of this scenario is again the same as the result in scenario1 described in step 16.
Cookie expiration date problem
Problem: Imagine that there are domain1, domain2 and sso sites. User navigates to the domain1 for the first time. There’s no authentication cookie on domain1 and user gets redirected to the sso where there’s no cookie on sso for the domain1 key. The user is validated and cookies are created on sso with the keys on domain1 and domain2.User is redirected to domain1 and auth cookie is created on domain1. All cookies have expiration time 60mins. User works on domain1 and each time user performs an action expiration date of cookie on domain1 gets refreshed. But the cookies on SSO are not refreshed. After 65mins user requests for the domain2 page and gets redirected to the SSO site. The cookie on SSO with the domain2 key is not found thus user is redirected to the log in page. This is unwanted behavior. The requirement is that the last action on any domain refreshes the expiration time on every domain.
Solution: The expiration date of the cookie on the domain1 or domain2 is set to the fixed time which means that new action on the domain1 or domain2 will not refresh the expiration date of the cookies. The minimum expiration date on the cookies on SSO with the keys for domain1 or domain 2 is set to be greater than the maximum expiration date on domain1 or domain2 cookies. The cookies on SSO have sliding expiration date which means they’re not fixed but can be refreshed.
Thus, when the user logs in and all the cookies are created e.g. domain1 cookie, and SSO cookies for domain 1 and domain2 it’s e.g. 1pm. Expiration time on domain1 cookie is fixed to 1:30pm and on SSO cookies it’s 1:45 but sliding. User only works on domain 1 and on 1:31 his request for the authenticated page is redirected to the SSO site because domain1 cookie has expired. On SSO the cookie with the key for domain1 is found and refreshed (+45mins) to 2:30pm but also is SSO cookie for domain2 key. The user is redirected to domain1 site and the cookie on domain1 is created again (+30min) to fixed time 2:01pm. User works only on domain1 and at 1:50 or 2:15 (>1:45) navigates to domain2. Domain2 cookie is not found in the browser so the user gets redirected to SSO where the SSO cookie is found for the key domain2 and again all the cookies on SSO for the domains are refreshed , the user is redirected to the domain2 and the domain2 cookie is created with the expiration time 1:50+30=2:20pm.
Single Sign Out
Logout method of the domain must clear authentication cookie for the domain. Also, logout method of each domain must be changed so that request is redirected to the SSO site. Here the SSO cookies will be deleted the end the user will be redirected to the logout page.