Atitit. Summary of Single Sign-On SSO Solutions

Atitit. Summary of Single Sign-On SSO Solutions

 

1. system application scenarios and SSO mode selection 2

2. system application principles and requirements 2

2.1. fast and simple development: For most systems, development is fast and simple.

2.2. Token exchange is supported, which facilitates integration of the first system module without major changes. You only need to change the login module .. 2

2.3. User Name ing is supported. If multiple subsystems have different usernames, 2

3. Verify SSO offline (decentralized authentication, similar to passport identification) 2

3.1. Applicable scenarios: high-performance scenarios, supporting unilateral transformation 3

3.2. disadvantage: You need to know more about the token format of each subsystem .. 3

4. distributed online Authentication + token Exchange 3

4.1. Principle: 3

4.2. Applicable scenarios: Most scenarios... two-way transformation required 3

4.3. Main process 3

4.3.1. --- system a establishes a Token Test API (the web system usually involves sessions, cookies, and so on), that is, the test is used to log on to login. copy the JSP code and modify it a little... for example, create a loginvalidapi. JSP 4

4.3.2. Access a module in system B 4

4.3.3. B checks whether to log on to the system, such as logon and normal access ....... If you have not logged on, the system B will jump to login without modification. PHP .. let's modify this jump to logstores first. PHP (this page needs to be created) 4

4.3.4. In logstores. php, forward the token to a for verification (using Redirect forwarding )...

4.3.5. -- check whether loginvalidapi. jsp of A is logged on to the system. For example, return usera information to the logstores. PHP page of B .. If you do not log on, logstores. php is returned (of course, the user information is blank in this case ).. 4

4.3.6. B system logtail. php checks user information. If there is no user information, it means that a system has not logged on .. 4

4.3.7. If multiple other systems, such as C and De, access API 4 in sequence.

4.3.8. If none of them are logged on, switch to login. php to enter normal logon... If any user information is returned, it indicates that the user has logged on to system .. in this case, if the usernames of the same user in system A and system B are different, username ing is required. usera> userb ...... 5

4.3.9. query userb information and generate the token of system B (this code can be copied from the logon code of system B and slightly modified) .. 5

4.3.10. Jump to the module of B and access it as a logon status. 5

4.3.11. For the process of accessing system module A, refer to this to add logstores. jsp and. Loginvalidapi. php. 5

4.4. Token exchange 5

4.5. Username ing 5

5. CAS open-source Single Sign-On SSO component (unified authentication center) 5

5.1. CAS principle: all application systems share an Identity Authentication System. 5

5.2. Applicable scenarios: New Development subsystem 6

5.3. Disadvantages: if an existing subsystem is introduced and the Development workload is greatly improved (three-party modifications), the regression test would be large, even if the CAS framework is used. 6

6. Refer to 6

 

 

1. system application scenarios and SSO mode selection

If multiple existing systems are used for SSO, use the "distributed online Authentication Mode", with the least development test

Existing multi-system, requiring high performance, using the "decentralized authentication offline verification SSO" Mode

The newly developed system can use CAS and other unified authentication center methods...

 

2. 2.1 system application principles and requirements. rapid and simple development: For most systems, development is fast and simple, mainly 2.2. token exchange is supported, which helps to integrate the first system module without major changes. You only need to change the login module .. 2.3. User Name ing is supported. When multiple subsystems have different usernames

 

Author: old wow's paw attilax iron, email: [email protected]

Reprinted please indicate Source: http://blog.csdn.net/attilax

 

3. Verify SSO offline (decentralized authentication, similar to passport recognition)

Use a realistic example for comparison. There are many independent sites inside the famous tourist attractions, such as "Suzhou Street", "foxiang ge", and "Deli". You can buy tickets separately at the entrance of each scenic spot. Many tourists need to visit all German attractions. This method of buying tickets is inconvenient. They need to queue up at the door of each attraction to buy tickets. The wallet is easy to lose and unsafe. Therefore, the vast majority of tourists choose to buy a pass (also called a pass) at the gate, they can play all the scenic spots without buying a new ticket. They only need to show the pass set they just bought at the entrance of each scenic spot to be allowed to access each independent scenic spot.

3.1. Applicable scenarios: high-performance scenarios, supporting unilateral Transformation

