CAS principles and protocols

SSO stands for Single Sign On. SSO is used in multiple application systems. Users only need to log on once to access all mutually trusted application systems.

There are many SSO solutions, such as UTrust, HP Smart, and open-source CAS and Smart SSO, among which CAS is the most widely used.

CAS (Central Authentication Service) Central Authentication Service. CAS (Central Authentication Service) is a good single sign-on Framework for Web applications.

CAS has the following features:
Open-source enterprise-level Single Sign-On solution.
CAS Server is a Web application that needs to be deployed independently.
CAS Client supports many clients, including Java,. Net, PHP, Perl, Apache, uPortal, and Ruby.

CAS principles and protocols

Structure: CAS contains two parts

1. CAS Server

CAS Server is responsible for user authentication. CAS Server needs to be deployed independently. There are more than one implementation of CAS Server.

CAS Server processes Credentials such as user name/password, which may retrieve a user account information from the database or the user password in an XML file. In this way, CAS provides a flexible but the same method of Interface/implementation separation. What authentication method does CAS use? It is separated from the CAS protocol, that is, you can customize and expand the implementation details of this authentication.

2. CAS Client

CAS Client is deployed on the Client (Web Application). In principle, the deployment of CAS Client means that when there are access requests to the protected resources of the local Web application, the Web application no longer accepts Credentials such as usernames and passwords, but redirects to the CAS Server for authentication.

Currently, CAS Client supports a large number of clients, including Java ,.. Net, ISAPI, Php, Perl, uPortal, Acegi, Ruby, VBScript, and other clients. The CAS protocol can be used for client applications written in any language.

Protocol:
The basic idea of the entire agreement is based on the bill method. Next, let's look at the basic Protocol framework of CAS:

CAS Client and protected Client applications are deployed together to protect protected resources in Filter mode. For each Web request that accesses protected resources, the CAS Client analyzes whether the Http request contains Service Ticket. If not, the current user has not logged on, therefore, the request is redirected to the specified CAS Server logon address, and the Service (that is, the destination resource address to be accessed) is passed so that the address can be returned after successful logon. The user enters the authentication information in step 1. If the login succeeds, the CAS Server randomly generates a fairly long, unique, and unfalsified Service Ticket, and caches it for future verification, then the system automatically redirects to the Service address and sets a Ticket Granted Cookie (TGC) for the Client browser. After the CAS Client obtains the Service and the newly generated Ticket, in step 5 and 6, perform proper identity with the CAS Server to ensure the validity of the Service Ticket.

In this Protocol, all interactions with CAS adopt the SSL protocol to ensure the security of ST and TGC. There will be two redirection processes during the Protocol work, but the process of Ticket verification between CAS Client and CAS Server is transparent to users.

In addition, the CAS Protocol also provides the Proxy mode to adapt to more advanced and complex application scenarios.