Configuring Single Sign-On (SSO) for

Single Sign-On (SSO) is a secure method for any organization to manage user access and authentication from a single Identity Provider (IdP). SSO allows for a single set of credentials to be shared across multiple applications or services. supports the SAML 2.0 authentication protocol with Identity Providers like Okta, OneLogin, AWS, Azure Active Directory, and others. SSO is included depending on your subscription, and can be applied to both the main account (including our Mobile App), as well as specifically configured Status Pages. For Status Page-specific information, see our article on Securing Your Status Page

This article will cover requirements for initial setup, configuration overviews, as well as special settings and use cases. For in-depth troubleshooting assistance, see our article Troubleshooting Single Sign-On (SSO) Errors.

Table of Contents SSO At A Glance

Manage access to an account from your Identity Provider.

Maintain security best practices with SAML 2.0 authentication.

Auto-provision users from your Identity Provider.



This guide assumes that you have an user account with Administrator access, in order to configure the SAML SSO settings page

To review if Single Sign-On is a part of your subscription, review your account usage. For more questions about accessing or enabling SSO, please contact




SAML 2.0 is an industry standard authentication protocol which connects an organization’s Identity Provider (IdP) with a third-party service (Service Provider, or SP). In this case, is the SP. Below is a brief overview, with more detailed information to follow in the Configuration section.’s SSO configuration will require an exchange of information between both ends.

The IdP will require:

  • The EntityID (sometimes called an Audience Restriction or Audience URI) which identifies as the SP
  • ACS URL destination for the IdP to send the required SAML assertions will require:

  • The IdP EntityID (or Audience Restriction/URI)
  • The IdP’s SSO Target URL, which will trigger the login via IdP portal
  • The IdP application’s X.509 Certificate in PEM forma

Please note: Naming conventions for these items may vary depending on the specific Identity Provider.



The SAML SSO integration relies on sharing entity-specific identifies and URL destinations from both and the IdP to send and authenticate the standardized SAML assertions, which will define the specific user attempting to login. 

Configuration will follow these steps:

  1. Create the Application with your IdP:

    Once you’ve created the requisite application with your IdP, you will need to fill out the application with several values from These values are the EntityID/Audience URI, as well as the ACS/Consumer URL. The EntityID identifies as the Service Provider (SP) and the ACS URL is the destination for the IdP to send its SAML assertions for authentication.


    Please note: Errors related to EntityIDs or ACS URLs usually mean that the URLs were copied incorrectly, or pasted into the wrong fields.

  2. Fill in the SAML Assertion fields:

    The SAML Assertion fields are how the user is defined in both systems, according to the SAML 2.0 protocol. You must ensure the following attributes are enabled and sent through your IdP’s configuration interface:

         - A SAML user unique identifier, expressed as NameID or Subject NameID
         - The user’s email, expressed as Email or User.Email or eduPersonPrincipalName
         - The user’s first name, expressed as FirstName or User.FirstName or givenName
         - The user’s last name, expressed as LastName or User.LastName or sn

    (example SAML Assertions above from Okta)

    Please note: These SAML assertions are the most common point of error in SSO configuration, so please confirm with the corresponding IdP documentation these are setup correctly. Below are a few additional notes:
         - These attributes are case sensitive, so confirm them against the expressed values above.
         - In most cases the NameID value is an email address that matches the Email value.
         - if a user is provisioned to access from the IdP-side, but there isn’t a matching account user, then one will be created automatically with View Only permissions. For more information, see the section User Management via Identity Provider below.

  3. Return IdP values to the SSO settings:

    Once the IdP application is configured, return to the SSO settings page and paste the following information to the corresponding fields:
         - The IdP's EntityID / Issuer ID URL
         - The IdP's SSO Target URL
         - The IdP application's X.509 Certificate (in PEM format)


    Please note: supports SHA-256. If your IdP doesn’t support SHA-256, then please select the checkbox “Use Legacy SHA-1 for signing in instead of the recommended SHA-256”. 

    When completed, click Save.

Please note: For IdP-specific instructions, see the corresponding section below.

Beyond using SSO for main account access, Status Pages set to External Users access mode can control access using the same steps via a completely separate application within the IdP. For more information, see our article Securing Your Status Page.

Identity Provider-Specific Overviews


We use SAML 2.0 which is an industry standard, and as such there are a variety of Identity Providers. We provide instructions for the most common IdPs, such as Okta, OneLogin, AWS, and Azure AD. 

In general, admin access to both and the IdP management accounts will be required to complete this configuration. Specific IdP permissions will be noted below where available.

Please note: these instructions are advisory only, and the corresponding settings, UI, or steps can be changed by the third party IdP at any time without consultation with If you have any questions, please contact



Okta is one of the most popular Identity Providers, and is frequently used by customers. 

Okta has the following requirement before you can complete setup:

  • Administrator access to the organization’s Okta account to manage applications, permissions, and user provisioning.

For more information, including Okta-specific screenshots and guidance, see our article Configuring SSO with Okta.



OneLogin is another popular Identity Provider frequently used by clients. 

