SSO

Enable single sign-on with SAML 2.0 compatible identity providers including Okta, Google, OneLogin, Auth0, Azure, and more.

Overview

Rootly supports SAML 2.0 single sign-on with any compatible identity provider. Once SSO is enabled, users authenticate through your IdP and are automatically provisioned via Just-In-Time (JIT) provisioning, or pre-provisioned via SCIM.

Both SP-initiated (login from Rootly) and IdP-initiated (login from your IdP dashboard tile) flows are supported.

You can setup this integration as a logged in admin user in the integrations page:

Before You Begin

Before configuring your identity provider, collect the values below to use during setup. You’ll also need to understand how Rootly maps SAML attributes and what certificate format is required.

Service Provider Details

When configuring Rootly as a SAML service provider in your identity provider, use the following values:

Field	Value
ACS URL	https://rootly.com/users/saml/auth
Entity ID / Audience URI	https://rootly.com/users/saml/metadata
SP Metadata URL	https://rootly.com/users/saml/metadata
Name ID Format	urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
Binding	HTTP-POST

The SP metadata endpoint accepts an optional idp_entity_id query parameter when your organization has multiple SSO configurations: https://rootly.com/users/saml/metadata?idp_entity_id=<your-idp-entity-id>.

SAML Attribute Mapping

Rootly reads the following attributes from the SAML assertion. Email is taken from the NameID element and is required. All other attributes are optional but recommended for accurate JIT provisioning.

Rootly field	SAML attribute
Email	NameID (emailAddress format)
First name	name.givenName
Last name	name.familyName
Preferred name	displayName
Phone number	phoneNumbers.work

Attribute names are case-sensitive. Use your IdP’s attribute mapping feature to rename attributes to exactly match the names above.

Certificate Requirements

Rootly requires a PEM-encoded X.509 certificate from your IdP to validate SAML assertions.

• Must be in PEM format with -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- headers
• Must not be expired — Rootly rejects expired certificates at save time
• Must match the certificate your IdP uses to sign SAML responses

Rootly monitors certificate expiry and sends warning emails automatically. Rotate the certificate before it expires to avoid locking out all users.

Identity Providers

Rootly is compatible with any SAML 2.0 identity provider. Setup instructions for common providers are below.

Okta

Rootly is available as a pre-built application in the Okta Integration Network. Follow the steps below to install it and connect it to Rootly.

1. Find the Rootly app in Okta

   Navigate to Applications in your Okta admin console.

   

   Search for Rootly and click Add.

   

   

   Select SAML 2.0 as the sign-on method.

2. Retrieve setup instructions

   Once the app is created, navigate to Applications > Rootly and click View Setup Instructions.

   
3. Configure Rootly

   Copy the fields from the setup instructions into the Rootly SSO configuration:

   Okta field	Rootly field
   Identity Provider Issuer	Identity Provider ID
   Identity Provider Single Sign-On URL	Identity Login URL
   X.509 Certificate	IdP Cert

   

Google Workspace

Google Workspace supports SAML SSO via custom app configuration in the Google Admin Console. Follow the steps below — pay close attention to the Signed Response requirement, which Google disables by default.

1. Create a custom SAML app

   Navigate to the Google Admin Console and create a new custom SAML app.

   

   

   

   

   
2. Enable Signed Response and activate the app

   Make sure Signed Response is checked — this is required. Rootly validates the SAML response signature, and Google does not sign responses by default.

   Set the app to ON for everyone (or for the relevant org unit).

   
3. Configure attribute mapping

   Add the following attribute mappings so Rootly receives user profile data during JIT provisioning:

   Google Workspace field	SAML attribute
   Primary email	NameID
   First name	name.givenName
   Last name	name.familyName

   
4. Configure Rootly

   Switch to Rootly. Use the TEST SAML LOGIN button to retrieve the Identity Login URL.

   

   

OneLogin

Rootly is available in the OneLogin Application Store. Install it and copy the IdP values into Rootly to complete the connection.

1. Install the Rootly app

   Browse the Applications Store in OneLogin and install Rootly.

   
2. Configure Rootly

   Copy the following fields from OneLogin into Rootly:

   OneLogin field	Rootly field
   Issuer URL	Identity Provider ID
   SAML 2.0 Endpoint	Identity Login URL
   X.509 Certificate (Certificate > View Details)	IdP Cert

   

Auth0

Follow the Auth0 marketplace integration guide:

View the Auth0 Marketplace integration guide

Microsoft Entra (Azure AD)

Install the SSO integration through the Azure Marketplace:

• Install Rootly from the Azure Marketplace
• Follow the Microsoft setup tutorial

