Overview
This document introduces how to troubleshoot single sign-on (SSO) failures according to your actual situations.
Procedure
SSO Setting
1. Frontend SSO: You can check whether the frontend can be directly accessed. If so, the single point request is successful.
2. Backend single point: You can check whether Set-Cookie exists in the request. If so, the request is usually normal.
If the frontend or backend SSO request is normal but SSO still fails, you need to check whether the environment is normal.
Browser Restriction
Switch to another browser with a different kernel to check whether SSo is successful. If so, the original browser causes the failure. You are advised to clear the cache before testing SSO to avoid wrong judgments.
Project Setting
Security Protection
1. You possibly cannot access reports embedded through the cross-domain iframe. To resolve this, simply disable Click Attack Protection under Advanced Setting in the Security Headers area.
2. If cross-domain errors are reported during SSO, you can disable Prevent Content Sniffing Attack under Advanced Setting in the Security Headers area.
User Account Anomaly
1. Platform users are disabled.
If platform users are disabled, the frontend SSO is abnormal, not affecting the backend SSO.
2. The username or password is wrong.
The system username should be consistent with the platform username.
If the username is in Chinese, or the password contains special characters, they need to be encoded through the encodeURIComponent() method.
Code Problem
1. Frontend SSO: Check whether the address has the following problems:
https and http are misspelled as each other.
The project name webroot is not changed to the actual project name.
The network is inaccessible because of intercepted requests, misspelled IP address/port number, or decision-making platform security restrictions.
You can directly access the SSO address in your browser and check the returned value.
2. Backend SSO: Take CAS SSO as an example. SSO may fail if the actual address is not used in the web.xml file.
CAS cluster: Since the session cannot be maintained in a cluster environment, a standalone CAS solution used in this environment may lead to SSO failures. You can check whether cas_login_ticket exists in the cookie after login. If so, a cluster CAS solution is used in this environment. If not, a standalone CAS solution is used in this environment.
CAS logout: The CAS server sends a request to go offline.Then the CAS-related filter in the project intercepts and judges whether the request is a logout one. If so, the filter works with sessionlistener to clear the token related information in the session. For the locally generated certificates and domain names, the JDK cannot be parsed and trusted, and the request fails to be sent. You need to import the certificate into the JDK used by the server.
JAR package missing: You need to check whether the JAR package is complete.
System Limitation
You need to check whether system settings have limitations, such as whitelist-based limitations.
