SAML 2.0 troubleshooting

  • Release version: Xanadu
  • Updated August 1, 2024
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of SAML 2.0 Troubleshooting

    This document provides troubleshooting guidance for SAML 2.0 issues within the ServiceNow platform, emphasizing solutions available in the knowledge base before contacting support. It specifically addresses common errors and necessary configurations for SAML authentication, particularly in multi-node environments and CMS pages.

    Show full answer Show less

    Key Features

    • Error Handling: Identifies common errors such as "is not a function" due to plugin activation issues in multi-node setups, requiring node restarts by Technical Support.
    • CMS Page Authentication: Explains that CMS pages are public by default and outlines steps to configure SAML for CMS page authentication by modifying the viewcontent.do setting.
    • Redirect Management: Discusses the limitations of redirecting users back to CMS pages post-authentication, highlighting the need for deep linking syntax and possible custom script modifications to manage RelayState URLs.
    • Monitoring Requests: Advises on tools for monitoring HTTP requests to ensure proper relay state passing during authentication processes.

    Key Outcomes

    By implementing the recommended solutions, ServiceNow customers can effectively troubleshoot SAML 2.0 issues, ensure proper authentication flows, and manage user redirects post-authentication. This enables a smoother user experience and minimizes disruptions in service delivery.

    Before contacting support, try the troubleshooting solutions available in the knowledge base on Hi.

    Note:
    The instance does not support solutions provided by external sites.

    See the following knowledge base article: KB0540617 '''SAML Error Matrix'''.

    Table 1. Other Common Issues
    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.