To learn about single sign-on (SSO), read:

Single sign-on those things (a) applications and principles

Single sign-on those things (2) under the same domain name single sign-on

Single sign-on is varied in enterprise applications. In the last article, we mentioned that an enterprise has a domain name hosting different applications. However, with the exploration of new business, enterprises will apply for some new domain names for function bearer, on the one hand to distinguish, on the other hand to meet regulatory requirements. In this different domain name mode, get through the user system of the original site, is introduced this time — single sign-on in different domains.

** Different domain name SSO principle design **The authentication system authenticates the user based on the login information of the browser. If yes, the browser sends a certificate [Authentication system_ticket] to the URL where the cookie is set for each application, and sends a certificate [application system_ticket] to the browser. Redirects to the page originally visited, and the application system can automatically log in later.

SSO principle analysis of different domain names

In the final analysis, the implementation of single sign-on is to solve how to generate and store this trust, and how other systems verify the validity of this trust, the key points are these two points: store trust, verify trust.

  • Cookie is used as the credential medium to store user credentials

After the user logs in to the parent application, the application returns an encrypted cookie. When the user accesses the child application, it carries the cookie and authorizes the application to decrypt the cookie and perform verification. If the verification passes, the current user logs in.

  • Implemented through JSONP

JSONP can realize cross-domain problems. After the user logs in to the parent application, the cookies matching the Session will be stored in the client. When the user logs in to the child application, the application is authorized to access the JSONP interface provided by the parent application, and the Cookie under the domain name of the parent application is brought in the request, and the parent application receives the request. Verify the login status of the user and return the encrypted information. The sub-application parses the returned encrypted information to authenticate the user. If the user passes the authentication, the user logs in.

  • By page redirection

Through the parent application and child application to communicate in the back and forth redirection, to achieve secure transmission of information. The parent application provides a login interface in GET mode. The user accesses this interface through the redirection connection of the child application. After login, the child application claims the encrypted Token and is redirected to the Token authentication interface provided by the child application.

  • Log in to the system independently

Large applications separate the logic of authorization from the logic of user information into a user-centric application. When a third-party application needs to log in, it forwards the user’s login request to the user center for processing. After processing, the user returns the credentials, and the third-party application verifies the credentials and logs in to the user.

** SSO authentication mode for different domain names **

  • With cookies, redirection between applications

If a user logs in to any of the preceding sites successfully, the user must set the cookie information of other sites in the browser.

  1. After the user logs in to site1 and passes the authentication, the browser stores a cookie of Site1.
  2. Before the user logs in to site1 and responds to the request, a redirection is required from Site 1 to Site 2 and Site 3 to set the cookie information.
  3. The browser sets cookies for site2 and Site3.

Log in to one of the sites in the browser to set the cookie, while other sites in the browser to set the corresponding cookie, you can achieve single sign-on, single sign-off is the same principle, one exit to clear cookies, others also clear.

  • Leverage a separate SSO server

With a separate SSOServer, the browser only needs to save the COOKIE information of the SSOServer. When the browser makes a request to any site, it will first redirect to the SSOServer to verify whether the cookie of the current user exists. If so, it will send the page after successful verification to the browser; otherwise, it will jump to the login page to prompt the user to log in.

The following is divided into three parts:

  • CAS

CAS is the framework for SSO SSO in different domains. The Central Authentication Service (CAS) enables users to log in by switching to intermediate domain names.In real enterprise application scenarios, service scenarios are more diverse. Single sign-on (SSO) in different domains is a common solution. For single sign-on and more information on the full range of identity and access management solutions, stay tuned to Authing.

For more information, please visit Authing’s official website