Configure WebAuthN for Keycloak

[jakubgs]

We want to use WebAuthN standard for Authentication with KeyCloak.

This task is required to complete integrations with other services:

• https://github.com/status-im/infra-office/issues/1
• https://github.com/status-im/infra-office/issues/2

[jakubgs]

I'm still worried that if credentials are missing someone can login with just username.

[jakubgs]

Now, if this was only an issue for administrators removing credentials this wouldn't be that bad, but users can do it too:

So if a user accidentally removes both then anyone can just login as them by simply knowing the username.

[jakubgs]

I've opened an issue describing this behavior: https://issues.redhat.com/browse/KEYCLOAK-19316

[jakubgs]

I've moved https://keycloak.status.im/ to https://keycloak.infra.status.im/ since it will be only for internal use: https://github.com/status-im/infra-office/commit/52f4fca8

We'll use https://auth.status.im/ for the status-im realm and any services for core contributors.

[jakubgs]

We had a call today with Serhan and Frederic and we came to a few conclusions:

• All recovery methods in Keycloak depend on the email user provides, in which case that is Gmail, and later Protonmail
• Since Protonmail supports only password + OTP it is the limiting factor to the security of our Keycloak setup
• In addition not everyone in the company has a Yubikey or other WebAuthn compatible device, which complicates roll-out
• Since most people in the company are also not familiar with WebAuthn and YubiKey usage this also makes roll-out harder
• Since M-out-of-N setups are not possible in Keycloak without complicated code changes it is not viable
• Because of KEYCLOAK-19316 the passwordless setup is considered not secure

For these reasons we decided on the following steps:

• User a simple (user + password) -> (otp / webauthn) for, where OTP registration is mandatory and WebAuthn optional
• Submit our Keycloak setup for audit with an external expert to verify it's secure
• Wait for ProtonMail to provide support for WebAuthn, which is estimated at 6 months in the future
• Gradually roll-out use of WebAuthn to all the users in the org and eventually phase out OTP as less secure

---

Some other things we discussed:

• We'll need to use separate realms for more sensitive things, like Jenkins release instance access for example
• The master realm should be limited to only administration tasks for Keycloak itself, and users also limited to 3 or 4 people
• There is a possibility of hiding some realms inside of our future office VPN for additional security
• This is not possible for our main status-im realm since it would also grant access to external services like Juro
• RedHat is hot garbage

[jakubgs]

I verified that with this configuration:

I get prompted to change password and OTP on first login via Google OAuth, but not for WebAuthn, which stays optional:

[jakubgs]

I also changed the display name for the status-im realm to be auth.status.im, same as domain.

This makes it more descriptive in something like AndOTP.

[jakubgs]

Based on @OxFred's suggestion I've made User Verification Requirement required in WebAuthn configuration:

Docs:

• https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/User_Presence_vs_User_Verification.html
• https://www.keycloak.org/docs/latest/server_admin/#managing-webauthn-as-an-administrator

[jakubgs]

It's worth noting that the Require Resident Key requirement makes YubiKeys older than 4th generation(2015) incompatible.

[jakubgs]

I've also switched Attestation Conveyance Preference to direct based on these docs:

• indirect -This value indicates that the Relying Party prefers an attestation conveyance yielding verifiable attestation statements, but allows the client to decide how to obtain such attestation statements. The client MAY replace the authenticator-generated attestation statements with attestation statements generated by an Anonymization CA, in order to protect the user’s privacy, or to assist Relying Parties with attestation verification in a heterogeneous ecosystem.
• direct - This value indicates that the Relying Party wants to receive the attestation statement as generated by the authenticator.

https://www.w3.org/TR/webauthn/#attestation-conveyance

Since I don't think we care about any "Anonymization CAs" for our use cases.

[jakubgs]

As far as I know WebAuthN works in Keycloak fine.