Another advantage is that it can be implemented by a single subsystem without having to change both sides of the system .. It is particularly suitable for situations where only one party's system can be modified...

3.2. disadvantage: You need to know more about the token format of each subsystem .. 4. distributed online Authentication + token exchange 4.1. Principles ::

For example, the bank verifies the ID card, in addition to verifying the physical anti-counterfeiting of the ID card itself .. You also need to connect to the (identity authentication organization) remote identity authentication interface to verify the identity information.

 

 

4.2. Applicable scenarios: Most scenarios... two-way transformation required 4.3. Main processes

For example, system A (Java System) is integrated with system B (PhP Forum). Today, a module of system B is used.

 

4.3.1. --- system a establishes a Token Test API (the web system usually involves sessions, cookies, and so on), that is, the test is used to log on to login. copy the JSP code and modify it a little... for example, create a loginvalidapi. jsp4.3.2. access a module in system B 4.3.3. B will check whether the system is logged on, such as login, normal access ....... If you have not logged on, the system B will jump to login without modification. PHP .. let's modify this jump to logstores first. PHP (this page needs to be created) 4.3.4. in logstores. in PHP, forward the token to a for verification (forward using Redirect )... jump to loginvalidapi. jsp4.3.5. -- loginvalidapi of. JSP checks whether to log on to the system. For example, if you log on, return usera information to B's logstores. PHP page .. If you do not log on, logstores. php is returned (of course, the user information is blank in this case ).. 4.3.6. B system logtail. php checks user information. If there is no user information, it means that a system has not logged on .. 4.3.7. If multiple other systems, such as C and De, access their API interfaces in sequence.

 

4.3.8. If none of them are logged on, switch to login. php to enter normal logon... If any user information is returned, it indicates that the user has logged on to system .. in this case, if the usernames of the same user in system A and system B are different, username ing is required. usera> userb ...... 4.3.9. query userb information and generate the token of system B (this code can be copied from the logon code of system B and slightly modified ).. 4.3.10. jump to the module of B and access it as a logon status. 4.3.11. you can refer to the process for accessing system module A to add logstores. JSP and. Loginvalidapi. php. 4.4. Token exchange 4.5. User Name ing

 

 

5. CAS open-source Single Sign-On SSO component (unified authentication center) 5.1. CAS principle: all application systems share an Identity Authentication System.

CAS open-source Single Sign-On SSO component, which has two deployment nodes: SSO server (the deployment content is a Web application) and Application System Client (the deployment content is CAS client CasClient. jar package and related configuration files ). Therefore, based on the SSO mechanism, we can analyze when timeout occurs. After multiple application systems are integrated with SSO, the session of the application system client (the following uses the browser client as an example) will save the authenticated user context in the SSO Single Sign-on process, the SSO server generates and caches a user credential (TGT), and the browser client saves TGC (TGT stored in the browser cookie ), TGT is a credential for issuing the SSO Access Service (ST). It can be accessed normally only after the st ticket is issued.

 

The CAS open-source Single Sign-On SSO component provides this mechanism. I have studied the CAS source code and basically understood the JSESSIONID processing mechanism. The general principle is as follows: when a user accesses the business system, the SSO client intercepts and redirects to the SSO server for authentication, the Request Path URI is written into "; JSESSIONID = specific session value ", the SSO server can identify this identity value for authentication, which is different from other client requests. The returned response to the client cookie also sets the JSESSIONID value, JSESSIONID is set in Uri and cookie for dual protection. After a single sign-on succeeds, the return business system access address also carries the JSESSIONID parameter, which looks awkward in the URI address.

 

5.2. applicable scenarios: New Development subsystem 5.3. disadvantages: If it is introduced in an existing subsystem, the development workload will be greatly modified (modified by three Parties), and the regression testing will be large .. the CAS framework is used.

 

6. Reference

SSO-cas single-point logon instance demonstration _ micmiu-software development environment life point drop .htm

Several problems encountered during SSO implementation-yan_dk column-blog channel-csdn.net.htm

 

SSO Single Sign-On solution [reprinted]-walk on the path of architect Jack. Wang's home-blogjava.htm

(Offline verification) implementation principle of Single Sign-On SSO-the path to architects-blog channel-csdn.net.htm

atitit. Summary of SSO solutions