CAS Authentication principle

A brief introduction to CAS principle

Introduction to the official CAS website:

Main principle:

The first time a user accesses a cas  service customer web  application (Access url :http://192.168.7.90:8081/web1 ), the CAS deployed in the customer Web application Authenticationfilter, this request is intercepted, the service  parameter is generated, and then the login  interface redirect  to the cas  service,url  to Https://cas : 8443/cas/login?service=http%3a%2f%2f192.168.7.90%3a8081%2fweb1%2f,,cas  server will generate authentication cookie&nbsp after successful authentication, write to Browser, The cookie  cache to the server local,cas  server will also be generated according to service  parameters ticket,ticket  will be saved to the server, will be added behind the url , The request is then redirect  back to the customer web  app with a URL of http://192.168.7.90:8081/web1/?ticket= st-5-sx6eyvj7cppcfn0pmzumwnbmvxpcbcnaii6-20 . When the client's authenticationfilter  sees the ticket  parameter, it skips and is processed by the ticketvalidationfilter  behind it, Ticketvalidationfilter will use the httpclient  tool to access the/servicevalidate  interface of the cas  service,  ticket , service   is passed to this interface, which verifies the validity of the ticket,ticketvalidationfilter  if a successful message is obtained, the user information is written to the session  of the web  application. So far the,sso  session has been established, in the future users in the same browser to access this web  application,authenticationfilter  will read the user information in session , so will not go to CAS   Authentication, if you access other web  applications in this browser, Authenticationfilter in the session  can not read the user information, will go to cas  login  interface authentication, but then cas  will read the browser came cookie  So cas  will not ask the user to log on to the login page, but will generate a ticket&nbsp according to the service  parameter, and then the web  application to do a validation ticket  interaction.

Processing logic of two CAS client Filter

1 Authenticationfilter

if (no ticket parameter in URL && assertion object not ticketvalidationfilter in session) {

Response.sendredirect (/login interface of CAS server);//Generate service parameters, add to URL after

}

else{

No processing.

}

2 Ticketvalidationfilter

If (the URL has the ticket parameter) {

The HttpClient tool accesses the/servicevalidate interface of the CAS server to verify the validity of the ticket, the validation fails, the error page is displayed, the validation succeeds, and the assertion object that identifies the user is generated and placed in the session.

}

else{

No processing.

}

Note:

1 authenticationfilter in front, ticketvalidationfilter in the rear.

2 Authenticationfilter:

1) The URL does not have ticket parameters, and the session does not have Ticketvalidationfilter assertion object, this situation indicates that the user has not been certified, Authenticationfilter will go to do authentication processing;

2) The URL does not have ticket parameters, and the session has Ticketvalidationfilter assertion objects, this situation indicates that the user has been certified successful, authenticationfilter do not do processing;

3) URL has ticket parameters, this situation indicates that the user has been certified successful, but also need to ticketvalidationfilter to verify ticket,authenticationfilter do not do processing.

3 Ticketvalidationfilter: Only the client calls the CAS server/login interface, and successfully authenticated, redirect back to the client, the URL only with the ticket parameters, in this case, Ticketvalidationfilter only to do the processing.

Processing logic of three CAS service end

A total of 7 interfaces have been exposed by the CAS server, and the client interacts with the server by accessing the 7 interfaces, which are:/login,/logout,/validate,/servicevalidate,/proxy,/proxyvalidate,/C Entralauthenticationservice.

/login is the authentication interface,

/logout is the exit interface responsible for destroying the authentication cookie,

/validate,/servicevalidate is the interface for validating ticket, where/validate is defined by CAS1.0,

/servicevalidate is defined by CAS2.0, where/servicevalidate returns data in XML format,

/proxy,/proxyvalidate is the interface that supports the agent authentication function,

The/centralauthenticationservice interface is used to interact with remote Web services.

for a general web application of single sign-on,/login,/logout,/servicevalidate these 3 interfaces have been able to meet the requirements . These interfaces have been defined in the CAS protocol and are linked to: Http://www.jasig.org/cas/protocol. Here is a detailed description of the implementation of the various CAS interfaces.

/login:

Login process This part takes into account the different kinds of user credential acquisition scheme, as well as the customer application of service, gateway, renew parameters of different value combinations, CAS in order to achieve the highly configurable process, the use of spring Web flow technology. By reading the 3 files of Login-webflow.xml, Cas-servlet.xml and Applicationcontext.xml in the CAS release package, I found all the components involved in the login and drew up its processing flowchart.

CAS default Logon processing process

The first time to access the Web app's process trend

After you have logged in to Web1, Access web1 resources (Web1 does not start session), or access WEB2 resources

Note:

1:initialflowsetupaction: Is the entrance to the process.  Use the value of Request.getcontextpath () to set the path value of the cookie, the path value of the cookie is defined in the configuration file, but this Action is responsible for setting the value of Request.getcontextpath () to The path value of the cookie, which is the flexible way to set the cookie path in the case of a change in the CAS deployment environment, and the value of the cookie and the value of the service parameter into the RequestContext flowscope.

