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.
Uptime.com 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 Uptime.com account (including our Mobile App), as well as specifically configured Status Pages. For Status Page-specific information, see our article on Securing Your Uptime.com 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.
- Uptime.com SSO At A Glance
- Special Settings
- General Troubleshooting
- Final Thoughts
Manage access to an Uptime.com account from your Identity Provider.
Maintain security best practices with SAML 2.0 authentication.
Auto-provision Uptime.com users from your Identity Provider.
This guide assumes that you have an Uptime.com user account with Administrator access, in order to configure the SAML SSO settings page.
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, Uptime.com is the SP. Below is a brief overview, with more detailed information to follow in the Configuration section.
Uptime.com’s SSO configuration will require an exchange of information between both ends.
The IdP will require:
- The Uptime.com EntityID (sometimes called an Audience Restriction or Audience URI) which identifies Uptime.com as the SP
- ACS URL destination for the IdP to send the required SAML assertions
Uptime.com 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 Uptime.com SAML SSO integration relies on sharing entity-specific identifies and URL destinations from both Uptime.com 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:
- Create the Uptime.com 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 Uptime.com. These values are the EntityID/Audience URI, as well as the ACS/Consumer URL. The EntityID identifies Uptime.com 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.
- 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 Uptime.com from the IdP-side, but there isn’t a matching Uptime.com account user, then one will be created automatically with View Only permissions. For more information, see the section User Management via Identity Provider below.
- Return IdP values to the Uptime.com SSO settings:
Once the IdP application is configured, return to the Uptime.com 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: Uptime.com 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 Uptime.com 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 Uptime.com Status Page.
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 Uptime.com 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 Uptime.com. If you have any questions, please contact email@example.com.
Okta is one of the most popular Identity Providers, and is frequently used by Uptime.com 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 Uptime.com 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.
Azure Active Directory (Azure AD or AAD) 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 Uptime.com Service Provider SAML Metadata XML file, and use it to import settings directly into Active Directory
- Edit the Claim Rules for Uptime.com and add a new rule.
- Map the following LDAP attributes to outgoing claim types:
- Fill in the Uptime.com SSO Setup form with the appropriate Active Directory details for:
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.
Once the SSO configuration has been completed in both the IdP and the Uptime.com 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 Uptime.com application in the IdP) is as follows:
- 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).
- Successful login at the IdP portal will redirect to the Uptime.com login portal. Login with both username and password to authenticate the Uptime.com user on first login.
- Successful login at the Uptime.com portal will redirect to the Uptime.com account (or Status Page).
- Close the browser and re-open a new one (or clear cache and cookies for a fresh session), and go to the required Uptime.com login portal (either
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.
As described in Step 2 of Configuring your SSO application above, it is possible to create or provision a user to the Uptime.com SAML application without a matching Uptime.com 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 Uptime.com 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 Uptime.com 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.
Security policies may require your users to access third-party providers exclusively via SSO. Please email firstname.lastname@example.org 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.
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 Uptime.com Status Page.
Our Mobile App supports login via SSO in the exact same manner as if logging in to an Uptime.com account via the web UI.
For more information, see our article on Getting Started with the Uptime.com Mobile App.
Configuring Single Sign-On (SSO) can be a complex process with multiple points of failure. Uptime.com 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 Uptime.com 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.
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. Uptime.com is no exception.
Our goal is uninterrupted workflow and application switching, so please reach out to email@example.com 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!