Cross-Domain Single Sign-On part 1-design blueprint)

Cross-Domain Single Sign-On part 1-design blueprint

Http://www.codeproject.com/KB/aspnet/CrossDomainSSOModel.aspx

An asp.net independent domain name Single Sign-On solution.

Introduction

"On a Monday morning, you sigh in the office that the weekend is doing well, and this week may be a tough week. You have received an email. Of course it is not a good job offer,
That's just another requirement of your customer. Your customer has several. net websites. He wants to log on to all other websites by logging on to one website. Of course, exiting a website requires
Exit all.

OK, so your customers need to introduce "Single Sign-On ". You may think, this is not very difficult. Asp.net form verification can complete this function, which allows programs of different sites under the same domain name
You can share the cookie by setting the <machineKey> segment in web. config. As a result, you can quickly search for a single sign-on using <machineKey>.
Okay, after all, programmers are not that difficult to mix.

Wait, as if something caught your attention. "Your customers have several websites, but they didn't say they are under the same domain name ". You just didn't notice this most important question,
As a result, your first day looks not very smooth. It is not that easy to implement Single-point logon for sites under different domain names. The most basic problem is that sites under one domain name cannot be connected to other sites.
Sharing cookies. Do you know that cookies are used to maintain verification information on different pages? "

The scenario I just described is very common now. In the era of Web and community websites, systems are very rare. You can often send a push on twitter and update it to LinkedIn at the same time.
And Facebook. You may also write an article on CodeProject and share it with hundreds of websites within one second. Therefore, you naturally want to log on to a website,
Then, you do not need to log on to another website, whether or not these sites are published under the same domain name.

Therefore, I want to develop a solution to achieve single-point Logon (of course asp.net website ). People have already implemented this feature in different ways, and you can also buy release solutions.
However, what I want to achieve is simple, free, and the most important thing is a running solution.

How does Asp.net implement verification?

Well, this may not be new to you. However, when we solve difficult problems, we often return to the basic working principle. So let's take a look at Form Verification in asp.net.

The following is a workflow for asp.net Form Verification:

Figure: asp.net Form Verification

Operation Sequence:

Click an asp.net page that can only be accessed by authenticated users.

