Single sign-on (sso) Getting Started

Single sign-English name is called Single Sign On, referred to as the SSO.

In the past, we usually single system, all functions on the same system.

Later, we rational use of resources and to reduce the coupling, so the single split into a plurality of sub-systems.

For example, Ali Taobao and Tmall, it is clear that we can know that this time the two systems, but when you use landed Lynx, Taobao will automatically log in. In simple terms, it is the single sign-on multiple systems, users need only log in once, each system that is able to sense the user is logged in.

Single System Log

As we all know, HTTP is a stateless protocol, which means that the server was unable to confirm the information of the user. Ever since, W3C put forward to every user issues a permit, regardless of the time who visit are required to carry a pass, so that the server can confirm the user's information from the pass. Pass is Cookie.

If Cookie is to check the user's body passport to confirm the identity of the user, then the Session is the list (passport list) to confirm the identity of the user by the client to check on the server. Session equivalent to establish a customer list (pass list) in the server.

Because HTTP is a stateless protocol, and therefore can not be based on HTTP Session is connected to determine whether a user is the same. Then the server sends the user's browser to a Cookie named JessionId, its value is the value of the Session id, then Session Cookie can be identified based on whether a user is the same.

General system of single sign-on function is to achieve the following steps:

1. After landing, the user information stored in the Session object. If they can be found in the Session object, explained that it had landed; If you can not find in the Session object, indicating not logged in (or has exited the landing).

2. logout (logout), delete user information from Sessoin in.

3. Remember me, request with Cookie's. As long as Session has not failed, even after you close your browser, re-open the browser can maintain login state. This step is to verify the identity, typically use interceptors to achieve.

Multi-landing system problems and solutions

Session Sharing

Single sign-on function The system is mainly to save the user information to achieve the Session, but the system may have a plurality of multiple Tomcat, and is dependent on the current system Session Tomcat, so Seesion system A and system B Session there is a shared problem.

Session solve shared problems between systems there are several options:

1.Tomcat Global Copy Cluster Session (Session Tomcat within each cluster fully synchronized), but this plan will affect the performance of the cluster is generally not recommended.

2. using a reverse proxy server, according to the request of IP mapping to a corresponding Hash machine, so the same IP address request will always be forwarded to the same server. Common solution is to use Nginx as a reverse proxy server, and use its ip_hash load balancing policy. This scheme may be because of server downtime withstand high concurrency and lead to the loss of most of the Session data, and therefore not recommended.

3. The Session Redis into the cache, each cache read by the server to achieve the same Redis Session sharing. Redis good performance, high throughput, it also provides persisted to disk functions, generally recommended to use this program.

Cookie cross-domain issues

When we request www.yanggb.com, the browser will automatically www.yanggb.com the Cookie with the past, but do not put www.renj.com the Cookie with the past, this time because of the different domain names lead to cross-domain problem. Specifically, when the same-origin policy problem caused by a browser, the same origin policy does not allow cross-domain access of Cookie JS, when sending the request to call the JS library browser's Cookie Cookie obtained, this time because Cookie is stored in the domain name attribute as identification tag, JS not get a domain of non-Cookie.

Cookie for cross-domain problem, there are several solutions:

1. Token instead of Session. After the server will write the client Cookie, Cookie client to parse, parse out the Token is stored in the SessionStroage, after which the request put the Token bring identity verification.

2. Multiple domain names share a Session, set domian Cookie at the time written to the client.

CAS principle

Speaking of single sign-on, it will certainly be exposed to CAS. CAS stands for Central Authentication Service, namely the central authentication service, it means an independent certification center.

Suppose now that there are three services, one www.yanggb.com, one www.renj.com, there is a www.sso.com, which is www.sso.com Certification Center.

1. When a user wants to access www.yanggb.com limited resources (requires login) of the time, www.yanggb.com found that users not logged in, you will be redirected to www.sso.com Certification Center, and their address as a parameter, such as:? www.sso.com service = www.yanggb.com.

2. Then www.sso.com authentication service if it is found the user is not logged in, will direct the user to the landing page. After the user with a user name and password to login, user authentication center will create a global conversation (written to generate Token Cookie and stored in the browser). Then Certification Center can be redirected to www.yanggb.com service, and the Token carry past:? Www.yanggb.com token = ********.

3. Then www.yanggb.com will go www.sso.com Certification Center check this Token is correct, if correct, would www.yanggb.com service and users to establish a local session (created Session).

4. Next, the user wants to access www.renj.com limited (requires login) resources, www.renj.com service discovery user does not log in, you will be redirected to www.sso.com authentication center, likewise his address as an argument:? www.sso.com service = www.renj.com. Because before the user and www.sso.com Certification Center has established a global session, so this www.renj.com redirected to www.sso.com certification center is to bring the Cookie. Certification Center found that the Cookie has brought over with the users to establish a global session, it will be redirected to www.renj.com, and the Token carry over to www.renj.com, redirection address: www.renj.com ? token = ********.

5. Finally, www.renj.com will go www.sso.com Certification Center check this Token is correct, if correct, would www.renj.com and users to establish a local session (created Session).

In fact, SSO authentication center is similar to a transfer station, which is the core idea of ​​CAS.

 

"The world's most cruel not to escape, but close does not own."

Guess you like

Origin www.cnblogs.com/yanggb/p/11136528.html