1. An unconventional start
1. Background introduction
Single sign-on: Single Sign On, referred to as SSO, SSO enables users to access all mutually trusted application systems with only one login in multiple application systems.
CAS framework: CAS (Central Authentication Service) is a framework for implementing SSO single sign-on.
2. Steal a picture that most people have seen in learning CAS and perform part of the analysis
Note: The originality has not been distinguished, so the address will not be given here.
Structurally, CAS consists of two parts: CAS Server and CAS Client need to be deployed independently and are mainly responsible for user authentication; CAS
Client is responsible for processing access requests to the client's protected resources, and redirects to CAS when login is required Server. Figure 1 is the most basic protocol process of CAS:The CAS Client is deployed with the protected client application to protect the protected resources of the Web application in the Filter mode, and filter each Web
request from the client. At the same time, the CAS Client will analyze whether the HTTP request contains the request Service Ticket ( Ticket) in the above figure
, if not, it means that the user is not authenticated, so the CAS Client will redirect the user request to the CAS Server ( Step 2 ). Step
3 is the user authentication process. If the user provides the correct Credentials, the CAS Server will generate a random Service Ticket
, then cache the Ticket and redirect the user to the CAS Client (with the Service Ticket just generated). The Service
Ticket is It cannot be forged. Finally, Step 5 and Step 6
are the completion of a user identity verification between the CAS Client and the CAS Server, and the Username is found with the Ticket, because the Ticket is
generated by the CAS Server, so the judgment of the CAS Server is No doubt about it.This protocol completes a very simple task, and all interactions with CAS use the SSL protocol to ensure the security of ST and TGC. There are two redirection processes in the working process of the protocol, but
the process of ticket authentication between the CAS Client and the CAS Server is transparent to the user.To summarize, as follows:
Access service: The SSO client sends a request to access the service resources provided by the application system.
Directed Authentication: The SSO client will redirect user requests to the SSO server.
User Authentication: User authentication.
Issue ticket: The SSO server will generate a random Service Ticket.
Verification ticket: The SSO server verifies the validity of the Service Ticket, and after the verification is passed, the client is allowed to access the service.
Transmission of user information: After the SSO server passes the verification ticket, it transmits the user authentication result information to the client.
2. Further search and exploration in the cloud and fog
The source of this part is given first: "SSO CAS Single Point Series" implements an SSO authentication server like this, and the red part below is your own question.
1. Login information transmission
When a user logs in for the first time, the process is as follows:
1) The user's browser needs to log in to the restricted resources to access the system A. At this time, the login check is performed, and it is found that the login is not logged in. Then, the operation to obtain the ticket is performed, and it is found that there is no ticket.
2) System A finds that the request needs to be logged in, redirects the request to the authentication center, and obtains the global ticket operation, if not , log in.
3) The authentication center presents the login page, and the user logs in. After the login is successful, the authentication center redirects the request to system A and attaches the authentication pass token. At this time, the authentication center generates a global ticket at the same time.
4) At this time, the login check is performed again, and it is found that the user is not logged in, and then the ticket operation is obtained again. At this time, the ticket (token) can be obtained. The system A communicates with the authentication center to verify that the token is valid, which proves that the user has logged in.
5) System A returns the restricted resource to the user.
When a logged-in user accesses system B in the application group for the first time:
1) The browser needs to log in to the restricted resource to access another application B. At this time, the login check is performed, and it is found that it is not logged in, and then the operation of obtaining the ticket is performed, and it is found that there is no ticket.
2), System B finds that the request needs to be logged in, redirects the request to the authentication center, obtains the global ticket operation, and obtains the global ticket, which can be obtained, and the authentication center finds that it has logged in.
3) The authentication center issues a temporary ticket (token), and redirects to system B with the token.
4) At this time, the login check is performed again, and it is found that the user is not logged in, and then the ticket operation is obtained again. At this time, the ticket (token) can be obtained. The system B communicates with the authentication center to verify that the token is valid, which proves that the user has logged in.
5) System B returns the restricted resource to the client.
2. Judgment of login status
用户到认证中心登录后，用户和认证中心之间建立起了会话，我们把这个会话称为全局会话。当用户后续访问系统应用时，我们不可能每次应用请求都到认证中心去判定是否登录，这样效率非常低下，这也是单Web应用不需要考虑的。
我们可以在系统应用和用户浏览器之间建立起局部会话，局部会话保持了客户端与该系统应用的登录状态，局部会话依附于全局会话存在，全局会话消失，局部会话必须消失。
用户访问应用时，首先判断局部会话是否存在，如存在，即认为是登录状态，无需再到认证中心去判断。如不存在，就重定向到认证中心判断全局会话是否存在，如存在，按1提到的方式通知该应用，该应用与客户端就建立起它们之间局部会话，下次请求该应用，就不去认证中心验证了。
3、登出
用户在一个系统登出了，访问其它子系统，也应该是登出状态。要想做到这一点，应用除结束本地局部会话外，还应该通知认证中心该用户登出。
认证中心接到登出通知，即可结束全局会话，同时需要通知所有已建立局部会话的子系统，将它们的局部会话销毁。这样，用户访问其它应用时，都显示已登出状态。
整个登出流程如下：
1)、客户端向应用A发送登出Logout请求。
2)、应用A取消本地会话，同时通知认证中心，用户已登出。
3)、应用A返回客户端登出请求。
4)、认证中心通知所有用户登录访问的应用，用户已登出。
三、拨开云雾见青天
1、对上面所有标红疑问一一解释
1)、问：系统A是如何发现该请求需要登录重定向到认证中心的？
答：用户通过浏览器地址栏访问系统A，系统A(也可以称为CAS客户端)去Cookie中拿JSESSION，即在Cookie中维护的当前回话session的id，如果拿到了，说明用户已经登录，如果未拿到，说明用户未登录。
2)、问：系统A重定向到认证中心，发送了什么信息或者地址变成了什么？
答：假如系统A的地址为http://a:8080/，CAS认证中心的服务地址为http://cas.server:8080/，那么重点向前后地址变化为：http://a:8080/————>ttp://cas.server:8080/?service=http://a:8080/，由此可知，重点向到认证中心，认证中心拿到了当前访问客户端的地址。
3)、问：登录成功后，认证中心重定向请求到系统A，认证通过令牌是如何附加发送给系统A的？
答：重定向之后的地址栏变成：http://a:8080/?ticket=ST-XXXX-XXX，将票据以ticket为参数名的方式通过地址栏发送给系统A
4)、问：系统A验证令牌，怎样操作证明用户登录的？
答：系统A通过地址栏获取ticket的参数值ST票据，然后从后台将ST发送给CAS server认证中心验证，验证ST有效后，CAS server返回当前用户登录的相关信息，系统A接收到返回的用户信息，并为该用户创建session会话，会话id由cookie维护，来证明其已登录。
5), Q: When logging in to system B, how does the authentication center judge that the user has logged in?
Answer: After the successful login of system A, a global session is established between the user and the authentication center. This global session is the TGT (Ticket Granting Ticket). The TGT is located on the CAS server side, and the TGT is not placed in the Session. That is to say, The implementation of the CAS global session does not directly use the Session mechanism, but uses the Cookie to implement itself. This Cookie is called TGC (Ticket Granting Cookie), which stores the id of the TGT and saves it on the user's browser.
Related content analysis can be viewed: "SSO CAS Single Point Series" practical operation! It's that simple to play SSO CAS easily (acquaintance)
When a user sends a request to log in to system B, he will first go to the cookie to get JSESSION, because system B has not logged in, the session session has not been created, and the value of JSESSION cannot be obtained, and then the request is redirected to the CAS authentication center, CAS The authentication center first goes to the user's browser to get the value of the TGC, that is, the global session id. If it exists, it means that the user has logged in in the authentication center, and is redirected to system B with the authentication token attached.
The above login status judgment is also the same logic.
6) Q: What did each system do to the current user during the logout process?
Answer: The authentication center clears the global session TGT of the current user, and at the same time clears the id of the TGT in the cookie: TGC;
then each client system, such as system A and system B, clears the local session session and clears the session session id in the cookie. :jsession
2. Add a note to the system A login flow chart to view
Never mind, I get it anyway.