/
WebAuthn IdP Authentication Plugin

WebAuthn IdP Authentication Plugin

May 21, 2021

 

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

    • 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?

  • 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.