.. multi-idp.rst .. _multi-idp: ==================== 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-params: 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 :ref:`config-file-mount-volume` and :ref:`config-file-blob-storage`. 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. .. _enable-multi-idp: Enabling Multi-IdP Support ============================= Multi-IdP support is disabled by default, and must first be enabled in your FIDO Connector instance. The :ref:`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 :ref:`Volume mount method `, or the :ref:`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: 1. Create a configuration YAML file containing the settings for your IdPs. Each IdP instance must have a unique identifier, see :ref:`config-file-example`. 2. Provide the IdP-specific configurations using *one of the following options*: * Update the configurations in the placeholder file in the Container App Secret, see :ref:`config-file-mount-volume`. * Upload the configuration file to a Blob container, see :ref:`config-file-blob-storage`. 3. 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. .. _config-file-example: 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. .. code-block:: bash 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 .. _config-file-mount-volume: 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: 1. Sign in to the `Azure Portal `_, go to your **Container App** > **Security** > **Secrets**. 2. Click **Add**, enter your Secret Key, select **Container App Secret** and, in value, enter your configuration YAML file content. Click **Save**. 3. If you are using the :ref:`arm-template-params` (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: a. In the **Container App** screen, go to **Volumes**, then click **Add**. b. Add your volume name. c. 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. d. In the **Container App** screen, go to **Containers** and select the **Volume mounts** tab. e. 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``. f. 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``. 4. Configure the Environment variables as described in :ref:`enable-multi-idp`. .. _config-file-blob-storage: 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 `_: 1. **Create a Blob storage account:** a. In the search bar at the top, type “Storage accounts” and select your account. b. Click **+ Create**. c. 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)”. d. Click **Review + create** and then **Create**. Wait for the deployment to finish. 2. **Create a Container and upload the configuration file**: a. If you are using the :ref:`arm-template-params` (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: i. Once the storage account is created, go to the new **Storage account** resource. ii. In the left menu, under **Data storage**, click **Containers**. iii. Click **+ Container** and enter the following: * **Name:** Enter ``“fidoconnectorblobs”``, or the name expected by your application. * **Public access level:** Use “Private” (no anonymous access). iv. Click **Create**. b. Click on the newly created container (``“fidoconnectorblobs”``). c. Click **Upload**. d. In the **Upload blob** panel, select your configuration file, for example “idp-configuration.yaml”. e. Click **Upload**. 3. **Assign "Storage Blob Data Contributor" Role to Container App:** a. Go to your **Storage account**. b. In the left menu, click **Access Control (IAM)**. c. Click **+ Add** and select **Add role assignment**. d. On the **Role** tab, search for **Storage Blob Data Contributor**, select it and click **Next**. e. 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**. f. Click **Review + assign** to complete the process. 4. Configure the Environment variables as described in :ref:`enable-multi-idp`