CAS implementation SSO Single sign-on principle

1. Introduction of CAS 1.1. What is a CAS?

CAS (central authentication Service) is an enterprise-class, open-source project initiated by Yale University, designed to provide a reliable single sign-on solution (belonging to Web SSO) for Web application systems.

CAS began in 2001 and officially became a project in Ja-sig in December 2004.

1.2. Key Features

1. Open source, Multi-Protocol SSO solution, Protocols:custom Protocol, CAS, OAuth, OpenID, RESTful API, SAML1.1, SAML2.0, etc.

2. Support multiple authentication mechanisms: Active Directory, JAAS, JDBC, LDAP, certificates, etc.

3, Security Policy: Use the ticket (Ticket) to achieve the supporting authentication protocol;

4. Support Authorization: Can decide which service can request and verify service ticket (services Ticket);

5. Provide high availability: By storing certified state data in the Ticketregistry component, these components have many implementations that support a distributed environment, such as Berkleydb, Default, Ehcacheticketregistry, jdbctic Ketregistry, JBOSS Treecache, Jpaticketregistry, memcacheticketregistry, etc.;

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

2. SSO Single Sign-on principle

The content of this article is primarily for Web SSO.

2.1. What is SSO

Single Sign-On (sign-on, SSO) is one of the most popular solutions for enterprise business integration, and SSO makes it possible for users to access all trusted applications in multiple applications with only one login.

2.2. SSO principle 2.2.1. Roles in the SSO system

There are three main roles of the General SSO system:

1. User (multiple)

2. Web Applications (multiple)

3. SSO Authentication Center (1)

2.2.2. Principles of the SSO implementation pattern

The SSO implementation pattern typically consists of the following three principles:

1, all the authentication login in the SSO Certification center;

2, the SSO Certification center through a number of methods to tell the WEB application that the current access to the user is not authenticated users;

3. The SSO Certification Center establishes a trust relationship with all Web applications, which means that the Web application must trust the authentication center. (Single point of trust)

2.2.3. SSO Main Implementation method

The main implementations of SSO are:

1. Sharing cookies

A cookie based on shared domain is a method used in the first phase of WEB, which uses the automatic transfer of cookies between the same domain name to realize the problem of system token transfer between two domain names. In addition, with regard to cross-domain issues, although the cookies themselves are not cross-domain, they can be used to implement cross-domain Sso. such as: proxies, exposing SSO token values, and so on.

Disadvantage: Not flexible and there are many security risks, has been abandoned.

2. broker-based (based on broker)

The feature of this technology is that there is a centralized authentication and user account Management Server. The broker gives access to the electronic identities that are used for further requests. The use of a central database reduces the cost of management and provides a public and independent "third party" for certification. Examples include Kerberos, Sesame, IBM kryptoknight (Credential Library Idea), and so on. Kerberos, a security certification service invented by MIT, has been integrated into the operating system by UNIX and Windows as the default security Authentication service.

3. agent-based (based on agent)

In this solution, there is an agent that automatically authenticates the user as a different application. This agent needs to be designed with different functions. For example, it can use a password table or encryption key to automatically move 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 authentication method. such as SSH.

4, token-based

For example, Secureid,webid, now widely used password authentication, such as FTP, mail server login authentication, this is an easy-to-use way to implement a password in a variety of applications.

5. Gateway-based

6. SAML-based

The advent of SAML (Security assertion Markup Language, secure Assertion Markup Language) greatly simplifies SSO and is approved by OASIS as the execution standard for SSO. Open source organization Opensaml implements the SAML specification.

3. Basic principles of CAS 3.1. Structural system

From the structural system, CAS consists of two parts: CAs Server and CAS Client.

3.1.1. CAS Server

CAS server is responsible for completing the authentication work for the user and requires a standalone deployment, and CAS server handles credentials such as username/password (Credentials).

3.1.2. CAS Client

