Continuing with the previous article, this article focuses on CAS application examples and related source code parsing
CAS source code parsing -CAS login commonly used classes
The corresponding file directory can be found in Cas-Server-Core according to login-webflow. XML. The source code can be changed as needed. Such as: landing cas need to provide a variety of ways (certificate landing, verification code calibration, SMS, etc.) into the AuthenticationViaFormAction cas login to submit. You can make conditional judgments on the way to log in.
CAS source code parsing – data access check one
When CAS logs in, it needs to access the database to check whether the user and password are correct. Can through the WEB – INF/deployerConfigContext. The XML file configuration database connection and access the corresponding Java classes to change the source code, for complex log in check. Such as: login when the user password validity check, user login times too many, the user does not exist and so on.
CAS source code parsing – data access check two
Data access: Password, login times, validity period, user permissions can be verified. For the verification process needs to be reminded to the front page according to different situations. So you can customize the exception according to the situation, through the exception to return to the front page, to remind.
CAS source resolution – Specifies the default access address
When CAS logs in to access the application, the interface address is:http://casip:casport/cas/login/? Service = destination address. After CAS login successfully, enter the target address. But some users require no matter the user access to any address, must be based on the user authority, default access to a fixed address. You can do this by changing the class’s methods.
You can set the address where the user logs in by default in this class. org.jasig.cas.authentication.principal.SimpleWebApplicationServiceImpl
Application scenarios of CAS single sign-on:
The SpringMVC service implements CAS single sign-on
VUE + SpringBoot integrated CAS
Change the SpringBoot configuration file as follows:
Change the Vue front-end configuration file as follows: Routing configuration change:
Nginx proxies log in to the integration CAS
1. Step 4: When the user logs in successfully, he/she needs to access CAS Server. Since CAS Server passes through a node via NGINX agent, CAS can be accessed by setting both primary and secondary Settings or setting CAS Server integrated Redis implementation service ticket redisSession share. Nginx can be configured as IP-hash or polling. (CAS cannot set IP-hash if ticket cluster sharing is not set)
2. Step 6: Random access to CAS-Client will be provided after the successful login of CAS in Step 5. When the Cas-client login is authenticated, a ticket check is sent to the Cas-server. It may be configured according to the following different scenarios. Such as:
1) The external service of Nginx is not in the same network segment as the internal service. CAS Client cannot access the external network.
1, CAS primary and secondary configuration, access the CAS-SERVER standby service. 2. CAS integrated Ticket Redis
2) CAS does not cluster and set IP-hash, because CAS server1 is logged in, but CAS server2 is not logged in, so the login authentication fails.
Solution: CAS use NGINX method, 1 use primary and standby, 2, CAS cluster Redis.
CAS integration redis
Change the web-inf \spring-configuration\ticketRegistry. XML file:
Web application integration with Redis Session-Spring MVC
In the case of Spring MVC the configuration file is as follows:
Usage scenario: 1. Front and rear end separation is often used. 3. Integration configuration in case of Spring MVC. 4. Redis configuration is used in case of front and rear end separation.
Web Application Integration Redis Session- Front End Separation
After logging in successfully, save Session information to Redis or use SpringBoot Redis Session’s own scanning method to implement. For a Vue page in the case of multiple microservices, the need to use. Otherwise, the Vue page will loop endlessly to the home page when logging in.
CAS provides a logon – free interface
There are two ways to achieve login-free application integration CAS:
1. Provide login-free interface on CAS service.
1) Configure a new interface address via web.xml.
2) Obtain the interface parameters and encrypt the ciphertext. After decryption, obtain the user name, password,
3) Log in free by loading login-webflow. XML.
Advantages: After CAS transformation, services using CAS single sign-on do not need to be transformed.
2. Provide the login address on the system service.
1) The system provides a login free address.
2) CAS interceptor opens this interface.
Disadvantages: can only achieve the current application login free, if multiple applications use CAS at the same time, need to make changes to multiple applications.
CAS single point exit
If there are multiple CAS-Client services, call the Session exit interface of all CAS-Client services. Then access the CasLogout interface address.
Summary: Common problems of CAS single login: 1, CAS default login address. 2. Common problems of ticket login failure. Scenario: Nginx agent production environment. Nginx main and backup setup. CAS integrates the Redis situation. Login timeout. Account configuration error. Front and rear end separation case Interceptor caused landing failure.