SSO Single Sign-on solutions for Internet e-commerce applications (CAS-based transformation)

E-commerce platform in both front-end and back-end there will be a large number of business applications, throughout the process of the transaction request is in the various business applications, for the user only need to log in once to access all the business, this is the single sign-on SSO.

Single Sign-on open source has a number of solutions, such as session-based SSO and cookie-based SSO.

The industry uses more session-based SSO for open source solutions such as CAs, the process is as follows:

This is not a detailed description of the process, the reader can refer to other information

Cookie-based SSO is similar in principle to the above, except that the user is set up in a cookie as part of the token, and the cookie in session-based SSO is the TGT generated by the server to the client.

Relatively speaking, cookie-based security is not high.

The above is a single-machine environment of the scheme, more to meet the traditional enterprise-level solutions, and in the e-commerce platform, the performance of SSO, availability, the amount of cache data is a challenge, so the need to transform based on CAs to meet the requirements of the Internet.

A simple test for the performance of CAs:

Hardware and Software Environment: two apps, one CAs Server. The machines are all PC Server,16core 32G

Scenario: The user logs in an iteration, operates a business, and logs out operations

Test results:

Machine conditions for CAS server
Top-17:05:18 up 1 day, 8:39, 2 users, Load average:4.25, 2.62, 1.22

tasks:783 Total, 1 running, 782sleeping, 0 stopped, 0 zombie

Cpu (s): 69.4%us, 5.9%sy, 0.0%ni, 22.7%id, 0.0%wa, 0.0%hi, 2.0%si, 0.0%st

mem:65964644k Total, 16462164k used,49502480k free, 251036k buffers

swap:30719992k Total, 0k used, 30719992k free, 1240744k cached

Tps:2000,rt:20-30ms

The architecture of the modified SSO is as follows:

1, the transformation of CAS server to a stateless node, the previously cached ticket, users and other information into the cache on the backend

2, back-end cache using Redis, remove the persistent function, only for the cache

3, consider the relationship between data volume, cache using a distributed scheme, data segmentation, each sharding only a certain range of data

4, each sharding adopts the main way, leader as the primary node, replica only as backup, can be upgraded to primary node when the master node is down

5, the whole cluster adopts zookeeper for distributed cluster Management service.

6, APP Watch SSO node changes, using the polling RR algorithm to select an SSO server for the request, Ssoserver to ticket using the hash algorithm to locate the cache to the backend storage.

7, the user logged out of the platform, the use of the polling RR algorithm to select an SSO server to make requests, clear the cache of relevant information and HTTP method callback for each application's Logout service interface

8, the platform initialization stage needs to assign each sharding of the cache to an SSO server to do timed ticketexpire verification cleanup work, that is, a single SSO The server is responsible for the ticketexpire work of one or more sharding, which in turn callback the logout service interface of each application.

SSO Single Sign-on solutions for Internet e-commerce applications (CAS-based transformation)