CAS implements SSO single sign-on principle

1. Introduction to CAS

1.1.What is CAS?

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

CAS started 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. Supports multiple authentication mechanisms: Active Directory, JAAS, JDBC, LDAP, X.509 Certificates, etc.;

3. Security policy: Use tickets to implement supported authentication Protocol;

4. Support authorization: you can decide which services can request and verify service tickets (Service Ticket);

5. Provide high availability: by storing authenticated status data in TicketRegistry Among the components, many of these components support the implementation of distributed environments, such as: BerkleyDB, Default, EhcacheTicketRegistry, JDBCTicketRegistry, JBOSS TreeCache, JpaTicketRegistry, MemcacheTicketRegistry, etc.;

6. Supports multiple clients: Java, .Net , PHP, Perl, Apache, uPortal, etc.

2. SSO single sign-on principle

The content of this article is mainly aimed at Web SSO.

2.1. What is SSO

Single Sign-On (SSO) is currently one of the more popular solutions for enterprise business integration. SSO enables multiple In the application system, users only need to log in once to access all mutually trusted application systems.

2.2. SSO principles

2.2.1. Roles in the SSO system

Generally, there are three main roles in the SSO system:

1. User (more )

2. Web applications (multiple)

3. SSO certification center (1)

2.2.2. Principles of SSO implementation model

The SSO implementation model generally includes the following three principles:

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

2. The SSO certification center uses some methods to tell the web application the current Whether the accessing user is an authenticated user;

3. The SSO certification center establishes a trust relationship with all web applications, which means that web applications must trust the certification center. (Single point of trust)

2.2.3. The main implementation methods of SSO

The main implementation methods of SSO are:

1. Shared cookies

Based on sharing Cookies in the same domain are a method used in the initial stage of the Web. It uses the automatic cookie transfer mechanism between browsing the same domain name to realize the problem of system token transfer between two domain names. In addition, regarding cross-domain issues, although cookies themselves It is not cross-domain, but it can be used to implement cross-domain SSO. Such as: proxy, exposing SSO token value, etc.

Disadvantages: Inflexible and has many safety hazards, it has been abandoned.

2. Broker-based (broker-based)

The characteristic of this technology is that it has a centralized authentication and user account management server. The broker gives electronic identity access which is used for further requests. The use of a central database reduces administrative costs and provides a public and independent "third party" for certification. For example, Kerberos, Sesame, IBM KryptoKnight (credential library idea), etc. Kerberos is a security authentication service invented by MIT and has been integrated into the operating system as the default security authentication service in UNIX and Windows.

3. Agent-based

In this solution, there is an agent that automatically authenticates users for different applications. This agent needs to be designed with different functions. For example, it can use password tables or encryption keys to automatically shift 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 method. For example SSH etc.

4. Token-based

For example, SecureID, WebID, password authentication that is now widely used, such as FTP, mail server login authentication, this is a simple and easy-to-use way to implement One password is used in multiple applications.

5. Based on gateway

6. Based on SAML

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

3. Basic principles of CAS

3.1. Structural system

From a structural system perspective, CAS includes two parts: CAS Server and CAS Client.

3.1.1.CAS Server

CAS Server is responsible for completing the authentication of users and needs to be deployed independently. CAS Server will handle credentials such as username/password (Credentials).

3.1.2.CAS Client

is responsible for processing access requests to the client's protected resources. When the requester needs to be authenticated, it will be redirected to the CAS Server for authentication. (In principle, client applications no longer accept any Credentials such as usernames and passwords).

CAS Client is deployed together with the protected client application to protect protected resources in Filter mode.

3.2. CAS principles and protocols

3.2.1. Basic mode

The basic mode SSO access process mainly has the following steps:

1. Access the service : The SSO client sends a request to access the service resources provided by the application system.

2. Directed authentication: The SSO client will redirect user requests to the SSO server.

3. User authentication: user identity authentication.

4. Issue tickets: The SSO server will generate a random Service Ticket.

5. Verify the ticket: The SSO server verifies the validity of the Service Ticket. After passing the verification, the client is allowed to access the service.

6. Transmit user information: After the SSO server passes the verification ticket, it transmits the user authentication result information to the client.

The following is the most basic protocol process of CAS:

CAS implements SSO single sign-on principle_PHP tutorial

Basic protocol diagram

As shown in the picture above: CAS Client is deployed together with the protected client application, using Filter method to protect the protected resources of the Web application, filtering every Web request from the client. At the same time, CAS Client will analyze whether the HTTP request contains Request a Service Ticket (Ticket in the ST picture above). If not, it means that the user has not been authenticated; then the CAS Client will redirect the user request to the CAS Server (Step 2) and pass the Service (the destination resource to be accessed) address). Step 3 is the user authentication process. If the user provides correct Credentials, the CAS Server randomly generates a service ticket of considerable length, unique and unforgeable, caches it for future verification, and redirects the user to the address of the Service (with the service ticket just generated Service Ticket), and sets a Ticket Granted Cookie (TGC) for the client browser; after CAS Client gets the Service and the newly generated Ticket, it performs identity verification with the CAS Server in Step 5 and Step 6 to ensure the Service Ticket of legality.

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

CAS request authentication sequence diagram is as follows:

CAS implements SSO single sign-on principle_PHP tutorial

3.2.1. How CAS implements SSO

When a user When the service accessing another application is redirected to the CAS Server again, the CAS Server will actively obtain the TGC cookie and then do the following:

