Modify Passkey/FIDO2 authenticator settings

Administrators do not add Passkey/FIDO2 to a user's list of authenticators. A user must self-register their Passkey/FIDO2 token in their User portal. When a Passkey/FiDO2 token is being used for User ID log in, administrators must ensure that the resource rule allows for Passkey/FIDO2 authentication.

Note: All resource rules created using Identity as a Service 4.3 or later automatically have Passkey/FIDO2 authentication enabled for applications that support Passkey/FIDO2 authentication. For all resource rules created prior to Identity as a Service 4.3, you must enable Passkey/FIDO2 authentication (User ID login). Passkey authentication must be enabled by an administrator. Passkey authentication is independent of resource rules.

Managing Passkey/FIDO2 token authentication

1.      Edit or add a resource rule to allow Passkey/FIDO2 token authentication. See Create and manage resource rules.

2.      Optional. Reorder the authenticators in the resource rule so that the primary authenticator is listed first.

3.      Set the Passkey/FIDO2 token timeout period, as follows:

a.      Click > Policies >Authenticators.

b.      Select Passkey/FIDO2. The Passkey/FIDO2 settings appear.

c.      In the Timeout field, enter the duration (in seconds) that the Passkey/FIDO2 authenticator waits for a response.

If authentication does not occur within the timeout period, the user receives an error message and must reattempt authentication.

4.      Select the Authentication API minimum authentication level. The minimum authentication method required to allow a user to perform the following Passkey/FIDO2 authenticator actions:

●       Registration

●       Edit

●       Delete

5.      Set the Passkey/FIDO2 Registration Policy for the following:

Note: Entrust recommends setting the following policies to Required for passwordless authentication:
- User Verification
- Resident Key (User ID)

a.      User Verification—Should the token perform verification?

–  Discouraged—Avoids verification, if possible.

–  Preferred—Performs verification, if possible.

–  Required—Must perform verification.

b.      Resident Key (User ID)—Should the user's identity be stored on the Passkey/FIDO2 token?

–  Discouraged—Avoids storing the User ID, if possible.

–  Preferred—Stores the user ID, if possible.

–  Required—Must store the user ID.

c.      Authenticator Attachment—Should the token be embedded on the device or stored externally?

–  Either—Embeds the token both on the device and stores it externally.

–  Platform—Embeds the token on the device, for example, a Mac.

–  Required—Stores the token externally, for example, on a Yubikey or phone.

6.      Select User Present Check to perform a hard check on the backend to ensure that the user is physically present at their computer or with their device during registration and authentication.

7.      Select Backup Eligible Check to block synced passkeys that are stored in the cloud and prevent them from being used for registration and authentication.

8.      Select the Enable FIDO2/Passkey Allowlist checkbox to set a list of allowed relying party IDs and origins for Passkey/FIDO2 registration and authentication, and then complete the following:

a.      Click Add and in the new blank field, enter a valid hostname.

b.      Repeat this procedure to add more hostnames.

c.      Click Save when done.

d.      Optional. For each hostname, as required, select Allow Subdomains. Note the following:

–  When selected, during registration, the hostname of the registration origin is checked against the list of allowed relying hostnames.

–  If Allow Subdomains is selected for a hostname, the registration origin can be a subdomain of that hostname.

–  The closest parent domain with Allow Subdomains selected is used as a registration relying party. If Allow Subdomains is not selected for any hostname, then registration origin must be an exact match for one of the hostnames.

–  If there is an exact match for origins, then the relying party must be that origin. 

Example: Hostname mycompany.com allows subdomains. If a user wants to authenticate using department.mycompany.com, the user can authenticate to this domain because it is a subdomain of the parent domain, mycompany.com.

9.      In the Test Registration Origin field, enter the origin to check what the relying party should be based on the current allowlist configuration. You must enter a valid hostname or IP address.

The Relying Party Preview displays the relying party that must be used during registration based on the allowlist.

10.  Click Save.