SAML 2.0 troubleshooting
Summarize
Summary of SAML 2.0 Troubleshooting
This guide outlines troubleshooting steps for SAML 2.0 issues in the Washingtondc release, aimed at helping ServiceNow customers resolve common problems before reaching out for support.
Show less
Key Features
- Error Handling: Addresses specific error messages, such as "is not a function," which may occur due to missing plugin activation across nodes.
- CMS Page Authentication: Provides solutions for enabling SAML authentication on CMS pages by changing configuration settings.
- Redirect Issues: Discusses challenges with redirecting users post-authentication and offers guidance on using proper URL syntax.
- Relay State Management: Explains how to verify the relay state in requests for proper redirection after authentication.
Key Outcomes
By following the outlined troubleshooting steps, ServiceNow customers can effectively diagnose and resolve SAML 2.0 issues, ensuring proper authentication and user redirection. This ultimately enhances the user experience and supports seamless integration with identity providers (IdPs).
Before contacting support, try the troubleshooting solutions available in the knowledge base on Hi.
See the following knowledge base article: KB0540617 '''SAML Error Matrix'''.
| Error or Symptom | Solution |
|---|---|
| Error message: "is not a function." This issue might occur in a multi-node environment. If the plugin does not get activated on all nodes, an error like the following appears: org.mozilla.javascript.EcmaError: [JavaPackage org.opensaml.saml2.core.impl.AuthnRequestBuilder] is not a function. |
This error occurs because the plugin was not active and did not load the .jar file. Therefore, the code appears to be missing. Contact Technical Support to restart nodes that are missing the plugin. |
| SAML does not authenticate users accessing CMS pages. | By default, CMS pages are public and therefore do not require authentication. If you want SAML to authenticate CMS pages, change the view_content.do public page from active=true to active=false. |
| Cannot redirect a user back to a CMS page after SAML authentication. | By default, the SSO integration uses a URL parameter called URI to
control where the user is directed after authentication at the IdP. SSO ignores relative
URLs. For example, SSO cannot redirect users to a /ess relative URL.
Instead, the user has to navigate to a URL such as /nav_to.do?uri=/ess,
which uses deep linking syntax. However, this puts the ESS portal inside the main navigation content IFrame. In other words, the site does not take up the full page, but rather loads as a page in your instance. For more information, see CMS Sites and Single Sign-On. If you change the CMS entry page to make it private by setting view_content.do to active=false, deep linking behavior then requires a customization to the Installation Exit login script. Create a script that looks for the URI portion of the URL and constructs a RelayState URL parameter containing the relative URL path to redirect users after authenticating at the IdP. |
| SAML does not redirect users to the appropriate page after authentication. | Determine if the relay state is passed out to the IdP and then passed back during authentication. You can do this with a browser capable of saving HTTP request headers and POST info, such as Chrome with its built-in developer tools, or Firefox with the add-on called HTTPfox. For Internet Explorer, use a third-party application such as Fiddler. The goal is to watch the requests pass from the client (browser) to the instance, and from the client to the IdP. |