Implementation of ASP. Net Site cross-subdomain single point of login (SSO) Implementation of ASP. Net Site cross-subdomain single point of login (SSO) Implementation

Last Update:2018-12-05 Source: Internet

Author: User

Tags subdomain subdomain name

Developer on Alibaba Coud: Build your first app with APIs, SDKs, and tutorials on the Alibaba Cloud. Read more ＞

Implementation of http://blog.csdn.net/jason_dct/article/details/8502075 ASP. Net Site cross-subdomain Single Sign-On (SSO)

In msdn's document "configure Forms authentication (http://msdn2.microsoft.com/zh-CN/library/eb0zx8fc.aspx) across applications", a method of implementing shared identity login information between Web farm and multiple applications is proposed. This method implements identity sharing in the field environment. For single-point login across sub-domain names, such as the implementation of Web and csdn passes, many friends have provided solutions. For details, refer: http://www.cnblogs.com/dudu/archive/2005/07/04/186279.html

Form authentication is based on identity cookies. After logging on to the client, a cookie containing user identity information (including a ticket) is generated. The cookie name is the name set by form in the authentication section of Web. config, as shown in

Here,. aspnetauth is the cookie name. This cookie is included in the request. Cookies set to transmit user identity information. Therefore, the idea of sharing authentication information is simple: as long as this authentication cookie can be shared in the Self-domain name, the form authentication information can naturally be shared!

There are many articles sharing cookies online. The basic practice is to set the domain attribute of the cookie. The domain of the cookie specifies the domain associated with the cookie. Domain is string. Empty by default, indicating that the associated domain is the domain corresponding to the current request. If a subdomain name is set for domain, such as Cookie. Domain = "brookes.com", this cookie is associated with all subordinate domains under brookes.com. Therefore, it can be shared by www.brookes.com/web2.brookes.com.

At this point, the method for sharing form verification information across subdomains is simple:

If (membership. validateuser (username, password ))
...{
Formsauthentication. setauthcookie (username. Text, false );
Httpcookie cookie = response. Cookies [formsauthentication. formscookiename];
Cookie. Domain = ".brookes.com ";
Response. Cookies. Add (cookie );
Formsauthentication. redirectfromloginpage (username, false );
}

This Code illustrates the implementation principle. Here, the process of self-Writing Form Verification is implemented. If you are using the login control and the Framework performs verification on its own, how do you set the domain of this cookie?

There are three methods:

1. Process in the login. onloggedin event. This event is triggered after the user passes authentication. If the cookie already exists, you can modify the domain attribute. For more information about the code, see the preceding section;
2. Write the process of verifying the user and setting the authcookie into an httpmoudle. This method is slightly responsible for Google Code
3. There is one of the simplest methods. In. NET 2.0, the authticainon forms element adds a new attribute: domain. This attribute corresponds to the domain attribute of form authcookie. Therefore, you only need to make the following settings in the web. config of each subdomain:

OK. Now you don't need to make any other settings. All subdomains under your brookes.com can share form authentication information!

Several points should also be noted:
1. This domain attribute will overwrite the domain attribute setting in the httpcookie configuration section, but it will only affect authcookie, and other cookies will not be affected;
2. After reading the above article, I will certainly think that I can set the httpcookies configuration section, for example:
<Httpcookies domain = "brookes.com"/>
The results are the same. The difference is that httpcookies specify the domain attribute of all cookies on the site. This will allow all cookies on the site to be shared across subdomains! Whether or not to avoid such sharing is necessary, and you can determine based on your needs.
3. This domain attribute is highlighted in some documents by adding a point in front, such as domain = ".brookes.com", which is not found in MS documents. Based on my test results, there is no difference between the two statements, and the results are the same.

Certificate -----------------------------------------------------------------------------------------------------------------------------------------

1 For pure web SSO, if there is an independent SSO Login server, all the verification will jump to the interface of this server, the login status will be retained on the SSO Server

2. If you want to authenticate the desktop and web, you must have an independent SSO,

For self-implemented solutions, for example, if a desktop program is used to implement SSO, there must be an SSO server. The desktop program verifies the identity through httpclient, and then can pass
A. modify local cookies to allow IE to pass authentication tokens
B. directly use the authentication token as the URL string root after a link of the desktop program

The token statement is vague. There are two methods:
1. All URLs have a rewrite token.
2. As long as you retain the browser's cookies for the SSO web server, when you jump to the application, the web app will first redirect to the ssoserver. After verifying the cookies, the web app will jump back. For users, they will not feel like they have been to ssoserver, haha,

Many websites, such as Google, seem to be using this method.

In essence, JAAS only solves the problem of configurable login. For example, if Tomcat uses JAAS, it can only solve the problem of logging on to N applications on Tomcat at the same time, and it is limited to Java. The above method is required for SSO implementation. Kerberos and system 1

These modules are closely integrated, making expansion inconvenient.

3 if windows is the only logon portal, that is, there is no second SSO Login server.
The core of SSO is that IE can send domain information to the server after the merge domain:

Configure IE browser
① Internet Options --> Security --> Local intranet --> site --> advanced
Add WLS
② Internet Options --> advanced --> Security
OK. Windows identity authentication is selected.

After WebLogic of the Service segment receives this token, it must go to the ad for verification.

Integrated with Windows authentication (formerly known as NTLM authentication and Windows NT question/Response Authentication), NTLM or kerbetas authentication can be used. NTLM is a proprietary Microsoft technology, several updates have been made since its publication,

Although this mechanism is stable and reliable, it has a fatal drawback that it cannot be delegated, which means that user creden。 cannot flow to remote services (such as SQL Server ). However, Kerberos does not have this problem. It maintains a stable and secure verification server.

You can also easily use delegation in a Windows environment. We will discuss this mechanism.

Microsoft Active Directory is required for Kerberos in most cases because Active Directory acts as a Kerberos token to authorize the Service (TGs/TGT ).

If Kerberos is used, it is easy. Both windows and WebLogic support Kerberos, and the authentication data is on the Active Directory.
Reference http://edocs.bea.com.cn/wls/docs92/secmanage/sso.html

From: http://www.cnblogs.com/csdnexpert/archive/2007/12/17/999415.html

Certificate -------------------------------------------------------------------------------------------------------------------------------------------

Java SSO reference: http://www.cnblogs.com/hannover/archive/2009/10/15/1583692.html