Configuring & Troubleshooting Single Sign-On (SSO)

Single sign-on (SSO) is a secure method for any organization to handle authentication allowing for log in with a single ID to any of several related systems or services. offers a simple process that requires just a few values from your Identity Provider (IdP).

This article offers general instruction on SSO setup with, and provides some basic troubleshooting steps for common SSO issues. 

Please note: SSO is included with any Premium subscription.

Table of Contents

Use these links to troubleshoot SSO depending on the error returned during the configuration process. has partnered with the following SSO Identity Providers, and users should refer to these instructions as applicable:

Using SSO with


This section is for users who are unfamiliar with SSO. If you already understand SSO at a fundamental level, feel free to skip to SSO setup instructions

The most common technology or protocol used for SSO today is SAML2 (Security Assertion Markup Language 2.0), a secure method to authenticate the enterprise's user management system (or IdP) and a third-party service, known as the Service Provider (or SP).

When using SSO, is acting as the SP. The process looks like this:

  1. The user attempts to sign into from the IdP
  2. IdP verifies the user credentials match those from
  3. IdP logs the user into

IDP Values

Your IdP configuration will require an EntityID, Audience Restriction, or Audience URI from any SP providing SSO.

The EntityID is a unique identifier for that defines it as the SP.

The IdP will also require an ACS URL, or a location your IdP will use to send SAML assertions. The SP ( “listens” for requests at this URL.

A WAYFless URL allows you to log in directly to from your IdP, assuming the configuration is correct. It’s useful for testing if your SSO is configured properly by completing the first handshake, and is required for first-time logging into via the IdP. 

SP Values provides you with three values to properly configure SSO: 

  • EntityID (or Audience URI)
  • ACS URL (or Consumer URL)
  • WAYFless URL (an optional parameter).

You will need to provide your IdP EntityID, as well as the URL that will trigger your SSO login.

The SSO Target URL will trigger a login through the user’s IdP. Once the user logs into the IdP, this link redirects to Uptime and authenticates the user.

Finally, we require a valid X.509 IdP Certificate in PEM format for signing by the IdP.

Now that we’ve established some basics, let’s setup SSO.

SSO Setup Instructions


The following instructions assume you have prepared your IdP platform for Single Sign On capabilities, including enabling or installing any SSO related applications specific to your platform. Please note, SSO is not currently supported by our mobile app.

Step One: Register the Application with your IdP

Once you have created the requisite application with your IdP, you will need to fill in several values from

ACS stands for Assertion Control Service, or more generally the Consumer URL, and it’s the URL where SAML assertions are sent. Copy and paste the ACS/Consumer URL into the Single Sign On/ACS URL field of your provider.

Paste the EntityID/Audience URI value into the Audience Restriction or EntityID field of your SSO provider.

If you receive an error related to ACS or Audience URI, it usually means you have copied the URLs incorrectly (either to incorrect fields or with some kind of typo or incorrect entry).


This step also requires you define the extra information the IdP must send with an authenticated login request.

These attributes identify a user in both systems. If a user in the IdP doesn't have a corresponding account user, then one will be created in based on the user's IdP credentials with View Only permissions. Please ensure the following attributes are enabled and sent through your IdP's configuration interface:

  • An SAML user unique identifier, expressed as: NameID / Subject NameID
  • The user's email, expressed as: Email  / User.Email  / eduPersonPrincipalName
  • The user's first name, expressed as: FirstName  / User.FirstName  / givenName
  • The user's last name, expressed as: LastName  / User.LastName  / sn

NOTE: These attributes are case sensitive. You can use the bolded values above to identify these attributes.

The NameID is often an email address that matches the Email/User.Email value.

If you receive an error related to Missing SAML Assertions, it is usually related to the above fields. Double-check the documentation from your provider to ensure you are using the correct values for each attribute.

Please note: any users created via IdP (with no corresponding account user) have View Only permissions with by default.

Step Two: Paste in the SSO Login Details and Certificate of Your IdP, requires an EntityID from the IdP. Additionally, you must supply the URL that triggers the SSO login with your IdP.


The final steps in your SSO configuration are to download the IdP X.509 certificate, and paste it into

Please ensure this certificate is in PEM format.

NOTE: supports SHA 256. Check the box for “Use legacy SHA-1 for signing instead of the recommended SHA-256” if your provider does not support SHA-256.

Creating and Removing Users via IdP

If a user connects to via the IdP, is not existing user of, and if your account has space for the user, that user’s account will be created on sign in. The user’s default permission is set to View Only.

Administrators can alter permissions in their account once a user has successfully logged in. The SAML provider also does not de-provision the user automatically from the IdP and You will need to remove the user manually in both interfaces.

Final Step: Testing

Once you believe you have configured your SSO with, test the process. There are several error screens built into the SSO process that provide some information that may assist you in troubleshooting.

Use the WAYfless URL to complete the initialization SSO “handshake”for each user. The WAYfless URL will connect to via the IdP you configured, and will present any errors this process encounters along the way.

More troubleshooting information is below.

Please note: Successful SSO setup overrides any existing two-factor authentication access settings for your account or users.

Enforce SSO Login


Security policies may require your users to access 3rd party providers exclusively via SSO. The support team can enable Forced SSO Login upon request.

Once activated, all users will be provided a message to login via their Idp only (even if they were previously able to login via username and password). 

Accessing your account is crucial during an outage or interruption with your SSO provider so the owner of the account will always have the ability to bypass the SSO and login using their username and password in case your Idp is down.

SSO for Status Page


It is possible to use SSO to allow external users access to a Status Page, 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

See this article for more details on securing your status page with SSO.

Basic SSO Troubleshooting


We provide an error page each time encounters an SSO error. This section is intended to provide a set of troubleshooting steps you can take depending on the error screen you may encounter during setup.

We first suggest checking that each value from the above steps have been entered correctly within your IdP configuration. The three most common IdP configuration errors when using SSO with are:

  • SAML Assertion Was Not Signed

  • SAML Assertion Missing Username
  • Incorrect SAML Issuer (EntityID)

The sections below detail corrective actions that address these problems in this order. Testing these errors in this order carries a higher likelihood of troubleshooting success.

SAML Assertion Was Not Signed


Verify that you are using a valid X.509 Certificate in PEM format, then paste this certificate into the IdP Certificate field.

Every SAML assertion requires an IdP certificate signature. While it’s possible that the entire response was signed (which is optional), this is insufficient. The assertion itself is what requires a signature. Be sure that your IdP configuration signs the SAML assertion (and not the entire response) with an IdP certificate.  

If you have used the certificate your IdP has provided, and are still seeing this error, contact your IdP to request a properly formatted and current certificate. Once you verify current details, contact for support.

SAML Assertion Missing Username


Verify that your NameID, Email, FirstName and LastName are required attributes, and that they match the user’s details on their Contact screen.

The IdP must send details of the user’s identity as SAML attributes to verify for login. requires four details:

  • An SAML user unique identifier, expressed as: NameID / Subject NameID
  • The user's email, one of: Email  / User.Email  / eduPersonPrincipalName
  • The user's first name, one of: FirstName  / User.FirstName  / givenName
  • The user's last name, one of: LastName  / User.LastName  / sn

Review these fields for accuracy.

If you use OneLogin, you can provide those attributes using the SAML Test Connector (IdP w/attr.)

If the error persists, try turning off encryption to avoid any potential errors with encoding.

Incorrect SAML Issuer (EntityID)


Verify the EntityID matches your IdP.

Once we’ve established the login is correct, and verified our SAML assertion is correctly signed, we can diagnose an incorrect Issuer or EntityID. will check for an appropriate metadata entry for the Issuer specified in the SAML response when checking an assertion. Quite often, due to mismatches with http vs. https (or other typos), the IdP EntityID sent in the SAML assertion doesn’t match what was filled in in the SAML Setup form. Verify that you have provided the correct EntityID before moving on to more testing.

Double-checking these values fixes the most common errors, so please verify the EntityID, User Attributes, and Assertion Signing first before you move on to more advanced troubleshooting.

More Advanced Troubleshooting

These errors are less frequent, but the solutions listed below tend to cover most support issues that were not corrected by the steps above. Begin this section after completing the tests listed in the section above.

Assertion Missing Subject NameID


Uptime requires that a SAML assertion contains a Subject NameID with a valid NameQualifier which uniquely identifies the user. Ideally, this would be the user’s email, the same value as the Username attribute referred to above.

Inside the SAML assertion the code looks like so:

   <saml:NameID SPNameQualifier="xxx"></saml:NameID>

This Subject/NameID node is required by our SAML library.

For a detailed live example, refer to this page.

To fix this error, verify that the Subject and NameID nodes are present in your assertion and contain a proper NameQualifier.

SSO Login Does Not Work from Uptime Form


This error tells us that the IdP is not accepting the login request originating from Uptime’s login form for some reason. It gives us the generic status code urn:oasis:names:tc:SAML:2.0:status:Responder, and no identity assertion.

Microsoft describes this error as “The request could not be performed due to an error on the part of the SAML responder or SAML authority.”

Users should review all relevant fields within the IdP and for accuracy. After a review, please gather all technical data available from your IdP and submit a support ticket to

Final Thoughts

If these steps did not solve your SSO issues, please submit a ticket and be sure to detail the support steps you have already taken so we can better serve you.

SSO/SAML is an elegant tool that compliments enterprise software suites well. Our goal is to provide you with seamless integration into your current workflow.

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