/
WebAuthn IdP Authentication Plugin
WebAuthn IdP Authentication Plugin
Functional things to think about
- Only support for the authentication ceremony
- Registration ceremony is handled elsewhere, out-of-band e.g. using Privacy Idea, or something else.
- Need a standard way to retrieve the registered credentials;
- or ask the party responsible for registration to generate a CredentialRequestOptions for the authentication ceremony to proceed, and ask it to validate the resulting assertion.
- Support for 'single-factor and '2nd-factor' experiences?
- Statically configured, or determined at runtime:
- This depends on the 'type' of authenticator you have e.g. does it support single-factor webauthn (supports UserVerification) or just 2nd-factor (only supports UserPresence)
- Original CTAP (U2F) with support for only User prescence or CTAP2 (FIDO2) with support for user verification.
- Different users may have different keys with different functionality. Limit support and say you must have a compatible key.
- See https://www.w3.org/TR/webauthn/#sctn-authenticator-taxonomy
- This depends on the 'type' of authenticator you have e.g. does it support single-factor webauthn (supports UserVerification) or just 2nd-factor (only supports UserPresence)
- Also, requires the authentication request (CredentialRequestOptions) to signal that requirement - easy enough if we control the creation of that, but not if we delegate to say PI?
- Statically configured, or determined at runtime:
- Support for usernameless in addition to passwordless. Depends on Credential Storage Modality.
- Passwordless requires an initial username input step, and key material can be stored IdP side - not on the authenticator.
- Usernameless requires the authenticator to store the public-private key pair, in addition to a user handle specific to that origin (site). Also know as a resident key or discoverable key.
Technical things to think about
- A pluggable way to create an authentication request (CredentialRequestOptions).
- A call to PrivacyIdea.
- An interface to 'local' public key attributes e.g. using the attribute resolver like the TOTP plugin
- Probably using the Yubico libraries to generate the request
- Although, the 'signature count' is mutable and may!? need writing back somewhere - need to check the spec.
- From an AJAX request or SWF action and page navigation.
- A pluggable way to verify the credential assertion response
- A call with the JSON assertion response to PrivacyIdea
- Using the locally resolvable attributes and a suitable internal library (Yubico works well) to verify the response i.e. abstractly, the signed assertion can be verified with the public key.
- Storage
- PublicKey in COSE format - fixed once registered
- A credential ID - fixed once registered
- A user handle (the same one for each key for a given user). - fixed once registered
- A signature count. - can mutate during authentication.
- If we use PI, do we make a generic integration library for it (or does it have a Java SDK, check) and just use that with the possibility of using more of its auth methods in the future.