Introduction of the CAS
CAS(Central Authentication Service) is an open source project initiated by Yale University to build Web SSO. What is SSO? SSO-Single Sign On is a Single Sign On that is a number of website procedures unified to a Web site for login authentication. The main features are: SSO applications use Web protocol (such as HTTPS), and there is only one login entry. When we talk about SSO, we mean Web SSO. In the SSO system, there are three roles: User Web application (multiple) SSO Certification Authority (one) All logins take place at the SSO Certification Authority. The SSO Authentication Authority has a number of ways to tell the Web application whether the current user is an authenticated user or not. The SSO Certification Authority establishes a trust relationship with all Web applications. So if you have access to a lot of different servers or websites on the same server all in one place and if you have access to the same browser then you can go to another website in that browser and that site doesn’t need to be logged in anymore
The structural system of CAS
CAS Server is responsible for authenticating user information and needs to be deployed separately. CAS Server handles Credentials such as user names/passwords. It’s a Web application that’s installed on the server side and it’s currently developed at Yale and other institutions, and it’s a replication of the authenticated server CAS Client and the CAS Client is deployed in the application, and when there’s a request for access to the protected resources of the local Web application, and you need to authenticate the requester, Redirect to CAS Server for authentication.
terms
TGT: An important ticket used to store the identity of the logged in user. Once the user has successfully logged in to the CAS server, the CAS server will generate a TGT and store it on the CAS server. Most importantly, make sure the TGT is a globally unique TGC: a Cookie that stores the TGT. Once logged in to CAS server, CAS will store it in the browser so that it is sent back to CAS server for login verification the next time it is logged in. Only through HTTPS transmission channel will TGC be sent back to CAS server. Granting Cookie Single sign-on TGT-Ticket Granting Ticket ST-Service Ticket Granting Cookie TGC-Ticket Granting Cookie storing user Granting credential
The principle diagram of the Cas
Access service:SSO clients send requests to access service resources provided by the application system.
Redirect authentication:The SSO client redirects user requests to the SSO server.
User authentication:User authentication.
Issue of bills:The SSO server generates a random Service Ticket.
Verify ticket:The SSO server validates the validity of the Service Ticket and allows the client to access the Service once the validation is passed.
Transfer user information:After the SSO server verifies the ticket passes, it transmits the user authentication result information to the client.
CAS principle analysis
When a logged-in user first accesses System B in the application group:
1) The browser needs to log in restricted resources to access another application B. At this time, it conducts login check and finds that it is not logged in. Then, it carries out ticket acquisition operation and finds that there is no ticket.
2), System B finds that the request needs to be logged in, redirects the request to the Certification Authority, obtains the global ticket operation, obtains the global ticket, can obtain, Certification Authority found that has logged in.
3) Certification authority issues temporary ticket (token) and carries the token redirect system B.
4) At this time, the login check is carried out again, and the ticket operation is obtained again. At this time, the ticket (token) can be obtained. System B communicates with the authentication center to verify the token is valid and prove that the user has logged in.
5) System B returns the constrained resource to the client.
