Recently, Xiaoming encountered a demand: several independent systems (subsystems) need to be aggregated into a centralized system (parent system). After the user logs in on the parent system, click here With several subsystems, you can jump to any system without logging in. At that time, duang~duang~ had a lot of plans pouring in (braggering), but only the following plan was affirmed by the leader. Now it has been running online, let’s review it for everyone.
After reading this requirement, does everyone’s first impression is: Isn’t this an SSO (Single Sign-On) system?
Single sign-on (English: Single sign-on, abbreviated as SSO), which is also translated as single sign-in, one for many mutual connections, but also Each independent software system provides access control attributes. With this attribute, when a user logs in, he can obtain access rights to all systems, instead of having to log in to each single system one by one. This function is usually implemented by the Lightweight Directory Access Protocol (LDAP), where user information is stored in the LDAP database on the server. Similarly, single sign-off means that only a single sign-off action is required to end access to multiple systems.
Yes, that’s right. After Xiao Ming received this demand, his overall idea was also based on SSO, but after careful consideration, he found that he could not copy it completely. The actual situation of the project should be considered: For example, several known subsystems have been developed before, and they cannot be used to make any effort. They need to be smoothly connected to the parent system, and according to requirements, SSO functions do not need to be fully implemented. In short, it is a castrated version. SSO.
Xiao Ming only needs to realize: After the user logs in with the parent system account password, he can jump to the subsystem by clicking any of the function buttons of any subsystem (no need to re-enter account login) The function page is fine.
Design process
Project
A simple and simple SpringBoot project
Timing diagram
The user enters the account and password, and requests the SSO user login module to verify the account and password. After the verification is passed, a global session is established and the front-end token credentials are returned (I use It is sessionId), carry the token when jumping to other systems. After the other systems get the token, they will call the SSO platform to verify the token. If the verification passes, the user can establish a session in the subsystem and the user jumps to the system. The following is an example of the sequence diagram of SSO jumping a subsystem:
Put in here. The flowchart tool I use is ProcessOn, which is an online drawing tool, very suitable for drawing various schematic diagrams. The experience is excellent. If you want to try it out, you can use my invitation link to register and use it~
The entire flow chart is shown above, and the following is a detailed description of each function point.
Login and session retention of SSO system
This session management uses redis session, spring perfectly supports redis storage Session information, in addition, it also supports MONGODB\JDBC\HAZELCAST and other storage session methods. Store sessions through redis, which can meet the needs of cluster deployment and session sharing in distributed systems (of course these are all later).
pom.xml dependency configuration is as follows
org.springframework .boot
spring-boot-starter-data-redis
org.springframework.session
spring-session-data-redis
application.yml configure redis and session
spring:
redis:
host: 127.0.0.1
password: 123456
port: 6379
timeout: 1500
database: 0
jedis:
pool:
max-active: 1000
max-wait: -1
max-idle : 10
min-idle: 5
# Set the session storage type to redis
session:
store-type: redis
At this time, redis stores the session The configuration has been completed, but I always feel that something is missing. Alas, in addition to this, we also need to set the effective duration of the session. The configuration in application.yml is as follows:
server:
servlet:
sessi on:
# Support Duration expression, which means 120 minutes at this time
timeout: PT120M
Of course, we also need to pass @EnableRedisHttpSession in the main Springboot method Open redis session
Note: If the effective duration of the session configured above does not take effect, we can configure the effective time of the session on the annotation attribute (to be honest, I just configured it here to take effect)
@SpringBootApplication
// Open the redis session and set the effective duration of the session
@EnableRedisHttpSession(maxInactiveIntervalInSeconds = 7200)
public class XiaoMingApplication {
public static void main(String[] args) {
SpringApplication.run(XiaoMingApplication.class, args);
}
}
So far, The login and session management of the sso system is complete. Next, let’s look at how to interact with other systems.
jump subsystem
process
If SSO is logged in -> the user clicks on a subsystem Button (link agreed with the person in charge of system A) to initiate a get request -> the back end of system A receives the request -> call the SSO system for token verification (described below) -> establish a session, for example
http://xxx/jump?token=123456
This is a get request entered in the address bar. This interface requires special processing and the back-end interceptor needs to be released.
parameter description
| Parameters | Description |
|---|---|
| xxx | where xxx is the domain name, and jump is the url address of the interface provided by system A, which can be customized, and an agreement is required |
| token | Returned verification certificate |
The interface actually needs to do two things:
- Request SSO for token verification (similar to the previous user and password Log in, just call the SSO platform interface to verify);
- Establish a local session (consistent with the establishment of a session after the account password is successfully logged in).
- Control the page jump after the verification is passed.
SSO provides a token verification interface for the subsystem
As mentioned above, SSO will expose a token verification interface. The logic of the verification interface is very simple, that is, take the token to redis to find whether the corresponding user information exists. As we all know, Xiao Ming is a lazy person. For the sake of opportunism, Xiao Ming’s token generation rule is the id of the session. Therefore, to determine whether a user is logged in is actually to find whether there is a session in redis according to the sessionId. There are bright spots here . By looking at the source code, I found that this function does not need to be implemented by ourselves. Spring has already thought that we will use it.
Spring provides an interface org.springframework.session.SessionRepository
package org.springframework.session;
public interface SessionRepository{
S createSession();
void save(S var1);
// This is
S findById(String var1);
void deleteById(String var1);
}
where S findById(String var1) is the method we want to call, this method The function is to find the session object in the session center according to the sessionId, which is exactly what we need, we only need to get it through @Autowired, and use it out of the box~ Let’s take a look at the business code:
< pre>@Autowired
private SessionRepository sessionRepository;
@PostMapping(“/checkToken”)
public BaseResponseFacade checkToken(@RequestBody UserLoginVo userLoginVo) {
if (Objects.isNull(userLoginVo) ) {
return ResponseUtil.error(NEED_LOGIN);
}
String token = userLoginVo.getToken();
Session session = sessionRepository.findById(token);
if (Objects.isNull(session)) {
return ResponseUtil.error(NEED_LOGI N);
}
AdverInfo adverInfo = JSON.parseObject(session.getAttribute(“adverInfo”), AdverInfo.class);
return ResponseUtil.success(adverInfo);
}
SSO and subsystem interaction documents are also posted for everyone to see it quickly
interface call request description
- request method : POST
- Request format: JSON
- Request address
- Test: http:/xxx/checkToken
- Official: http://xxx /checkToken
- POST data example
{
"token": "123456"
} Parameter description
| Parameter | Description | < /tr>
|---|---|
| xxx/checkToken | xxx is the domain name, checkToken is the verification interface address provided by the marketing cloud platform |
| token | Call interface credentials |
Return to description
Example of json data packet returned under normal conditions
If SSO verification passes, system A can communicate with The current user establishes a local session and the user enters the system normally
{
"data":{
"XXX":"XXX"
},
"errorMsg ":"Success",
"errorCode":0
}< /pre> Parameter description
| Parameter | Description |
|---|---|
| errorCode | 0: indicates that the request was successful |
| errorMsg | Return code description |
| XXX | Other related information |
Example of json data package returned when abnormal
When SSO background verification fails, the return parameters are as follows
{
"errorMsg": "NEED_LOGIN",
"errorCode": 10
}
Parameter description
| Parameter | Description |
|---|---|
| errorMsg | Error message description |
| errorCode | error flag |
error code Description
| error code | description |
|---|---|
| 1 | The system is busy |
| 10 | User login required< /td> |
| 500 | Server internal error |
Designed by Xiaoming The concise version of sso is roughly like this. You can look at it as an introductory sso demo?? If you have any suggestions or questions, please leave a message~ You can also follow the WeChat public account "Programmer Xiaoming" for more resources~
Welcome to follow the WeChat public account "Programmer Xiaoming" for more resources.