search

Versent / saml2aws

CLI tool which enables you to login and retrieve AWS temporary credentials using a SAML IDP
https://github.com/Versent/saml2aws
MIT License
2.09k stars 563 forks source link

Add support for Okta FIDO2 biometric authentication #912

Open seppestas opened 2 years ago

seppestas commented 2 years ago

Okta supports FIDO2 platform authentication that's integrated into a device and uses biometric data, such as Windows Hello or Apple Touch ID.

I'm able to use a Windows Hello fingerprint scanner on the Okta web app, which is awesome. It would be great if saml2aws also support it so I can stop having to use my phone for authentication. I can imagine supporting Apple Touch ID would also help many people.

Related to #419, though that issue talks about YubiKeys, which seem to be supported already.

seppestas commented 2 years ago

Note: it seems like the WebAuthn method is found by saml2aws, however it does not work. When running saml2aws login with MFA method set to Auto and the Windows biometric fingerprint reader registered to my Okta account I get presented the following MFA options:

? Select which MFA option to use FIDO: WebAuthn MFA authentication Okta MFA authentication PUSH MFA authentication

If the biometric MFA factor is not registered, I do not get the option.

However, when I try to log in, I get the following error: error authenticating to IdP: error verifying MFA: error retrieving verify response: request for url:

https://<redacted>.okta.com/api/v1/authn/factors/<redacted>/verify failed status: 401 Unauthorized

Running with the --verbose flag also shows following error:

no U2F devices found. device might not be plugged in
error verifying MFA

So it looks like the underlying go-u2fhost does not support Windows Hello U2F devices.

jwshieldsGetty commented 1 year ago

I believe I am running into a similar issue, receiving the same error message regarding "no U2F devices found" -
but I do not use Windows Hello.

I would say the only thing is that my Yubikey (5C, not a Bio) has a PIN set for U2F/FIDO auth. Which makes me wonder if the PIN is the issue here, as it was pointed out in this comment: https://github.com/Versent/saml2aws/issues/419#issuecomment-741916350

@seppestas do you have a PIN enabled on your Yubikey device?

seppestas commented 1 year ago

I am not using a Yubikey, but a fingerprint reader built into my laptop. This provides 2FA through the Windows hello framework, which supports WebAuthn (FIDO2), not FIDO U2F.

Your Yubikey 5C should work, since it supports FIDO U2F. Maybe create a ticket in https://github.com/marshallbrekka/go-u2fhost if it doesn't or ensure FIDO U2F is enabled.

In a way, I think the issue is SAML2AWS says WebAuthn MFA authentication is supported, but in fact it only supports the older FIDO U2F.

seppestas commented 10 months ago

I have a simple PoC (mostly) working for this. One caveat is that the MFA mode is "FIDO" for both the Windows Hello Webauthn factor and U2F FIDO devices. Okta does not distinguish between the 2, so parseMfaIdentifer returns "FIDO WEBAUTHN" for both.

It's not clear to me what the best way to handle this is.

Should there be a distinction between the "native USB" FIDO MFA and the "system level" FIDO MFA? At least for Windows, this could be done by parsing the authName, which seems to be "Windows Hello Hardware Authenticator" for Windows Hello. It may not be an option for Apple Touch ID and it may not be stable (Windows / The browser / Okta could change this name, potentially breaking the ability to distinguish it).

Should we only fall back on System level authentication if no devices are found? This could cause extra delays for users that have a hardware authenticator that is support by U2FHost but want to use the system authenticator instead.

Should the "system level" authenticator be treated as just another U2F device? The resulting system level assertion prompts could upset users on Windows that are using their FIDO keys directly.

For me, the second option works fine because I don't have any authenticators that are supported by U2FHost. I also think it could be acceptable because the impact on existing users is minimal. The only users that could be negatively impacted are those that have a U2FHost supported USB authenticator but want to use it (or another authenticator) through the system APIs. Sounds like a bit of a border case.

seppestas commented 8 months ago

This now works for Windows Hello (at least once the changes in #1221 are released). I'm keeping this issue open because I plan to get this working with MacOS Touch ID at some point.