Post-deployment Operations

The following describes useful runtime parameters and some important maintenance operations that are needed to avoid service interruption due to for example rotation of YubiEnterprise API tokens.

Additional Runtime Environment Parameters

The following table lists useful parameters for the FIDO Connector App that you can change in the Azure Container if needed. To add or change these variables, navigate to the container’s environment as described in Configuring Container App.

Variable
Default value (if not changed
by Environment Variable)
Possible values
CRON_PROCESS_SHIPMENT_SCHEDULE
0 0 * * * *
The cron expression for the
schedule that checks ongoing
shipments and processes them.

The default setting is to run
every hour at the top of the hour.

It can be changed to any valid
cron expression, for example to
run every 30 minutes:
0 */30 * * * *
LOGGING_LEVEL_COM_YUBICO
INFO
DEBUG
ENTRA_FIDO_API_CHALLENGE_TIMEOUT_MI
NUTES
20160
Numeric value representing time in
minutes that the Entra FIDO
challenge is valid for.
CRON_DATA_CLEANUP_COMPLETED_DAYS
0
The below cron schedule will purge
‘complete‘ shipment records that
are older than this value.

0 = do nothing, no records will be
deleted, the schedule is
effectively disabled.

n = integer value means delete
‘complete‘ shipment items older
than today - n days.
CRON_DATA_CLEANUP_SCHEDULE
0 30 * * * *
The cron expression for the
cleanup schedule that purges
‘complete’ shipments and their
secrets from the Azure table
and vault.

The default setting is to run
at every 30 minutes past the hour.

The effective values of the various runtime environment variables can be obtained by the API Check Deployment Component Status.

The Process Shipment job can also be run outside of the scheduled time to process shipments on demand by using the API Process Shipments.

Configuring Key Vault and Storage Permissions

To be able to change the YubEnterprise API token or to view the shipments status table from the Azure portal, you need to configure appropriate user and firewall rules. The following describes how to set up these permissions in Key Vault and Storage.

Azure Key Vault Access configuration uses a permission model based on Azure RBAC (role-based access control). Access to Azure Key Vault is defined at a specific scope level by assigning appropriate Azure roles.

By default, the Resource Group Owner does not have permissions to view the contents of the Azure Key Vault. Therefore a special Key Vault Secrets Officer role can be assigned to a User or User Group for these to be able to access the Azure Key Vault.

To assign the “Key Vault Secrets Officer“ role, do the following:

  1. Log in to the Azure Portal.
  2. Go to your Resource Group > Key Vault > Access control (IAM).
  3. Add role assignment “Key Vault Secrets Officer”.
  4. Select a User Group or User to assign this role to.

As a user with this permission you can now go to Resource Group > Key Vault > Secrets and view the Key Vault Secrets.

In this reference implementation, Azure Vault and Storage public network access is disabled. To allow IT Administrators access to Azure Vault or Storage, the IP address or range of your on-premises network must be allowed on the Azure Vault and Storage firewall settings.

To allow the on-premises network through the firewall on Azure Vault and Storage, do the following:

  1. Log in to the Azure Portal.
  2. Go to your Resource Group > Key Vault > Settings > Networking.
  3. On the tab Firewalls and virtual networks, scroll down to the Firewall section. Add your client IP address or range, for example “10.0.10.0”. Microsoft trusted services are allowed by default, but you can disable “Allow trusted Microsoft services to bypass this firewall” depending on your organizations’ preferences.
  4. Go to your Resource Group > Storage account > Security + networking > Networking.
  5. On the tab Firewalls and virtual networks, scroll down to the Firewall section. Add your client IP address or range, for example “10.0.10.0”. Microsoft trusted services are allowed by default, but you can disable “Allow Azure services on the trusted services list to access this storage account” depending on your organizations’ preferences.

Rotating API Tokens

YubiEnterprise API tokens expire one year after generation. Since a user (API caller) can have only one API token at a time, you must have a plan to roll over to a new API token before the old one expires.

To avoid service interruptions, it is recommended to regularly rotate the API tokens. The YubiEnterprise API token can be easily changed from the Key Vault objects without having to perform a complete deployment.

Note

Ensure that the user performing the API token rotation in Azure Key Vault has the Key Vault Secrets Officer role, see Configuring Key Vault and Storage Permissions.

To manage the API tokens, do the the following:

  1. Log in to the Azure Portal.
  2. Go to your Resource Group > Key Vault > Secrets.
  3. List the YubiEnterprise API tokens and click to view versions. Open and view the current version, add a new version, and disable the previous version. For information on how to retrieve API tokens, see Generating API Tokens.

Rotating Application Client Secrets

The Application Client Secret created as part of the application registration steps for Yubico FIDO Connector App have an expiration set by the administrator.

To perform regular rotation, the Microsoft Entra ID Administrator can also delete an existing Client Secret and create a new Client Secret to be used by the registered Application.

The FIDO_Connector_Client_Secret can be easily changed from the Key Vault objects without having to perform a complete deployment.

Note

Ensure that the user performing the API token rotation in Azure Key Vault has the Key Vault Secrets Officer role, see Configuring Key Vault and Storage Permissions.

To manage the Client Secret, do the the following:

  1. Log in to the Azure Portal.
  2. Go to your Resource Group > Key Vault > Secrets.
  3. List the ENTRA-FIDO-API-CLIENT-SECRET and click to view versions. Open and view the current version, add a new version, and disable the previous version.

Changing Microsoft 365 Email Account

The Microsoft 365 email account is used for example to send the Yubico FIDO Pre-reg PIN to end users. If needed, the email account can be changed as described in the following.

To change the Microsoft 365 email account, do the following:

  1. Log in to the Azure Portal.
  2. Go to Resource Group > Logic App.
  3. In the left menu, click Development tools > API connections.
  4. Select Microsoft 365.
  5. Go to General > Edit API connection.
  6. Click Authorize.
  7. Click Authorize again.
  8. Log in with the account that will be used as the sender of emails for Yubico FIDO Pre-reg PINs.
  9. When logged in, click Save.

Resending PIN Email

The PIN email can be resent for a successfully completed shipment by using the API, see Resend PIN.