Rippling

Integrate Rippling SSO + SCIM in one click:

Install Rootly from the Rippling App Shop

Keycloak

Keycloak is an open-source identity and access management solution. Unlike managed IdPs, it requires manual SAML client configuration. Follow the steps below to create and configure a SAML client in your Keycloak realm.

Prerequisites

• Access to Keycloak admin console
• Keycloak realm configured
• User accounts with email attributes set and verified

1. Create a SAML client

   1. Navigate to Clients in the Keycloak admin console.
   2. Click Create Client and select SAML as the client type.
   3. Set Client ID to: https://rootly.com/users/saml/metadata
   4. Click Next and Save.
2. Configure client settings

   Navigate to the Settings tab and configure:

   Access Settings

   • Valid redirect URIs: https://rootly.com/* and https://rootly.com/users/saml/auth
   • Master SAML Processing URL: https://rootly.com/users/saml/auth

   SAML Capabilities

   • Name ID format: email
   • Force POST binding: On
   • Include AuthnStatement: On

   Signature and Encryption

   • Sign documents: On
   • Sign assertions: On
   • Signature algorithm: RSA_SHA256
   • SAML signature key name: KEY_ID
   • Canonicalization method: EXCLUSIVE
   • Client signature required: Off
   • Encrypt assertions: Off
3. Configure Name ID mapper

   1. Go to Client scopes > Dedicated scopes > Mappers.
   2. Create an Email mapper:
      • Mapper type: User Attribute Mapper For NameID
      • Name ID Format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
      • User Attribute: email
4. Configure Rootly

   Collect the certificate from Realm Settings > Keys > RS256 > Certificate and enter the following into Rootly:

   Rootly field	Keycloak value
   Identity Provider ID	https://your-keycloak-host/realms/your-realm
   Identity Login URL	https://your-keycloak-host/realms/your-realm/protocol/saml
   Identity Logout URL	https://your-keycloak-host/realms/your-realm/protocol/saml (optional)
   IdP Cert	RS256 certificate wrapped in PEM headers
   Domain Name	Your domain (e.g. company.com)

JumpCloud

Rootly is available as a pre-built SSO application in JumpCloud. The steps below cover SSO setup and optionally configuring SCIM group provisioning to assign Rootly roles based on JumpCloud group membership.

1. Create the Rootly SSO application

   Navigate to SSO Applications in the JumpCloud admin console.

   

   Click Add New Application.

   

   Search for and install the Rootly application.

   
2. Configure the SSO tab

   Select the Rootly application, go to the SSO tab, and update IdP Entity ID from JumpCloud to JumpCloud-<BusinessName>.

   

   Download your IDP Certificate (.pem file).

   
3. Configure Rootly

   Fill in the Rootly SSO fields:

   

   Rootly field	JumpCloud field
   Identity Provider ID	IdP Entity ID
   Identity Login URL	IDP URL
   Identity Logout URL	Leave blank, or set your desired post-logout redirect
   IdP Cert	Open the .pem file in a text editor and paste the full contents
   Domain Name	Your domain (e.g. mycompany.com)

   Click Enable and Save.

   
4. Optional: Set up SCIM group provisioning

   Navigate to the Identity Management tab in JumpCloud to configure SCIM:

   

   Field	Value
   API Type	SCIM API
   SCIM Version	SCIM 2.0
   Base URL	https://rootly.com/scim
   Token Key	Copy from Integrations > SSO > SCIM Token in Rootly

   

   Set Test User Email to an address whose domain matches your Rootly SSO domain configuration and click Test Connection.

   To provision users by JumpCloud Group and assign them specific Rootly roles, enable group-based provisioning:

   

   Then map each JumpCloud Group to a Rootly Role in the Rootly SSO modal:

   

Just-In-Time (JIT) Provisioning

When a user logs in for the first time via SSO, Rootly automatically creates their account — no pre-provisioning required. The following happens on first login:

• Account is created with a random password (SSO users never use password login)
• Email confirmation is bypassed
• User is added as a member of the SSO account’s organization
• Attributes (name, email, phone) are populated from the SAML assertion
• Role is assigned from group membership (if configured) or the default SSO role set under Integrations > SSO
• On-call role is assigned from group membership or the default on-call role

On every subsequent login, Rootly re-syncs the user’s attributes from the SAML assertion. Name, email, and other profile fields are updated to match your IdP.

Default role fallback: If no default role is configured, the user receives the first available standard user role. If no default on-call role is configured, the user receives no on-call access. Configure both under Integrations > SSO before enabling SSO.

