CAS server3.3.3 source code)

Project requirements:Source codeAfter some understanding, record it, so that you can easily find ideas in the future.

 

First, we need to understand the requirements that CAs uses to meet. CAS needs to provide two protocols, cas1.0 and 2.0. This is illustrated at http://www.jasig.org/cas/protocol, but it is not very rational. The CAS client. Net version is very refined. (Http://www.middleware.vt.edu/doku.php? Id = middleware: CAS: Protocol) in short,Cas1.0 provides Response in plain text format, Cas2.0 provides the XML format. In addition,The biggest difference between cas2.0 is that it provides the proxy ticket function, that is, a service can represent a user accessing another service without user interaction.. In cas2.0, there are common XML response and SAML-compliant response. The difference is that common XML response only needs to contain userid information, SAML response can contain multiple attributes, and the client can parse as agreed. I thinkCas2.0 SAML is more practical. It can transmit email addresses and permission information.. (If the common XML response of cas2.0 is slightly modified, the same effect can be achieved, but the attributes name or quantity can be manually added)

 

Second, we need to understand casCodeYou need to know the general structureProgramThe Approximate sequence of execution. To achieve SSO performance and security, CAS performs two interactions after you enter your username and password and click the submit button. The first time you perform verification based on your username and password, if the request succeeds, a cookie containing TGT is sent to the browser. Then the CAS server reads the cookie and checks whether the TGT is sent by the CAS server. If so, The TGT generates the st, returns the parameters and values with the st value. After the client obtains the St, it sends a verification request to/servicevalidate or/samlvalidate of CAS. CAS returns the specific verification information, including the user name, email, and permission. The logon is complete.

 

According to the above general process, it is easier to understand the code. The whole code entry is in centralauthenticationserviceimpl (the two interactions are implemented through spring webflow, and the action in each step calls this class). In the webflow process, servicevalidatecontroller extracts the information in the request through casargumentextractor and combines it into the simplewebapplicationserviceimpl class (the parent class is service-> principal ). Authentication of username and password is implemented by authenticationmanagerimpl. After the verification is passed, credentialstoprincipalresolvers extracts the various attributes to be obtained and encapsulates them into the simpleprincipal class (the parent class is principal ). After verification, the immutableauthentication class is returned. This class carries simpleprincipal. Then ticketgrantingticketimpl generates TGT, including the generation time and expiration policy. In the next step, TGT generates the st and sends it back to the client.

 

Abstract class is often used in the structure of CAS code. This class inherits one or more interfaces and implements some of them. The final implementation class inherits this abstract class and interface to map different protocol requirement types. In the process of use, all calls to this type adopt the injection method, and all the interfaces referenced are their interfaces, so that the configuration can determine the target service to be provided, which is worth learning.

 

In addition, by reading the code and understanding its structure, I also made some modifications to the dog's tail. This project needs to provide soap APIs, but requires permission control. If you write a set separately, you can use the existing items as you already have CAS. The biggest logical difference between the soap API and CAS client is the cookie. Because there are many possibilities for calling the soap API client, it is not necessarily possible to store cookies. In this way, the CAS authentication process is broken, and it cannot be called SSO. Fortunately, the soap API does not require high requirements. You only need to be able to log on and control permissions, and do not need to contact the logon part of the webpage.

 

After the requirements are clear, you only need to perform subtraction on the original code. Look at the UML diagram and code to get a basic understanding of the direction, as long as you use a few items of CAS, one is to the database to retrieve user information, one is to generate ticket and maintain for a period of time. Therefore, I simplified the original things and used xfire to get Cas with the login function for developing soap APIs.

 

It is not easy to describe CAS code in words. You need a UML diagram to help you understand it.