OpenID Connect Protocol

After you connect your existing identity provider to Immuta, users can authenticate to the Immuta application through the OpenID Connect protocol.

Beyond authentication, you can configure an external user info endpoint so that Immuta can ingest groups and attributes already assigned to your users. Then, you can use that user metadata to author access control policies.

This reference guide outlines details about the configuration options available for OpenID Connect.

Configuration options

The following options are available when setting up an identity provider that uses the OpenID Connect protocol.

  • Allow identity-provider-initiated single sign-on: When enabled, users authenticate once in their identity provider and can log in to Immuta.

  • Allow Immuta attributes to be applied to OpenID users and groups: Attributes created in Immuta can be added to your users and groups in your identity provider. SCIM must be enabled or you must configure an external user info endpoint for this option to be available.

  • Allow OpenID users to be added to Immuta groups: This allows you to create groups in Immuta and add OpenID users to those groups. SCIM must be enabled or you must configure an external user info endpoint for this option to be available.

  • Attribute schema: Map OpenID Connect attributes into Immuta after you enable SCIM.

  • Authorization endpoint: The URL of the authorization server. The user will be redirected to this URL to authenticate when they log in to Immuta. If the Discover URL is provided, this field will be disabled.

  • Client ID: The unique string identifier assigned to the OpenID Connect application you created in your identity provider. See your identity provider's documentation for details.

  • Client secret: Client secret the OpenID Connect application uses to verify its identity with the authorization server. See your identity provider's documentation for details.

  • Discover URL: URL of the identity provider's discovery endpoint. If this URL is provided, the fields for manually specifying the endpoint will be disabled.

  • Enable SSL: Use SSL to protect user credentials, identity tokens, and profile data during login.

  • End session endpoint: The URL of the identity provider's end session endpoint, which will trigger single logout.

  • External groups and attributes endpoint: Immuta uses this REST endpoint to retrieve a user's groups and attributes from an external IAM service.

    • Sync REST attributes: Ingest user attributes from the external IAM service into Immuta.

    • Sync REST groups: Ingest user groups from the external IAM service into Immuta.

    • Use authentication: Provide credentials Immuta will use to connect to the external IAM service.

  • Group permissions: Once you enable group permissions, you can define a mapping of groups to Immuta permissions. Users who belong to one of the given groups will be granted the listed permissions automatically. SCIM must be enabled or you must configure an external user info endpoint for this option to be available.

  • Issuer: The identity provider's URL. If the Discover URL is provided, this field will be disabled.

  • JWKS URI: URL of the identity provider's JSON Web Key set. This is configured in the authorization server. If the Discover URL is provided, this field will be disabled.

  • Migrate users: Migrate users from a previously configured identity provider to the current identity provider being configured.

  • Profile schema: Map attributes from your identity provider to automatically fill in a user’s Immuta profile.

  • SCIM support: When enabled, your identity provider automatically creates new users in Immuta and updates existing user accounts, whether or not users log in to Immuta. When you click this checkbox, Immuta generates a SCIM API key.

  • Scopes: The scopes sent when a user authenticates. Scopes authorize access to a user’s profile details, like name and email.

  • Supported ID token signing algorithms: A list of supported signing algorithms for verifying ID token signatures. If the Discover URL is provided, this field will be disabled.

  • Token endpoint: URL of the identity provider's endpoint that returns access tokens or ID tokens. If the Discover URL is provided, this field will be disabled.

  • User info endpoint: URL of the identity provider's user info endpoint. Complete this field if you will add custom scopes. If the Discover URL is provided, this field will be disabled.

  • User ID claim: This key (primarily the sub (subject) claim) of the claim holds a unique identifier for the end user assigned by the identity provider.

SCIM support

When configuring an identity provider that uses the OpenID Connect protocol, you can enable SCIM support. SCIM support allows Immuta to

  • Automatically create new users in Immuta as they are created in your identity provider

  • Keep existing users up-to-date in your identity provider

  • Map OpenID Connect attributes to Immuta attributes

  • Ingest OpenID Connect groups

  • Add Immuta attributes to OpenID Connect users and groups

  • Add OpenID Connect users to Immuta groups

See the Identity managers overview for details about SCIM support.

Syncing groups and attributes

If you enable SCIM for OpenID Connect, Immuta will ingest the attributes and groups configured in your identity provider.

For groups and attributes to sync in Immuta, no additional configuration is required beyond enabling SCIM. However, you can define how user attributes are mapped into Immuta. See the attribute mapping section for details.

Attribute mapping

To configure attribute mapping for OpenID Connect, SCIM must be enabled. Once enabled, you can complete the attribute schema, which defines how attributes are mapped in Immuta.

For SCIM attribute mapping, the attribute prefix is mapped to the relevant SCIM schema. The Immuta attribute prefix will be prepended to all attribute keys included in that schema. For example, if the SCIM schema urn:immuta:schemas:extension:custom:2.0:User included the attributes Title, employeeNumber, and AccessLevel and was mapped to the Immuta attribute prefix Immuta, the attribute key-value pairs would be pulled into Immuta like this:

  • Immuta.Title:x

  • Immuta.employeeNumber:x

  • Immuta.AccessLevel:x

The table below illustrates a sample attribute schema mapping with SCIM enabled for Taylor, who has the following attribute key-value pairs:

  • "role": "Manager"

  • "dept": "Engineering"

SCIM schema
IAM Immuta attribute prefix
Taylor's resulting attribute key-value pair in Immuta

urn:immuta:schemas:extension:custom:2.0:User

Title

Title.role:Manager

urn:ietf:params:scim:schemas:core:2.0:User

Immuta

Immuta.dept:Engineering

Once these attributes are pulled into Immuta, policy authors can create global policies using these attributes to automatically enforce access controls for users based on their attributes. Consider the following example:

Only show rows where user possesses an attribute in Immuta.dept that matches the value in column tagged LOB on all data sources.

Then, Taylor would only see rows that include the value of her department (Engineering) in the column tagged LOB.

Single sign-on

Immuta's OpenID Connect integration supports the identity-provider-initiated authentication flow single sign-on method.

Last updated

Was this helpful?