CAS implementation SSO Single Sign-on principle _php Tutorial

CAS implementation SSO Single sign-on principle

1.CAS Introduction

1.1.What is 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, Jdbcticketregistry, 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

Roles in the 2.2.1.SSO system

There are three main roles of the General SSO system:

1. User (multiple)

2. Web applications (multiple)

3. SSO Authentication Center (1)

The principle of 2.2.2.SSO implementation mode

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 Realization Mode

The main implementations of SSO are:

1. Sharing cookies

A cookie based on shared domain is a method used in the initial 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, However, it can be used to enable 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.

Fundamentals of 3.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 Principles and protocols

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

For example, CAS client is deployed with a protected client application to filter the protected resources of the Web app, filtering every Web request coming from the client, and CAS client parses the HTTP request for the request service Ticket ( Ticket in St), if not, indicates that the user is not certified, and CAS client redirects the user to the CAs Server (Step 2) and passes the service (the destination resource address to be accessed). Step 3 is the user authentication process, and if the user provides the correct Credentials,cas server randomly generates a fairly long, unique, non-counterfeit service Ticket, and caches it for future verification, and redirect the user to the service address (with the service Ticket that was just generated) and set a Ticket granted Cookie (TGC) for the client browser; CAS Client authenticates with CAS server in step 5 and STEP6 after receiving the service and the newly created ticket to ensure the legality of the service 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.CAS How to implement 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 App1,app1 and relies on APP2 to obtain some information, such as: User-->app1-->app2.

In this case, assuming that APP2 is also required to authenticate the user in order to access it, the CAs introduces a proxy authentication mechanism, which is the CAs, so as to not affect the users ' experience (too many redirects cause the IE window of user to flicker constantly). The client can delegate the user 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, you can eliminate the need to enter a password to get service Ticket to access other services, so here Pgt,web applications can proxy users for back-end authentication without the involvement of the front-end users.

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 the base protocol when validating St, allowing CAS server to provide a PGT to CAS via the PGT URL Client.

The CAS client gets the PGT (PGTIOU-85.....TI2TD) and can be authenticated by PGT back-end Web applications.

Here are the procedures for Agent authentication and service delivery:

As shown, proxy authentication and common authentication is not very different, step1,2 and basic mode of step1,2 almost the same, the only difference is that proxy mode is PGT instead of TGC, is proxy Ticket (PT) instead of service 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 The 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 return the response information from the credential checksum to the CAS Client by CAS server, while the Pgtiou corresponding to the PGT will pass the callback link to the Web App. 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

http://www.bkjia.com/PHPjc/1067485.html www.bkjia.com true http://www.bkjia.com/PHPjc/1067485.html techarticle CAS implementation SSO Single Sign-on principle 1.CAS introduction 1.1.What is CAS? CAS (central authentication Service) is an enterprise-class, open-source project launched by Yale University, designed for Web applications ...

