Setting Up SSO & SCIM

Configure SAML-based Single Sign-On (SSO) and Directory Sync (SCIM) to give your IT team centralized control over who can access Solidroad. This guide walks through prerequisites, domain verification, setup, testing, and automated user provisioning.

Solidroad supports SAML 2.0 SSO including Okta, Microsoft Entra ID (Azure AD), Google Workspace, Ping Identity, and OneLogin. OIDC and EASIE are also supported for less common setups.

Before You Begin

Make sure you have the following in place before starting setup:

• An identity provider that supports SAML 2.0 (Okta, Microsoft Entra ID, Google Workspace, Ping, OneLogin, etc.)

• An IT contact who can configure SAML app settings in your IdP and add DNS records for your domain

• The email domain(s) you want to enable SSO for (e.g., @yourcompany.com)

• At least one admin user already set up in your Solidroad workspace

Verify Your Domain

Before setting up SSO or SCIM, you must first verify that you own your email domain via DNS.

What to do:

• In your Solidroad SSO & SCIM settings, click + Add Domain to start the domain verification process

• Enter the domain you'd like to verify (e.g., yourcompany.com) and select Continue

• Add the provided DNS record to your domain's DNS settings, then complete verification

• Once the record is detected, your domain shows as Verified

• You can add multiple domains by using the + button on the right side of the table.

If you run into any issues verifying your domain, reach out to Solidroad support.

Configuring SSO

Once your domain is verified, you can set up SSO directly from Solidroad.

What to do:

• In your SSO & SCIM settings, click Configure SSO to open the guided setup

• Follow the guided steps — they include direct guidance for all major identity providers (Okta, Microsoft Entra ID, Google Workspace, Ping Identity, OneLogin, and more)

• During setup you can optionally map custom claims (such as role and groups) to drive role and group provisioning — see Automated Role & Group Provisioning below

• You can reconfigure your connection at any time by returning to the setup page and clicking the pencil icon next to the connection.

Once your connection is configured and active, all users on your verified domains must authenticate through your IdP.

A raw SAML request should look something like this:

<saml:Subject>
  <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">alice@example.com</saml:NameID>
  ...
</saml:Subject>

<saml:AttributeStatement>
  <saml:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
    <saml:AttributeValue xsi:type="xs:string">hank.scorpio@globex.example</saml:AttributeValue>
  </saml:Attribute>
  <saml:Attribute Name="firstName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
    <saml:AttributeValue xsi:type="xs:string">Hank</saml:AttributeValue>
  </saml:Attribute>
  <saml:Attribute Name="lastName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
    <saml:AttributeValue xsi:type="xs:string">Scorpio</saml:AttributeValue>
  </saml:Attribute>

  <!-- multi-valued: one <AttributeValue> per group; values may be /-delimited for sub groups -->
  <saml:Attribute Name="groups" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
    <saml:AttributeValue xsi:type="xs:string">Support/GroupLeads</saml:AttributeValue>
    <saml:AttributeValue xsi:type="xs:string">Support</saml:AttributeValue>
  </saml:Attribute>

  <saml:Attribute Name="role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
    <saml:AttributeValue xsi:type="xs:string">Admin</saml:AttributeValue>
  </saml:Attribute>

  <!-- multi-valued: one <AttributeValue> per workspace NAME -->
  <saml:Attribute Name="workspaces" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
    <saml:AttributeValue xsi:type="xs:string">Example Corp</saml:AttributeValue>
    <saml:AttributeValue xsi:type="xs:string">Example Corp EU</saml:AttributeValue>
  </saml:Attribute>
</saml:AttributeStatement>

Note: groups / role / workspaces fields are optional

Configuring SCIM (Directory Sync)

Directory Sync automates user lifecycle management via the SCIM 2.0 protocol. It requires an active SSO connection and is available with supported IdPs including Okta and Microsoft Entra ID.

• In your SSO & SCIM settings, click Configure SCIM to open the guided setup

• The guided setup provides your SCIM Base URL and Bearer Token — enter these in your IdP using the provider-specific steps below

• During setup you can optionally map custom claims (such as role and groups) to drive role and group provisioning — see Automated Role & Group Provisioning below.

• You can reconfigure your connection at any time by returning to the setup page and clicking the pencil icon next to the connection.

With Directory Sync enabled:

• User creation: Assigning a user to the Solidroad app in your IdP automatically creates their Solidroad account

