Article directory
1. Introduction to CAS
There are many ways to implement SSO. The relatively simple and feasible ones are generally the above two plus CAS. Generally, if you want to implement SSO between multiple systems in an enterprise, the recommended way is the CAS that will be introduced today, Central Authentication Service , a central authentication service.
The CAS scheme mainly includes the following two parts:
- CAS Server, as the center of authentication services, needs to be deployed separately;
- CAS Client, refers to each system that requires single sign-on, and officially supports 10+ types of clients;
The following is a complete CAS SSO process for multiple systems:
SSO login process
- When the browser first accesses system 1, system 1 determines that it is not logged in (no local session), so it redirects to the SSO authentication center, and the authentication center does not have the current global session of the browser, so it returns the login page to the browser to request login;
- After the browser logs in successfully, the authentication center will retain the global session of the browser user. When the user subsequently authenticates with the SSO authentication center through other systems, the JSESSIONID of the global session will be brought to the authentication center, and the authentication center will know the user Currently has a global session and is logged in;
- The authentication center creates a temporary authorization token and gives it to system 1. This token has a time validity period and can only be used once. After system 1 receives the token, it cannot determine whether it has been forged, so it needs to request the authentication center to check again. test. After receiving a successful authentication reply, system 1 will create a partial session for the current user. Before the partial session expires, the user does not need to go to the authentication center for authentication again when accessing system 1 again;
- If the browser user accesses other system 2 at this time, system 2 determines that he is not logged in (no local session), so it redirects to the SSO authentication center with the global session JSESSIONID saved in the second step, and the authentication center determines that the user has logged in. Therefore, a temporary authorization token is created and given to system 2, and system 2 proceeds to step 3.
Then there is a process for SSO logout:
SSO logout process
2. Implementation of CAS
2.1 CAS Server
The server has a ready-made war package available at the official github address, just download it directly. Since the latest version of the dependency management tool has been changed from maven to gradle, I am more familiar with maven, so I did not choose the latest version, but Use version 5.3 . After downloading, unzip it.
Execute the packaging command in the decompressed directory build.cmd package, and you can see the war package in the target directory. Put the cas.war in the local tomcat webapps directory and start tomcat.
At this point, when you visit the local tomcat service, http://localhost:8080/casyou can see the login page.
CAS Server login page
The default account password is: casuser/Mellon. The password is configured in the following directory WEB-INF\classes\application.properties. If you need to change the password, you need to modify the content of the following files after decompression in tomcat.
##
# CAS Authentication Credentials
#
cas.authn.accept.users=casuser::Mellon
By default, the communication protocol between client and server is https. If you want to run through the local http protocol environment, you need to turn off the default https service.
在WEB-INF\classes\application.properties的最后添加如下配置内容：
cas.tgc.secure=false
cas.serviceRegistry.initFromJson=true
在WEB-INF\classes\services\HTTPSandIMAPS-10000001.json中修改内容：
"serviceId" : "^(https|http|imaps)://.*"
Then restart the CAS Server.
2.2 CAS Client
<dependency>
<groupId>net.unicon.cas</groupId>
<artifactId>cas-client-autoconfig-support</artifactId>
<version>2.1.0-GA</version>
</dependency>
@EnableCasClient
@SpringBootApplication
public class SsoClient1Application {
public static void main(String[] args) {
SpringApplication.run(SsoClient1Application.class, args);
}
}
@RestController
public class LoginClient1Controller {
@GetMapping("/getUserInfo")
public String getUserInfo(){
return "user1";
}
}
server.port=8081
cas.server-url-prefix=http://localhost:8080/cas
cas.server-login-url=http://localhost:8080/cas/login
cas.client-host-url=http://localhost:8081
cas.validation-type=cas3
The above is the entire content of client1, and client2 is basically similar, so I won’t repeat them here.
After starting the two clients, accessing any of their interfaces will be redirected to the login page of the CAS Server. As long as one login is completed, any interface of the two systems can be accessed directly without logging in again, thus realizing SSO.
So what is the difference between CAS and the OAuth2.0 protocol we are familiar with?
- OAuth2 is a three-party authorization protocol that allows users to authorize through trusted applications without providing account passwords, so that their clients can access resources within the scope of authority.
- CAS is a central authentication service protocol, a framework for implementing SSO single sign-on based on tickets, and provides a reliable single sign-on solution for Web application systems.
- The single sign-on of CAS is to ensure the security of user resources on the client side, while OAuth2 is to ensure the security of user resources on the server side.
The final information that the CAS client needs to obtain is whether this user has permission to access my (CAS client) resources; the final information obtained by OAuth2 is whether my (oauth2 service provider) user’s resources can allow you ( oauth2 client) access.
Therefore, a unified account password is required for identity authentication, using CAS; third-party services need to be authorized to use our resources, using OAuth2
Finally, CAS not only supports the CAS protocol in the SSO implementation scheme, but also supports OAuth2, SAML and other protocols. For details, please refer to the official documents.
reference documents