1. Introduction of CAS

1.1. What is CAS?

Central Authentication Service (CAS) is an enterprise-level and open source project initiated by Yale University. It aims to provide a reliable single sign-on (SSO) solution for Web application systems.

CAS began in 2001 and officially became a project of JA-SIG in December 2004.

1.2. Main features

1. Open source, multi-protocol SSO solution; Protocols: Custom Protocol, CAS, OAuth, OpenID, RESTful API, SAML1.1, SAML2.0, etc.

2, support a variety of authentication mechanisms: Active Directory, JAAS, JDBC, LDAP, X.509 Certificates, etc.

3. Security policy: Use Ticket to implement the supported authentication protocol;

4, support authorization: can decide which services can request and verify Service tickets;

5. High availability: By storing authenticated status data in TicketRegistry components, many of these components support distributed implementations such as: BerkleyDB, Default, EhcacheTicketRegistry, JDBCTicketRegistry, JBOSS, JpaTicketRegistry, MemcacheTicketRegistry, etc.

6, support a variety of clients: Java,.NET, PHP, Perl, Apache, uPortal and so on.

2. SSO SSO principle

This article focuses on Web SSO.

2.1. What is SSO

Single sign-on (SSO) is one of the more popular solutions for enterprise business integration. SSO allows users to log in once to access all trusted applications (one access, running everywhere) in multiple applications.

2.2. SSO principle

2.2.1. Roles in SSO System

There are three main roles in the GENERAL SSO system:

1. User (multiple)

2. Web Applications (multiple)

3. SSO Certification Center (1)

2.2.2. Principles of SSO implementation pattern

The SSO implementation pattern generally includes the following three principles:

1. All authentication logins are performed at the SSO authentication center;

2. SSO authentication center uses some methods to tell the Web application whether the current access user is an authenticated user;

3. The SSO authentication authority establishes a trust relationship with all Web applications, that is, Web applications must trust the authentication Authority. (Single point of trust)

2.2.3. Main implementation methods of SSO

The main implementations of SSO are:

  • 1. Share cookies

Cookie based on shared domain is a method used at the beginning of the Web. It makes use of the automatic transfer of cookies between browsing and domain names to realize the problem of token transfer between two domain names. Also, regarding cross-domain issues, cookies can be used for cross-domain SSO, although they themselves are not cross-domain. Such as proxy, exposing SSO token value, etc.

Cons: inflexible and full of security risks, abandoned.

  • 2. Broker-based

This technology features a centralized authentication and user account management server. The broker gives electronic identity access to be used for further requests. The use of a central database reduces the cost of administration and provides a public and independent “third party” for certification. Examples include Kerberos, Sesame, IBM KryptoKnight (credential library idea), etc. Kerberos is a security authentication service invented by MIT. It has been integrated into the operating system by UNIX and Windows as the default security authentication service.

  • 3. Agent-based (Agent based)

In this solution, there is an agent that automatically authenticates users for different applications. The agent needs to be designed to have different functions. For example, it can use a password table or encryption key to automatically take the burden of authentication away from the user. The agent is placed on the server and acts as a “translator” between the server’s authentication system and the client’s authentication methods. For example, SSH.

  • 4, the Token – -based

For example, SecureID and WebID are widely used password authentication, such as FTP and email server login authentication. This is an easy to use way to implement a password for multiple applications.

  • 5. Gateway based

  • 6. Based on SAML

The emergence of SAML(Security Assertion Markup Language) greatly simplifies SSO and has been approved by OASIS as the implementation standard for SSO. The open source organization OpenSAML implements the SAML specification.

3. Basic principles of CAS

3.1. Structural system

The CAS consists of two parts: the CAS Server and the CAS Client.

3.1.1. The CAS Server

The CAS Server authenticates users and must be deployed independently. The CAS Server processes the Credentials such as user names and passwords.

3.1.2. CAS Client

The CAS Server processes the access requests to the protected resources on the client and redirects the requests to the CAS Server for authentication. In principle, client applications do not accept any Credentials, such as user names and passwords.

The CAS Client and protected Client applications are deployed together to protect protected resources in Filter mode.

3.2 CAS principle and protocol

3.2.1. Basic mode

The basic SSO access process consists of the following steps:

Access services: The SSO client sends requests to access service resources provided by the application system.

Directed authentication: The SSO client redirects user requests to the SSO server.

User authentication: User identity authentication.

Ticket issuance: The SSO server generates a random Service Ticket.

Ticket verification: The SSO server verifies the validity of the Ticket Service Ticket and allows clients to access the Service.

Transferring user information: After the SSO server authenticates the ticket, the SSO server transmits the user authentication result to the client.

The following is the basic CAS protocol process:

As shown above: The CAS Client is deployed with the protected Client application to protect the protected resources of the Web application in Filter mode and Filter every Web request from the Client. The CAS Client analyzes whether the HTTP request contains a Service Ticket(ST shown in the preceding figure). If the request does not contain a Ticket, the user is not authenticated. The CAS Client then redirects the user request to the CAS Server (Step 2) and passes the Service (address of the destination resource to be accessed). Step 3 is the user authentication process. If the users provide the correct Credentials, the CAS Server randomly generates a Service Ticket of considerable length, unique, and unforgeable, and caches the Ticket for future verification. Redirect the user to the address of the Service (with the generated Service Ticket), and set a Ticket Granted Cookie (TGC) for the client browser. After obtaining the Service and the new Ticket, the CAS Client checks its identity with the CAS Server in Step 5 and Step6 to ensure the validity of the Service Ticket.

