How to implement single sign-on in different .net versions

Single Sign On is a problem in multiple application systems where users only need to log in once to access all mutually trusted application systems. In fact, for programmers to implement it technically, they have to share cookies between multiple different domain names.

Recently, I added an ERP to deploy on another machine, linked to a sub-project in the original old system, called Login in the original old project to achieve single sign-on, and tried N times but failed repeatedly. Finally, I determined that the problem was that the encryption/decryption methods of cookies in .net2.0 and 4.0 differed from this. So after research, I rewrite implemented a simple method that can implement single sign-on in different .net versions.

1. Shared login page code implementation:

Copy the codeThe code is as follows:

protected void btnLogin_Click(object sender, EventArgs e)
{
//Certification invoice, jump to the original request page
   ("ejiyuan", false);
}

2. Configuration file:

Copy the codeThe code is as follows:

<!--Access Rights Control-->
<authorization>
    <deny users="?"/>
</authorization>    
<!--Identity Authentication Method-->
<authentication mode="Forms">
    <forms name=".ASPNET" protection="All" enableCrossAppRedirects="true" loginUrl="" timeout="2880" path="/" domain="."/>
</authentication>   
<!--Verification Algorithm-->
<machineKey validationKey="F9D1A2D3E1D3E2F7B3D9F90FF3965ABDAC304902" decryptionKey="F9D1A2D3E1D3E2F7B3D9F90FF3965ABDAC304902F8D923AC" validation="SHA1" decryption="3DES" /> <compilation debug="true"/>

here:The two most important attributes of the authentication/forms node are name and protection. All projects that implement single sign-on must have the same configuration so that they can read and write cookies under the same protection level in different programs.
When the protection property is set to "All", the encryption and verification data are stored in the cookie through the Hash value. The key used for default verification and encryption are stored in the file, and we can overwrite these values in the application file. The default values are as follows:

<machineKeyvalidationKey="AutoGenerate,IsolateApps"decryptionKey=" AutoGenerate,IsolateApps"validation="SHA1" />

IsolateApps means that a different key is generated for each application. We cannot use this. In order to use the same key in multiple applications to encrypt and decrypt cookies, we can remove the IsolateApps option or better yet set a specific key value in all applications that require SSO:

If you use the same storage method, implementing SSO is just a change. You must ensure that each application in a single point has the same configuration. If the single sign-on application spans different .net versions, do not use md5 for encryption/decryption here.

3. Single sign-in without login page does not require code. Just configure it directly. The configuration is as follows

Copy the codeThe code is as follows:

<authorization>
  <deny users="?"/>
</authorization>
<authentication mode="Forms">
    <forms name=".ASPNET" protection="All" enableCrossAppRedirects="true" loginUrl="/" timeout="2880" path="/" domain="."/>
</authentication>

4. The login module is encapsulated from the directional code in httpModules for direct call by other systems. Here is the encapsulation code and reference method:

Copy the codeThe code is as follows:

public class SsoLoginRedirectModule : IHttpModule
{
    public void Init(HttpApplication i_application)
    {
        // TODO: Add implementation
        i_application.EndRequest += new EventHandler(i_application_EndRequest);
    }

    void i_application_EndRequest(object sender, EventArgs e)
    {
        if (( == 302) && ())
        {
            = + "?ReturnUrl=" + ();
        }
    }

    public void Dispose()
    {
        //throw new NotImplementedException();
    }
}

Quote:

Copy the codeThe code is as follows:

<httpModules>
    <add name="SsoModule" type=", SsoModule"/>
</httpModules>