Cross-origin SSO implementation

Best Article translated from the codeproject website ASP. NET in August: Single Sign On (SSO) for cross-domain ASP. NET applications.

If the translation is inappropriate, I hope you can provide more guidance and communicate with each other.

This article consists of two parts: architecture design and program implementation. This is the first article: Architecture Design or design blueprint (Part-I-the design blue print ). :)

Introduction

On Monday morning, you received an email when you were wondering how the weekend would have been blinking and felt terrible for the next long week.

It is neither Microsoft's offer nor Google's offer, but a new requirement from the customer.

He said that you have done a lot of ASP for our company. net websites and various systems that we launched, now I want my customers to log on to any of our websites once, the user has logged on to all my websites. Similarly, he can log off from any other website, then he logged out from all our websites ......

You can't stand the customer's embarrassment. Do you want an SSO function? Can I use form authentication of ASP. NET? In this way, the cookie can be shared with websites in the same domain, and you only need to set the same configuration section in the machinekey. Put the dog in a search, and there are XXXX results. Looking for a dog is a special skill of our programmers.

Before the project started, you glanced at the email and waited. When you saw a line in the email, it hurt a little bit: We deployed those websites, but not all of them under the same domain name.

Your customer gave you a downloading ticket, as if he had already launched a dog search. Because Cookies cannot be shared across domains, they cannot be used for cross-domain verification.

This is exactly what it is! (It's just as simple as a foreigner. Here are some details)

Validation principles in ASP. NET

This problem may have been commonplace, but before solving the problem, we should first go back to the basics to see what the essence of things is. Therefore, the principle of ASP. NET form verification is not bad.
The following is a flowchart of ASP. NET form verification.

Verification process

1: You access an ASP. NET page that requires user authentication.

2: Asp.. Net starts to search for cookies (because the cookies for form authentication are not found). If not, the page will jump to the logon page (the logon page address is configured on the web. config File)

3: On the logon page, you provide the relevant verification creden. and click the log on button. After the system and the stored data are verified and compared successfully, thread. currentprincipal. identity. the property value of name is set to the user name you provide, and the cookie is written into the response (user information and some such as the cookie name and expiration date are also written ), and redirect to the page before logon.

4: When you click another page (or click to navigate to another page), the browser sends the verification cookie (or may contain some other cookies written under the website ), this time contains the Cookie obtained from the last verification in the previous response.

5: as before, Asp. net runtime searches for the verified cookie in the request. This time it is found, and then performs some checks (such as the expiration date and Path). If it has not expired, then read and retrieve its value, restore the user information, and set the thread. currentprincipal. identity. set the property value of name to the restored user name, and check whether the user has the permission to access the page of the current request. If so, the execution result of the page is returned to the user's browser.

The process is simple, right?

Validation principles of multiple sites in the same domain in ASP. NET

As mentioned above, ASP. NET form authentication relies entirely on cookies. So long as different sites share the same authentication cookie, you can log on to the same site to log on to all sites.

The HTTP Protocol indicates that if two sites are in the same domain (or subdomain), they can share cookies. Local processing is that the browser stores cookies locally (in disk or memory) based on the URL of the website ). When you request any next page, the browser reads cookies in the domain or subdomain that match the URL of the current request and includes the cookies in the current request.

Now let's assume there are two websites:

Www.mydomain.com/site1

Www.mydomain.com/site2

The two sites share the same host address (the same domain is mydomain.com and the sub-domain www), and both sites are configured to use Form Verification for user authentication and authorization. Assume that you have logged on to the website.

Now, you can access the URLs starting with www.mydomain.com/site1. cookiefor table validation will be included in the request and sent. Why? Is this cookie actually belong to this site? Yes, but it is not completely correct. In fact, the request URL: www.mydomain.com/site1and http://www.mydomain.com/has the same domain name and subdomain name.

So when you log on to the role (Site2 ). Obviously, the Form Verification cookie can be shared between application site names with different host addresses, thus implementing the function of logging on everywhere (that is, single sign-on ).

However, ASP. NET does not allow you to automatically complete single-point logon by deploying the site under the same host address to form verification. Why? Because each different ASP. NET web application uses its own key to encrypt and encrypt cookies (as well as viewstate and so on) to ensure security. Unless you specify the same encryption key for each site, cookies will be sent, but the other application site cannot read the value of cookies for verification.

The same authentication key can solve this problem. Use the same <machinekey> Configuration section for each ASP. NET application site as follows:

