401 error and infinite loop when loading CMS URL after ExternalAuthentication SSO using SiteMinderIssue <!-- div.margin{ padding: 10px 40px 40px 30px; } table.tocTable{ border: 1px solid; border-color:#E0E0E0; background-color: rgb(245, 245, 245); padding-top: .6em; padding-bottom: .6em; padding-left: .9em; padding-right: .6em; } table.noteTable{ border:1px solid; border-color:#E0E0E0; background-color: rgb(245, 245, 245); width: 100%; border-spacing:2; } table.internalTable{ border:1px solid; border-color:#E0E0E0; background-color: rgb(245, 245, 245); width: 100%; border-spacing:0; } .sp td{ border-bottom: 1px solid; border-right: 1px solid; border-color:#E0E0E0; background-color: #ffffff; height: 20px; padding-top: .5em; padding-bottom: .5em; padding-left: .5em; padding-right: .5em; } .sphr td{ border-right: 1px solid; border-bottom: 1px solid; border-color:#E0E0E0; background-color: rgb(245, 245, 245); padding-top: .5em; padding-bottom: .5em; padding-left: .5em; padding-right: .5em; height: 20px; } .title { color: #D1232B; font-weight:; font-size:25px; } .hd1{ color: #D1232B; font-weight:; font-size:18px; } .hd2{ color: #646464; font-weight:bold; font-size:16px; } .hd3{ color: #7a7a7a; font-weight:; font-size:16 px; text-decoration:; } .hd4{ color: #000000; font-weight:bold; font-size:14 px; text-decoration:; } --> 401 error and infinite loop when loading CMS URL after ExternalAuthentication SSO using SiteMinder ProblemThere is a 401 error and infinite looping when loading a CMS site after ExternalAuthentication SSO using SiteMinder. SymptomsLaunching a CMS site URL (for example, https://<instance>.service-now.com/ess) when the instance is integrated with SSO using SiteMinder can cause an infinite loop and 401 unauthorized errors within the Chrome Developer Tool Console: CauseThis issue only occurs when SAML (glide.authenticate.external) is enabled and the specific configuration below is in place: System property glide.authenticate.failed_requirement_redirect is set to the instance URL:For example: https://<instance>.service-now.comProduct documentation reference: https://docs.servicenow.com/csh?topicname=r_ForcingLoginViaSSOOnly.html&version=latest The view_content Public Pages [sys_public] record is set to false.This makes CMS private and not available to "guest" requiring authentication and login.Product documentation reference: https://docs.servicenow.com/ For the above scenario, the glide.authenticate.failed_requirement_redirect property needs to be set to a static page; otherwise, it goes into the authentication loop. Warning: The glide.authenticate.failed_requirement_redirect property should be set to the URL of the IdP login page or a company portal page outside of ServiceNow. Resolution This issue can be resolved using these steps: Set view_content to true.Set glide.authenticate.failed_requirement_redirect to the URL of the IdP login page. Another possible solution is to use this configuration: Set the glide.authenticate.failed_requirement_redirect system property to the URL of the IdP login page or a company portal page outside of ServiceNow.Add the glide.ui.rotate_sessions system property.Product documentation reference: https://docs.servicenow.com/csh?topicname=c_HighSecuritySettings.html&version=latest Rotate HTTP session identifiers to reduce security vulnerabilities.See: https://www.owasp.org/index.php/Session_Management#Rotate_Session_IdentifiersSet Default: Yes Note: If you are using the SAML 2.0 plugin for single sign-on authentication, set this feature to false. Otherwise, it interferes with the session information sharing that takes place between ServiceNow and the identity provider.