1) If the User holds the TGC and it has not expired , then follow Step 4 of the basic protocol diagram to achieve the SSO effect;

2) If TGC fails, the user still needs to re-authenticate (step 3 of the basic protocol diagram).

3.2.2.CAS proxy mode

The form of this mode is that the user accesses App1, and App1 relies on App2 to obtain some information, such as: User --> App1 -->App2.

In this case, assuming that App2 also needs to authenticate the User before accessing it, in order not to affect the user experience (excessive redirections cause the User's IE window to keep flashing), CAS is introduced A Proxy authentication mechanism is introduced, that is, CAS Client can act as a proxy for users to access other web applications.

The premise of proxy is that CAS Client needs to have the user's identity information (similar to credentials). The TGC we mentioned before is a credential held by the user for his or her identity information. The PGT here is a credential held by the CAS Client for the user's identity information. With TGC, Users can obtain Service Tickets to access other services without having to enter passwords. Therefore, with PGT, web applications can proxy users to achieve back-end authentication without the participation of front-end users.

The following is the process for the proxy application (helloService) to obtain PGT: (Note: PGTURL is used to represent a Proxy service, which is a callback link; PGT is equivalent to the proxy certificate; PGTIOU is the key to obtain the proxy certificate, used to Associated with PGT;)

CAS implements SSO single sign-on principle_PHP tutorial

As shown in the CAS Proxy diagram above, CAS Client is based on the basic protocol and is provided when verifying ST An additional PGT URL (and an SSL entry) is provided to the CAS Server so that the CAS Server can provide a PGT to the CAS Client through the PGT URL.

After CAS Client gets PGT (PGTIOU-85…..ti2td), it can authenticate the back-end web application through PGT.

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

As shown in the figure above, there is actually a difference between proxy authentication and ordinary authentication. Not big. Steps 1 and 2 are almost the same as Steps 1 and 2 in the basic mode. The only difference is that the Proxy mode uses PGT instead of TGC, and Proxy Ticket (PT) instead of Service Ticket.

3.2.3. Auxiliary instructions

The SSO implementation method of CAS can be simplified and understood as: 1 Cookie and N Sessions. CAS Server creates cookies and uses them for authentication in all applications. Each application creates its own Session to identify whether the user is logged in.

After a user is authenticated in an application, when the user accesses the application in the same browser in the future, the filter in the client application will read the user information in the session, so it will not go to the CAS Server for authentication. If you access other web applications in this browser and the filter in the client application cannot read the user information in the session, it will go to the login interface of the CAS Server for authentication, but at this time the CAS Server will read the browser The cookie (TGC) passed by the server, so the CAS Server will not require the user to log in to the login page, but will generate a ticket based on the service parameters, and then interact with the web application to verify the ticket.

3.3. Explanation of terms

There are 5 types of tickets designed in the CAS system: TGC, ST, PGT, PGTIOU, and PT.

?Ticket-granting cookie (TGC): A cookie that stores user authentication credentials. It is used when communicating between the browser and CAS Server. It can only be transmitted based on secure channel (Https) and is used by CAS Server. Credentials that clarify the user's identity;

? Service ticket (ST): Service ticket, the unique identification code of the service, is issued by the CAS Server (HTTP transmission), and reaches the business server through the client browser; a specific A service can only have one unique ST;

? Proxy-Granting ticket (PGT): issued by the CAS Server to a service with an ST certificate. PGT binds a user's specific service so that it has the right to request the CAS Server Apply to obtain the ability of PT;

?Proxy-Granting Ticket I Owe You (PGTIOU): The function is to return the response information when passing the certificate verification from the CAS Server to the CAS Client, and at the same time, correspond to the PGTIOU The PGT will be passed to the web application through the callback link. The web application is responsible for maintaining the content table of the mapping relationship between PGTIOU and PGT;

?Proxy Ticket (PT): It is the credential for the application proxy user to access the target program;

Other instructions are as follows:

?Ticket Granting ticket (TGT): Ticket authorization ticket, issued by KDC’s AS. That is, after obtaining such a ticket, you no longer need to submit identity authentication information (Credentials) to KDC when applying for various other service tickets (ST) in the future;

?Authentication service (AS) ------- --Authentication service, request Credentials, issue TGT;

?Ticket-granting service (TGS) ---------Ticket authorization service, request TGT, issue ST;

?KDC (Key Distribution Center) ----------Key distribution center;

4.CAS security

CAS security Just rely on SSL. Secure cookies are used.

4.1.TGC/PGT security

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

As can be seen from the basic mode, TGC is sent by CAS Server to end users through SSL. Therefore, it is very difficult to intercept TGC to ensure the security of CAS.

The default survival period of TGT is 120 minutes.

4.2.ST/PT Security

ST (Service Ticket) is transmitted through Http, so other people in the network can Sniffer to other people's Tickets. CAS makes ST more secure through the following aspects (in fact, they are all configurable):

1. ST can only be used once

CAS protocol stipulates that regardless of whether the Service Ticket is verified or not If successful, the CAS Server will clear the Ticket in the server cache, thereby ensuring that a Service Ticket is not used twice.

2. ST expires within a period of time

CAS stipulates that ST can only survive for a certain period of time, and then the CAS Server will let it expire. The default validity time is 5 minutes.

3. ST is generated based on random numbers

ST must be random enough. If the ST generation rules are guessed, Hacker will bypass CAS authentication and directly access the corresponding service.