Skip to content

SAML & SCIM

Orvanta offers SAML and SCIM functionality as part of its Enterprise Edition, enabling authentication through identity providers. Configuration occurs via Instance settings.

The SAML entity ID is orvanta. The ACS URL follows the pattern <instance_url>/api/saml/acs, with the application username format set to Email.

Users can provide either a SAML Metadata URL or XML content directly in the Instance settings UI. The entity ID can be customized using the SAML_AUDIENCE environment variable for scenarios involving multiple instances.

For Okta setup, configure settings with your domain (e.g. cf.orvanta.cloud). The platform requires providing the SAML Metadata URL from Okta’s configuration panel to Orvanta’s Instance settings.

To configure Azure:

  1. Create a non-gallery enterprise application.
  2. Access the Single sign-on section and select SAML.
  3. Set Entity ID to orvanta and ACS URL to <instance_url>/api/saml/acs.
  4. Configure the NameIdentifier claim with Email address format and user.mail as the source attribute.
  5. Copy the App Federation Metadata URL and paste it into Orvanta’s Instance settings.

A metadata endpoint is available at GET /api/saml/metadata.

The /api/scim endpoint must be internet-accessible for Okta to synchronize groups and users. Generate a secure random string as the SCIM token and configure it in Okta’s Authentication Mode → HTTP Header setting.

From Enterprise Applications, select Provisioning and choose Automatic mode. Input <instance_url>/api/scim as the Tenant URL. Set the SCIM token in Orvanta’s Instance settings and validate the connection through Azure’s test functionality.

When an identity provider sends a SCIM PATCH request with active: false, Orvanta disables the user at the instance level rather than deleting them. Disabled users cannot authenticate via any method and are excluded from on-behalf-of selectors. Re-enabling via SCIM restores access.

SCIM-synchronized groups become instance groups in Orvanta. These groups:

  • Are automatically managed by the identity provider.
  • Sync users and memberships automatically.
  • Function across multiple workspaces.
  • Can be assigned permissions like regular groups.

Instance groups support instance-level role assignments (superadmin or devops) that propagate automatically when group membership changes occur.

Instance groups can map to specific workspaces with predefined role assignments (viewer, developer, admin). When users join an instance group via SCIM, they automatically gain access to configured workspaces with their assigned roles. Removing users from groups automatically removes workspace access.