.. Net is used to search for a cookie (Form Verification cookie) in the request during runtime. If the cookie cannot be found, redirect the current request to the login (the location of the logon page is configured on the web. config.

Enter the logon information and click "Log on. If the verification information is correct, your program will verify the information in the database. The user Name is assigned to the Thread. CurrentPrincipal. Identity. Name attribute.
Enter a cookie in response (including the user information, cookie name, And timeout) and redirect it to the original page.

Click another page of the system (or click a link to navigate to another page). This time, the browser will send the verification cookie (there are other cookies written in the previous Domain Name) because
The cookie has been verified.

Similarly, asp.net searches for the authentication cookie in the request header. This time, he can find the cookie. Then, it checks the cookie attributes (timeout time, path, etc.). If no timeout occurs, it reads the cookie value,
Obtain the user information in the cookie, and then set the user Name to the Thread. CurrentPrincipal. Identity. Name attribute again to check whether the user has accessed the page completely new, and then execute the page and return it to the user.

It's quite simple, isn't it?

How does one verify different sites under the same domain name?

As we have just said, form authentication for asp.net relies entirely on cookies. Therefore, if two sites can share the same cookie, you can log on to the two sites only when you log on to the same website.

Now, the http protocol tells us that two different sites can share cookies only when both sites are under the same domain name (or subdomain name. In the internal directory, the browser stores cookies locally (memory or hard disk) and corresponds to the url of the article.
When you continue to access other links to the site, the browser will compare the Domain Name of the current requested URL with the local cookie information with the same domain name and sub-domain name. If the domain name is the same, these cookies will be sent.

Therefore, we assume that you have the following two sites:

Www.mydomain.com/site1

Www.mydomain.com/site2

The two sites have the same host address (the same domain name mydomain.com and the sub-domain name www), and both sites are configured to verify the user using form verification.
Assume that you have logged on to the ingress.

Now, if you click "www.mydomain.com/site1site", the table validation cookiewill be sent together in the request. Why? Because the cookie is from
This website? Yes, 100% is correct. Specifically, the request url www.mydomain.com/site1and www.domain.comhas the same subdomain name and domain name (host name ).

Therefore, after you log on to www.mydomain.com/site1, if you request the Form validation cookie (or other matching cookies) of www.mydomain.com/site2 and the same sample, it will be sent in the request.
Because, www.mydomain.com/site2 and www.mydomain.com even if they are connected to a different program (site2 ). Therefore, the same form verification cookie can be assigned to two different
Web application sharing: it is feasible to log on to two websites by logging on to one site (that is, single sign-on ).

However, asp.net will automatically implement Single-point logon under the same domain name without introducing form authentication. Why? Because two different asp.net applications use different encryption keys to encrypt cookie data
(And other data, such as viewstate) to ensure security. Therefore, unless you specify an encryption key for each. net application, the cookie will be sent from the browser, but the program will not read the verification cookie from other applications.

The solution is to use the same verification key. For asp.net applications, you must use the same <machineKey> Field in web. config:

<MachineKey
ValidationKey = "Courier"
DecryptionKey = "ABAA84D7EC4BB56D75D217CECFFB9628809BDB8BF91CFCD64568A145BE59719F"
Validation = "SHA1"
Decryption = "AES"/>

If all applications under the same domain name use the same machinekey (including validationKey and decryptionKey), each application can read the cookie information of other applications.

What if the two websites are under different domain names or subdomains?

Assume that your site is not published under the host address below:
Site1.mydomain.com
Site2.mydomain.com

These two sites share the same domain name (the same second-level domain name mydomain.com) but different third-level domain names (different sub-domain names site1 and site2)

By default, the browser only sends cookies under the xiantong domain name (the domain name matches the subdomain name ). Therefore, the site1.mydomain.com site will not obtain the cookie of site2.mydomain.com (because they do not have the same host address, their subdomain names are different)
In an emergency, you have configured the same machinekey and cannot access the cookies of another domain name.

Therefore, in addition to setting the same machineKey for all sites in the processing settings, you also need to specify the domain name to verify the cookie when asp.net is running, this allows the browser to send cookies when requesting links under the same domain name.
You must configure Form Verification cookies:

<Forms name = "name" loginUrl = "URL" defaultUrl = "URL" domain = "mydomain.com"/>

So, how do I share the verification cookie under different domain names?

Okay, there is absolutely no such method. Http prevents you from accessing cookies from different domain names for security reasons.

Assume that you have two websites with different domain names:
Www.domain1.com
Www.domain2.com

Now, if you use Form Verification to log on to www.domain1.com and click the URL of www.domain2.com, the browser will not simply send the cookie under domain1.com to domain2.com.
Therefore, Asp.net does not have a mechanism to implement Single-point logon for different sites.

To achieve single-point Logon at different sites, there must be some solution or implementation model that allows two sites to access the same cookie through indirect mechanisms.

A basic SSO Implementation Model

Suppose we must implement SSO in the following sites:

Www.domain1.com
Www.domain2.com
Www.domain3.com

To implement SSO, after the user authenticates on any site, we must make other sites generate authentication cookies in the client browser.

If user1 is verified on www.domain1.com, the browser will write the verification information to cookies before the server returns the request data. However, we also need to log on to www.domain2.com and www.domain3.com. We also need
Set cookies for www.domain2.com and www.domain3.com in the client browser. Therefore, when the returned information is sent to the browser, www.domain1.com is redirected to www.domain2.com and www.domain3.com to set the verification cookie.

Describes the basic idea (arrows indicate redirection ):

Figure: Basic SSO model Overview

Then, the detailed idea is identified:

Figure: logon sequence of the basic SSO Model

Time Series Operation:

Click a verification page under www.domain1.com.
[Status: browser has no authentication cookie]

The browser sends an unauthenticated cookie request to www.domain1.com (because there is no cookie for www.domain1.com domain name)
[Status: browser has no authentication cookie]

Www.domain1.com: No cookie verification information is found in the request. Therefore, the request is redirected to the logon page of www.domain1.com.
[Status: browser has no authentication cookie]

Enter the logon information and click "Log On". The browser sends a POST request to www.domain1.com.
[Status: browser has no authentication cookie]

Www.domain1.com accepts the logon information and verifies the logon information in the data storage area. If the logon succeeds, it indicates that the logon is successful. In this case, a cookie containing the user information is created and added to response.
[Status: browser has no authentication cookie]

Www.domain1.com redirects the request to a page on www.domain2.com, instead of directly returning data to the browser. It also contains a returnurl that directs to www.domain1.com and returns the connection. Wait until the verification cookie is set to respose.
The cookie is sent to the browser.
[Status: browser has no authentication cookie]

The browser receives the returned data containing the verification cookie and a command redirected to www.domain2.com. Therefore, the browser stores the authentication cookie www.domain2.com and sends a request with a cookie to www.domain2.com.
[Status: browser has an authentication cookie for www.domain2.com]

Www.domain2.com immediately redirects to the ReturnUrl address and sets the verification cookie for www.domain1.com. Finally, verify that the cookie and redirect command are sent to the client.
[Status: browser has an authentication cookie for www.domain2.com]

At this time, the browser receives the corresponding data, including the command to verify that the cookie has been redirected to www.domain1.com. Therefore, the browser saves the authentication cookie,
Then send a redirect request to www.domain1.com with the verification cookie
[Status: browser has authentication cookie for both www.domain1.com and www.domain2.com].

Www.domain1.com, the verification cookie is found in the request, and the user access page is returned, instead of the login page.
[Status: browser has authentication cookie for both www.domain1.com and www.domain2.com].

Therefore, if the user accesses the next page to be verified on www.domain2.com in the browser, because the verification cookie under www.domain2.com already exists with the browser,
The cookie information is sent to the server together with the request. www.domain2.com checks the user information in the cookie and enables the user to log on to and access the page of the user request.

Because the browser now has two site verification cookies: www.domain1.com and www.domain2.com, the user has logged on to the two sites, and finally implemented single-point logon in the two sites.

So what about single-point logout?

If we only want users to log on to multiple websites, our task has been completed. However, we also need to enable single-point logout as part of the most single-point logon. That is to say, the user exits a website
You must log out of all websites.

When a user logs out of a website (for example, www.domain1.com), the verification cookies of other websites should also be removed (in this example, www.domain2.com). The cookie can be sent before the returned data is sent to the browser.
Remove.

To remove the verification cookies for all websites, you only need to continue using the request-redirect-response process we mentioned above, but now it is not to add a cookie, but to remove the cookie.

SSO model Problems

This model is okay if there are only two websites. Log on to or log out of a site. Other Sites (sites under SSO) must follow the request-redirect-response process.
When a user logs on to a site, other sites will send subsequent requests. The request-redirect-response loop does not appear here, because each site has its own authentication cookie.

However, if there are more than two sites, the complexity will increase. That is to say, if a user logs on to www.domain1.com, the site will redirect to www.domain2.com and www.domain3.com to set the verification cookie.
Finally, www.domain3.com redirects to the page where www.domain1.com starts the request and returns it to the browser. This time, the login and logout functions become good resources and complex. What if you have more than 3 websites? If more than 20
What if the website is in the same single sign-on model? This model is obviously not suitable.

This model requires that each site know all other sites under SSO (because each site needs to redirect other sites to set verification cookies ). At the same time, each website must implement the user authentication function.

This can be clearly understood. As the number of sites increases, the SSO model will become chaotic and unacceptable. Therefore, this model cannot be considered as a universal SSO model for cross-Origin applications. Therefore, we need an unlimited number of websites.
A better model of impact.

Cross-origin SSO recommendation Model

The model mentioned earlier is a bit confusing because each site must be redirected to another N-1 site, and each site authentication cookie is removed consecutively. Therefore, each site must configure information related to other N-1 sites, while also implementing complex login and logout logic.

What if we want to verify that the cookies of all websites only maintain one separate verification? If an independent new site is introduced to manage user authentication and set authentication cookies? It sounds like you have earned.

In order to introduce SSO to multiple sites, the user database must be unified and user authentication and verification functions can be achieved through a dedicated website, other Websites access these functions through web service or WCF Service.
Therefore, this can reduce other redundant user verification/verification features. But the main problem I encountered was how to implement Single-point logon for this independent website?

In this model, will the browser store the verification cookies for each website. Instead, it will save the cookie dedicated to implementing single-point logon. This is called www.sso.com.

In this model, each request to any site (page in the SSO model) is redirected to the SSO site (www.sso.com) to set and detect existing authentication cookies. If the cookie is found,
The verified page will be sent to the browser. If no page is found, the user will redirect to the login page of the corresponding site.

The following describes the basic idea:

Figure: Use a separate (www.sso.com) Site Management authentication cookie in the recommendation Model

To better understand this model, we assume that we need to implement this model in the following two sites:

Www.domain1.com
Www.domain2.com

Now, we need a site that independently manages and verifies cookies.

Www.sso.com

Here is the workflow of this model:

Figure: the sequence of Access to the page when no logon is available

Procedure:

The user accesses www.domain1.com on a page to be verified.

Www.domain1.com is redirected to www.sso.com and a ReturnUrl parameter is added to the url to set it to the original URL.

Www.sso.com checks whether there is a verification cookie or whether the request contains a User Token. If not, redirect to www.domain1.com and include a well-known user to log on. At the same time, it also attaches
The ReturnUrl parameter.

Www.domain1.com checks the url parameters redirected from www.sso.com. The url parameter identifies user authentication and does not discover it. Then it redirects to the login page of www.domain1.com, And the identity in the request is not redirected to www.sso.com.

Figure: logon Sequence

Enter the logon information and click "Log on. In this model, do not redirect to the SSO site. This time, www.domain1.com calls the webservice or WCF Service provided by www.sso.com to check whether the user information is correct. If yes, return
The user object and the token (for example, guid) attribute generated by a user upon each login.

Www.domain1.com indicates that the user has logged on (for example, storing the user object in the session). In this case, you need to construct a returnurl parameter containing the User Token and return the original page, and then redirect it to www. Set the verification cookie on sso.com.

Www.sso.com checks the request URL and finds the User Token. Currently, no verification Cookie has been found. On this surface, the user has passed the verification on the client (www.domain1.com), and now needs to set the authentication cookie of www.sso.com to the client browser.
Therefore, he uses the token to query user information in the cache, prepares to verify the user information required by the cookie, sets the cookie attribute (timeout time, etc.), and adds the cookie to the response, finally, check the original page in the redirection back to returnurl (link of www.domain1.com.
And the token is included in the URL.

The browser obtains a redirection command, which also contains the returnurl pointing to www.domain.com and the cookie www.sso.com. Therefore, he saves the verification cookie for www.sso.com and requests the link for www.domain1.com.

Www.domain1.com now you can see the User Token of the URL parameter. He calls www.sso.com to call the Web/WCF Service to authenticate the user. If the verification passes, he will execute the original request to the www.domain1.com page and then output it to the browser.

Figure: view the timing diagram of a page to be verified after Logon

Click www.domain2.com to verify the URL.

Www.domain2.com is redirected to www.sso.com with the returnurl of the original access page as the parameter.

The browser gets a command to redirect www.sso.com, but it already has a verification cookie stored in the browser. Therefore, when requesting www.sso.com, the cookie is first appended to the request.

Www.sso.com checks whether the request has a verification cookie. If the verification cookie is detected, check whether it expires. If it does not expire, go to the original page of www.domain2.com Based on the User Token and redirect it to the original page of www.domain2.com.
And output it to the client browser.

Conclusion,

Wow, it sounds like a lot of things have happened. Let me summarize it here:

At the beginning, the browser did not have any authentication cookies for www.sso.com. Therefore, when you click any pages for verification at www.domain1.com or www.domain2.com, will be redirected to the logon page (through internal redirection to www.sso.com to check whether the cookie exists)
Once a user logs on to a site, www.sso.com sets a verification cookie in the browser of the client, including the user information (mainly used to detect the User Token of the user's logon session ).

Now, if you click any verification page of www.domain1.com or www.domain2.com, the request will be redirected to www.sso.com, And the browser will also send a verification cookie, which was previously set, the user's Token is extracted and then redirected back to the original url,
Add a Token to the url, run the Token, and return it to the browser.

A user must log on to any site in the SSO model and click www.domain1.com or www.domain2.com to redirect to www.sso.com (check the authentication cookie and retrieve the Token ), then execute the verification page and output it to the browser.