Implementation of Single Sign-on

First, Single Sign-On must depend on the client, that is, the client must return the ID to the server. This is the principle.

There are three basic single-point logon solutions.

1. Session

2. Cookies

3. url

Because the client can only save the three basic information

 

1. Session: The session depends on the sessionid of the client, and the sessionid exists in cookies or URLs. The principle of sessionid System GenerationAs long as the request. url. Host is different, sessionid will regenerate the same request. url. host, and sessionid will not change.Or re-open a browser and the sessionid will be re-generated. Therefore, due to the principle of sessionid generation, it is difficult to use session for SSO. If you want to use session for SSO, you can also, the idea is this: override sessionid, And the sessionid generated after each user logs on is fixed, and the sessionid information is stored in the database. When the system jumps, the database verifies the sessionid and obtains the user information, this advantage is that you can perform single-point logon across the primary domain. The disadvantage is that sessionid is fixed and the security is very poor.

 

Public class sessionidoverride: system. Web. sessionstate. sessionidmanager
{

Public sessionidoverride ()
{
//
// Todo: Add constructor logic here
//
}
Public override string createsessionid (httpcontext context)
{
String sessionstring = guid. newguid (). tostring () + context. Request. userhostaddress;
Return sessionstring;
}

/// <Summary>
/// Gets a value indicating whether a session identifier is valid.
/// </Summary>
/// <Param name = "ID"> the session identifier to validate. </param>
/// <Returns>
/// True if the session identifier is valid; otherwise, false.
/// </Returns>
Public override bool validate (string ID)
{
Try
{
Guid testguid = new GUID (ID );

If (ID = testguid. tostring ())
Return true;
}
Catch
{
}
Return true;
}
}

 

 

 

2Cookies

In terms of cookie specification, a cookie can only be used for one domain name and cannot be sent to other domain names. However, when the primary domain name is the same, the second-level domain name can share cookies.

 

SimpleCodeAs follows :-----------------------------------
Update cooikes
// If a cookie exists, the value attribute is updated. Otherwise, a new cookie is created.
Httpcookie cookies = request. Cookies ["username"];
If (cookies = NULL)
{
Cookies = new httpcookie ("username", this.txt username. Text );
Cookies. Domain = "common.com ";
Response. Cookies. Set (cookies );
}
Else
{
Cookies. value = this.txt username. text;
Cookies. Domain = "common.com ";
Response. Cookies. Set (cookies );
Cookies = new httpcookie ("username", this.txt username. Text );

}
Read cookies
Httpcookie cookies = request. Cookies ["username"];
If (cookies! = NULL)
{

This. textbox1.text = cookies. value;
}
View All cookies
Httpcookiecollection cookies;
Httpcookie onecookie;
Cookies = request. Cookies;
String [] cookiearray = cookies. allkeys;
For (INT I = 0; I <cookiearray. length; I ++)
{

Onecookie = Cookies [cookiearray [I];

Response. Write (onecookie. Name + "-" + onecookie. value );
}

 

Restrict the valid range of cookies to the domain
By default, cookies are associated with specific domains. For example, if your website is www.contoso.com, when a user requests a page from the site, the cookie you wrote will be sent to the server. (Except for cookies with specific path values, which I have explained in the previous section .) If your site has subdomains (such as contoso.com, sales.contoso.com, and support.contoso.com), you can associate cookies with specific subdomains. Therefore, you need to set the domain attribute of the cookie as follows:

Response. Cookies ("Domain"). value = datetime. Now. tostring
Response. Cookies ("Domain"). expires = datetime. Now. adddays (1)
Response. Cookies ("Domain"). Domain = "support.contoso.com"

If you set the domain in this way, the cookie can only be used to specify the page in the subdomain.

You can also use the domain attribute to create cookies that can be shared in multiple sub-domains. For example, set the domain as follows:

Response. Cookies ("Domain"). value = datetime. Now. tostring
Response. Cookies ("Domain"). expires = datetime. Now. adddays (1) General cookies. If they are valid only on the current browser and sub-page, they are disabled or newly opened.
Response. Cookies ("Domain"). Domain = "contoso.com"

In this way, the cookie can be used for the primary domain, sales.contoso.com, and support.contoso.com.

Note: cookies must be encrypted in consideration of security. It is best to serialize encryption.

3.URL: the URL principle is very simple. When you jump to the system, the URL of the login user is randomly generated, and the user information corresponding to the URL is stored in the database (or other ), jump to other systems and fetch the information based on the URL. The actual principle is the same as that of session, which is troublesome, but this is safer.