is responsible for processing access requests to the client's protected resources and is redirected to CAS Server for authentication when the requester needs to be authenticated. (In principle, the client app no longer accepts any Credentials such as user name passwords).

The CAS client is deployed together with protected client applications to protect protected resources in a Filter manner.

3.2. CAS principle and protocol 3.2.1. Basic mode

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

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

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

3. User authentication: User identity authentication.

4. Issuing notes: The SSO server generates a random Service Ticket.

5. Verify the ticket: The SSO server verifies the legality of the ticket service Ticket, and after validation passes, allows the client to access the service.

6. Transfer user information: The SSO server verifies that the ticket is passed and transmits the user authentication result information to the client.

Here is the most basic protocol process for CAS:

Basic Agreement diagram

such as:  cas client  is deployed with protected client apps to protect protected resources  Web  apps in  Filter , filtering every  web that comes from the client   request, at the same time,  cas client  will analyze whether the request  service Ticket (st  in  ticket) is included in the  HTTP  request   , if not, the user is not certified, so  cas client  redirects user requests to  cas server  ( step 2 ) and passes  service   (The destination resource address to access).  step 3  is a user authentication process, if the user provides the correct  credentials , cas server  randomly produces a fairly long, unique, non-counterfeit   Service ticket , and cached for future verification, and redirect the user to the  Service  address (with the  service ticket  that was just generated)  ,  and set up a  ticket granted cookie  ( TGC ) for the client browser  ; cas client  to get  Service  And newly generated  Ticket , verify with  cas server  in  step 5  and  Step6  to ensure  service The legitimacy of ticket .

In this protocol, all interactions with CAS Server use the SSL protocol to ensure the safety of ST and TGC. There are 2 redirects during the protocol work process. However, the process of Ticket authentication between CAs Client and CAS Server is transparent to the user (using Httpsurlconnection).

CAS Request authentication sequence diagram as follows:

3.2.1. How CAS implements SSO

When a user accesses another app's service and is redirected to the CAS server again, CAS server proactively receives the TGC cookie and does the following:

1) If User holds TGC and it has not expired, then go to the Step4 of the Basic Agreement diagram, achieve the effect of SSO;

2) If the TGC fails, then the user will still have to re-authenticate (take the Basic agreement diagram of the STEP3).

3.2.2. CAS Proxy Mode

This mode is for the user to access the APP1, APP1 also relies on APP2 to obtain some information, such as: User-->app1-->app2.

In this case, it is assumed that APP2 also needs to authenticate to the user to access, so that, in order not to affect the users experience (too many redirects cause user IE window to flicker constantly), CAS introduces a proxy authentication mechanism, that is, CAS Client can proxy users To access other WEB applications.

The agent is premised on the need for CAS Client to have the user's identity information (similar credentials). The TGC we mentioned earlier is a credential that the user holds on their own identity information, where PGT is a credential held by the CAS Client for the identity of the user. With TGC, user can eliminate the need to enter a password for service Ticket to access other services, so here, with PGT, the Web application can proxy users to achieve back-end authentication without the involvement of the front-end user.

The following is the process for the agent application (HelloService) to obtain the PGT: (Note: Pgturl is used to represent a proxy service, is a callback link; PGT is the equivalent of a proxy certificate; Pgtiou is the key to take the proxy card, used to associate with PGT;)

As shown in the CAS Proxy diagram above, CAS Client provides an additional PGT URL (and SSL ingress) to CAS server on top of the underlying protocol, allowing CAS server to provide a PGT URL with a A PGT to CAS Client.

CAS Client got PGT (PGTIOU-85 ...). TI2TD), you can authenticate with the PGT back-end Web app.

Here are the procedures for Agent authentication and service delivery:

As shown, proxy authentication and common authentication is not very different, STEP1, 2 and the basic mode of step1,2 almost the same, the only difference is that the proxy mode is PGT instead of TGC, is proxy Ticket (PT) and not Servi Ce Ticket.

3.2.3. Auxiliary instructions