• User updates: Changes to user attributes (name, email) in your IdP sync to Solidroad automatically

• User deactivation: Removing or deactivating a user in your IdP immediately disables their Solidroad account and revokes active sessions

• Via SCIM Attribute and Via SCIM Groups are valid for driving app behavior in the Advanced Settings section

A raw SCIM Request for a User should look something like this:

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "alice@example.com",
  "externalId": "example-0001",
  "name": { "givenName": "Alice", "familyName": "Example" },
  "displayName": "Alice Example",
  "emails": [{ "value": "alice@example.com", "type": "work", "primary": true }],
  "active": true,
  "role": "Admin",
  "groups": ["Support/Leaders", "Support"],
  "workspaces": ["Example Corp", "Example Corp EU"],
  "employeeId": "E-0001"
}

A raw SCIM Group request should look something like this:

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
  "displayName": "Example Group",
  "externalId": "grp-example-exec",
  "members": [{ "value": "scim_user_01Alice..." }]
}

Note: SCIM Groups can be used for Solidroad Group Membership, Role Assignment, or Workspace access. See related sections below for more details.

Automated Role & Group Provisioning

Once your SSO or SCIM connection is active, your identity provider can automatically manage each user's role and group memberships in Solidroad on every login or sync. These are two independent settings, found in the connection's Advanced Settings — you can enable either, both, or neither.

Each can be set to read its value in one of two ways:

• Via SAML Attribute — the value is read from a claim in the SAML assertion when the user signs in.

• Via SCIM Attribute — the value is read from a user attribute synced from your directory.

• Via SCIM Groups - the value is created via SCIM group creation and membership.

Role Assignment

Solidroad sets each user's role from a single-valued role claim sent by your IdP.

• Standard roles are matched by display name — e.g. a role value of Admin assigns the Admin role.

• If the value is unknown or empty, the user's current role is left unchanged.

Group Membership

Solidroad adds users to groups from a multi-valued groups claim. Group assignment is additive and reuses existing groups by name.

• One group — Support adds the user to the Support group.

• Multiple groups — Support, Sales adds the user to both Support and Sales.

• Sub-groups — use / to nest a hierarchy. Support/Tier 2 builds Support → Tier 2 and adds the user to the leaf group (**Tier 2**) only.

Note: Solidroad internal groups are a different concept to SCIM groups. You can choose to provision Solidroad groups via SCIM groups, however the concepts and terms are not interchangeable.

Multiple Identity Providers

The + Add another IdP button allows for multiple SSO connections to be made to the workspace, the setup process is identical to the initial IdP setup.

Multiple Workspaces

If you are an Admin of more than one workspace, you can optionally apply the configured SSO & SCIM connections to these other workspaces with the "Apply to Workspaces" advanced setting.

Workspace Access via SAML / SCIM

If your SSO and SCIM connections are configured on multiple Workspaces a new option for Workspace Access will appear that gates access to linked Workspaces

There are 5 options:

• All Users grants access to all workspaces for all users.

• Via SAML Attribute access to linked workspaces is explicitly granted via SAML Attribute. This is an exact name match of the Workspace, multiple values are accepted.

• Via SCIM Attribute access to linked workspaces is explicitly granted via SCIM Attribute. This is an exact name match of the Workspace, multiple values are accepted.

• Via SCIM Groups access to linked workspaces is explicitly granted via SCIM Group membership.

• Manual Users must still be invited to access linked workspaces within the app.

Note: Access to the base / origin workspace is granted to all Users, only linked Workspaces are gated.

Frequently Asked Questions

Which identity providers are supported?

Any IdP that supports SAML 2.0, including Okta, Microsoft Entra ID (Azure AD), Google Workspace, OneLogin, and Ping Identity. OIDC and EASIE are also supported for less common setups.

Will enabling SSO lock out existing users?

It can — once SSO is enabled for a domain, users on that domain must authenticate through your IdP. Rollout is coordinated carefully so no one is locked out unexpectedly.

Can we use SSO and email/password login at the same time?

SSO is enforced per domain. Users on SSO-enabled domains must use SSO; users on other domains can continue using email/password.

Is Directory Sync required for SSO?

No. Directory Sync is optional — you can use SSO on its own for authentication and manage user provisioning manually.

How do I get started?

Head to your SSO & SCIM settings to verify your domain and configure SSO. Need a hand? Contact us at support@solidroad.com.