directory
One, foreword
Second, first know SSO
2.1 What is SSO? What is single sign-on?
2.2 Realistic requirements for single sign-on? How to implement single sign-on?
2.3 From a single architecture to a distributed architecture
Traditional login
3.1 Traditional Login Service Process
3.2 Problems of traditional login
3.3 Solutions
Single sign-on
4.1 SSO Service Process
4.2 Token
4.3 with domain SSO
4.3.1 Introduction: What is a domain? (How to understand domains in computer networks)
4.3.2 with domain SSO
4.4 cross-domain SSO
4.4.1 CAS
4.4.2 Cross-domain SSO sequence diagram
Five, the summary
One, foreword
This article introduces single sign-on SSO, divided into three parts: “Getting to know SSO”, “Traditional Login”, “Single sign-on”,
Introduction to SSO: Introduce the meaning of SSO, practical requirements, implementation methods and corresponding distributed architecture design;
Traditional login: introduces the traditional login process, existing problems, and solutions.
Single sign-on (SSO) : Describes the single sign-on (SSO) service process, Token, same-domain SSO, and cross-domain SSO.
Take a look!
Second, first know SSO
2.1 What is SSO? What is single sign-on?
Single sign-on (SSO) is the same thing. SSO means that users can log in to all trusted application systems only once. It includes a mechanism to map this primary login to another login for the same user in another application. It is one of the more popular enterprise business integration solutions. As shown below:
As shown in the figure above, there are four applications, Application1, Application2, Application3, and SSO. Application1, Application2, and Application3 have no login module. SSO has only the login module and no other service module. When any of Application1, Application2, and Application3 log in to the system, It jumps to the SSO system, which does the login, and the other applications follow suit. This enables a single login to access all trusted applications, which is exactly what we mean by single sign-on (SSO).
2.2 Realistic requirements for single sign-on? How to implement single sign-on?
In the early stage of enterprise development, enterprises use very few systems, usually one or two, each system has its own login module, operation personnel log in with their own account every day, very convenient. However, with the development of enterprises, more and more systems are used. When operating different systems, operation personnel need to log in several times, and the account of each system is different, which is very inconvenient for operation personnel. For example, such a system as Baidu, there are baidu know (Zhidao.baidu.com), Baidu Experience (Jingyan.baidu.com), Baidu Wenku.baidu.com and other subsystems, each of which has a different secondary domain name. If you want to set a login module for each subsystem, for developers, is cumbersome, for users, from one subsystem to jump to another subsystem to log back in again (may be its set password is different, that would be much big), so, traditional way of login cannot adapt to big companies multiple subsystems structure (of course, Like personal blog site is no problem), must to separate out the login function as a single SSO module (or SSO subsystem) and other specific business subsystems need only in the SSO system login, you can get a legal documents (token), in the company of all other system the freedom to jump.
Say so,
The practical requirements of single sign-on: the traditional login method can not adapt to the multi-subsystem structure of large companies;
Single sign-on (SSO) implementation: The login function is isolated as a separate module (i.e. SSO module), and only and only logon-related operations are performed in this module.
2.3 From a single architecture to a distributed architecture
Only as we are familiar with Java development as an example, the early web development needs only a login module, all the business logic is concentrated in this (a Tomcat) to complete an application server, including login, query, modify, because fewer early web applications use, less concurrency and interactive requirements is low, all this is done without any problems. But with the expansion of the company, and constantly develop more new business, and they (the new development of the business) are integrated into the web system, if still incorporating all of the business at this time for a project, to deploy on a tomcat, login using a template, not only in communication in the process of project development, maintenance, deployment is difficult, In addition, a Tomcat cannot withstand the combined concurrency of all the businesses, resulting in bad user experience. What is more fatal is that if Tomcat breaks down, the whole system of the company crashes, the consequences are unimaginable.
Single architecture:
With the advent of the Internet era, we still put all applications on the official website (.company.com), but different applications use different Tomcat, form a Tomcat cluster, or even use one Tomcat for each module of an application, in order to maximize the concurrency under the limit.
Distributed cluster architecture:
This creates a problem of how login information is shared between multiple Tomcats.
Our requirement is that for all products in the company (Application1 Application2 Application3), users log in to one product and then switch to another (all other products in the company become logged in).
Therefore, it is possible to log in in one application (Application1) and another application (Application2… ApplicationX). So as to realize the sharing of login status between applications, this is the problem that single sign-on (SSO) needs to solve.
Traditional login
3.1 Traditional Login Service Process
Simple B/S interchange diagram:
As is shown in the figure above, we access an application in Browser, which requires login. After filling in the user name and password, we complete login authentication. At this point, we need to do two things,
First, on the Server side, we mark the login status as yes in the user’s session.
Second, in the Browser, we need to write a Cookie in the Browser, which is the unique identity of the user.
Next time we visit this application, the request will carry this Cookie, and the server will find the corresponding session according to this Cookie, and judge whether the user logs in or not. If no special configuration is made, the Cookie is named sessionID and the value is unique on the server.
Let’s use a more detailed flow chart to illustrate the above process:
There are two server requests in total. The first request is a user login request. After entering the user name and password, the login authentication is completed. The second time is a service request. Check whether you have logged in. If yes, perform the service request. Flow chart of traditional login service:
3.2 Problems of traditional login
The logon flow chart above uses the server session to record the logon status. At first glance, this logon flow seems to meet the requirements. Indeed, if the early Web system, as described in Part 2, is deployed on a single Tomcat machine, the above implementation will not have any problems. However, in modern distributed Web system, using cluster Tomcat, there will be the problem that session cannot be shared between Tomcat.
Each application is deployed on a Tomcat. Each application has an independent session and does not communicate with other applications.
As long as the session sharing problem is solved, the login problem can be solved.
3.3 Solutions
Idea 1: Tomcat session replication
Advantages: No additional development is required, just setting up a Tomcat cluster.
Disadvantages: Tomcat is a global session replication. The sessions of each Tomcat in a cluster are completely synchronized (that is, the same at all times). In large-scale applications, if there are too many users and too many Tomcats in the cluster, the global session replication will degrade the cluster performance. The number of Tomcat should not be too large, preferably less than 5.
Summary: This method limits the scale of the Web application system, which cannot adapt to the growth of the company’s business needs.
Idea 2: Store session data in Redis.
Redis can set the survival time of the key, fast access speed and high efficiency.
Advantages: Redis has fast access speed and avoids the problem of session replication on multiple nodes. High efficiency.
Cons: Requires programmer development and uses redis as an extra.
Summary: Need extra help to use redis, skip.
Idea 3: Implement a single sign-on (SSO) system. Use tokens instead of sessions to save login status.
Advantages: The token is a string generated during user login and stored in the request header for network transmission. The token is used instead of the session. Compared with the session, the token can be shared between applications.
Faults: None.
Summary: Using token perfectly solves the problem of login authentication being shared (i.e. passed to each other) between Tomcat, which is the current SSO solution.
Single sign-on
4.1 SSO Service Process
How does single sign-on solve the multi-system login problem? How to implement single sign-on for multiple systems at one time?
Answer: Token mechanism. After a user successfully enters the account password for the first time, a token is generated. In the future, the user only needs to verify the validity of the token. If the token is valid, the user does not need to log in again. That is, it is shared between Tomcat application servers. The following is the single sign-on service flow chart:
Comparing the single sign-on service flow chart with the traditional login service flow chart above, we know that simple single sign-on (i.e. same-domain single sign-on below) actually uses token instead of sessionId for session authentication (traditional login writes the sessionId of the server into the browser through Cookie, Sso in the same domain writes the token generated by the server to the browser through the Cookie.
From traditional login to single sign-on, only change the sessionId to token, can you really share login state between applications? That is, one application of the company is logged in, while other applications are logged in.
Let’s take a full look at this new concept — tokens.
4.2 Token
Question 1: What is token?
Answer 1: The token is actually a string returned by the server after a user successfully logs in.
Question 2: What is the use of token after it is returned? How does it work?
Answer 2:
(1) What is the use of token? The token exists to enable multiple systems to log in once and share the login status.
(2) As for how to use the token, the application will put the token in the request header every time it interacts with the server and requests the server (whether it is a GET request or a POST request). Token is usually put in the request header), together with the entire request sent to the server, the server receives request message from the program to test the validity of the token request header, token effective cases in complete relevant operation, if the token is invalid, returns a status code, corresponding program after receiving the status code, users need to login again.
Question 3: Where is the user token returned by the server stored?
Answer 3: The browser receives the token from the server and stores it in a cookie or localStorage.
Q4: How to determine the token value generated by the server? Is it random? Or are there rules?
Answer 4: Theoretically, it can be random, as long as the token meets the uniqueness and certainty. Because single sign-on (SSO) requires a single login, and multiple systems use this function together, it is only necessary to have a unique and determined token string generated. There is no need to specify which rule the string is generated according to. However, in the project development of the company, the project leader and C/S and B/S developers generally communicate well and follow certain norms.
The composition of a simple token can be: Uid (the user’s unique identity), time(the timestamp of the current time), and sign (the signature) can be the hexadecimal string of a certain length compressed by the hash algorithm for the first few bits of the token, or the string of the token can be changed into 32 fixed length unique string by MD5 encryption. Although MD5 encryption is not secure, Skin)
Just like when we started to write the program, the command of variable name and method name, although theoretically can be customized, but in order to facilitate communication and later maintenance, will follow some established rules.
Q5: Token generation and removal?
Answer 5:
The generation of token
Token generation consists of two parts,
First, the server generates the token and stores it in the key of the map. The value of the map stores the user object. That is, the server (key,value) = (token value,user object).
Second, the browser needs to generate a Cookie named token, which is used to store the value of the token returned by the server, that is, browser Cookie= (“token”,”token specific value XXX “);
The token was removed after expiration
The token removal is also done in two parts: first, the token is removed from the Map on the server and the Cookie named token is deleted on the browser.
4.3 with domain SSO
4.3.1 Introduction: What is a domain? (How to understand domains in computer networks)
Domain in a computer network is a concept in the application-layer DNS system. Because IP addresses are not easy to remember, the DOMAIN name System maps IP addresses into easy-to-understand domain names. From right to left, a domain name is divided into top-level domain names (also known as level-1 domain names), level-2 domain names, and level-3 domain names. About domain, can be simply understood as a level domain name is a domain (although not authoritative), a level domain name as a domain, can facilitate the following understanding of the same-domain and cross-domain.
What are co-domain and cross-domain? Take a look at the table below:
| URL(domain name, only two level domain name here) | The detail | Co-domain/cross-domain | The sample |
|---|---|---|---|
| Application1.company.com/a.htmlhttp:… | Under the same domain name, different web pages with the same domain name (level-1 domain name and level-2 domain name are the same) have different pages | The same domain | Fully co-domain SSO, with the same domain name |
| Application1.com panycom/test1 / a.h tm… | The same domain name, different pages in different folders have the same domain name (level-1 domain name and level-2 domain name are the same) and the subfolders are different, so the pages are naturally different | The same domain | Fully co-domain SSO, with the same domain name |
| Application1.company.com/a.htmlhttp:… | The default value is port 80. The default value is port 80 and port 8080. The default value is port 80 | Cross-domain (different ports) | |
| Application1.company.com/a.htmlhttps… | Same domain name Different web pages in different protocols Same domain name (level-1 domain name and level-2 domain name are the same) Same port number 80 different protocols (HTTP and HTTPS) | Cross-domain (different protocols) | |
| Application1.company.com/a.htmlhttp:… | One is a domain name and the other is an IP address | Cross-domain (considered cross-domain) | |
| Application1.company.com/a.htmlhttp:… | Different domain names (same level 1 domain name, different level 2 domain name) | Cross domain (different domain names) | The secondary domain name is different from the parent domain SSO |
| Application1.company.com/a.htmlhttp:… | Different domain names (the level-1 domain name is the same, but the level-2 domain name is different) The default value of the level-2 domain name is the responsibility of o&M. Generally, The JavaWeb project is configured by nginx server | Cross domain (different domain names) | The secondary domain name is different from the parent domain SSO |
| Application1.company.com/a.htmlhttp:… | Different domain names (level 1 domain name, level 2 domain name are different) | Cross domain (different domain names) | Cross-domain SSO, level 1 domain name is different |
Kingship: According to the same origin policy, the protocol, domain name, and port must all be the same.
Note: the domain classification is not only to http://application1.company.com as an example
Full specification format agreement :// Class N domain name… Level 3 domain name Level 2 domain name Level 1 domain name (as above “agreement :// Level 3 domain name. Level 2 domain name. Level 1 domain name “)
Com is a level 1 domain name (also called a top-level domain name)
Company is a secondary domain name
Application1 is a three-level domain name
HTTP indicates the protocol name
Statement 2 (Industry) :
Company.com is a level-1 domain name
Application1 is a second-level domain name
Note: Statement 1 is the official statement, which is used in the authoritative textbook computer Network written by Xie Xiren in China and wikipedia abroad, and statement 1 has a complete standard format. However, in the domestic industry, we always classify domain names from the perspective of purchasers (in fact, renters). For example, if the company.com domain name is purchased by a company, company.com is a first-class domain name and Application1 is a second-class domain name.
Sometimes it is said that QQ.com and Baidu.com are first-class domain names, which is the same reason. From the perspective of Tencent and Baidu, they regard the domain names they purchased (QQ.com and Baidu.com) as first-class domain names. The subsystem developed by myself (lol.qq.com, game.qq.com) is regarded as a secondary domain name.
Note: in the industry, not only company.com is considered as a first-class domain name. www.company.com is also considered as a first-class domain name, such as www.baidu.com and www.qq.com. Reason: because WWW is too commonly used, everybody recognized so……
To sum up, there are two ways to divide domain name, the academic world is statement 1, the industrial world is statement 2, here we are all programmers, please allow this article to use statement 2.
4.3.2 with domain SSO
Web applications use client/ Server architecture. HTTP is a stateless protocol (that is, the last connection is not recorded) for network communication. The Session of a single system is maintained by the server Session. Session persistence the principle of Session persistence is to write the Session ID into the browser through cookies. Each access automatically carries all cookies, and the server reads the Session ID for verification to achieve Session persistence.
Assume that the company.com domain name is company.com and the application domain names of the company are applicaton1.company.com, Application2.company.com, application3.company.com. Separate the login module with the domain name sso.company.com.
As long as we are logged in at sso.company.com, application1.company.com, Application2.company.com and application3.company.com are also logged in. Sso.company.com is a login authentication system that allows you to log in to sso.company.com
The login status is recorded in the session on the server of sso.company.com, and cookies are written in the sso.application.com on the Browser. So how do we get App1.a.com and App2.a.com to log in? There are two questions:
(1) Browser cookies are not cross-domain: The domain attribute of our Cookie is sso.company.com, and we cannot send requests to application1.company.com, Application2.company.com, and application3.company.com.
Sso, Application1, Application2, and Application3 are different applications. Their sessions are stored in their own applications and do not share.
Regarding the first question, browser cookies cannot cross domains. How can other applications (Application1, Application2, application3) access SSO cookies?
Solution: After sso login, you can set the sso Cookie domain to the top domain, i.e. Company.com, so that all sub-domain systems can access the cookies in the top domain. When we set cookies, any application can only set the top field and its own field, not other fields.
On the second question, the server session cannot be shared between applications?
Sessions cannot be shared between different applications:
When we log in to the SSO system and then access APP1, the Cookie is also brought to the Server of APP1. How can the Server of APP1 find the Session corresponding to this Cookie? Here, the Session of each system will be shared, as shown in the figure:
There are many solutions for sharing sessions, such as Spring-Session.
Single sign-on in the same domain is implemented:
In fact, we can see that there seems to be no difference between same-domain sso and traditional login, the only difference is,
In the same domain SSO, handwritten tokens replace session ids for session authentication (traditional login writes the JSESSIONID of the server into the browser through cookies, while sso writes the token generated by the server into the browser through cookies).
However, it is invisible to users and does not bring any improvement to user experience or contribute to user convenience.
The reason is that this isn’t really single sign-on, that is, single sign-on hasn’t really worked out yet. Take a look at the cross-domain SSO principle analysis.
4.4 cross-domain SSO
4.4.1 CAS
Central Authentication Service (CAS) is a multi-language single sign-on (SSO) solution for enterprises and strives to become a comprehensive platform for Authentication and authorization requirements.
CAS is an enterprise-level, open source project initiated by Yale University that aims to provide a reliable single sign-on solution (Web SSO) for Web applications.
The CAS protocol involves at least three parties: the Web browser (Brower in the sequence diagram below), the Web application (Protected App, Protected App #2 in the sequence diagram below), and the CAS Server (CAS Server in the sequence diagram below). It may also involve a back-end service, such as a database server, that does not have its own HTTP interface but communicates with a Web application.
4.4.2 Cross-domain SSO sequence diagram
1. Request app page for the first time
The figure above is the standard process of CAS official website, and the specific process is as follows:
- The user accesses the APP system, which requires login, but the user is not logged in.
- When the CAS server (SSO login system) is switched to, the SSO system is not logged in to, and the user login page is displayed.
- After a user enters the user name and password, the SSO system authenticates the user, writes the login status to SSO session, and writes the Cookie in the SSO domain in Browser.
- After the SSO system logs in to the system, a Service Ticket (ST) is generated. Then, the SYSTEM switches to the APP system and passes the ST to the APP system as a parameter.
- After the APP system gets the ST, it sends a request to SSO from the background to verify whether the ST is valid.
- After the authentication passes, the APP system writes the login status into the session and sets the Cookie in the APP domain.
At this point, cross-domain single sign-on is complete. 2. Request app page for the second time
As shown in the picture, when we visit the APP system in the future, the APP is logged in.
3. Request app2 page for the first time
The figure above shows the flow when accessing app2 system:
- When a user accesses app2, the user does not log in to app2 and switches to SSO.
- Since SSO is already logged in, re-login authentication is not required.
- SSO generates an ST, and the browser jumps to the APP2 system and passes the ST to App2 as a parameter.
- App2 gets the ST and accesses SSO in the background to verify whether the ST is valid.
- After successful authentication, App2 writes the login status to session and cookies to the App2 domain.
In this way, app2 system does not need to go through the login process, it is already logged in. SSO, APP, and App2 are in different domains, so it’s ok that the session between them is not shared.
Add: Account password login, mobile phone verification code login, third party login, single sign-on discrimination
One by one, account password login is the most primitive way, system (website or APP or game) developers maintain an account system, and provide registration, login, password retrieval and a series of specific business logic processing;
Mobile verification code login is an efficient and secure login method after the rise of mobile Internet, which is almost a perfect design.
Efficiency: in modern and efficient social life, there is no need for users to memorize difficult passwords, reducing the burden of users.
Security: The 4-digit or 6-digit SMS verification code is directly sent to the user’s mobile phone, and then copied and pasted to the login page to ensure that the user does not forget it and others do not know about it.
Third-party login is one of the most common QQ login and WeChat logged in (mainly both products the widest audience), developers when related development center according to the official API call interface, and then you can use directly, also ensure the efficiency and safety, high efficiency: products don’t need an account system, users don’t have to remember passwords, security: Give your account number and password to a large company for safekeeping.
Nowadays, Internet companies do not need to maintain an account system by using mobile verification code to log in or third-party login, so they can concentrate more on business development and product design. Mobile phone login authentication code and the third party, therefore, almost completely replace the login account password, modern emerging Internet products all at the same time support mobile login authentication code and third-party login, almost does not provide account password, only kept in some of the early Internet sites account password login interface, such as CSDN, B station.
Account password login, mobile verification code login and third-party login are all independent login methods. However, single sign-on is only an architectural design idea, not an actual login method. Its actual login method should be realized from the first three most common login methods or other login methods.
Single sign-on (SSO) shows its advantages only in multiple systems. After a user logs in successfully for the first time, a token is generated. The token mechanism is used to ensure that multiple systems need only one login to maximize user experience.
Five, the summary
This article introduces single sign-on SSO, which is divided into three parts: “Getting to know SSO”, “Traditional Login” and “single sign-on”.
Play code every day, progress every day!
