[Original] multi-site Single Sign-On (SSO) Design

This is an old topic. Currently, portals generally implement Single-point logon between multiple services. Next, let's talk about my own ideas based on the projects I 've experienced.

 

Why do I need single-point logon:

When the product is launched, generally because the number of users is small, all functions are put together, and specific single sign-on is not required. As the number of users and business grows, it is required that products be divided into independent sites based on their functions or performance and deployed separately. This requires single-point logon between sites, to achieve one user login, you can use multiple sites.

 

Single Sign-on implementation:

Simple Method: a site in the same domain can achieve single-point logon simply by sharing cookies (storing logon usernames in cookies. This method is easy to implement, and the security method can be enhanced by encrypting the cookie value, but it is difficult to implement it in different domains and different development languages (such as site a c # and site B C.

 

Recommended method: Establish a unified authentication center, which provides:

1. User logon authentication (authentication username and password). If the authentication succeeds, the logon token for this logon is returned.

2. log on to token for authentication (whether the authentication token is correct). If the authentication token is successful, the user name of the current logon is returned.

3. Extend the token Validity Period

4. Exit (invalidate the token)

The authentication center is independent of each site. The single-point process is generally used in the following scenarios:

1. log on to site a by entering the user name and password.

2. Site A forwards the user name and password to the authentication center for authentication. The authentication center returns the token

3. Site A saves the current login user and token to the session (or cookie)

4. Click Connect to Access Site B on Site A and send the token to Site B through URL parameters.

5. Site B transfers the token to the authentication center. The authentication is correct and the current user name is returned.

6. Site B saves the current login user and token to the session (or cookie) to complete the login process.

This token can also be used to asynchronously use ajax to access the server interface (the interface may be deployed independently on different sites, after the server-side interface passes the Token Authentication, the corresponding user information of the login user is directly returned.

 

Security considerations:

1. Users can log on to the authentication interface to add authentication frequency, authentication IP address, and other restrictions to prevent violent attacks.

2. the token is actually a string that represents the unique string of the current logon. When a string can be generated, the digest information is added. For example, if the token is composed of A + MD5 (a + PWD) mode, A is a random guid, so that when the token is verified, you can directly passAlgorithmTo verify the legality. Only after the algorithm verification is passed can you proceed to the next step.

 

The above is only the overall description of the uniform authentication design. There are still many details not described in the middle. We can further discuss what we need to know.

Next, I want to write about how to implement a Distributed Authentication System within the certification center and support high concurrency and attack protection.

------------------------

Retained the source for forwarding. Thank you.