Yubikey Authentication Modes and Azure AD integration via the APM
Introduction
The Yubikey ( https://www.yubico.com/) supports three major functions, authentication, signing and encryption. As far as authentication goes, it supports a list of the following mechanisms.
- OTP (one-time password)
- Yubikey OTP (Time based OTP)
- OATH HOTP (HMAC based OTP)
- FIDO U2F (Universal 2nd Factor)
- FIDO2
- PIV (Smartcard)
Each of the above-mentioned protocols has its own set of requirements and is therefore not universally supported everywhere.
OTP
OTP is probably the simplest, with a one-time password being used, typically as the 2nd factor. However, it is also the weakest, as it does not mitigate against MITM attacks. E.g., A fake site impersonating a legitimate site can trick the user into entering the OTP and subsequently forwards it to the real site.
All Yubikey’s by default have manufacture assigned secrets registered with Yubico’s own validation servers. Yubico provides a tool that allows you to re-program the key, giving it a different secret. However, the new secret has to be uploaded to Yubico’s validation servers ( https://upload.yubico.com/ ) otherwise OTP will stop working.
Yubikey OTP integrates with a large number of services (e.g., Gmail, LastPass). When a service receives an OTP, it reaches out to Yubico for validation. In the case of Okta, the secrets can be uploaded directly into Okta and validation happens within Okta.
FIDO U2F
FIDO U2F or U2F for short, mitigates MITM. This method requires the user to register the authenticator (e.g., Yubikey) with the application (e.g., Gmail) first, during which a key pair is generated by the authenticator, and the public key is sent and stored on the application. Once the registration is complete, the user can then use the authenticator as the 2nd factor. In the case of Gmail, once the user’s credentials are verified, the user touches the Yubikey for 2nd factor. No code is entered by the user.
FIDO2
FIDO2 enables passwordless authentication. Once the Yubikey is registered with an application (e.g., Azure Portal) for FIDO2 authentication, the user touches the Yubikey, optionally provides a PIN code for the key, logs straight in. – no username is entered
FIDO2 is an evolution of U2F and is dependent upon WebAuthn (client API implemented within the browser) and CTAP2 (authenticator API that enables FIDO2-capable devices to interface to external/roaming authenticators over Bluetooth, USB or Near field communication (NFC)).
Per FIDO Alliance ( https://fidoalliance.org/fido2/fido2-web-authentication-webauthn/#:~:text=WebAuthn%20is%20currently%20supported%20in,Windows%2010%20and%20Android%20platforms ), browser support for U2F and WebAuthn are shown below.
PIV
YubiKey can also present itself as a PIV smartcard that contains a client certificate.
APM Integration
There are a number of articles on DevCentral that cover programming the APM to receive the Yubikey OTP and then send it over to Yubico’s validation servers via a side band connection for OTP verification.
My particular use case is to leverage an IDaaS (e.g., Azure AD) as an IDP and use the APM as the SP. My choice of integration is via OIDC, but SAML is an equally valid option.
Since authentication is offloaded to Azure AD, both the OTP and FIDO2 passwordless authentication methods are now available. Azure AD does not support U2F.
Azure AD and User Configuration
OTP
If Yubikey is used for OTP, Azure AD needs to have MFA enabled, a ‘Conditional Access’ policy is created to ‘Require multi-factor authentication’ for your selected apps. This process is documented by Microsoft ( https://docs.microsoft.com/en-us/azure/active-directory/authentication/tutorial-enable-azure-mfa ).
The user must also add an authenticator app via self-registration ( https://mysignins.microsoft.com/ ), be sure to click on the highlighted, this allows you to enrol the ‘Yubico Authenticator’ ( https://www.yubico.com/products/services-software/download/yubico-authenticator/ ).
The Yubico Authenticator works with the Yubikey to generate the OTP.
Yubico argues that it is more secure as unlike a soft authenticator, the secrets are not saved within the authenticator itself, but rather in a secure element within the Yubikey. Note ‘Touch your Yubikey’, which is needed before an OTP is generated.
The OTP method does not impose special requirements on the browsers, which means it works on any browsers, as well as on the APM Edge client, which leverages certain browser functions
FIDO2
With FIDO2 based passwordless authentication, the ‘FIDO2 Security Key’ option within the Azure AD (e.g., under Security) has to be enabled first.
Again, the user goes through self-registration ( https://mysignins.microsoft.com/ ) prior to the Yubikey becoming available.
I have tried different browsers on the Mac, the only browsers that work are Chrome and Edge. Milage may vary in Windows.
If FIDO2 works, the highlighted option will appear.
In the case of Azure AD, a PIN is required (configured over the self-registration process). Once it’s entered, the user logs in after touching the Yubikey.
At this time, the latest (v7210) APM Edge client’s embedded browser for login does not work with FIDO2, likely due to WebAuthn not being supported. If the user uses a supported browser, passwordless authentication should work, after which a webtop is presented.
- nikzinAltocumulus
Great article !
Are there any limitations regarding BIG-IP Edge Client ? Can i use SAML with Yubikey FIDO2 and Azure AD as IdP ?
Cheers
Nick
- fredlubranoCirrus
Hello, I believe this issue is resolved after reading the release notes for the EDGE client 7.2.5.
Windows Edge Client supports SAML Authentication using the default browser of the system
This feature uses the default browser of the system when authenticating users with SAML IDP. This feature will solve the current limitations of Edge Client, which uses IE technology-based Trident embedded browser for authentication. The Trident engine only supports ECMAScript version 5 and earlier. Users who use IDPs that include JavaScript versions later than ES5 were facing issues with earlier versions of Edge Client. This version of Edge Client resolves all such issues.
To enable this feature customers should load iRules and iFiles and map it to the Virtual servers for which Access profiles are configured. Once 725 Edgeclient is installed on windows need to set Windows registry key "UseExternalBrowserForAuth" with DWORD value 1 at location Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\F5 Networks\RemoteAccess
Note:
- Users must raise a support ticket to get iFiles and iRules.
- This feature requires modern customization to be configured in the access policy.