For more information, including OneLogin-specific screenshots and guidance, see our article Configuring SSO with OneLogin.



AWS SSO is another popular and frequently used Identity Provider. 

AWS has the following requirement before you can complete setup:

  • Access to the AWS SSO console under an account with proper permissions to manage applications.

For more information, including AWS SSO-specific screenshots and guidance, see our article Configuring SSO with AWS.

Microsoft Entra ID (formerly Azure Active Directory)


Microsoft Entra ID (formerly Azure Active Directory) is another popular, but complex and frequently varied Identity Provider. As such, we have a limited scope of support for SSO configuration. However, we do have some tips, which are also linked in our SAML SSO Setup page

  • Download the Service Provider SAML Metadata XML file, and use it to import settings directly into Active Directory
  • Edit the Claim Rules for and add a new rule.
  • Map the following LDAP attributes to outgoing claim types:
    • E-Mail-Addresses -> Name ID
    • E-Mail-Addresses -> E-Mail Address
    • Given-Name -> Given Name
    • Surname -> Surname
  • Fill in the SSO Setup form with the appropriate Entra ID details for:
    • EntityID/Issuer ID
    • SSO Target URL
    • IdP X.509 Certificate (PEM Format)
  • Select the checkbox “Don’t digitally sign SAML AuthN Login requests (required by Azure)” at the bottom of the SSO Setup page form.

For more information, see Microsoft’s support article on Configuring Azure Active Directory as Your IdP.

Testing Your SSO Configuration


Once the SSO configuration has been completed in both the IdP and the SSO settings page, it’s time to test the configuration URLs and authenticate this integration using the WAYFless URL. 

This URL is a trigger for the “handshake” between the two systems, who until now haven’t actually authenticated to each other. 

The entire SSO configuration testing process (which assumes that the user has been properly provisioned and assigned to the application in the IdP) is as follows:

  1. Copy + paste the WAYFless URL into their browser (sometimes a guest or private browser is helpful). This mandatory step will trigger the IdP portal login and begin the “handshake” authentication process (if there’s an error at this stage, that means something is incorrect about the configuration).
  2. Successful login at the IdP portal will redirect to the login portal. Login with both username and password to authenticate the user on first login.
  3. Successful login at the portal will redirect to the account (or Status Page).
  4. Close the browser and re-open a new one (or clear cache and cookies for a fresh session), and go to the required login portal (either or insert_status_page_url/login). Fill in the username field only, and hit Login. This will redirect to the IdP login portal, and confirm that the SSO configuration is working as expected.

Please note: the WAYFless URL and use of both username and password are required for initial login only, to complete the “handshake” and authenticate both ends of the connection. This will be needed if you are not logged into your IDP, Subsequent logins will only require the username.

Special Settings

User Management via Identity Provider


As described in Step 2 of Configuring your SSO application above, it is possible to create or provision a user to the SAML application without a matching user account. 

In this scenario, a user account will be created with a default permission level of View Only. Administrators can alter permissions for such users once they have successfully logged in to the account. 

While the IdP can provision users in this manner, it cannot de-provision them in the same way. That must be done by an Administrator from the account to manually remove them.

Please note: Automatically provisioned users will only be created if there are available user seats in the account. To double check your user seat availability, see Account Usage.


Enforce Login via SSO


Security policies may require your users to access third-party providers exclusively via SSO. Please email to enable Forced SSO login for the entire account

Once this setting is activated, all users will be provided a message to login via their IdP only, even if they were previously able to login with normal username and password.

Please note: Account owners can always login via normal username and password, in case of an IdP-sided outage.

We also provide an option to Disable SSO email invites. This will disable sending email invites to users that can only login via SSO. Disabling regular login and enabling SSO on the account is required, however, for this to be activated. 


Status Page Login via SSO


It is possible to use SSO to allow external users access to a Status Page (depending on subscription), but a separate application in your IdP must be created for this purpose.

To view any status page secured via SSO, users must be allocated through this separate application. This secondary application does not allow for access to the main account.

For more information and detailed instructions, see our support article on Securing your Status Page.

Mobile App Login via SSO


Our Mobile App supports login via SSO in the exact same manner as if logging in to an account via the web UI.

For more information, see our article on Getting Started with the Mobile App.

General Troubleshooting


Configuring Single Sign-On (SSO) can be a complex process with multiple points of failure. provides an error page as well as specific error code message when an SSO login attempt fails. 

The most common errors are due to misconfigured or unsaved settings in the SAML SSO settings page, or incorrect SAML assertions on the IdP-side. 

For in-depth troubleshooting help and corrective steps, see our article Troubleshooting SSO Errors.

Final Thoughts


Single Sign-On via SAML 2.0 is an elegant tool which allows for seamless integration of existing security protocols and practices among all your organizations’ third-party services. is no exception. 

Our goal is uninterrupted workflow and application switching, so please reach out to if you run into any issues in the configuration or troubleshooting process. Be sure to outline in the ticket what you’ve tried and any error messages you receive!

Was this article helpful?
1 out of 5 found this helpful



Article is closed for comments.

Have more questions?
Submit a request
Share it, if you like it.