2:generateserviceticketaction This Action is responsible for generating Serviceticket objects based on service, GTC cookie values, Serviceticket's ID is the tick returned to the customer app The ET parameter, if Serviceticket is successfully created, is forwarded to warnaction, and if the creation fails, and the gateway parameter is true, it is redirect directly to the customer application, otherwise it will require reauthentication.

3:viewloginform This is the login page, where CAS collects user credentials. The default implementation provided by CAS is/web-inf/view/jsp/simple/ui/casloginview.jsp.

4:bindandvalidate corresponding to Authenticationviaformaction Dobind method, this method is responsible for collecting the login page user input credentials (user name, password, etc.), and then the information encapsulated in the internal CAS credent The IALs object. This method is triggered when the user clicks Submit on the casloginview.jsp page.

5:submit corresponds to Authenticationviaformaction's Submit method, if the Dobind method executes successfully, the Submit method is triggered, this method is responsible for invoking Centralauthenticationse Rvice Grantserviceticket method, complete the certification work, if the authentication is successful, then generate Ticketgrantingticket object, put in the cache, Ticketgrantingticket ID is TGC Cook The value of IE.

6:warn CAs provides a feature: When a user jumps to another web app in one web app, the CAs can jump to a hint page that prompts the user to leave an app and go to another app, allowing the user to choose. The user selects the id= "Warn" checkbox on the login page Viewloginform to enable this feature.

Warnaction Check whether the user has turned on this function, if it is turned on, then forward to Showwarnview, if not open, then directly redirect to the customer application.

7:sendticketgrantingticketaction This action is responsible for generating TGC cookies for response, and the value of the cookie is Authenticationviaformaction's Submit method generation The ID of the Ticketgrantingticket object.

8:viewgenerateloginsuccess This is the Certification Success page for CAS.

/logout: ( corresponds to implementation class Org.jasig.cas.web.LogoutController)

Processing logic:

1) Removecookie

2) Delete the Ticketgrantingticket object on the server (this object encapsulates the value of the cookie)

3) Redirect to Exit page, there are 2 kinds of options:

if (the Followserviceredirects property of the Logoutcontroller is a true value and the service parameter in the URL is not null) {

Redirect to the URL of the sevice parameter identification

}

else{

Redirect to the built-in Caslogoutview (cas/web-inf/view/jsp/default/ui/caslogoutview.jsp), this URL if there is a URL parameter in the URL The link to the parameter identification is displayed on the Caslogoutview page.

}

/servicevalidate: (corresponds to implementation class Org.jasig.cas.web.ServiceValidateController)

Processing logic:

If the service parameter is empty or the ticket parameter is empty, it is forwarded to Failureview (/web-inf/view/jsp/default/protocol/2.0/ CASSERVICEVALIDATIONFAILURE.JSP)

Verify the ticket. Take ticket as the parameter, go to the cache to find Serviceticketimpl object, if can find, and not expired, and Serviceticketimpl object corresponding service attribute and service parameter corresponding, then verify pass, after verification pass, request forward to Casservicesuccessview (cas/web-inf/view/jsp/default/protocol/2.0/casservicevalidationsuccess.jsp), verification does not pass, is forwarded to Failureview.

Iv. concepts and processes related to certificationConcept

• Credentials User-supplied credential information for login, such as username/password, certificate, IP address, Cookie value, etc. For example, Usernamepasswordcredentials, which encapsulates a user name and password. The first step in CAS authentication is to encapsulate the user credentials from the UI or the request object into a Credentials object, which is then passed to the authentication manager for authentication.

• Authenticationhandler Certified handler, each Authenticationhandler can only handle one credentials, such as Abstractusernamepasswordauthenticationhandler is only responsible for handling U sernamepasswordcredentials.

• Principal Encapsulates user identities, such as Simpleprincipal, just encapsulates the user name. After successful authentication, Credentialstoprincipalresolvers is responsible for generating Principal objects by Credentials.

• Credentialstoprincipalresolvers is responsible for generating Principal objects from Credentials, each of which handles only A credentials, such as Usernamepasswordcredentialstoprincipalresolver, is responsible for removing the user name from the U sernamepasswordcredentials and assigning it to the generated The ID attribute of the Simpleprincipal.

• Authenticationmetadatapopulators is responsible for assigning some properties of Credentials to the Attributes property of authentication.

• Authentication Authentication is the final processing result of the authentication manager, authentication encapsulates Principal, authentication time, and some other attributes (possibly from Credentials).

• After the AuthenticationManager authentication Manager obtains the Credentials object, it is responsible for dispatching the Authenticationhandler to complete the authentication work, and the result of the final return is the authentication object.

• Centralauthenticationservice The service classes of CAS provide some methods for the Web tier. The class is also responsible for invoking AuthenticationManager to complete the authentication logic .

Sequence diagram

CAS Certified processing sequence diagram

Class diagram

CAS Authentication class Diagram

CAS Authentication principle