Shulou(Shulou.com)06/03 Report--

This article mainly introduces "what are the steps to achieve SSO single sign-on". In daily operation, I believe many people have doubts about the steps to achieve SSO single sign-on. Xiaobian consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "what are the steps to achieve SSO single sign-on". Next, please follow the editor to study!

Some of our subsystems use Redis to store Session, which is originally to solve the problem of Session sharing in application cluster deployment, but it also provides support for sharing Session among applications, but it is impossible to achieve single sign-on by sharing Session between applications alone.

In a single application, when the user logs in to the system, the login status of the user is stored in the Session of the server, and the SessionId is passed to the browser through the Cookie field of the response header. When the server is requested later, the browser will automatically add Cookie to the request header, so the login status of the user can be maintained.

Using Redis to share Session, the principle that Session can be shared between clusters is the same as the principle of keeping login state after service restart.

After the application is restarted, since the browser still carries cookie to initiate the request, if the Session does not expire, the Session obtained from Redis can continue to be used.

Thus, although applications can share Session through Redis, browsers are required to send requests to each application with the same Cookie in order to achieve single sign-on.

However, browsers do not support Cookie sharing between different domain names, and the server cannot control client browsers to access sites under different domain names with the same SessionId. We have to find another way to achieve single sign-on.

Although browsers do not support sharing Cookie between different domain names, Cookie sharing can be achieved between different sub-domain name applications with the same primary domain name by configuring Cookie as the primary domain name, as long as all subsystems share one primary domain name. Such a scheme is both desirable and undesirable, preferable in the short term and undesirable in the long run.

If only the web applications jump to each other, the user clicks the button in the application a to jump to the application b, and the user clicks on the jump application b with SessionId on the jump link, and the application b reads the user information according to the SessionId and then writes to the Session.

Regardless of the security, the disadvantages of this approach are also obvious. users cannot directly enter the domain name of application B in the browser, but can only jump to application B through application A. to return to application A, you can only jump from application B to application A by clicking the button.

While it's not a good idea to jump between apps by clicking a button, at least the idea of sharing login status with SessionId on the jump link is desirable.

According to this idea, can we enable browsers to automatically carry SessionId without clicking a button?

Yes, but it can be achieved through redirection.

When the user logs in on system An and modifies the domain name access system B directly on the browser, system B checks that the user does not log in and redirects the request to system A, and system A checks that the request is redirected from system B, and the user has logged in, then the SessionId can be spliced to the redirect link and then redirected back to system B. In this way, the automatic SessionId jump can be realized.

However, this approach requires every system to implement this function once, and each system should also provide login function.

In order to simplify the implementation, and the subsequent new systems no longer repeat the login function, we should consider extracting the login function into a separate application, and other systems no longer provide login function.

After extracting the login function into a stand-alone application, the process of implementing SSO single sign-on is sorted out as follows:

Extract SSO into a separate application, independent domain name, provide login page, require other applications no longer provide login page, all must log in through SSO.

When other applications receive the request, they first determine whether they have logged in according to session. If they do not log in, they redirect to the SSO login page, and which application jumps over on the redirect link, and when the user logs in successfully with SSO, they are redirected back to the original application.

When the browser is redirected to the SSO login page, the browser stores the cookie of the SSO, and the SSO stores the login status of the user after the SSO login is successful.

The original application check request carries token. In this case, you need to access SSO to verify the token and obtain user information. After successful SSO verification, the user information is returned. The original application stores the user information in Session, and then redirects it to the home page after successful verification.

If the user accesses application B by entering the domain name of application B in the browser, because application B checks that Session has no user information (not logged in), it is redirected to the SSO application.

Because the user has logged in to SSO, the browser will bring cookie when redirecting the request to the SSO application, so the SSO application finds that the user has logged in and generates a token and redirects the response with B.

Application B receives the redirect request, obtains the token from the request, then accesses the sso application to verify the token and obtains the user information, writes the Session after obtaining the user information successfully, and finally redirects to the home page.

According to the combing process, summarize the functions that each application needs to achieve:

SSO applications:

Provide login function to support redirection from which application, and redirect to which application after successful login

Provides an interface to obtain information about currently logged-in users according to token.

Other applications:

If you are not logged in, you will redirect to SSO with the API to be redirected after successful login on the jump link.

The interface provided to the SSO redirect call is used to receive the token transmitted by SSO, obtain the login user information from SSO according to token, write the user information to Session, and finally redirect to the front-end home page.

It is not easy to implement this process on a system with separate front and rear ends, and the actual implementation is more than the steps described in this article.

We encapsulate the tedious steps as much as possible by encapsulating SDK, so that other applications only need to rely on one jar package and add a small amount of configuration when interfacing with SSO.

SDK intercepts all requests through the filter provided by Servlet:

1. If the request is "/ checketSsoToken", it means that the user jumped over after a successful SSO login (browser redirection), and will carry the token parameter. At this point, SDK needs to request SSO to verify token, write the obtained user information into Session, and then redirect to the front-end home page of the current application.

2. If it is not "/ checketSsoToken", check the configuration to determine whether the current request does not require login and can also be released. If so, release it. Otherwise, determine whether the user has logged in in Session. If not, jump to the SSO login from the front end in response to redirection.

Because the front and rear ends are separated, the front end uses the ajax request API, and the back end determines that the response redirection of unlogged-in response cannot be truly redirected, so the front end is required to intercept all request responses. If there is a redirection flag in the response header, you should obtain the redirection link from the request header and let the browser redirect it.

3. If it is an exit login request, first clear the user login information that is cached by yourself, and then redirect to SSO to log in.

The actual single sign-on process is as follows:

2. The front end calls a back-end interface on the home page, such as getting the menu, triggering the check login (front-end implementation), splicing the redirect link if you are not logged in, and responding to the front-end, requiring redirection to the SSO login page (SDK encapsulation implementation)

3. After the user has successfully logged in to SSO, the "/ checketSsoToken" of Application An is called by SSO redirection. This url is spliced after the URL as a parameter when the application A redirects to the SSO login, which is provided by the backend, and the front end is only responsible for the redirection. (SSO application implementation)

(SDK encapsulation implementation)

It should be noted that if the session expiration time set by SSO is one hour, if the user jumps back to Application An after logging in to SSO, and then jumps to Application B after one hour of inaction, the user will have to log in again because the session of SSO has expired, so the session expiration time of SSO should be set reasonably as needed, not too short.

Finally, leave a thinking question: how to log out synchronously?

When a user logs out of application A, only Application An and SSO know that the user has logged in, but other applications do not know.

The easiest way is to configure the Session expiration time of other applications as short as possible after SSO. Or every time you open the home page of the application, you will jump to SSO first, and if you have logged in, you will naturally be redirected back. This step is transparent to the user.

Finally, because each application uses Shiro to implement interface permission verification, as well as Shiro annotations, we adapt Shiro annotations in SDK, but completely abandon Shiro.

At this point, the study on "what are the steps to achieve SSO single sign-on" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.