Skip to main content

​
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:
Document Image

​
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:
FieldValue
ACS URLhttps://rootly.com/users/saml/auth
Entity ID / Audience URIhttps://rootly.com/users/saml/metadata
SP Metadata URLhttps://rootly.com/users/saml/metadata
Name ID Formaturn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
BindingHTTP-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 fieldSAML attribute
EmailNameID (emailAddress format)
First namename.givenName
Last namename.familyName
Preferred namedisplayName
Phone numberphoneNumbers.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.
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.
Document Image
Search for Rootly and click Add.
Document Image
Document Image
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.
Document Image
3

Configure Rootly

Copy the fields from the setup instructions into the Rootly SSO configuration:
Okta fieldRootly field
Identity Provider IssuerIdentity Provider ID
Identity Provider Single Sign-On URLIdentity Login URL
X.509 CertificateIdP Cert
Document Image
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.
Document Image
Document Image
Document Image
Document Image
Document Image
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).
Document Image
3

Configure attribute mapping

Add the following attribute mappings so Rootly receives user profile data during JIT provisioning:
Google Workspace fieldSAML attribute
Primary emailNameID
First namename.givenName
Last namename.familyName
Document Image
4

Configure Rootly

Switch to Rootly. Use the TEST SAML LOGIN button to retrieve the Identity Login URL.
Document Image
Document Image
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.
Document Image
2

Configure Rootly

Copy the following fields from OneLogin into Rootly:
OneLogin fieldRootly field
Issuer URLIdentity Provider ID
SAML 2.0 EndpointIdentity Login URL
X.509 Certificate (Certificate > View Details)IdP Cert
Document Image
Follow the Auth0 marketplace integration guide:View the Auth0 Marketplace integration guide
Install the SSO integration through the Azure Marketplace:
Integrate Rippling SSO + SCIM in one click:Install Rootly from the Rippling App Shop
Document Image
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 fieldKeycloak value
Identity Provider IDhttps://your-keycloak-host/realms/your-realm
Identity Login URLhttps://your-keycloak-host/realms/your-realm/protocol/saml
Identity Logout URLhttps://your-keycloak-host/realms/your-realm/protocol/saml (optional)
IdP CertRS256 certificate wrapped in PEM headers
Domain NameYour domain (e.g. company.com)
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.
Document Image
Click Add New Application.Images 29 WebSearch for and install the Rootly application.
Document Image
2

Configure the SSO tab

Select the Rootly application, go to the SSO tab, and update IdP Entity ID from JumpCloud to JumpCloud-<BusinessName>.
Document Image
Download your IDP Certificate (.pem file).
Document Image
3

Configure Rootly

Fill in the Rootly SSO fields:
Document Image
Rootly fieldJumpCloud field
Identity Provider IDIdP Entity ID
Identity Login URLIDP URL
Identity Logout URLLeave blank, or set your desired post-logout redirect
IdP CertOpen the .pem file in a text editor and paste the full contents
Domain NameYour domain (e.g. mycompany.com)
Click Enable and Save.
Document Image
4

Optional: Set up SCIM group provisioning

Navigate to the Identity Management tab in JumpCloud to configure SCIM:
Document Image
FieldValue
API TypeSCIM API
SCIM VersionSCIM 2.0
Base URLhttps://rootly.com/scim
Token KeyCopy from Integrations > SSO > SCIM Token in Rootly
Document Image
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:
Document Image
Then map each JumpCloud Group to a Rootly Role in the Rootly SSO modal:
Document Image

​
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: support@rootly.com
  • 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

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.
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.
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.
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.
The user’s email domain is not in the Domain Name field of any active SSO configuration. Add the domain under Integrations > SSO.
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.
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.
No. API tokens are not subject to SSO enforcement and remain valid regardless of SSO state.

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.