Group-based role assignment lets you map IdP groups (via SCIM) to Rootly roles. When a user belongs to multiple groups with different roles, the highest-weight role wins. See SCIM for group sync setup.

JIT provisioning creates accounts on first login. To pre-populate your organization before users log in — or to deprovision users automatically when they leave — use SCIM.

Domain Routing

The Domain Name field controls which users are routed through SSO. When a user enters their email at login:

• No match — error: “Could not find any organization associated with this domain”
• One match — user is redirected to the matched IdP automatically
• Multiple matches — user sees an organization picker

One SSO account can serve multiple email domains — useful for organizations with more than one email domain. Email domain validation is also enforced on every SAML assertion — a response whose email domain is not in the allowed list is rejected even with a valid signature.

Single Logout (SLO)

Rootly supports SP-initiated and IdP-initiated Single Logout. To enable SLO, populate the Identity Logout URL field with your IdP’s SLO service URL.

• SP-initiated: When a user signs out of Rootly, Rootly sends a SAML LogoutRequest to your IdP, ending the IdP session.
• IdP-initiated: When a session is terminated via your IdP, the IdP sends a LogoutRequest to Rootly, which signs the user out and returns a LogoutResponse.

If the Identity Logout URL is left blank, signing out of Rootly only clears the local session — the IdP session remains active.

Login Behaviour

When SSO is enabled, all other login methods — Google OAuth, Slack OAuth, and email/password — are automatically redirected through your identity provider for any user whose email domain matches a configured SSO account. Users cannot bypass SSO using an alternate method.

API keys are not affected by SSO. Existing API tokens continue to work regardless of SSO state, making them useful for programmatic access and automation even during an IdP outage.

Emergency Access & Lockout Recovery

Enabling SSO disables all other login paths for affected users. An IdP outage, expired certificate, attribute mapping error, or misconfiguration can lock all admins out simultaneously.

Locked Out?

Contact Rootly support — our team can disable SSO enforcement on your organization to restore access:

• Email: [e-mail]
• Slack: Use the /rootly support command from any workspace where Rootly is installed
• Live chat: Use the chat widget at rootly.com

Have your organization name, organization slug, and the email address of an admin user ready to expedite recovery.

Prevention

Complete these steps before enabling SSO in production.

1. Test first. Enable SSO without enforcing it, verify one user can complete the full login flow including JIT provisioning and attribute mapping, then roll out broadly.
2. Watch your certificate expiry. Rootly sends expiration warning emails automatically. Rotate the certificate before it expires.
3. Keep two or more organization owners. If one admin is locked out, another can contact support and verify identity.
4. Store API keys outside Rootly. API access bypasses SSO enforcement. Keys in a password manager or secrets vault let you manage resources programmatically during an IdP outage.
5. Know your IdP’s break-glass procedure. Every major IdP has an emergency admin recovery path. Know it before you need it.
6. Record your org slug and admin emails so support can quickly verify your identity and restore access.

FAQs

Why do users see 'Invalid SAML response' on login?

This usually indicates a certificate mismatch or incorrect Entity ID. Re-download the IdP certificate and confirm the Entity ID is set to https://rootly.com/users/saml/metadata.

Why are JIT-provisioned users getting the wrong role?

The default SSO role has not been configured. Set Default Role under Integrations > SSO before enabling JIT provisioning. If group-based role assignment is active, also verify your SCIM group-to-role mappings.

Why does Google Workspace login fail with a signature error?

Google does not check Signed Response by default. Open your Google SAML app settings and enable Signed Response — Rootly requires a signed response to validate the assertion.

Why is the login redirecting in a loop?

This is usually an ACS URL or NameID format mismatch. Verify the ACS URL is exactly https://rootly.com/users/saml/auth and the NameID format is emailAddress.

Why do users get 'Could not find any organization associated with this domain'?

The user’s email domain is not in the Domain Name field of any active SSO configuration. Add the domain under Integrations > SSO.

Why are user names missing or wrong after JIT provisioning?

The IdP is not sending the expected SAML attributes. Add attribute statements for name.givenName and name.familyName in your IdP’s attribute mapping configuration.

Can one SSO account cover multiple email domains?

Yes. The Domain Name field accepts multiple domains on a single SSO account. All users from any configured domain are routed to the same IdP.

Does SSO affect API key access?

No. API tokens are not subject to SSO enforcement and remain valid regardless of SSO state.

Related Pages

SCIM

Automate user provisioning and group sync with SCIM 2.0.

Google Directory Sync

Sync users and groups directly from Google Workspace.

Teams

Manage Rootly teams and role assignments.