Strong WebAuthn for passwordless authentication

[Marek Posolda]

Hi,

I started the work on https://issues.redhat.com/browse/KEYCLOAK-12174 . It is about the ability to add another WebAuthn policy to the realm, so that you can have 2 policies - one used mainly for two-factor authentication and another for passwordless authentication, and both available in same realm. Some details described in the old email thread https://lists.jboss.org/pipermail/keycloak-dev/2019-November/012947.html .

In the prototype, I've added another WebAuthn policy called "Strong WebAuthn policy", the required action called "Webauthn Register Strong Credential" and authenticator called "WebAuthn Strong Credential Authenticator" . Are these names fine or is it better to use wording like "Passwordless WebAuthn policy" instead or even something different?

Some more details in the screenshots:

(This one contains how the tooltip looks like)
https://paste.pics/2a37ee75d85c9df0f1207d7995888b31
https://paste.pics/0c9c8f54b42bcb8d1e2bcf1ca84ee271 (This one contains some more details shown in the tooltip)
https://paste.pics/34ae3e0b129152e75ffc998587285a82
https://paste.pics/52e19eff5b1a9f9e3df847489d15e9bb The last screenshot contains the example of authentication flow configuration, where user can authenticate either with strong WebAuthn credential OR with (password AND two-factor WebAuthn credential).

WDYT?

Marek

[Schuster Sebastian (INST-CSS/BSV-OS2)]

Hi Marek,

 

I think the differentiation between “Strong WebAuthn policy” and just “WebAuthn policy” is not very clear.

 

“Passwordless WebAuthn policy” more clearly conveys what this is used for (or is there a case where this would be combined with password login?).

Maybe the standard “WebAuthn policy” could even be called “Second factor WebAuthn policy” or “Additional Factor WebAuthn policy”.

 

On the other hand, the alternatives might be a little long in the UI…

 

Best regards,

Sebastian

 

Mit freundlichen Grüßen / Best regards

Dr.-Ing. Sebastian Schuster

Open Source Services (INST-CSS/BSV-OS2)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 726112-100 | Sebastian...@bosch-si.com

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic

​

--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/e8ba395a-b0c8-422c-8dd1-c941944046b4%40googlegroups.com.

[Stian Thorgersen]

I'd got with "WebAuthn Passwordless" and "WebAuthn Second Factor" - "Strong" doesn't really describe anything and can be confusing

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/a8d8456861c0425293a5cf07a2a5b74d%40bosch-si.com.

[Marek Posolda]

Thanks for the feedback. So regarding naming, if we rename the current "WebAuthn policy" to "WebAuthn Second Factor", we possibly need to rename requiredAction and authenticator as well? So new naming could be like this:

For passwordless webauthn:

Policy: WebAuthn Passwordless Policy

Required action: WebAuthn Register Passwordless

Authenticator: WebAuthn Passwordless Authenticator

For second factor webauthn, which already exists, it will be renamed like this:

Policy: WebAuthn Second Factor Policy

Required action: WebAuthn Register Second Factor

Authenticator: WebAuthn Second Factor Authenticator

Is it ok?

One side-effect is, that there will be likely some migration needed. Because current authenticator had providerId like "webauthn-authenticator", but this will likely need to be renamed to "webauthn-second-factor-authenticator" and hence migration is needed too. Same for the credential type, which was named just "webauthn", but we may need to rename credential type to "webauthn-second-factor" as well... But hopefully migration is doable.

Marek

[Stian Thorgersen]

Wondering a bit if we should just keep the second factor one as is. That depends a bit on the long term plans though.

We were talking about introducing some sort of sharable policy/config right, in which case there wouldn't be this duplication, but instead something like:

* Policies/config (guess just a key/value map)

* Authenticator in flow references a policy/config

* Required action references a policy/config

In which case there would be in the default flow one instance of "WebAuthn" referring to "WebAuthnPasswordLess" policy" and another one referring to "WebAuthnSecondFactorPolicy".

Or something along those lines. If that's the plan I would just keep the current one as much as is and have that for two-factor, then use the new names for the passwordless one, so preventing the migration and extra work.

[Marek Posolda]

Yes, fact is that it will be nice to avoid migration.

So we can keep the current "WebAuthn policy" (and authenticator and requiredAction) as is and just introduce new stuff for passwordless. So introduce something like this:

Policy: WebAuthn Passwordless Policy

Required action: WebAuthn Register Passwordless

Authenticator: WebAuthn Passwordless Authenticator

We may just need to document that "WebAuthn Policy" is primarily useful for two-factor authentication and "WebAuthn Passwordless Policy" is primarily used for passwordless /1st factor authentication.

