A single sign-on introduction
Single sign-on (Single Sign On), referred to as SSO, it is one of the more popular solutions for enterprise business integration. SSO is defined in multiple applications, users need only log in once to access all applications of mutual trust.
II. Technical Implementation Mechanism
When users first visit when the application system, because are not logged in, will be directed to the login authentication system; identity verification based on the login information provided by the user authentication system, if by check, it should be returned to the user a authentication credentials --ticket; when other users access the application, this will bring the ticket, as their authentication credentials, to the authentication ticket application system will check the system after receiving the request, checks the ticket legality. If by check, in case the user can not log in again to access applications 2 and 3 of the application system.
To achieve SSO, requires the following major functions:
1. All applications share a single authentication system.
Unified authentication system is one of the prerequisites for SSO. The main function of the authentication system is the user's login information and user information base compared to the user login authentication; authentication is successful, the authentication system should generate a unified certification mark (ticket), returned to the user. Further, the authentication system further ticket should also be verified, to determine its effectiveness.
2. All applications can identify and extract the ticket information.
To achieve SSO functionality, allowing users to log in only once, it must be allowed to apply the system to recognize the user has logged off. Application of the system should be able to identify and extract the ticket, through the communication with the authentication system, and can automatically determine whether the user is currently logged in, to complete the function of single sign-on.
Three .CAS open source
Official website: CAS
Portions of this code can achieve reference: CAS Single Sign-On
IV. A single point in the same domain logon
Under normal circumstances a business is only one domain name, the domain name distinguished by two different systems. For example, we have a domain name is called: a.com, while there are two operational systems are: app1.a.com and app2.a.com. We do single sign-on (SSO), require a login system, called: sso.a.com.
As long as we in sso.a.com login, app1.a.com and app2.a.com will also be logged. Through the above login authentication mechanism, we can know, I logged in sso.a.com, the fact is recorded in the session logged in the service side of sso.a.com, while sso in the browser (Browser) is. Cookie written under a.com. So how do we make it app1.a.com and app2.a.com login? There are two issues:
Cookie is not cross-domain, the domain property is our Cookie sso.a.com, giving app1.a.com and send a request app2.a.com is not on the tape.
sso, app1 and app2 are different applications, there is a session within their own applications, is not shared.
So how do we solve these problems? For the first question, after sso login, you can Cookie domain is set to top fields, namely .a.com, so that all subdomains of the system can access the Cookie top domain. When we set the Cookie, only the top domain and set its own domain, you can not set other domain. For example: We can not set the Cookie domain to baidu.com in their own systems.
Cookie solve the problem, let us look at the question session. We sso log on the system, the next time you visit app1, Cookie also brought to the service side of app1 (Server), the server app1 of how to find the corresponding Session Cookie do? Session should here sharing system 3, as shown in FIG. Sharing Session There are many solutions, for example: Spring-Session. This second problem solved.
Single sign-on in the same field is realized, but this is not a true single sign-on.
V. single point under different domain logon
Single sign-on under the same domain is clever use of the characteristics of the Cookie top domain. If it is a different domain? Between different domains Cookie is not shared, how do?
Here we will talk about the CAS process, and this process is the single sign-on standard processes.
FIG CAS is the official Internet standard protocols process is as follows:
1. The user accesses the system app, app system is required to log in, but users do not have to log in.
2. Go to the CAS server, namely SSO login system, after the figure of our unity is called the CAS Server SSO system. SSO systems are not logged in, pop-up user login page.
3. After the user fills out the user name, password, SSO systems for authentication, SSO will be logged writes the session, Cookie domain in the SSO browser (Browser) writing.
After the registration completion 4.SSO system generates a ST (Service Ticket), the system then jumps to the app, while ST passed as a parameter to the system app.
5.app get the system ST, send a request from the background to the SSO, verify ST is valid.
6. verified, app session status is written to the system log and set the Cookie field in the app.
So far, cross-domain single sign-on is complete. When we visit again later system app, app is logged. Next, we look at the process when accessing app2 system.
1. The user accesses app2 system, app2 system does not log on, jump to the SSO.
2. As the SSO is already logged in, do not need to re-login authentication.
3.SSO ST generated, the browser jumps to app2 system and passed to ST app2 as a parameter.
4.app2 get ST, backstage access SSO, verify that ST is valid.
5. After the verification is successful, the login status is written app2 session, and writes Cookie at app2 domain.
In this way, app2 system does not need to go login process, it is already registered. SSO, app and app2 in different domains, session between them do not share is not the problem.
Some students asked me, after SSO system registry, when the jump back to the original business system, brought a parameter ST, ST access business systems but also to take the SSO to authenticate again, that this step a bit redundant. He wanted to login authentication, SSO via callback address will return to the original user information systems business, the original business system directly logging so simple process, but also to complete the login, is not it?
In fact, when this very serious problem, if I'm not logged in SSO, but directly typing the address of a callback in the browser, and bring fake user information is not a business system is also considered to log out? It is very scary.
VI. Summary
All processes single sign-on (SSO) are introduced over, we all know the principle. To sum up single sign of things to do:
1. Single Sign On (SSO systems) is to protect the resources of the business user security system.
2. Information obtained from various business systems is that the user can not access my resources.
3. Single sign-on system resources in all business here, not in that party SSO. The user provides a user name and password to the SSO server, as a business system does not know about it. SSO just give ST a business system, then the business system can not determine the user ST is forged, or really effective, so to take this ST SSO server to ask about this user gave me the ST is valid, effective I can let the user access.
Resources:
1. Single sign-on (SSO) to see which one is enough
2.SpringBoot simple implementation imitation CAS Single Sign
3.CAS single sign
4 new realm of open source
