Diagram of CAS single-point Logon

I have been busy recently and haven't written any blog for a long time. The company wants to create an SSO application, and some departments have the need to define the login page on their own application end, instead of fully redirecting to the CAS unified login interface. After reading the source code of the CAS server, I can understand it. So I took off my clothes and started to do it .....

This article mainly introduces the modification principle. If it is too troublesome, you can skip this article and read the implementation article.

The two solutions support remote logon by using IFRAME + JS and redirection technologies on the client respectively. The redirection technology solution is provided first.

This solution mainly implements independent client login page through page redirection

Basic Principles

First, let's take a look at the following basic principles of CAS operation between our modifications. The sequence of CAS server, client (application), and browser is as follows:

Where:

• St: service ticket, used by client applications. Each st corresponds to a user on a client.
• TGT: ticket granting ticket, which is stored on the CAS server and user cookie.

The CAS server holds the st ing between ST and TGT + client, and the client holds the ing between ST and user session. In the case of RENEW, each time the client sends the st to the CAS server based on the user session, the server checks whether the st exists to know whether the user has logged on. Under normal circumstances, when a user logs on to the application for the first time, the client redirects the user page to the CAS server, and the server retrieves the TGT in the user cookie to check whether the cookie exists on the server, if yes, generate the st and return it to the client (If NO, log on to the client. If yes, return the st to the client after successful login). After the client obtains the St, it sends the st to the CAS server for authentication, if the authentication succeeds, the logon is successful.

As we can see, what we need to do is to change the login page returned in step 1 from the server to the client, in step 2, the user enters the user name and password on the client and submits the password to the CAS server. Both the login success and failure will be switched to the client.

Detailed Server login process

For the overall login process described in the previous section, CAS 3.3.1 on the server side is dependent on Spring webflow 1.0.3 implementation, its main process is configured in the/WEB-INF/login-webflow.xml, the page flow activity diagram configured is as follows (with strikethrough ):

The name in the figure is based on the name in the webflow configuration file, as shown in the following figure:

• The action state icon indicates the action-state or view-state node in the webflow configuration file.
• The demo-state icon indicates the demo-state node in the webflow configuration file.
• The initial state icon indicates the start-state node in the webflow configuration file.
• The final state icon indicates the end-state node in the webflow configuration file.

The login process is described in the figure below. The following describes the operations of spring webflow on the CAS server.

First, CAS configures the servlet named CAs in/WEB-INF/Web. XML to intercept the input request. If the resource path requests outside the CAS Servlet Mapping range are redirected to/login:

<Servlet>
<Servlet-Name> CAS </servlet-Name>
<Servlet-class> org. JASIG. Cas. Web. init. safedispatcherservlet </servlet-class>
<Init-param>
<Param-Name> publishcontext </param-Name>
<Param-value> false </param-value>
</Init-param>
<Load-on-startup> 1 </load-on-startup>
</Servlet>
<Servlet-mapping>
<Servlet-Name> CAS </servlet-Name>
<URL-pattern>/login </url-pattern>
</Servlet-mapping>
...
<! -- Other CAS Servlet Mapping -->

All requests mapped to the CAS servlet are checked by/WEB-INF/cas-servlet.xml to determine which action to enter. The two most important beans in the cas-servlet.xml are handlermappingb and handlermappingc.

Handlermappingb configures path ing for login flows, while handlermappingc configures path ing for other flows. The/WEB-INF/login-webflow.xml flow configuration file is entered through the/login ing in handlermappingb.

Based on a generated flowexecutionkey, webflow determines the step of a process instance, this flowexecutionkey is always required for every page flow operation to tell webflow where it is based on the above theory, in the next section, we can modify the process as needed to support remote logon.

Server login process modification target

The modified login process activity diagram is as follows:

In the figure, orange indicates the flow node we modified. Here we add a Start Node remotelogin and an end node.
Remotecallbackview: deletes the original loginformview node, viewgenericloginsuccess, and
Renew node (the renew node is deleted because the system does not have this requirement), and then all these nodes are switched
To the remotecallbackview node, because login and display of successful login information should be completed by the client