In this protocol, SSL is used for all interactions with the CAS Server to ensure the security of the ST and TGC. There will be two redirection processes during the protocol work. However, Ticket authentication between the CAS Client and CAS Server is transparent to users (using HttpsURLConnection).

The sequence diagram of CAS authentication request is as follows:

3.2.1. How does CAS implement SSO

When a user accessing another application’s service is redirected to the CAS Server, the CAS Server automatically obtains the TGC cookie and then does the following:

If the User holds a TGC and it is not invalidated, then Step4 of the basic protocol diagram is used to achieve SSO effect.

If the TGC fails, then the user must re-authenticate (go to Step3 of the basic protocol diagram).

3.2.2. CAS agent mode

This mode takes the form of User accessing App1, which in turn relies on App2 to obtain some information, such as User –>App1 –>App2.

In this case, assuming that App2 also needs to authenticate User to access, CAS introduced a Proxy authentication mechanism in order not to affect the User experience (excessive redirection causes User’s IE window to constantly flash). That is, the CAS Client can access other Web applications on behalf of users.

The CAS Client must have the user’s identity information (similar to credentials). The TGC mentioned before is a credential for the user’s identity information. PGT here is a credential for the USER’s identity information held by the CAS Client. By virtue of TGC, a User can obtain a Service Ticket to access other services without entering a password. Therefore, by virtue of PGT, Web applications can proxy users to achieve back-end authentication without the involvement of front-end users.

Here is how the Proxy application (helloService) obtains PGT: (Note: PGTURL is used to represent a Proxy service, which is a callback link; PGT is equivalent to agency certificate; PGTIOU is the key to obtain the agency certificate, which is used to associate with PGT;)

CAS Client gets PGT(PGTIou-85… . Ti2td), you can use PGT to authenticate back-end Web applications.

The following is the process of proxy authentication and service provision:

3.2.3. Supplementary instructions

The SSO implementation of CAS can be simplified as: 1 Cookie and N sessions. The CAS Server creates cookies for authentication of all applications. Each application creates its own Session to identify whether a user has logged in.

After a user passes the authentication of an application, when the user accesses the application in the same browser, the filter in the client application will read the user information in the session, so the user will not go to the CAS Server for authentication. If the filter of the client application fails to read the user information during the session when you access other Web applications from this browser, the CAS Server goes to the LOGIN interface for authentication. However, the CAS Server reads the cookie (TGC) sent by the browser. Therefore, the CAS Server does not require the user to log in to the login page. Instead, the CAS Server generates a Ticket based on the service parameter and interacts with the Web application to authenticate the Ticket.

3.3. Explanation of terminology

Five bills are designed in CAS system: TGC, ST, PGT, PGTIOU and PT.

Ticket-granting cookie(TGC) : a cookie storing a user’s identity certificate, which is used in communication between a browser and the CAS Server. The cookie must be transmitted over a secure channel (Https) and used by the CAS Server to confirm a user’s identity.

Service ticket(ST) : a Service ticket, which is a unique Service ID. It is sent by the CAS Server (through Http) and sent to the Service Server through the client browser. A particular service can have only one unique ST;

Proxy-granting ticket (PGT) : a proxy-granting ticket (PGT) granted by the CAS Server to a service that possesses an ST certificate. The PGT is bound to a specific service of a user, enabling the user to apply for a PT from the CAS Server.

Proxy-granting Ticket I Owe You (PGTIOU) : The CAS Server returns the reply information during certificate verification to the CAS Client, and the PGT corresponding to the PGTIOU is sent to the Web application through the callback link. Web applications maintain the content table of the mapping between PGTIOU and PGT.

Proxy Ticket (PT) : a credential used by an application to access the target program as a Proxy user.

Other instructions are as follows:

Ticket Granting Ticket (TGT) : A Ticket granted by the AS of the KDC. After obtaining such a ticket, you do not need to submit the Credentials to KDC when applying for other service tickets.

Authentication Service (AS) ——— Authentication service, obtaining Credentials, and issuing TGTS.

Ticket-granting Service (TGS) ——— Granting a Ticket, granting a TGT, and granting an ST.

Key Distribution Center (KDC) ———- Key Distribution Center;

4. CAS security

The security of CAS only depends on SSL. Secure cookies are used.

4.1. TGC/PGT security

The most important thing for a CAS user to do is to protect its TGC. If a TGC is accidentally acquired by an entity other than the CAS Server, the Hacker can find that TGC and impersonate it as a CAS user to access all authorized resources. The role of PGT is the same as that of TGC.

Based on the basic mode, a TGC is sent by the CAS Server to the end user over SSL. Therefore, it is difficult to intercept a TGC to ensure the SECURITY of the CAS.

The default lifetime of a TGT is 120 minutes.

4.2. ST/PT security

The Service Ticket (ST) is transmitted through Http. Therefore, other people on the network can Sniffer to other people’s tickets. CAS makes ST more secure (and actually configurable) in the following ways:

1. ST can only be used once

According to the CAS protocol, the CAS Server clears the Ticket from the Server cache regardless of whether the Service Ticket authentication succeeds. This ensures that a Service Ticket cannot be used twice.

2. ST fails for a period of time

CAS specifies that the ST can only survive for a certain amount of time before the CAS Server invalidates it. The default validity period is 5 minutes.

3. ST is generated based on random numbers

ST must be random enough that if the ST generation rule is guessed, Hacker will bypass CAS authentication and access the corresponding service directly.

5. Reference materials

1, wiki.jasig.org/display/CAS…

2, www.jasig.org/cas/protoco…

3, www.ibm.com/developerwo…

4, www.blogjava.net/security/ar…

5, baike.baidu.com/view/190743…

The original address: www.cnblogs.com/gxbk629/p/4…