CAS certification (3): Verifying user Information

This article is mainly for user-submitted user name and password authentication. The process is relatively simple, but we are learning more about his design ideas.

In the previous article, we generated the TGT in the Submit method in Authenticationviaformaction by

String temptgt= This.centralAuthenticationService.createTicketGrantingTicket (credentials);

method to generate the.

In this method, the parameter credentials is the encapsulation of the authentication information submitted by the user, the object is basically simply contains the user name and password.

Let's go into a detailed look at the logical behavior of the method.

The Centralauthenticationservice interface is the core interface in CAs, and he has set some of the core behaviors in CAs.

Createticketgrantingticket	This method mainly validates the authentication information and generates a TGT.
Grantserviceticket	The method is mainly to generate St
Validateserviceticket	The method is mainly to verify the St validity.
Destroyticketgrantingticket	The main method is to destroy the TGT
Delegateticketgrantingticket	This method is mainly the generation of proxy tickets

As you can see, these are the core methods in the certification process.

The default implementation of this interface is Centralauthenticationserviceimpl. Let's first look at the Createticketgrantingticket method.

Final authenticationauthentication = this.authenticationManager.authenticate (credentials); Finalticketgrantingticket ticketgrantingticket= New Ticketgrantingticketimpl (    This.ticketGrantingTicketUniqueTicketIdGenerator.getNewTicketId (Ticketgrantingticket.prefix),    authentication, this.ticketgrantingticketexpirationpolicy); This.ticketRegistry.addTicket (Ticketgrantingticket); return Ticketgrantingticket.getid ();

As you can see, the code first validates the credentials by calling the this. Authenticationmanager.authenticate method. and returns the validation result authentication. In this process, an exception is thrown if there is a problem with validation.

The TGT corresponding information is then formed by constructing a Ticketgrantingticketimpl object. As previously mentioned, the TGT exists in the form of a cookie. That is the form that exists in the client browser. There is a Ticketgrantticket object in the server-side test. This is very similar to the relationship between the session and the Jessionid. The generated TGT is stored in the ticketregistry. Then return the TGT. Here first do not explain the generation and management of ticket, the following will be described in detail, here continue to explain the process of certification.

This.authenticationManager.authenticate (credentials);

Let's take a look at how the authentication in this method is, first look at what the structure of this class is. The management of objects in CAS is implemented primarily through the IOC of spring. The configuration of the certified bean is primarily defined in Deployconfigcontext.xml. In this configuration file

<bean id= "AuthenticationManager" class= "Org.jasig.cas.authentication.AuthenticationManagerImpl" ><!--    Credentialstoprincipalresolvers mainly do two things, one is to confirm the user to authorize, in the default configuration with the Defaultcredentialstoprincipalresolver to fill the role The second is to use these decomposition device to confirm a service request proxy ticket verification.        This need to be clear is the proxy login process +--> <property name= "Credentialstoprincipalresolvers" > <list> <!-- This usernamepasswordcredentials is a parser that supports user name password login. If other authentication methods are used, then the parser needs to be replaced. This parser needs to support this authentication method +--> <bean class= "Org.jasig.cas.authentication.principal.UsernamePasswordCredentialsToPr Incipalresolver "> <property name=" attributerepository "> <ref local=" attributerepository "/ > </property> </bean> <!--This class represents support for HTTP or HTTPS protocols. He can get the credentials from the URL, and can get the service address based on the callback address. If other communication protocols are used, the corresponding replacement +--> <bean class= " Org.jasig.cas.authentication.principal.HttpBasedServiceCredentialsToPrincipalResolver "/> </list> </ property> <!--the list master hereIf a chain of authenticator is maintained, it can be used to authenticate the authentication information submitted by the user. +--> <property name= "Authenticationhandlers" > <list> <bean class= "org.jasig.cas.authentication . Handler.support.HttpBasedServiceCredentialsAuthenticationHandler "p:httpclient-ref=" httpClient "/> <b Ean class= "Org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler" > <property name= "DataSource" R ef= "DataSource"/> <property name= "sql" value= "select User_password fromt_sso_userinfo where User_name=?" "/> </bean> </list> </property></bean>

As we can see, in the manager, there are mainly two list properties: Credentialstoprincipalresolvers and Authenticationhandlers

Where Authenticationhandlers list is mainly used for certification purposes. All the beans in the list need to implement the Authenticate method in the Authenticationhandler interface. After the user submits the authentication request, satisfies the list the condition of any authentication to be considered the authentication success. Each bean can be configured with its own authentication method. So, for applications with multiple authentication methods, it is possible to assemble the certification conditions here.

The Credentialstoprincipalresolverslist property is primarily extracted from user properties after validation succeeds. and delivered to the access system. If the user data is stored in multiple data sources, you can write multiple property extractors here, extract the attributes of the user, and then pass them on to the client.

Let's analyze the source code below. To view the Authenticationmanagerimpl.authenticateandobtainprincipal method:

Authenticating user-provided authentication information through the validator chain for (final AuthenticationHandlerauthenticationHandler:this.authenticationHandlers) {    if (Authenticationhandler.supports (credentials)) {        foundsupported = true;        if (!authenticationhandler.authenticate (credentials)) {            ...        } else {           ...            Authenticatedclass =authenticationhandler;            Authenticated = true;            Break;}}}    

As you can see here, the authenticationhandlers is traversed, and if it passes authentication, then break.

foundsupported = false;//Authentication is successful, the full information of the user is extracted by the authentication information for (finalcredentialstoprincipalresolver CredentialsToPrincipalResolver:this.credentialsToPrincipalResolvers) {    if ( Credentialstoprincipalresolver.supports (Credentials)) {        final Principal Principal = Credentialstoprincipalresolver           . Resolveprincipal (credentials);        Foundsupported = true;        if (principal! = null) {            return new pair<authenticationhandler,principal> (Authenticatedclass,principal);        }    }}

The credentialstoprincipalresolvers is parsed here, and once the user's properties are obtained, a new pair object is built with the authenticated class and user attributes.

Below, let's dive into the Org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler to see how the class authenticates the user.

Here, I take a simple look at this class, credentials is a simple encapsulation of authentication requests. Of course, you can get the user name and password. The password is then encrypted and compared to the results of the database query.

Final stringusername = Getprincipalnametransformer (). Transform (Credentials.getusername ()); final String password = Credentials.getpassword (); final String Encryptedpassword = This.getpasswordencoder (). Encode (    password); try {    final String Dbpassword =getjdbctemplate (). queryForObject (This.sql, string.class,username);    Returndbpassword.equals (Encryptedpassword);} catch (Finalincorrectresultsizedataaccessexception e) {    //This means the username is notfound.    return false;}

In CAs, the operation of the database is primarily done using spring's jdbctemplate. This is no exception.

The business logic here is relatively straightforward. Look back at the implementation here. He separates all the components that can be separated out. For example, password encryption algorithm. Data sources, query statements, and so on. Changes to any component have no effect on other components. This is the object-oriented benefit, which is the benefit of using spring IOC.

CAS certification (3): Verifying user Information