Thales FIDO authenticator policy

The Thales FIDO authenticator policy enables your organization to specify both the types of authenticators and the user experience to be expected during the registration and authentication of users using FIDO. When a FIDO registration or authentication request is initiated under a defined policy, the operation verifies compliance with the FIDO attributes derived from that policy. Non-compliance with the policy can result in the FIDO server either failing the operation outright or succeeding with a warning response.

By configuring these authenticator requirements as a FIDO registration and authentication policies, your organization can avoid the need to apply them individually to each of the operation requests.

The Thales FIDO authenticator policy can define the following:

• User experience for FIDO operations:

• Device type preference

• User verification preference
• Synchronized passkeys support

• Username-less (autofill) authentication support

• FIDO specific rules:

• Minimum authenticator FIDO certification level

• Allow or deny specific authenticators based on AAGUID (for FIDO2 authenticators) or attestation certificate key identifier (for U2F authenticators)

• Set a list of allowed cryptographic algorithm

• The outcome in the event of a policy validation failure in FIDO operations, specifying whether to fail the operation or pass with a warning

Creating authenticator policies

Create an authenticator policy for a tenant using the create authenticator policies admin operation with a mandatory unique policy name in the request body.

Refer to policy samples for a starters' guide to creating a policy.

Setting policy requirements for FIDO operations

To initiate validating the policy fields with registration and authentication use cases, you can set authenticator policies into FIDO attestation and assertion operations.

Specifying multiple policies in a FIDO attestation and assertion options API is considered to be an AND operator, meaning that all policies have to be compliant to pass the policy validation. The attestation and assertion options response from the FIDO server displays the strictest option for policy mapped FIDO attributes. This implies the following with examples:

• Specifying two policies with a userVerification/discoverable field of preferred and required provides the options response of required.
• Specifying two policies with a metadata field of listed and certified-1 only considers the assertion options of authenticators with only FIDO certification of certified_1 and above.
• Multiple policies with deviceType, algorithm, and whitelist fields only consider common elements.
• Multiple policies with blacklist fields consider all elements.
• A policy conflict error occurs if there are multiple policies with a field that has contrasting elements, for example:
  • backupEligible field of true and false
  • Authenticator attachment of platform and cross-platform, which is inferred from the policy deviceType field. Refer to the API docs for the mapping.

FIDO attestation

Indicate the authenticator policy during the attestation options by setting the policies request field with the policy name.

{
    "userId": "D1VGMaIcnHJSFDHwy9pDV2woyyoMgD3CKfWx20HXIdb1HCQFAc1-BA0Wl8N_Ybc9lehBRE4d_-D2mrS984rI3Q",
    "displayName": "testUser1",
    "relyingPartyOptions": {
        "policies": ["demoPolicy1"],
        "rp": {
            "origins": [
                "https://myawesomesite.com"
            ],
            "id": "myawesomesite.com"
        }
    }
}

FIDO assertion

Indicate the authenticator policy during the assertion options by setting the policies request field with the policy name.

{
    "userId": "D1VGMaIcnHJSFDHwy9pDV2woyyoMgD3CKfWx20HXIdb1HCQFAc1-BA0Wl8N_Ybc9lehBRE4d_-D2mrS984rI3Q",
    "relyingPartyOptions": {
        "policies": ["demoPolicy1"],
        "rp": {
            "origins": [
                "https://myawesomesite.com"
            ],
            "id": "myawesomesite.com"
        }
    }
}

Updating authenticator policies

Modify the authenticator policy fields using the update authenticator policy admin operation by policyId as the path parameter.

Note that only fields in the request body of the update authenticator policy API are updated while the rest of the fields are unchanged.

Retrieving authenticator policies

Retrieve all authenticator policies from a tenant using the list authenticator policies admin operation, with an optional query parameter to retrieve a particular authenticator policy by the policy name.

Alternatively, it is also possible to retrieve a particular authenticator policy using the get authenticator policy admin operation, with policyId as the path parameter.

Deleting authenticator policies

Delete the authenticator policy from a tenant using the delete authenticator policy admin operation, with the policyId as the path parameter.