Cross-Site Single Sign-on for websites

I discussed this topic with several friends yesterday and found that although single sign-on or independent passport logon has many implementation methods, however, there are not many people who can really understand and implement it. Therefore, I hope you can understand more about it in terms of principle and implementation.

For example, if you log on to MSN Messenger, you do not need to log on to Hotmail.
Generally, single-point logon requires an independent logon site, which generally has an independent domain name for special registration, login, cancellation, and other operations.

For the convenience of discussion, we call this login site P, set its URL to http://passport.yizhu2000.com, the site that needs to provide services to a and B, cross-Site Single Sign-On means that after you log on to website a, you do not need to log on to the service of website B.

From a technical perspective, single sign-on is divided:

• Cross-subdomain Single Sign-on
• Fully cross-single-point domain login

Cross-subdomain Single Sign-on

The so-called cross-subdomain login, A, B site and P site are located under the same domain, such as site A for http://blog.yizhu2000.com Site B for http://forum.yizhu2000.com, they and login site P relationship can be seen, all belong to the same parent domain, yizhu2000.com. Different subdomains are different. One is blog, one is forum, and the other is passport.

First, let's take a look at the most common non-Cross-Site normal login situations. Generally, after the login verification is passed, your user name and some user information will be encrypted through a key, it is written locally, that is, an encrypted cookie. We call this cookie ticket ).

To determine whether the user is logged on to the page, read the ticket and decrypt the user information from it. If the ticket does not exist or cannot be decrypted, it means that the user has not logged on or the login information is incorrect, at this time, we will jump to the login page to log on. Here, encryption has two functions: one is to prevent user information from being viewed by malicious users, and the other is to ensure that ticket will not be forged. The latter is actually more important, after encryption, each application needs to use the same key as the encryption for decryption. If you do not know the key, you cannot forge a ticket,

(Note: the encryption and decryption keys may be different depending on which encryption is used.AlgorithmThe same key is used for symmetric encryption. If the key is not symmetric, it is different. Generally, the private key is used for encryption and Public Key decryption. However, the key is only known internally, in this way, the counterfeiter cannot forge or decrypt ticket)

The cross-subdomain single-point logon process is no different from the preceding normal logon process. The only difference is that when the cookie is written, because the login site P and application a are in different subdomains, the cookie domain written by the P site is passport.yizhu2000.net, and site A is forum.yizhu2000.net. A cannot read the ticket of the P site when judging the user's logon.

The solution is very simple. When the P site writes ticket after login is complete, you only need to set the cookie domain to their common parent domain, and yizhu2000.net will be able to: cookie. domain = "yizhu2000.net", Site A can naturally read this ticket.

ASP. Net form authentication itself to achieve this mechanism, you can refer to the http://blog.csdn.net/octverve/archive/2007/09/22/1796338.aspx

ASP. NET authentication information cross-origin sharing status

In ASP. NET 2.0, you only need to modify the Web. config file. The modification method is as follows:

<Authentication mode = "forms">
<Forms name = ". aspnetform "Domain =" imneio.com "loginurl ="/login. aspx "defaulturl ="/default. aspx "Protection =" all "timeout =" 30 "Path ="/"requiressl =" false "slidingexpiration =" true "enablecrossappredirects =" false "cookieless =" usedeviceprofile "/>
</Authentication>

Domain specifies the domain in which the cookie is saved. As long as the domain is saved in the form of abc.com or .abc.com, its second-level domain names can share the cookie.

In addition, the <sessionstate> in the web. config tag is modified accordingly. If the mode is changed to StateServer or sqlserver, all session information in the tag can be shared.

StateServer needs to enable the "Asp.net Status Service" service in the service.

Http://www.imneio.com/2007/11/17/aspnetnote1/. here is the link for your reference.

Fully cross-single-point domain login

Full cross-origin login means that site A, site B and site P do not have a common parent domain, for example site A is forum.yizhu%.net, site B is blog.yizhu1998.net, you can refer to Microsoft's several site http://www.live.com, www.hotmail.com, the two sites do not have a common parent domain, but can still share the login, how can we achieve it? For more information, see ticket. In this case, the ticket created by site P is called P-ticket. The ticket created by site A is called a-ticket, and B is called B-ticket.

 

Because Site A (forum.yizhu1999.com) cannot read the encrypted ticket created by site P (passport.yizhu2000.com), when users access resources on Site A that require logon, site A first checks whether a-ticket exists. If no, it indicates that the user has not logged on to site a, but it does not guarantee that the user has not logged on to site B, since it is a single sign-on, of course, whether you have logged on to any site A or B, another site must be accessible), the request will be redirected to the authentication page of site p, the verification page reads p-ticket. If no, or the decryption fails, you need to redirect the logon page. After logging on to the page, write an encrypted cookie, that is, p-ticket, and redirects to the login processing page of Site A, and passes encrypted user information to this page as a parameter. This page receives user information on the login page and writes a cookie after decryption, that is, a-ticket. In the future, when users attempt to access resources on Site A again, they only need to check whether the-Cookie exists.

When a user accesses site B, the above process will be repeated. If no B-ticket is detected, the system will redirect to the verification page of site P to check the site p-ticket. If no, log on. If yes, return to B's logon processing page and write B-ticket.

 

Delete P-ticket and a-ticket

 

 

How to delete a cookie: I thought this was not a problem, but some friends asked, simply put, it is actually creating a cookie with the same name as the cookie you want to delete, set the cookie expire to a time before the current time. However, when deleting a cookie across subdomains, note that the cookie domain must be set as the parent domain. In this article, yizhu2000.com is used.

To ensure the security of transmission at all stages, it is best to use HTTPS connection