Single sign-on before the World This Life __ Project combat

http Stateless Protocol

HTTP is a stateless protocol, each time the browser requests, the server will be processed independently, not with the previous or subsequent requests, so that any user can access the server resources through the browser.

Session and Cookie mechanisms

The session is server-level and the cookie is browser-level.

Session: The first time the browser requests the server, the server creates a session, and sends the session ID as part of the response to the browser, the browser stores the session ID, and then every time the browser's access server takes a conversation ID, and the server knows if it is the same user based on the session ID.

Cookie:session mechanism every time the browser accesses the server, the server has to judge the session ID once, which is obviously not appropriate. So the browser to maintain the session ID is the cookie mechanism. The browser automatically ships with cookie information each time it accesses the server.

Cookies and session mechanisms ensure that a user logs on to a system, and that subsequent operations do not need to log on again for a certain amount of time.
Multi-System solution 1--top-level domain

The above session and cookies are only applicable to a single system, but the number of systems become multiple systems, we can not access a branch system to log on once, so that the domain name of these subsystems unified into a top-level domain, and then the cookie domain to set the top-level domain name, Cookies can then be shared between subsystems.

single point of entry where do you come from?

There are many limitations to sharing cookies. For example: Domain name is difficult to unify, subsystem technology is difficult to unify. Therefore, a new login method is needed to realize the login of multi-system application group-single sign-on.

is what

Single sign-on full name sign, referred to as SSO, means that you can log in to a system in a multiple-system application group and be authorized in all other systems without having to log on again, including a single sign-on and a single logout.

How to achieve Log in

SSO requires an independent certification center, only the certification center can accept the user's user name password and other security information, other systems do not provide access to the login, only the certification center authorized indirectly. Indirect authorization through token implementation, SSO Certification Center to verify the user's username password is no problem, create authorization token, in the next jump process, the authorization token as a parameter sent to each subsystem, the subsystem to get the token, that is authorized, can use this to create a local session, A local session is logged in the same way as a single system. The exact process is as shown in the figure:

Action steps are as follows:

1. User access to the system 1 of the protected resources, System 1 found that users are not logged in, jump to the SSO Certification Center, and its own address as a parameter
2.sso Certification Center found that users are not logged in, the user to boot to the login page
3. User input user name password Submit Login application
4.sso Certification Center Verifies user information, creates a session between the user and the SSO Authentication Center, is called a global session, and creates an authorization token
5.sso Certification Center with token jump transfer initial request address (System 1)
6. System 1 Get token, go to SSO Authentication Center Verify token is valid
7.sso Certification Center Check token, return valid, registration system 1
8. System 1 uses this token to create a session with the user, called a local session, that returns a protected resource
9. User access to System 2 protected resources
10. System 2 found that the user is not logged in, jump to the SSO Certification Center, and its own address as a parameter
11.sso Certification Center found that the user has logged in, jumped back to the System 2 address, and attached a token
12. System 2 Get token, go to SSO Authentication Center Verify token is valid
13.sso Certification Center Check token, return valid, registration system 2

14. System 2 uses this token to create a local session with the user, returning the protected resource to a sudden

Log Off

Log off in one subsystem and all subsystems are logged off. As shown in the following illustration:

Specific procedures

1. User initiates cancellation request to System 1
2. System 1, according to the user and system 1 established session ID to get the token, to the SSO Certification Center to initiate a cancellation request
3.sso Certification Center Verify token is valid, destroy global session, and remove all system addresses registered with this token
4.sso Certification Center initiates logoff requests to all registration systems
5. Each registration system receives the SSO authentication Center the cancellation request, destroys the local session
6.sso Certification Center to guide users to the login page