Single sign-on application

Single sign-on (Single Sign-On, referred to as SSO) is an authentication technology that allows users to use a set of credentials (such as user name and password) to log in to multiple applications or systems without having to log in to each application or system. Log in separately in the system. This technique can improve user experience, reduce the burden of password management, and improve security. In this article, we'll dive into the principles, benefits, and implementation of single sign-on technology.

1. The principle of single sign-on

The principle of single sign-on is based on authentication and authorization. When a user logs in to an application or system, the application or system sends an authentication request to an Identity Provider (IdP for short). The identity provider verifies the user's credentials and sends an authorization token to the application or system. The token contains information about the user's identity, such as username, roles, and permissions. When a user tries to access other applications or systems, those applications or systems send an authentication request to the identity provider and authorize using the previously obtained authorization token. This allows users to seamlessly access resources across multiple applications or systems without requiring a separate login in each application or system.

2. Advantages of single sign-on

Single sign-on technology has many advantages, including:

1. Improve user experience: Single sign-on can reduce the number of user names and passwords that users need to remember, thereby improving user experience. Users only need to log in once to access multiple applications or systems.

2. Reduce the burden of password management: Single sign-on can reduce the number of passwords that users need to manage, thereby reducing the burden of password management. Users only need to remember one password to access multiple applications or systems.

3. Improved security: Single sign-on improves security because users only need to enter their credentials in one place instead of entering them in multiple applications or systems. This reduces the risk of password compromise and increases the reliability of authentication.

4. Reduced costs: Single sign-on reduces costs because it reduces spending on password resets and account management. Additionally, it reduces the need for IT support as users can manage their accounts themselves.

3. Implementation method of single sign-on

Single sign-on can be achieved in a number of ways, including:

1. Cookie-based single sign-on: This method uses cookies to store user authentication information. When a user logs in to an application or system, the application or system stores the user's authentication information in a cookie. When a user tries to access other applications or systems, those applications or systems check the authentication information in the cookie and use that information for authentication and authorization.

2. Token-based single sign-on: This method uses a token to store the user's authentication information. When a user logs into an application or system, the application or system sends an authentication request to the identity provider and obtains an authorization token. When a user tries to access other applications or systems, those applications or systems send an authentication request to the identity provider and authorize using the previously obtained authorization token.

3. SAML-based single sign-on: This method uses Security Assertion Markup Language (SAML for short) to implement single sign-on. When a user logs into an application or system, the application or system sends an authentication request to the identity provider and gets a SAML assertion. When a user tries to access other applications or systems, those applications or systems send an authentication request to the identity provider and use the previously obtained SAML assertion for authorization.

4. Application scenarios of single sign-on

Single sign-on technology can be applied in many scenarios, including:

1. Internal enterprise applications: There may be multiple applications or systems within an enterprise, such as email, CRM, and ERP systems. Using single sign-on technology, employees can seamlessly switch between these applications or systems without having to log in individually in each application or system.

2. Cloud applications: Many businesses use cloud applications such as Office 365 and Salesforce. Using single sign-on technology, employees can seamlessly switch between these applications without having to log in individually in each application.

3. Federated Identity: Many businesses need to share resources with other businesses, such as supply chain partners and customers. Using single sign-on technology, these businesses can implement federated authentication for increased security and convenience.

5. Security considerations of single sign-on

Single sign-on technology can improve security, but there are also some security issues that need to be considered, such as:

1. Security of the identity provider: The identity provider can be targeted by attackers because it stores the user's authentication information. Therefore, identity providers must implement appropriate security measures, such as encryption and access controls, to protect users' authentication information.

2. Token Security: Tokens may be stolen or tampered with by attackers. Therefore, the token must take certain security measures to protect its security, such as encryption, signature, anti-counterfeiting marks, etc. In addition, the use of tokens also needs to follow certain security regulations, for example, do not use tokens in an unsafe network environment, do not disclose tokens to others, etc. If the token is stolen or tampered with, timely measures should be taken, such as revoking the token, changing the password, etc., to protect the security of the user.