<Machinekey
Validationkey = "Courier"
Decryptionkey = "abaa84d7ec4bb56d75d217cecffb9628809bdb8bf91cfcd64568a145be59719f"
Validation = "sha1"
Decryption = "AES"/>

If the same machinekey (including validationkey and decryptionkey) is used on all application sites in the same domain, the cookie can be read across sites.

What if they are different subdomains of the same domain?

Assume that you have the following two sites:
Site1.mydomain.com
Site2.mydomain.com
These two sites share the same domain (the same second-level domain name mydomain.com), but have different third-level domain names (different subdomains Site1 and Site2 ).
By default, the browser only sends cookies for sites with the same host address (same domain and subdomain. Therefore, the site site1.mydomain.com cannot obtain the cookie under the site site2.mydomain.com (because they do not have the same host address and Their subdomains are different), even though you have configured the same machinekey for the two sites, one site still cannot obtain the cookie under another site.
In addition to configuring the same machinekey for all sites, you also need to define the same domain for the authentication cookie so that the browser can send any request under the same domain name.

You need to configure the Form Verification cookie as follows:

<Forms name = "name" loginurl = "url" defaulturl = "url" Domain = "mydomain.com"/> How can I share a verification cookie in a domain that is not used?

Obviously, this is impossible because the HTTP protocol prevents you from sharing cookies between different domains for security reasons.
Similarly, assume there are the following two domain names:
Http://www.domain1.com/
Http://www.domain2.com/
If you use Form Verification to log on to the login. There is no built-in method in ASP. NET to implement Single-point logon between two different sites.
To achieve single-point login through accessing the same cookie between two sites, there is really no advanced technique or an existing architecture model to solve it.

Cross-origin Single Sign-On design prototype

Assume there are three sites:
Http://www.domain1.com/

Http://www.domain2.com/
Http://www.domain3.com/
To achieve SSO between these sites, when users log on to any site, we need to set verification cookies for all sites.
If user 1 logs on to the ingress. Therefore, before response returns to the browser, site 1 has to be directed to Site 2 and site 3 to set verification cookies.

The following flowchart describes the concept in detail:

Procedure:

Request token (because there is no cookie that belongs to http://www.domain1.com ). Status: the browser does not verify the cookie. Because the request does not verify the cookie, the request is rejected/
Bytes. After the cookie is verified to be contained in the response, the cookie is sent to the browser. Status: the browser does not verify the cookie. the browser receives the response containing the verification cookie and redirects the command to http://www.domain2.com. The browser stores the verification cookieat http://www.domain2.com/and sends a request to http://www.domain2.com. Status: The Browser contains. Finally, these authentication cookies are included in the redirection command. Status: The Browser contains /. Now, the browser stores the verification cookie of Site 1 and starts to request site 1. Of course, the request contains the verification cookie. Status: The Browser contains

If the user requests Site 2 because the browser has stored the verification cookie of Site 2, the cookie will be included in the request, and site 2 will get the user information from the cookie, and return the requested page for this user.
After the browser verifies Site 2 and site 3, the user has logged on to all the sites, thus completing a single sign-on.

How to cancel a single sign-off?

As part of single-point logon, we also need to pay attention to single-point logout. That is to say, when a user logs out of a single site, he is considered to have logged out of all sites.
Clearing cookies for all sites is the same as logging on to the site above. It is also the process of request-redirect-return. The difference is that the verification cookie is removed from response this time.

Disadvantages of this single sign-on Model

This model can still run well on two sites. Log on or log off from a site. All the sites under this SSO model will follow the request-redirect-return process. When you log on to any page, because the verification cookies of all sites are stored, you do not need to execute the preceding loop.
However, when there are more than two sites, the problem becomes complicated. When you log on to site 1, the program redirects to Site 2 and site 3 for Cookie verification settings, when site 3 jumps to site 1, the server returns the user request page. This makes the login and logout processes for each site complicated and costly. How can we create more than three sites? How can we design single-point logon for over 20 sites? This model will be completely incompetent.
In addition, this model requires that each site have the user authentication logic, because it needs to request this site and set its authentication cookie.
Therefore, this model loses the concept of Single Sign-on in the general sense. We need a better model to implement the Single Sign-On function.

Better cross-origin Single Sign-On Architecture

In the architecture mentioned above, setting to remove cookies all needs to jump to the N-1 site to complete. Each site also needs to know the complex login logout logic of N-1 sites,
What if we only maintain one verification cookie for all sites? How can I use an independent site to verify the user and set the authentication cookie? This idea seems good.
To use single-point logon, user data must be unified. In this way, you can use a website to provide web or WCF services for verification and authorization. In this way, redundant user verification logic is eliminated. The most important thing now is how this independent site plays a role in the SSO architecture.
In this architecture model, the browser does not store the verification cookies of any other sites. Instead, it only saves the authentication cookies of the independent site. we name it http://www.sso.com /.
In this architecture, requests to each site are directly redirected to http://www.sso.com/, and the existence of cookie is verified by checking. If the cookie exists, the requested page is returned. If the cookie does not exist, the corresponding logon page is displayed.
The general flowchart is as follows:

For ease of understanding, we assume there are two websites:
Http://www.domain1.com/
Http://www.domain2.com/
There is also a site for managing verification cookies: http://www.sso.com /.
The verification process is as follows:

User request http://www.domain1.com/a verification page
Redirect to http://www.sso.com/, and set the returnurl.pdf to the urlwhen the request site is 1.
Bytes. The value of the previous returnurl parameter is retained in the query string.
Site 1 learns from the parameter that it is from Region /.
The user provides verification information and click the login button. The request is not returned to the site metadata (which can be a guid ).
Site 1 indicates that the user has successfully logged on (storing the user object in the session). a url containing the token will jump to http://www.sso.com/set to verify cookie, and returnurl.pdf will also be set to the urlof the previous request.
Bytes. After the cookie is set, add the cookie to response, and add the User Token to return the response according to the URL in the returnurl parameter.
The browser will know that it wants to jump to site 1, and has the verification cookieat site http://www.sso.com/, and verifies cookieat sso under the Local Storage and initiates a request for Site 1.
Site 1 checks the User Token. Because it is verified and passed through the Web/WCF Service of the site SSO, site 1 returns the page of the user request.

Now the user requests Site 2
When the browser jumps to the SSO site, the returnurl value is still set.
The browser adds the cookie to the request and sends it out because it needs to jump to the SSO site and finds that there is a verification cookie for the SSO site.
When the SSO site checks the cookie and finds that the cookie has not expired, the User Token added to the query string is returned according to the returnurl.
Site 2 finds a User Token and proves that the verification process has passed. Then, the page of the user request is returned.

Summary

At the beginning, the browser did not have any verification cookieat http://www.sso.com/site. Request site 1 and Site 2 any page to be verified (internal jump to the SSO site to check whether the verification cookie exists ). After a user logs on, the authentication cookie of the SSO site is stored locally (it is important that the User Token is only used when the user logs on to the session ).
The request site 1 or site 2 is redirected to the SSO site. The browser sends the authentication cookie of the SSO site and checks the User Token. After verification, the browser redirects to the URL of the original request, after the Origin Site checks that the User Token is correct, it returns to the user request page.

Transmission Cost

Scenario 1: access a public page
From browser to site + site to Browser
1 request + 1 response
Scenario 2: Access a page to be verified
Redirect from the browser to the site + to the SSO site (check cookie) + redirect to the original site (no cookie) + the original site returns to the login page to the browser
1 request + 2 redirect + 1 return
Scenario 3: Logon
Browser post to site + call verification service for user verification + browser jump to SSO site (with token) + redirect to original site (with verification cookie) + General Service verification token + return the page for user request verification
1 request + 2 verification service call + 2 redirect + 1 response
Scenario 4: request a page for verification after logging on
Request site + redirect to SSO site verification cookie (with verification cookie) + redirect to original site (check verification cookie) + call service verification token + return request page
1 request + 2 redirect + 1 service request + 1 return
Scenario 5: log out
Request site cancellation + Request SSO site cancellation + Request original site removal verification cookie + return
1 request + 2 redirect + 1 return

Which is

Compared with these two architectures, the first architecture is more suitable for two sites, with a maximum of three sites. Although complex redundant verification logic needs to be deployed, however, the subsequent page request is a normal page request (1 request + 1 response ).
The first architecture is not easy to expand, and many user verification logic is redundant.
In the second architecture, no matter how many websites require single sign-on, or other websites do not need to participate in this process, only SSO site management is used to verify cookies, the architecture logic is clear, easy to expand, and easy to deploy.
However, there are some performance problems. Unlike the first architecture, this architecture requires three requests when a user requests a page to be verified (request the SSO site and the original site, the two requests are internal redirects, and the two requests take little time (empty jump requests are used to set and check cookies ), in today's network environment, this is acceptable.

Cross-origin SSO implementation