Single Sign-On, unified authentication solution (3)

Based on our needs, there are generally two types of user experience:
1. Users who use multiple subsystems may directly log on to the unified authentication system and jump to multiple subsystems through the list of subsystem connections of the unified system; 2. For some scenarios where a single sub-system is used, or you enter the platform for a specific task, or the logon times out, the sub-system should be directly accessed, then we need to insert the login verification before it enters the subsystem. Shows the interaction process between three systems in two different ways:

Figure 1. General steps: log on to multiple subsystems at the same time

Figure 2. Go directly to the subsystem and jump between subsystems

I will explain the following in the first interaction mode:
1. the user first interacts with the unified logon system and logs on with a unique account and password. At this time, no subsystem is involved;
2. After the user successfully logs on, the unified logon System displays the list of trusted application subsystems to the user;
3. the user selects the subsystem to connect to the Access Subsystem as needed, and starts the interaction between the user and the subsystem;
4. Since the authentication relationship between the user and the sub-system has not yet been established, the sub-system redirects the user to the unified logon system;
5. log on to the system in a unified manner to verify the user's login information. If the user has logged on, the login information is inserted into the database and the authentication information is sent to the user. A waiting page is returned;
6. the user submits (automatically) The verification information on the page to the subsystem to obtain the authentication information;
7. The subsystem verifies the information through a certain method and waits for the verification information on the page, and establishes a trust relationship with the user;
The interaction process with the implementation solution project encapsulated by ASP. NET seems very annoying, and we still need to implement a lot of functions on our own. However, our interaction implementation process is controllable. I can limit and agree on the information content transmitted between systems and when it will be transmitted, in addition, we can register the interaction records between systems. This is what we need. To solve this problem, the added step is to automatically submit the login wait page. If both systems can run normally, the network will not be congested, the user waits for a short time, or even fails to see the page. In addition, we can beautify the waiting page so that users will not get bored even if they see the waiting page.

Having said so much, the sharing of sessions in the application subsystem of the unified authentication system has not yet begun, which is the biggest difficulty of this solution ......