CAS entry six: CAS login process (bottom)

Assume CAS Server service address: Http://cas-server:8080/cas

Application of CAS client integration address: Http://cas-client:8070/castest

CAS Client side: 1. The user accesses the http://cas-client:8070/castest/index.jsp in the browser
2. When the CASTest application determines that the user is not logged on, redirects to the CAS server server with service query parameters
The content resembles the following: http://cas-server:8080/cas/login?service=http://cas-client:8070/castest/index.jsp

(This CAS client logic is not detailed here, this is discussed later).

----------------------------------------------------------------------------------------

CAS Server side: 1.tomcat start, load Web. xml;
Load in 2.web.xml
/web-inf/spring-configuration/*.xml
/web-inf/deployerconfigcontext.xml these configuration files;
3.spring Auto Load Cas-servlet.xml. Because a servlet named CAS is configured on the Web, the Serlet name-servlet.xml is automatically loaded after servlet2.5 (as if it were);
4. When the user accesses Http://cas-server:8080/cas/login, the servlet named CAs that is configured in Web. XML is called, and the servlet calls the spring dispatcher servlet, It then enters spring MVC and reads the Cas-servlet.xml file;
5. Calling the Cas-servlet.xml file
To move from spring MVC to spring Web flow requires a combination of both, so you need to configure
org.springframework.webflow.mvc.servlet.FlowHandlerMapping;
Org.springframework.webflow.mvc.servlet.FlowHandlerAdapter;
The specific process is:
Requests sent by the client are received first by the servlet container, the servlet container finds the appropriate application, and the servlet that conforms to the mapping criteria is processed according to the configuration of Web. Xml.
The servlet that processes the request in Spring Web MVC is Dispatcherservlet, if the requested path satisfies the dispatcherservlet mapping condition,
Then Dispatcherservlet will find all the handlermapping in the Spring IoC container,
The request is processed according to the best handler in these handlermapping (typically a controller, or a director).
When the Controller is finished, it will generally return a view (view) name, Dispatcherservlet then find the corresponding view resource according to the view name to return to the client.
Having figured out the process of Spring web MVC processing requests, it's almost clear that the configuration needed to integrate spring Web MVC with spring Web flow.
In order for the client's request to become a request to perform a flow, the following issues are addressed:
A. Need to configure the handler (or controller) responsible for handling flow requests in a handlermapping
B. The handler (or controller) is responsible for initiating the specified flow
C.flow the views involved during execution and after execution are presented to the client
5.1. Configure Flow Executor
Flowexecutor
Flowexecutor is a core interface of Spring Web flow, and it is the interface through which you start a flow. From a configuration standpoint, the default behavior of Spring Web Flow is sufficient as long as a flowexecutor is guaranteed.
5.2 Configuring Flowregistry

Flowregistry is the warehouse where flow is stored, and each XML document defining flow is parsed, assigned a unique ID and stored in flowresigtry as a Flowdefinition object. There may be more than one flow registered in Flowregistry, but each flow will have an ID, no configuration, and a default value, Flowexecutor is the ID to find out which flow to perform. As for this ID, it is to be specified by the user. In the default configuration scenario, if the client sends the following URL request:

Http://localhost:8080/cas/login from the point of view of Spring Web Flow, this URL indicates that the customer wants to execute a Flow with the id "login", and will then look in Flowregistry for the name " Login "flow, which is executed by Flowexecutor. With regard to the determination of flow ID, there are two allocation algorithms, if Base-path exists, then the ID of the stream is the directory path from Base-path to the definition file of the stream, for example, the stream definition file is/web-inf/views/hotels/ Booking/booking-webflow.xml, and Base-path is/web-inf/views,

So the flow ID is hotels/booking. If the Base-path does not exist or the definition file for the stream is in the Base-path directory,

The flow ID then subtracts the suffix of the stream's defined file name (here we define the suffix-webflow.xml), i.e. our stream definition file is called Login-webflow.xml, then the flow ID is login.
Now we have entered the Spring login-webflow.xml configuration file,
6.login-webflow.xml
Picture of the CAs: CAS login process (top)

Because this is the initial login, so the user does not have a cookie, so there is no TGT, but there is service, so entered the login page
7.login-webflow.xml file flow is completed, a view will be generated for the user foreground display, at this time to execute cas-servlet.xml in the builder;
Builder--->viewfactorycreator--->viewresolver because Cas-servelet.xml introduced/spring-configuration/ Propertyfileconfigurer.xml file, and Propertyfileconfigurer.xml read/web-inf/cas.properties, So viewresolver in the cas-servlet.xml can read the attribute values in Cas.properties cas.viewResolver.basename and cas.viewResolver.basename corresponding value default_views, so that corresponds to default_views.properties;
8. Enter the default_views.properties under the Classpath,
can find the corresponding URL page, so smoothly entered the login page/web-inf/view/jsp/default/ui/casloginview.jsp;

9. Login

Enter the user name in the casloginview.jsp, password click Login, in Login-webflow.xml <view-state id= "viewloginform" Data binding, when click to log in the time of the form submission,   Executes realsubmit this authenticationviaformaction in the Submit method, and this authenticationviaformaction is defined in Cas-servlet.xml;
10. Go to Cas-servlet.xml to find the authenticationviaformaction, from the configuration it refers to the

/web-inf/spring-configuration/applicationcontext.xml in the Centralauthenticationservice, this service is the center-certified service class, This class is the central class of authentication, basically all of the authentication configuration is around this class, the most important is that it refers to/web-inf/deployerconfigcontext.xml in AuthenticationManager,
AuthenticationManager is the authentication manager, which manages the basic process of certification; (for Certification manager See CAS: Certification manager)
11. Go to Deployerconfigcontext.xml
Find AuthenticationManager, how you need to modify the authentication method and the authentication data source can modify this configuration
12. None of the others looked, and now we're only looking at when we're in
Login-webflow.xml Realsubmit Executes the return success, the following process,
Sendticketgrantingticket->servicecheck->generateserviceticket->warn->redirect
->postredirectdecision->redirectview
<end-state id= "Redirectview" view= "Externalredirect:${requestscope.response.url}"/>
Now we are back to the CAS client clients, and the returned address resembles the following form:

Http://cas-client:8070/castest/index.jsp?jsessionid=122222222&ticket=ST-ssssssXXXXX

--------------------------------------------------------------------------------------------------------------- -------------

CAS Client side:

3. Back to the CAS client side

At this time back to the application is redirected, at this time the CAS server side completed to the user browser to write a cookie action. As for CAS client and CAS server ticket checksum and return user information, this we will discuss later.