Sounds ok?

Marek

[Stian Thorgersen]

+1

[Jan Lieskovsky]

On Thu, Jan 9, 2020 at 8:18 AM Stian Thorgersen <stho...@redhat.com> wrote:

I'd got with "WebAuthn Passwordless" and "WebAuthn Second Factor" - "Strong" doesn't really describe anything and can be confusing

+1 for this proposal. "Strong" evokes the other one might be weak, which is not the case. Also, strong authentication

doesn't need to be a multifactor one. Besides that, users might be familiar with the "passwordless" term from other

envs, so having it in policy name it might be immediately clear, what's the policy about.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/CAJgngAfuvXJEhaZhGZ98s7PzvphKhNh5LZrpwBR5gQXFn50Vcw%40mail.gmail.com.

[Jan Lieskovsky]

On Thu, Jan 9, 2020 at 11:26 AM Stian Thorgersen <stho...@redhat.com> wrote:

+1

On Thu, 9 Jan 2020 at 11:11, Marek Posolda <mpos...@redhat.com> wrote:

Yes, fact is that it will be nice to avoid migration.

So we can keep the current "WebAuthn policy" (and authenticator and requiredAction) as is and just introduce new stuff for passwordless. So introduce something like this:

Policy: WebAuthn Passwordless Policy

Required action: WebAuthn Register Passwordless

Authenticator: WebAuthn Passwordless Authenticator

We may just need to document that "WebAuthn Policy" is primarily useful for two-factor authentication and "WebAuthn Passwordless Policy" is primarily used for passwordless /1st factor authentication.

Sounds ok?

+1, lgtm. When documenting / describing the two, I would also describe the differences between the two, compare them. So it's clear, the user wouldn't want to use the Passwordless variant for the two factor case, and vice versa.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/CAJgngAenPn4%3D9AzZ--T46-ymSfBYfZtpP5DnDrvmGN98Erz8_Q%40mail.gmail.com.

[Marek Posolda]

Thanks everyone for the feedback.

Send code PR and docs PR to use "Passwordless" naming everywhere as described below. If anyone has a chance to review, it will be great :) Thanks

https://github.com/keycloak/keycloak/pull/6649

https://github.com/keycloak/keycloak-documentation/pull/817

Marek

[Marek Posolda]

Thanks!

On 10. 01. 20 3:38, 乗松隆志 / NORIMATSU，TAKASHI wrote:

Hello,

 

I’ll try to review these code PR and docs PR.

 

Regards,

Takashi Norimatsu

Hitachi, Ltd.

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/a49cb1d0-f7cf-0ea7-27ad-29f5eeed9460%40redhat.com.

[Schuster Sebastian (INST-CSS/BSV-OS2)]

Sounds good to me.

 

Best regards,

Sebastian

 

Mit freundlichen Grüßen / Best regards

Dr.-Ing. Sebastian Schuster

Open Source Services (INST-CSS/BSV-OS2)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 726112-100 | Sebastian...@bosch-si.com

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic

​

[乗松隆志 / NORIMATSU，TAKASHI]

Hello,

 

I’ll try to review these code PR and docs PR.

 

Regards,

Takashi Norimatsu

Hitachi, Ltd.

 

From: keyclo...@googlegroups.com <keyclo...@googlegroups.com> On Behalf Of Marek Posolda

Sent: Friday, January 10, 2020 3:07 AM
To: Jan Lieskovsky <jlie...@redhat.com>; Stian Thorgersen <st...@redhat.com>
Cc: Schuster Sebastian (INST-CSS/BSV-OS2) <Sebastian...@bosch-si.com>; Keycloak Dev <keyclo...@googlegroups.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/a49cb1d0-f7cf-0ea7-27ad-29f5eeed9460%40redhat.com.

[Martin Maher]

Jan, et al:

Apologies for the late response.  The new group server just forwarded all of the messages from January through this morning, a few minutes ago.

With respect to authentication methods, the term strong has a specific connotation, being that the element is the result of a strong cryptographic method.  Static passwords, or any strictly static element, is by comparison weak.

On a related issue of parlance, any exchange where multiple factors are utilized over the course of the transaction is multi-factor.  However, only exchanges where two factors are linked together in the authentication system (the PIN plus token code makes PASSCODE from of RSA SecurID® is a good example) and presented at the same point in the transaction are two-factor.  It might be best to ensure that the proper wording is used in order to maintain the clarity that appears to be desired.

Respectfully submitted,

Martin Maher

gen...@penguindreams.us

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/CAPr-%2BaEFKQJr%3DM21SX6TNiKSra_e%3DD2RP8H4SjeO3qiWtoNggA%40mail.gmail.com.