CAS series (i)--cas Single sign-on fundamentals

(This time to do a single sign-on, so the study of some CAS data and as a series of records, one may help some people, and the knowledge I have learned is also a consolidation.) )

First, why to achieve single sign-on

With the development of information technology, the process of enterprise informatization is a gradual process, in the process of building each business website gradually, according to the needs of various business information level to build the corresponding application system, because these application systems are generally developed in different periods, the application system due to functional focus, Design methods and development technology are different, but also formed their own independent user base and user authentication system. With the new business site continues to increase, the user in each application system has a separate account, so that in the access to different applications, the need to record the corresponding user name and password, multiple user name password is easy to mix, if you forget or remember the wrong user name or password of a business site can not log in, delay work, affect work efficiency, with the development of the information process in the Bureau will also have a new application system, if not introduce a single user login solution, all the company's work names, especially those who assume the approval authority at all levels are difficult to remember the user name and password of various types of application system, serious impact from the information to bring fast and efficient. In addition, multiple application platforms have multiple user management, which also brings a huge amount of work for system administrator maintenance personnel system, for example, a change of 10 people, even if only 5 applications, but also need to re-maintain 50 personnel information, and the enterprise every person adjustment far less than 10 people, this geometric growth of maintenance workload, Will waste a lot of energy and time, weaken the information system to bring convenience and fast, for this, need to establish a unified, perfect, scientific single sign-on system, each user only need to record a user name password, login a platform can realize the transparent jump of each application system, and the implementation of a unified user information management system, The system administrator only needs to maintain a set of personnel information, change the information through the Platform interface synchronization update to each application system, realize the personnel system single maintenance whole company synchronization change, greatly improve work efficiency.

Ii. Understanding SSO

(a) The English name of single sign-on is sign-on, abbreviated to SSO, which is a user authentication process that allows users to access different applications in the system once they are authenticated, without having to re-enter the password when accessing each app. IBM has an image of SSO that explains "single sign-on, full-network roaming."
SSO centralizes the use of user logins and user account management across all domains within an enterprise, and the benefits of SSO are obvious:
Reduce user logon time in different systems and reduce the likelihood of user login errors
Achieve security while avoiding the processing and saving of authentication information for multiple system users
Reduced time for system administrators to increase, remove, and modify user permissions
Added security: System administrators have a better way to manage users, including the ability to disable and remove users from access to all system resources by directly prohibiting and removing them

(b) The implementation mechanism of SSO is different, which is broadly divided into two categories: cookie mechanism and session mechanism.
WebLogic through the session to share authentication information. Session is a server-side mechanism, when the client accesses the server, the server creates a unique SessionID for the client so that it remains in the state throughout the interaction, and the information of the interaction can be specified by the application, so that SSO is implemented by the session. You cannot implement single sign-on between multiple browsers, but you can cross domains.
WebSphere Records authentication information through cookies. A cookie is a client-side mechanism that stores content that includes first name, value, expiration time, path, and domain, where the path and domain are combined to form the scope of the cookie, so that SSO can be implemented in a cookie manner, but the domain name must be the same.

Iii. knowledge of CAs

(a) CAS Single sign-on system was first developed by Yale University. In December 2004, CAS became a project in Ja-sig. The full name of Ja-sig is the Java Architectures Special Interest Group, an organization that promotes and explores Java-based open source technology in universities. CAS has many advantages, such as advanced design concept, reasonable architecture, simple configuration, broad client support, mature technology and so on.

(ii) CAS main characteristics

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.

Iv. Basic principles of CAs

(a) structural system

From the structural system, CAS consists of two parts: CAs Server and CAS Client. 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). The CAS client is responsible for processing access requests to the client's protected resources and is redirected to CAS Server for authentication when the supplicant 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.

(ii) CAS principles and protocols---basic model

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:

Such as:

1. At the beginning of the application, the original login interface is skipped, and the login interface of CAS comes directly. Of course, you can also add a login button on the main interface of the application to complete the jump work.
2. If the user likes, you can also manually enter the CAs login interface, first log in, start other applications. However, this mode is primarily used for test environments.
The 3.CAS login interface handles the so-called "Principal authentication". It requires the user to enter a user name and password, just like a normal login interface.
4. When the principal is authenticated, CAS obtains the user name and password, which is then authenticated by some kind of authentication mechanism. Usually the authentication mechanism is LDAP.
5. For future single sign-on, CAS sends back a so-called "memory Cookie" to the browser. This cookie is not really stored in memory, but the cookie expires automatically when the browser is closed. This cookie is called a "ticket-granting cookie" to indicate that the user has successfully logged in.
6. After successful authentication, the CAS server creates a long, randomly generated string called "Ticket". Subsequently, CAS links the ticket with the users who have successfully logged in, as well as the services. This ticket is a one-time credential that is used only once for users who are logged on successfully and their services. Once used, it expires immediately.
7. After the main authentication is completed, CAS redirects the user's browser back to the original application. The CAS client, while moving from application to CAS, also records the original URL, so CAs knows who is calling itself. When CAs redirects, the ticket is passed back as a parameter.
8. For example, the original application URL is http://www.itil.com/, on this site, at the beginning of the following statement, to the CAS server's single sign-on page https://secure.oa.com/cas/login?service=http:/ /www.itil.com/auth.aspx.
9.CAS after completing the principal authentication, the following URL will be used for redirection http://www.itil.com/authenticate.aspx?ticket= St-2-7fahvdq0rydqxhfbikkgfycrcoshrtsfz2w-20.
10. After receiving ticket, the application needs to verify the ticket. This is done by passing the ticket to a checksum URL. The checksum URL is also provided by the CAS server.
11.CAS through the calibration path obtained ticket, through the internal database to judge it. If the judgment is valid, a netid is returned to the application.
12. CAs will then void the ticket and leave a cookie on the client.
13. Subsequent applications will use this cookie for authentication (of course through the CAS client), and no longer need to enter a user name and password.
The SSO system, which uses. NET to implement CAS principles, lists some issues based on the first version of the SSO system, some of which are already in the form of the first version of the SSO system.

(iii) CAS principle and protocol---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, assuming that APP2 is also required to authenticate user to access, in order not to affect the user experience (excessive redirection causes user's IE window to flicker constantly), CAS introduces a proxy authentication mechanism, that is, CAS Client can proxy users to visit Ask other Web apps.
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 the base protocol when validating ST, allowing CAS server to provide the PGT URL A PGT to the 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, proxy Ticket (PT) instead of Service Ticket.

(iv) CAS principles and protocols---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.

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): Service ticket, the unique identifier of the service, issued by CAS server (Http transfer), the client browser to reach the business Server side; 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 be passed through the callback link to Web apps. 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 center;

(iv) CAS principles and protocols---security

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.

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.

Transferred from: http://m.blog.csdn.net/article/details?id=51177500

CAS series (i)--cas Single sign-on fundamentals