The following is the single sign-on authentication process:

  1. The user accesses application A, and application A detects that the user is not logged in, and redirects the user to the authentication center.

  2. The user enters the user name and password in the authentication center for authentication.

  3. The authentication center verifies the user's identity, and if the verification is passed, a token (Token) is generated.

  4. The certificate authority returns the token to application A.

  5. App A sends the token to App B.

  6. Application B sends the token to the authentication authority for verification.

  7. The authentication center verifies the token, and returns an authorization token (Access Token) if the verification is passed.

  8. Application B uses the authorization token to access the authentication center to obtain user information.

  9. The authentication center returns user information to application B.

  10. Application B uses user information to complete user login.

After the user logs in successfully, a session will be established with the SSO authentication center and each subsystem. The session established between the user and the SSO authentication center is called a global session, and the session established between the user and each subsystem is called a local session. After the local session is established, the user accesses The protected resources of the subsystem will no longer pass through the SSO authentication center, and the global session and the local session have the following constraints:

A local session exists, a global session must exist a global session exists, a local session does not necessarily exist a global session is destroyed, and a local session must be destroyed

  • First, the user accesses the protected resources of system 1. When system 1 finds that it is not logged in, it jumps to the SSO authentication center and passes its own parameters to it.

  • The SSO authentication center finds that the user is not logged in, and directs the user to the login page

  • The user enters the username and password and submits them to the SSO authentication center

  • The SSO authentication center verifies user information, creates a session between the user and the SSO authentication center, called a global session, and creates an authorization token at the same time

  • The SSO authentication center takes the token to jump to the original request address (system 1)

  • System 1 gets the token and goes to the SSO authentication center to verify whether the token is valid

  • The SSO authentication center verifies the token and returns a valid, registered system 1 address

  • System 1 uses this token to create a session with the user, called a local session, and returns the protected resource to the user

  • User accesses system 2 protected resources

  • System 2 finds that the user is not logged in, jumps to the SSO authentication center, and passes its own address as a parameter

  • The SSO authentication center finds that the user has logged in, jumps back to the address of system 2, and attaches the token

  • System 2 gets the token and goes to the SSO authentication center to verify whether the token is valid

  • The SSO authentication center verifies the token, returns valid, and registers the system 2 address

  • System 2 uses this token to create a partial session with the user, returning the protected resource to the user

 

The implementation of single sign-on: 1.cookie+redis store the user's id, ip as key, and user account password data information as value in redis; store the user's credentials in the cookie, and return an encrypted message after the user logs in to the system The cookie, and then bring this cookie when the user accesses other systems, check with the sso authentication center, and log in after passing the verification 2, session broadcast When the user logs in to one of the systems, the system server will copy the user's login information to another system server Among them, when the user logs in to another system, the server checks whether there is user information, and if so, it will log in directly. 3. The token uses jwt to generate a string, saves the user information in the string, and returns it through the cookie or address bar Front-end, the front-end stores the received token in the request or url address, each request can carry the token to make a request, when accessing other systems, obtain the token in the address bar or request header, and obtain user information according to the string, you can Put the token in redis to set the validity period

Code

1 Tomcat HTTPS support

Note: When generating the keystore, you must fill in the first name and last name, and you must fill in the domain name.

# 1 生成密钥库
	1)d盘下面建一个文件夹cas,文件夹下面再建一个文件夹keystore(存放证书的地方)
	2)keytool -genkey -v -alias laohan -keyalg RSA -keystore D:\cas\keystore\laohan.keystore 
	输入口令(随便输,自己记得就行)
# 2 从密钥库导出证书
	keytool -export -trustcacerts -alias laohan -file D:/cas/keystore/laohan.cer -keystore D:/cas/keystore/laohan.keystore
# 3 将证书导入到JDK证书库
	keytool -import -trustcacerts -alias laohan -file D:/cas/keystore/laohan.cer -keystore "D:\java\jdk8\jre\lib\security\cacerts"
	密码:laohan
# 4 查看证书列表:
	keytool -list -keystore "D:\java\jdk8\jre\lib\security\cacerts"
# 5 删除证书
	keytool -delete -alias laohan -keystore "D:\java\jdk8\jre\lib\security\cacerts"

 