The SSO implementation of CAS can be simplified as follows: 1 cookies and N Session. CAS Server creates a cookie that is used for all application certifications, and each app identifies whether the user is logged in by creating a separate Session.

When a user accesses the app in the same browser after an app has been validated, the filter in the client application reads the user information in the session, so it does not go to CAS Server authentication. If you access another Web application in this browser, the filter in the client application does not read the user information in the session, it will go to the CAS server login interface authentication, but then CAS server will read the cookie from the browser (TGC), so CAS Server does not require the user to log on to the login page, but generates a Ticket based on the service parameters and then makes a validation Ticket interaction with the Web application.

3.3. Terminology interpretation

5 notes were designed in CAS system: TGC, ST, PGT, Pgtiou, PT.

? Ticket-granting Cookie (TGC): A cookie that holds user authentication credentials, is used when communicating between the browser and the CAS server, and can only be based on secure channel transmission (HTTPS), which is the credential used by CAS Server to clarify the user's identity;

? Service Ticket (ST): Services ticket, unique identifier of the service, issued by CAS server (Http transfer), to the business Server side via the client browser; A specific service can only have a single ST;

? Proxy-granting ticket (PGT): issued by CAS Server to the service that owns the ST credential, PGT binds a user's specific service, and has the ability to apply to CAS server to obtain PT;

? Proxy-granting Ticket I Owe You (Pgtiou): The function is to pass the credential check when the response information is returned by the CAS Server to the CAs Client, and the Pgtiou corresponding to the PGT will pass the callback link to the W EB applications. The WEB application is responsible for maintaining the table of contents of the mapping relationship between Pgtiou and PGT;

? Proxy Ticket (PT): Is the application proxy user identity to the target program to access the credentials;

Other explanations are as follows:

? Ticket granting Ticket (TGT): Ticket-granting instrument, issued by the KDC. That is, after obtaining such a ticket, the subsequent application of various other service notes (ST) will no longer have to submit identity authentication information to the KDC (Credentials);

? Authentication Service (AS)---------certification services, request Credentials, issue TGT;

? Ticket-granting Service (TGS)---------Ticket Authorization services, request TGT, release ST;

? KDC (Key Distribution center)----------Key Distribution centre;

4. CAS Security

The security of CAS relies only on SSL. The secure cookie is used.

4.1. TGC/PGT Security

For a CAS user, the most important thing is to protect its TGC, if TGC is inadvertently obtained by an entity other than CAs Server, Hacker can find the TGC and then impersonate a CAS user to access all authorized resources. PGT's role is the same as TGC.

As can be seen from the basic pattern, TGC is the CAS Server sent to end users via SSL, so it is very difficult to intercept TGC to ensure the security of CAs.

The TGT's survival period defaults to 120 minutes.

4.2. ST/PT Security

ST (Service Ticket) is transmitted over Http, so other people on the network can Sniffer to other people's Ticket. CAS makes ST more secure (in fact, configurable) in the following ways:

1, ST can only use once

The CAS protocol stipulates that, regardless of the success of service Ticket validation, CAS Server clears the Ticket in the server-side cache, ensuring that a service Ticket is not used two times.

2, ST in a period of time failure

CAS stipulates that ST can only survive for a certain amount of time, and then CAs Server will invalidate it. The default validity time is 5 minutes.

3, ST is based on the random number generation

St must be random enough, if the St generation rule is guessed, Hacker is equivalent to bypassing CAS authentication and directly accessing the corresponding service.

5. References

1, Https://wiki.jasig.org/display/CASUM/Introduction

2, http://www.jasig.org/cas/protocol/

3, http://www.ibm.com/developerworks/cn/opensource/os-cn-cas/index.html

4, http://www.blogjava.net/security/archive/2006/10/02/sso_in_action.html

5, Http://baike.baidu.com/view/190743.htm

Original address: http://www.cnblogs.com/gxbk629/p/4473569.html

CAS implementation SSO Single sign-on principle