5.10.7. WebAuthn Token Config¶
5.10.7.1. Trust Anchor Directory¶
You may define a directory containing trust roots for attestation certificates.
This should be a path to a local directory on the server to which eduMFA has read access to. Any certificate in this directory will be trusted to correctly attest authenticators during enrollment.
This does not need to be set for WebAuthn to work, however without this, eduMFA can not check, whether an attestation certificate is actually trusted (it will still be checked for validity). Therefore it is mandatory to set this, if webauthn_authenticator_attestation_level is set to “trusted” through policy for any user.
5.10.8. WebAuthn Required Policies¶
For WebAuthn to work, a name and ID for the relying party need to be set. The relying party in WebAuthn represents the entity the user is registering with. In most cases this will be your company. In larger companies it is often helpful to segment according to department by setting up multiple ID and name policies for WebAuthn that apply to different users.
5.10.8.1. Relying Party ID¶
The ID of the relying party must be a fully-qualified domain name. Every web-service
where the WebAuthn token should be used needs to be reachable under a domain name
which is a superset (i.e. a subdomain) of this ID.
This means that a WebAuthn token enrolled with a relying party ID of example.com
may be used to sign in to edumfa.example.com
and owncloud.example.com
.
However, this token will not be able to sign in to a service under example.de
, or any
other webservice that is not hosted on a subdomain of example.com
.
See also: webauthn_relying_party_id.
5.10.8.2. Relying Party Name¶
This is a human-readable name to go along with the relying party ID. It will usually be either the name of your company (if there is just one relying party for the entire company) or the name of the department or other organizational unit the relying party represents.
See also: webauthn_relying_party_name.