What is single sign-on
Simply put, it is the company has A, B two systems, I logged A system after the jump to the B system can be accessed directly, without the need to log B system again.
Several common single sign-on implementation
Before explaining single sign first explain a few basic concepts:
Cookie:
Cookie is a period of no more than 4KB small text data is stored in the user's local, usually in the format:
Expires property: Set Cookie's survival
Domain attribute: specifies the Web site or domain can access the Cookie's
For example, the figure Domain: 192.168.1.72 This means that only under request only 1.72 can use this cookie, Baidu what you can not use this cookie
Path attribute: defines the directory can be accessed on the Web site of the Cookie
Figure Path is /, which means that this cookie is owned by the root, as long as the request will default to bring this cookie, adding that Path 1.72 / webaikn, then only http://192.168.1.72/webaikn/** request We will bring this cookie, but http://192.168.1.72/webadmin/** can not use this cookie
Other: Slightly
Session:
http request is stateless, but when we daily access to the system is that I want the system to remember the user, this time to rely on the session to achieve, thus becoming session control session, but still can not achieve alone session session control , cookie required configuration, as shown:
The key is to keep JESSIONID session, it is the value corresponding to the user in the sessionId server, so we write code directly HttpSession session = request.getSession (); data not only confusion.
Ps: there is session facilitated our development, but also increases the trouble to a certain extent, such as multi-machine deployment seesion lost time,
Redirect
In short, the forwarding server behavior, redirect the client behavior.
Forwarding and redirection can be implemented by java background, such as:
Forwards the request:
request.getRequestDispatcher("/user").forward(request,response);
Redirect:
response.sendRedirect(request.getContextPath + "/user")
Once set up forwarding, the request will go directly to the forwarding address, and redirected, then the request will first return to the client, then the client re-launched to the new address requests here hides a knowledge point, when I set in the background a cookie and then redirect the time, in fact, I redirected request has been set up to bring me a cookie
(1) A and B is assumed that two systems are deployed on the server 192.168.110.110
After users log in the A system, code-behind set the userName and password stored as a cookie to the user's browser and the cookie domain is set to 192.168.110.110, path is set to /
When after a visit to the B system Ip because we are the same, so the B system can obtain the cookie A system settings, it is only need to set an interceptor, the interceptor to determine whether the user is logged in, if not logged on We went to request information acquired cookie, and then decrypt the simulation to log on after the acquisition, so the user can not log on to the B-aware system.
Comments: This is typical of the same domain single sign-on implementation, the limitations of very large, both systems must be achieved at the same the same server or secondary domain name cases, generally referred to as pseudo single sign-on
A single point (2) Knowledge Base System sign-on implementation
Knowledge of the program increases Nginx as a reverse proxy (reverse proxy have forward proxy, look for information on their own what is forward proxy What is a reverse proxy) on the basis of 1
Although webaikn and webadmin deployed in different servers, but the customer is not aware, as are access Nginx, and then do the forwarding agent by the nginx, so the domain name is the same, so is the cookie can be shared, there is a need to point note, webaikn may be multi-machine deployment, nginx in doing so need to set ip_hash forwarding strategy, the purpose of which is to ensure that requests access to a server on the user, or the next time that access servers, and will not lead to the loss of session Happening.
Comments: to solve the multi-machine deployment single sign of failure, but still need to save server-side session state of the user, on the one hand for the server generates memory pressure, on the other hand you need to configure ip_hash lead to uneven flow, pressure some servers relatively large. and the user name and password in a cookie there are some security risks, as long as the result is truncated to the next request will account stolen
(3) cross-domain single sign-token
The main steps:
- A user logs on the system, a discovery request interceptor A system with no token, then redirected to the single sign-on authentication center sso system, attention request url belt before the user, we call back oldUrl
- Sso receiving the request, not found in the cookie request token token successful login, then redirected to the login page of the present system, continue with oldUrl
- User to enter a user name and password, submit
- Sso verify that the user name is correct, incorrect to continue redirected to the login page, if correct, the following operations:
Generating a cookie, name called token, value can be any unique values, uuid line (note that the cookie is between the browser and the system sso)
The user information stored in redis, key is generated uuid, value is the user objects
Redirected to address oldUrl, pay attention to the stitching parameter token
- A system receives the request again, except that the token has parameters, the system A according to the value of the token verification redis needed here discussed Points
Not found: Description of other subsystems initiated cancellation of operations, sso needs to be redirected to the login page
Found: Once you have a User object can determine whether the current request the user permissions table, there is a direct release, there is no lack of permission to return, after the request requires the token into the request header information or the url
- After the user has finished browsing system A, system B ready to go around, so the browser sends a request to the system B, system B receives the request interceptors, with no discovery request token, to initiate redirection SSO, remember to take this request oldUrl
- In fact, at this time, and the second step above similar, except that due to the previously signed sso so this request is in the cookie token, it only needs to be redirected to address sso oldUrl point on the line, but remember to take a cookie spliced out of the token to the url
- After the B-system receives the request again, step 5, and the operation is the same as the
Comments: an independent single sign-on authentication center, unified certification authority to do the operation, clarity
Subsystem does not need to use the session to save the user login status, reducing the burden on the server
Each request is to verify the token as standard, even if the request is intercepted, will not disclose user information
When the latter do not need to log tripartite will expose user data to other systems, other systems can get only token (tripartite really need to do to log stored in redis certainly some of the most simple user information)
The following chart is taken from big brother who I have no address, as if the door is a treasure
Source: https: //www.cnblogs.com/renchunpeng/p/11753921.html
What is single sign-on
Simply put, it is the company has A, B two systems, I logged A system after the jump to the B system can be accessed directly, without the need to log B system again.
Several common single sign-on implementation
Before explaining single sign first explain a few basic concepts:
Cookie:
Cookie is a period of no more than 4KB small text data is stored in the user's local, usually in the format:
Expires property: Set Cookie's survival
Domain attribute: specifies the Web site or domain can access the Cookie's
For example, the figure Domain: 192.168.1.72 This means that only under request only 1.72 can use this cookie, Baidu what you can not use this cookie
Path attribute: defines the directory can be accessed on the Web site of the Cookie
Figure Path is /, which means that this cookie is owned by the root, as long as the request will default to bring this cookie, adding that Path 1.72 / webaikn, then only http://192.168.1.72/webaikn/** request We will bring this cookie, but http://192.168.1.72/webadmin/** can not use this cookie
Other: Slightly
Session:
http request is stateless, but when we daily access to the system is that I want the system to remember the user, this time to rely on the session to achieve, thus becoming session control session, but still can not achieve alone session session control , cookie required configuration, as shown:
The key is to keep JESSIONID session, it is the value corresponding to the user in the sessionId server, so we write code directly HttpSession session = request.getSession (); data not only confusion.
Ps: there is session facilitated our development, but also increases the trouble to a certain extent, such as multi-machine deployment seesion lost time,
Redirect
In short, the forwarding server behavior, redirect the client behavior.
Forwarding and redirection can be implemented by java background, such as:
Forwards the request:
request.getRequestDispatcher("/user").forward(request,response);
Redirect:
response.sendRedirect(request.getContextPath + "/user")
Once set up forwarding, the request will go directly to the forwarding address, and redirected, then the request will first return to the client, then the client re-launched to the new address requests here hides a knowledge point, when I set in the background a cookie and then redirect the time, in fact, I redirected request has been set up to bring me a cookie
(1) A and B is assumed that two systems are deployed on the server 192.168.110.110
After users log in the A system, code-behind set the userName and password stored as a cookie to the user's browser and the cookie domain is set to 192.168.110.110, path is set to /
When after a visit to the B system Ip because we are the same, so the B system can obtain the cookie A system settings, it is only need to set an interceptor, the interceptor to determine whether the user is logged in, if not logged on We went to request information acquired cookie, and then decrypt the simulation to log on after the acquisition, so the user can not log on to the B-aware system.
Comments: This is typical of the same domain single sign-on implementation, the limitations of very large, both systems must be achieved at the same the same server or secondary domain name cases, generally referred to as pseudo single sign-on
A single point (2) Knowledge Base System sign-on implementation
Knowledge of the program increases Nginx as a reverse proxy (reverse proxy have forward proxy, look for information on their own what is forward proxy What is a reverse proxy) on the basis of 1
Although webaikn and webadmin deployed in different servers, but the customer is not aware, as are access Nginx, and then do the forwarding agent by the nginx, so the domain name is the same, so is the cookie can be shared, there is a need to point note, webaikn may be multi-machine deployment, nginx in doing so need to set ip_hash forwarding strategy, the purpose of which is to ensure that requests access to a server on the user, or the next time that access servers, and will not lead to the loss of session Happening.
Comments: to solve the multi-machine deployment single sign of failure, but still need to save server-side session state of the user, on the one hand for the server generates memory pressure, on the other hand you need to configure ip_hash lead to uneven flow, pressure some servers relatively large. and the user name and password in a cookie there are some security risks, as long as the result is truncated to the next request will account stolen
(3) cross-domain single sign-token
The main steps:
- A user logs on the system, a discovery request interceptor A system with no token, then redirected to the single sign-on authentication center sso system, attention request url belt before the user, we call back oldUrl
- Sso receiving the request, not found in the cookie request token token successful login, then redirected to the login page of the present system, continue with oldUrl
- User to enter a user name and password, submit
- Sso verify that the user name is correct, incorrect to continue redirected to the login page, if correct, the following operations:
Generating a cookie, name called token, value can be any unique values, uuid line (note that the cookie is between the browser and the system sso)
The user information stored in redis, key is generated uuid, value is the user objects
Redirected to address oldUrl, pay attention to the stitching parameter token
- A system receives the request again, except that the token has parameters, the system A according to the value of the token verification redis needed here discussed Points
Not found: Description of other subsystems initiated cancellation of operations, sso needs to be redirected to the login page
Found: Once you have a User object can determine whether the current request the user permissions table, there is a direct release, there is no lack of permission to return, after the request requires the token into the request header information or the url
- After the user has finished browsing system A, system B ready to go around, so the browser sends a request to the system B, system B receives the request interceptors, with no discovery request token, to initiate redirection SSO, remember to take this request oldUrl
- In fact, at this time, and the second step above similar, except that due to the previously signed sso so this request is in the cookie token, it only needs to be redirected to address sso oldUrl point on the line, but remember to take a cookie spliced out of the token to the url
- After the B-system receives the request again, step 5, and the operation is the same as the
Comments: an independent single sign-on authentication center, unified certification authority to do the operation, clarity
Subsystem does not need to use the session to save the user login status, reducing the burden on the server
Each request is to verify the token as standard, even if the request is intercepted, will not disclose user information
When the latter do not need to log tripartite will expose user data to other systems, other systems can get only token (tripartite really need to do to log stored in redis certainly some of the most simple user information)
The following chart is taken from big brother who I have no address, as if the door is a treasure
Source: https: //www.cnblogs.com/renchunpeng/p/11753921.html