Multi-IdP Support

The multi-IdP feature enables the FIDO Connector to operate with multiple IdP instances. The FIDO Connector (v2) can be configured to support one or more of the following IdPs:

Microsoft Entra ID
PingOne PingID
PingOne AIC

For information about these integrations, see FIDO Pre-reg with MicrosoftTitle and FIDO Pre-reg with PingOne.

ARM Template Parameters

The ARM template provided by Yubico contains the following primary parameters for enabling or disabling multi-IdP support for the FIDO Connector:

ShouldUseMultiIdp: Determines whether the FIDO Connector operates in single-IdP mode, configured via environment variables only, or multi-IdP mode where the configuration is pulled from an external file (multi-idp-config.yaml).

The parameter has the following values, available for selection in a drop-down menu when deploying the ARM template: “No”, “Yes, configured via Container Volume Mount file”, “Yes, configured via Blob Storage file”.
defaultIdentityProvider: Defines the primary identity provider used by the FIDO Connector. The following values are available for selection when deploying the ARM template: “EntraID”, “PingOne PingID”, or “PingOne Advanced Cloud Identity”. The behavior depends on whether multi-IdP is disabled or enabled:
- Multi-IdP is disabled (ShouldUseMultiIdp = “No'”): Controls which single IdP to be used. The ARM template will automatically inject the corresponding environment variables, for example client IDs and endpoints, required for that specific IdP.
- Multi-IdP is enabled: A configuration file is used to support multiple IdPs. In this mode, defaultIdentityProvider acts as a fallback, telling the FIDO Connector which IdP should be the default when nothing is specified in the requests.

The selected configuration method when enabling multi-IdP support will impact the deployed resources and the required post-deployment steps. For more information, see Option 1: Container Volume Mount and Option 2: Blob Storage Container.

The ShouldUseMultiIdp and defaultIdentityProvider parameter settings impact the following:

FIDO Connector environment variables:
- The single-IdP mode injects individual environment variables, for example ENTRA_FIDO_API_CLIENT_ID or PINGONE_CLIENT_ID.
- The multi-IdP mode bypasses these variables, setting IDP_ENABLE_MULTI_IDP to “true” and defines the file lookup path via IDP_CONFIGURATION_PATH.
Storage and container architecture: The Volume mount method creates container secrets and disk mounts. The Blob storage method provisions Blob components and RBAC roles.

Regardless of the single-IdP/multi-IdP settings, the ARM template always deploys the following:

Virtual Network (VNet), subnets, and private endpoints.
Azure Storage Account, including Azure Table Storage for shipment tracking.
Azure Key Vault secrets for all supported IdPs (Entra ID, PingOne PingID/AIC).
Container App instance, Log Analytics Workspace, App Insights, and Logic App workflows.

Enabling Multi-IdP Support

Multi-IdP support is disabled by default, and must first be enabled in your FIDO Connector instance. The parameters in the ARM template lets you enable multi-IdP support, and choose the method for providing the IdP-specific configurations. You can provide these either by using the Volume mount method, or the Blob storage container method.

Note

Version 1 of the FIDO Connector does not support multiple IdPs, the IDP_DEFAULT that has been configured will always be used. If you are migrating from v1 to v2 of the FIDO Connector, and want to enable multi-IdP and add a new IdP, consider configuring your existing IdP as default_idp for processing existing requests, and use the new IdP for new requests.

To enable multi-IdP support in the FIDO Connector in your Azure environment, do the following:

Create a configuration YAML file containing the settings for your IdPs. Each IdP instance must have a unique identifier, see Configuration File Example.
Provide the IdP-specific configurations using one of the following options:
- Update the configurations in the placeholder file in the Container App Secret, see Option 1: Container Volume Mount.
- Upload the configuration file to a Blob container, see Option 2: Blob Storage Container.
Configure Environment variables in the Container App as follows:
- IDP_ENABLE_MULTI_IDP: Set to “true”.
- IDP_DEFAULT: Set to your primary IdP’s unique identifier. Note that when using multiple IdPs, IDP_DEFAULT must be one of the identifiers used in the configuration file created in step 1.
- IDP_CONFIGURATION_PATH: Configuration YAML file name or path, derived from either of the options in step 2.
- AZURE_STORAGE_BLOB_CONTAINER_NAME: If using Blob Storage, also provide the Container name of the Blob Storage.
- AZURE_STORAGE_BLOB_ENDPOINT: If using Blob Storage, also provide your Azure endpoint. Example “https://msfprstorage.blob.core.windows.net/”.

In your implementation you can use multiple instances of the same IdP, for example, two PingOne PingID instances. Or you can have multiple instances of all supported IdPs. The credentials.idp_id in the request provides information about which IdP to use for each set of credentials. If this is not provided, IDP_DEFAULT will be used.

Configuration File Example

The following shows an example of a multi-IdP YAML configuration file using one instance each of Microsoft Entra ID, PingOne PingID, and PingOne AIC.

 idp:
instances:
  entraid: # Unique random name of the instance (for example "entraid-123"), only letters and numbers.
    type: entraid
    secrets: # More than one secret can be used
      client-secret-id: STRING_VALUE # Use keys from KeyVault
    online-endpoint: STRING_VALUE
    graph-endpoint: STRING_VALUE
    challenge-timeout-minutes: NUMBER_VALUE
    api-version: STRING_VALUE
    client-id: STRING_VALUE
    tenant-id: STRING_VALUE
  pingone:
    type: pingone
    environment-id: STRING_VALUE
    client-id: STRING_VALUE
    secrets:
      client-secret-id: STRING_VALUE
    auth-base-url: STRING_VALUE
    api-base-url: STRING_VALUE
    pre-registration-timeout-days: NUMBER_VALUE
    default-relying-party: STRING_VALUE
  ping-aic:
    type: ping-aic
    realm: STRING_VALUE
    auth-base-url: STRING_VALUE
    client-id: STRING_VALUE
    api-base-url: STRING_VALUE
    scope: STRING_VALUE
    journey: STRING_VALUE
    authentication-header: STRING_VALUE
    callback-1: STRING_VALUE
    callback-2: STRING_VALUE
    callback-3: STRING_VALUE
    token-id-1: STRING_VALUE
    token-id-2: STRING_VALUE
    challenge-timeout-milliseconds: NUMBER_VALUE
    default-relying-party: STRING_VALUE
    secrets:
      client-secret-id: STRING_VALUE

Option 1: Container Volume Mount

The following describes how provide the IdP-specific configurations for multi-IdP support, using the Container volume mount method, configured through “ShouldUseMultiIdp = Yes, configured via Container Volume Mount file”.

What happens in Azure: The ARM template automatically creates an Azure Container App secret containing a boilerplate multi-IdP YAML structure (exampleMultiIdpConfigYaml). It then mounts this secret directly into the container as a file at /app/config/multi-idp-config.yaml.
Post-deployment step: A placeholder file is automatically provided. To configure your IdPs, you only need to update the placeholder values directly within the Container App’s secrets management, removing the need to manage external storage files.

To mount and store a volume file in Azure, do the following:

Sign in to the Azure Portal, go to your Container App > Security > Secrets.
Click Add, enter your Secret Key, select Container App Secret and, in value, enter your configuration YAML file content. Click Save.
If you are using the ARM Template Parameters (FIDO Connector v2) when configuring multi-IdP, update the contents of the Container App Secret created in step 2, then continue to step 4.

If you are not using the ARM template, do the following:
1. In the Container App screen, go to Volumes, then click Add.
2. Add your volume name.
3. Deselect Mount all secrets, click the dropdown and select the secret you created in the previous step, as File Path add the YAML file name.
4. In the Container App screen, go to Containers and select the Volume mounts tab.
5. Click Add, select your volume in the Volume name dropdown, then add your Mount path. The path should start from the /app directory, for example /app/config.
6. Still in Containers, go to the Environment variables tab, and add a variable IDP_CONFIGURATION_PATH=config/{FILE_PATH} Example: IDP_CONFIGURATION_PATH: config/idp-configuration.yaml.
Configure the Environment variables as described in Enabling Multi-IdP Support.

Option 2: Blob Storage Container

The following describes how provide the IdP-specific configurations for multi-IdP support, using the Blob storage container method, configured through the setting “ShouldUseMultiIdp = Yes, configured via Blob Storage file”.

What happens in Azure: The ARM template provisions an Azure Storage Blob Service, creates a private Blob container named fidoconnectorblobs, and grants the Container App permission (Storage Blob Data Contributor) to read from it.
Post-deployment step: ARM/Bicep templates cannot natively generate file contents inside a Blob container during infrastructure provisioning. Therefore you must manually upload your multi-idp-config.yaml file to the newly created fidoconnectorblobs container in order for the FIDO Connector to successfully ingest multiple provider configurations.

To add the file to a Blob storage, do the following in the the Azure Portal:

Create a Blob storage account:
1. In the search bar at the top, type “Storage accounts” and select your account.
2. Click + Create.
3. On the Basics tab, enter the following:
  - Subscription: Select your active subscription.
  - Resource Group: Select your existing Resource Group.
  - Storage account name: Enter a unique name, for example “yubifprstorage”, use only lowercase letters and numbers.
  - Region: Choose the same region as your Resource Group.
  - Performance: Standard is recommended for most use cases.
  - Redundancy: Select the desired redundancy, for example “Locally-redundant storage (LRS)”.
4. Click Review + create and then Create. Wait for the deployment to finish.
Create a Container and upload the configuration file:
1. If you are using the ARM Template Parameters (FIDO Connector v2) when configuring multi-IdP, continue to step 2b to upload the configuration file.
  
  If you are not using the ARM template, do the following:
1. Once the storage account is created, go to the new Storage account resource.
2. In the left menu, under Data storage, click Containers.
3. Click + Container and enter the following:
  - Name: Enter “fidoconnectorblobs”, or the name expected by your application.
  - Public access level: Use “Private” (no anonymous access).
4. Click Create.
1. Click on the newly created container (“fidoconnectorblobs”).
2. Click Upload.
3. In the Upload blob panel, select your configuration file, for example “idp-configuration.yaml”.
4. Click Upload.
Assign “Storage Blob Data Contributor” Role to Container App:
1. Go to your Storage account.
2. In the left menu, click Access Control (IAM).
3. Click + Add and select Add role assignment.
4. On the Role tab, search for Storage Blob Data Contributor, select it and click Next.
5. On the Members tab do the following:
  - Assign access to Managed identity.
  - Click + Select members.
  - In the Managed identity dropdown, select Container App.
  - Find and select your Container App from the list.
  - Click Select.
6. Click Review + assign to complete the process.
Configure the Environment variables as described in Enabling Multi-IdP Support