CAS-authentication principle, cas Authentication

CAS-authentication principle, cas Authentication

CAS, Central Authentication Service-Central certification Service is an enterprise-level open-source project initiated by Yale University. It aims to provide a reliable SSO solution for Web application systems. The following is a brief introduction to SSO, focusing on the CAS authentication process.

1. SSO Introduction 1.1 concepts

SSO, short for Single Sign On, is one of the most popular solutions for enterprise business integration. SSO enables, you only need to log on once to access all mutually trusted application systems.

1.2 roles

Generally, the SSO system has three main roles:

* User (multiple)

* Web applications (multiple)

* SSO authentication center (one)

1.3 principles

The SSO implementation mode generally includes the following three principles:

* All authentication logins are performed in the SSO authentication center;

* The SSO authentication center uses some methods to tell the Web application whether the current user has been authenticated or not;

* The SSO authentication center establishes a trust relationship with all Web applications. That is to say, web applications must trust the authentication center. (Single point of Trust)

II. Introduction to CAS principles
2.1 Architecture

From the perspective of the structure system, CAS includes two parts: CAS Server and CAS Client.

CAS ServerTo authenticate users, two important tickets will be issued: the logon ticket (TGT) and the service ticket (ST). CAS Server must be deployed independently.

CAS ClientIt is responsible for processing access requests to protected resources on the client. It is redirected to the CAS Server for authentication when identity authentication is required for the requester. Accurately speaking, it protects Protected Resources in the Filter mode. For each Web request that accesses protected resources, the CAS Client analyzes whether the Http request contains ServiceTicket (service ticket, which is issued by the CAS Server to identify the target service ). CAS Client and protected Client applications are deployed together.

As shown above, it complies with the role architecture in SSO, as shown below:

* User (multiple)

* Web applications (multipleCAS Client-deployed together with Web Applications)

* SSO authentication center (oneCAS Server-independent deployment)

2.2 core ticket

The core of CAS is its Ticket and a series of processing operations on the Ticket. CAS's main tickets include TGT, ST, PGT, PGTIOU, and pt. Among them, TGT and ST are the tickets in CAS1.0 (Basic Mode) protocol, PGT, PGTIOU, and PT are all tickets in CAS2.0 (proxy mode) protocol. Here we mainly introduce several bills in the basic mode of CAS1.0.

TGT (Ticket Grangting Ticket)

TGT is a logon ticket issued by CAS. With TGT, you can prove that you have successfully logged on to CAS. TGT encapsulates the Cookie value and the user information corresponding to this Cookie value. After CAS authentication is successful, the user generates a TGT object and puts it into his own cache (Session). Meanwhile, CAS generates a cookie (called TGC, which is actually the SessionId of TGT ), write to the browser. The ID of the TGT object is the cookie value. When an HTTP request arrives again, if CAS generates a cookie, CAS uses this cookie value (SessionId) query whether TGT (Session) exists in the cache for the key. If yes, it indicates that the user has logged on. If no, the user needs to log on again.

TGC (Ticket-granting cookie)

As mentioned above, CAS-Server generates TGT and puts it into its own Session, while TGC is the unique identifier of this Session (SessionId) and put it in the browser as a Cookie, is the credential used by CAS Server to identify the user. (If you understand the Session storage principle, you can understand it well)

ST (ServiceTicket)

ST is a service bill issued by CAS for users to access. When a user accesses the service and finds that the user does not have a ST, the user must go to CAS to obtain the ST. The user sends a request to CAS to obtain the ST. If the request contains a cookie, CAS queries the cache for TGT Based on the cookie value as the key. If TGT exists, use this TGT to issue a ST and return it to the user. The user uses the ST to access the service, and the service uses the ST to perform CAS verification. After the verification is passed, the user is allowed to access the resource.

To ensure the security of ST, ST is generated randomly and has no regularity. Moreover, CAS specifies that ST can only survive for a certain period of time, and CAS Server will invalidate it. Moreover, the CAS Protocol stipulates that the ST can only be used once. No matter whether the Service Ticket verification is successful or not, CASServer will clear the Ticket in the server cache, so that a Service Ticket is not used twice.

2.3 authentication process

Here, a terminal is used to describe the CAS authentication process by sending three requests to two CAS-clients, including TGT, TGC, ST, and how to implement SSO.

For example, the first two requests are access to the CAS-Client1, mainly to describe the role of TGT, TGC, ST and other tickets; then the third request to access the CAS-Client2, it mainly describes how to implement SSO.

Request1

[Step 1] the first time the terminal accesses the CAS-Client1, AuthenticationFilter will intercept this request:1,First, check that the local Session does not cache user information;2,Then, no ST is detected in the request information;3,Therefore, the CAS-Client1 redirects the request to the CAS-Server and passes the Service (that is, the destination resource address to be accessed so that the address is transferred back after successful login), for example: [https: // cas: 8443/cas/login? Service = http0 % 3A8081% 2F]

[Step 2] the first time the terminal accesses CAS-Server:1,CAS-Server detects that the request information does not contain TGC, so it jumps to its logon page;2,Enter the user name and password of the terminal to log on to the CAS-Server. After the authentication is successful, the CAS-Server generates the logon ticket-TGT (integrating the user information with the ST), andRandomGenerate a service ticket-ST and CAS session ID-TGC. TGT is actually a Session, and TGC is the SessionID that identifies the Session stored in the Cookie; ST is to generate Ticket according to the Service.3,Then, CAS-Server adds Ticket to the url and then returns the request redirect back to the customer's web application. For example, the URL is [http: // 192.168.1.90: 8081/web1 /? Ticket = ST-5-Sx6eyvj7cPPCfn0pMZ]

[Step 3] at this time, the terminal carries ticket again request CAS-Client1: 1, then the client's AuthenticationFilter to see the ticket parameter, will skip, The TicketValidationFilter processing; 2. The TicketValidationFilter uses the httpclient tool to access the/serviceValidate interface of the cas service and transmits both ticket and service to this interface. This interface verifies the validity of ticket, verify the validity of ST to CAS-Server. 3. If the message of TicketValidationFilter is successfully verified, the user information will be written into the session of the web application. So far, the SSO session is established.

Request2

The above mentioned SSO session has been established, then the user in the same browser for the second visit this web application (CAS-Client1), AuthenticationFilter will read the user information in the session, this means that the user has successfully logged on, so he will not go to CAS for authentication.

Request3

[Step 1] and Request1 is exactly the same, as follows: the first time the terminal accesses the CAS-Client2, AuthenticationFilter will intercept this request:1,First, check that the local Session does not cache user information;2,Then, no ST is detected in the request information;3,Therefore, the CAS-Client1 redirects the request to the CAS-Server and passes the Service (that is, the destination resource address to be accessed so that the address is transferred back after successful login), for example: [https: // cas: 8443/cas/login? Service = http0 % 3A8081% 2F]

[Step 2] Then, the terminal accesses CAS-Server for the second time: At this time, the Request will contain the TGC generated last time, and then according to the TGC (SessionID) check whether the corresponding TGT (Session) exists. If yes, it indicates that the user has successfully logged on. Therefore, the user does not have to log on to the logon page (SSO ), the CAS-Server will issue a ST directly with the found TGT, and then redirect to the CAS-Client2, the rest of the [Step 3] In Request1 is exactly the same.

Iii. Summary

The core concept of CAS authentication is several [tickets], which are actually one Cookie and N sessions. Including TGT, ST, and TGC of CAS1.0 (basic mode), and PGT, PT, and PGTIOU of CAS2.0 (proxy mode. The authentication process is the process of transferring and comparing and verifying these tickets.