Single Sign On (SSO), referred to as SSO, is currently one of the more popular enterprise business integration solutions. The definition of SSO is that in multiple application systems, users only need to log in once to access all mutually trusted application systems. There are many subsystems in our current system, and these subsystems are deployed in different servers, so using the traditional session cannot solve it. We need to use related single sign-on technology to solve it.
CAS is a single sign-on framework, originally developed by an organization at Yale University, and later managed by apereo. At the same time, CAS is also open source, following the apache 2.0 protocol, and the code is currently managed on github. Single sign-on: Single Sign On, referred to as SSO, SSO enables users to log in once in multiple application systems to access all mutually trusted application systems. CAS is an open source project initiated by Yale University, which aims to provide a reliable single sign-on method for Web application systems. In December 2004, CAS officially became a project of JA-SIG.
CAS features the following: An open-source, enterprise-grade single sign-on solution. CAS Server is a web application that needs to be deployed independently. CAS Client supports a lot of clients (here refers to each Web application in the single sign-on system), including Java, .Net, PHP, Perl, Apache, uPortal, Ruby, etc.
CAS principle and protocol: From a structural point of view, CAS consists of two parts: CAS Server and CAS Client. CAS Server needs to be deployed independently, and is mainly responsible for user authentication; CAS Client is responsible for processing access requests to protected resources on the client side, and redirects to CAS Server when login is required. Figure 1 is the most basic protocol process of CAS:
CAS base protocol
The CAS Client is deployed together with the protected client application, and the protected resources are protected in the form of Filter. For each web request to access protected resources, CAS Client will analyze whether the Http request of the request contains Service Ticket, if not, it means that the current user has not logged in, so the request will be redirected to the specified CAS Server login address, And pass the Service (that is, the address of the destination resource to be accessed), so that the address will be returned after the login is successful. The user enters the authentication information in step 3. If the login is successful, the CAS Server randomly generates a fairly long, unique, and unforgeable Service Ticket, and caches it for future verification. After that, the system automatically redirects to the address of the Service, and provides the customer The terminal browser sets a Ticket Granted Cookie (TGC). After the CAS Client gets the Service and the newly generated Ticket, it will verify its identity with the CAS Server in steps 5 and 6 to ensure the legitimacy of the Service Ticket.
In this protocol, all interactions with CAS adopt SSL protocol to ensure the security of ST and TGC. There will be two redirection processes during the working process of the agreement, but the process of Ticket verification between CAS Client and CAS Server is transparent to users.
In addition, the Proxy (proxy) mode is also provided in the CAS protocol to adapt to more advanced and complex application scenarios. For details, please refer to the relevant documents on the official website of CAS.