---
title: "Identity Providers"
slug: "identity-providers"
updated: 2026-10-12T12:36:46Z
published: 2026-10-12T12:36:46Z
canonical: "docs.britive.com/identity-providers"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.britive.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Identity Providers

An identity provider (IdP) is a service that stores and verifies user identities. The default identity provider for any user is Britive. Create and configure an IdP to trust authentication tokens using the following steps:

1. Log in to Britive with administrator privileges.
2. Click **System admin** -> **Identity Management**.
3. Select the **Identity Providers** tab and click on the **Add Identity Provider** button.
4. Enter the following in the **Add Identity Provider** window:
  1. Select **Identity Provider Type**:
    1. **SAML**: Enter **Name** and **Description**.
    2. **OIDC**: Enter **Name, Issuer Url,** and **Description**. The issuer URL is part of the [Prerequisites for OIDC Providers](https://portal.document360.io/v1/docs/service-identity-federation#prerequisites-for-oidc-providers).
    3. **SPIFFE:**
      1. To use the SPIFFE (Secure Production Identity Framework for Everyone) workload identity providers, you need to install and configure SPIRE (SPIFFE Runtime Environment) first. To install and configure SPIRE, see [SPIFFE](/v1/docs/spiffe-integration).
      2. **Name**: Enter the name of the workload identity provider.
      3. **Attributes Map**: Select the **Identity attribute**, enter the **Provider attribute,** and select the **Match type** from **Exact** or **Regex**. For more information about how attributes are mapped, see [Attributes Mapping](/v1/docs/identity-providers#attributes-mapping).

> **Note:** Attributes map must contain only one mapping pair with the *idpAttr* set to the subject claim ('sub') in the JWT-SVID and the *userAttr* set to the ‘spiffe id’ custom attribute id created while configuring SPIRE.
      4. **Validation Window**: The validation window starts from the time the token is signed, as specified by the x-amz-date request header in the token. For more information, see [Validation Window](/v1/docs/service-identities#validation-window).
      5. **Bundle Endpoint, Bundle Profile** (only the **https_web** profile is supported for now), and **Trust Domain:** Ensure these values match the SPIRE server configuration.
      6. **Description**: Enter description.
    4. **AWS STS**: Enter **Name** and **Description**. You can configure only one AWS STS identity.
  2. Click **Add**.
5. The new identity provider is displayed in the list. Click the **Manage** icon to configure the identity provider.
6. Click **Edit**, make changes, and click **Save**.
  1. **SAML**: For configuring SSO or SCIM configuration for a particular identity provider, see [Identity Provider Integration Guides](https://portal.document360.io/v1/docs/identity-provider-integration-guides).
  2. **OIDC**:
    1. **Validation Window:** The validation window starts from the time the token was issued, as specified in the JWT issued at the ('iat') claim. The default validation window is 30 seconds. For more information, see [Validation Window](/v1/docs/service-identities#validation-window).
    2. **Attributes map**: Select the **Identity attribute**, enter the **Provider attribute,** and select the **Match type** from **Exact** or **Regex**. For more information about how attributes are mapped, see [Attributes Mapping](/v1/docs/identity-providers#attributes-mapping). You can add multiple attributes.
    3. **Allowed Audiences:** Edit a list of allowed audiences. **Allowed Audiences** are part of the [Prerequisites for OIDC Providers](https://portal.document360.io/v1/docs/service-identity-federation#prerequisites-for-oidc-providers).
  3. **SPIFFE**:
    1. **Attributes map**: Select the **Identity attribute**, enter the **Provider attribute,** and select the **Match type** from **Exact** or **Regex**. For more information about how attributes are mapped, see [Attributes Mapping](/v1/docs/identity-providers#attributes-mapping).
    2. **Validation Window**:
    3. **Bundle Endpoint**:
    4. **Bundle Profile:**
    5. **Trust Domain**:
  4. **AWS STS**:
    1. **Validation Window**: The validation window starts from the time the token is signed, as specified by the *x-amz-date* request header in the token. For more information, see [Validation Window](/v1/docs/service-identities#validation-window).
    2. **Max Request Token Duration**: This is the maximum token validity period that can be requested by the client.
    3. **Attributes map**: ~~S~~elect the **Identity attribute**, enter the **Provider attribute,** and select the **Match type** from **Exact** or **Regex**. For more information about how attributes are mapped, see [Attributes Mapping](/v1/docs/identity-providers#attributes-mapping).
7. Click the **Test Matching** button to check which service or AI identity uses this pattern. In the **Test Matching** window, enter the value and click **Find Match** to get a list of matching identities. This button is greyed out till you save the attributes successfully.

**Note:**

If an IdP is deleted, all service identities associated with that IdP are no longer available for authentication, and the access type is set to **Static**.

### Attributes Mapping

You can map the ID token attributes issued with the OIDC or AWS or SPIFFE providers to Britive service or AI identity attributes. Identity attributes can be added from the **Admin** -> **Identity Management** -> **Identity Attributes** tab.

There are two ways to map attributes. The match types are:

- **Exact**: The stored value must equal the claim. This is the default setting.
- **Regex**: The stored value is a regular expression, and the claim must match it.

> [!NOTE]
> Note:
> 
> Match type is set per claim, per provider.

Changing the match type of a claim that already has values:

- Exact → Regex: Existing values are rewritten so they keep matching exactly what they matched before. A value containing regular expression characters is wrapped as *Q… E*, which means match this as is. A value with no special characters is not changed. Expect to see *Q… E* in the stored values after switching a claim to Regex. If you want it to become a real pattern, edit it and remove the Q and E wrapper.
- Regex → Exact: A value that was wrapped by the conversion above is unwrapped back to the original text. A value that is a real pattern cannot be converted—compared literally, it would match no token at all, so the change is refused with a message naming the identity and value.