2 tomcat configuration https support

  • Open the server.xml file under conf under tomcat and put it in for saving. The protocol maximum thread enables ssl

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"  
               maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS"
			   keystoreFile="D:\cas\keystore\laohan.keystore"
			   keystorePass="laohan"/>

 

  • Garbled conf Find the logging.properties file and find the following configuration modification, change UTF-8 to the following GBK

 java.util.logging.ConsoleHandler.encoding = GBK

 

  • Download the war package, put it in the tomcat/webapp directory, and modify the name of the war package to cas.war

 

 

  • Modify username and password

D:\devlop\apache-tomcat-cas\webapps\cas\WEB-INF\classes    如果没有,先启动一下tomcat

找这个文件
application.properties

打开最后一行有用户名密码
cas.authn.accept.users=casuser::Mellon

  https://localhost:8443/cas/login

 

3 Support database password

D:\devlop\apache-tomcat-cas\webapps\cas\WEB-INF\classes    

找这个文件
application.properties

cas.authn.jdbc.query[0].url=jdbc:mysql://localhost:3306/test?serverTimezone=GMT
cas.authn.jdbc.query[0].user=root
cas.authn.jdbc.query[0].password=root
cas.authn.jdbc.query[0].sql=select * from t_cas where username=?
cas.authn.jdbc.query[0].fieldPassword=password
cas.authn.jdbc.query[0].driverClass=com.mysql.cj.jdbc.Driver

cas.tgc.secure=false
cas.serviceRegistry.initFromJson=true

 Put the following packages under D:\devlop\apache-tomcat-cas\webapps\cas\WEB-INF\lib

 4 database configuration t_cas

CREATE TABLE `t_cas` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `username` varchar(255) DEFAULT NULL,
  `password` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;

4 support http

D:\devlop\apache-tomcat-cas\webapps\cas\WEB-INF\classes\services\HTTPSandIMAPS-10000001.json

Add http "serviceId" : "^(https|http|imaps)://.*",

 

4 Springboot integration

1 import dependencies

<dependency>
    <groupId>net.unicon.cas</groupId>
    <artifactId>cas-client-autoconfig-support</artifactId>
    <version>2.3.0-GA</version>
</dependency>

<dependency>
    <groupId>org.jasig.cas.client</groupId>
    <artifactId>cas-client-core</artifactId>
    <version>3.6.2</version>
</dependency>

<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-cas</artifactId>
</dependency>

 <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-thymeleaf</artifactId>
</dependency>

2 application.yml

server:
  port: 7777
cas:
  #  cas服务端地址
  server-url-prefix: https://www.laohan.com:8443/cas
  # 没有带票据或者票据过期,定义的就是服务端的登录地址
  server-login-url: https://www.laohan.com:8443/cas/login
  #  登录成功后回调的地址
  client-host-url: http://www.laohan.com:8888
  #  类型
  validation-type: cas3

3 front page

<!DOCTYPE html>
<html  xmlns:th="http://www.thymeleaf.org">

    <head>
        <meta http-equiv="Content-Type" content="text/html" charset="UTF-8"/>
        <title>风展超市</title>
    </head>
    <body>
        欢迎:&nbsp;&nbsp;<font th:text="${session._const_cas_assertion_.principal.name}"></font>&nbsp;&nbsp;进入风展超市
        <br>
        <a href="http://www.laohan.com:7777" target="_blank">后台系统</a><br>
        <a href="http://www.laohan.com:8888" target="_blank">前台系统</a><br>
        <br><br>
        &nbsp;&nbsp; <a href="/logout">安全退出</a>
	</body>
</html>

4 backend

@Controller
@EnableCasClient
public class IndexController {
    /**
     * 网站根目录请求
     * @return
     */
    @RequestMapping("/")
    public ModelAndView root(){
        //它可以返回前端页面
        ModelAndView modelAndView = new ModelAndView();
        modelAndView.setViewName("index");
        return modelAndView;
    }

    /**
     * 退出
     * @return
     */
    @RequestMapping("/logout")
    public String logout(){
        return "redirect:https://www.laohan.com:8443/cas/logout";
    }
}

5 Configure two identical servers with different ports

Guess you like

Origin blog.csdn.net/weixin_46894136/article/details/131033714