KEYCLOAK-12753 Apply feedback

This commit is contained in:
mposolda 2020-02-06 09:10:27 +01:00 committed by Marek Posolda
parent 301e906e85
commit c2da0a2fd8
4 changed files with 15 additions and 15 deletions

View file

@ -16,10 +16,10 @@ extension. The creation and management of the credential store is handled by Ely
== More updates to W3C WebAuthn and Authentication flows
In this release, we did some usability improvements to the authentication flows. It should be more easy for end user to choose between
available authentication mechanisms for two-factor authentication. It should be more intuitive to login with OTP or WebAuthn
In this release, we did some usability improvements to the authentication flows. It should be easier for the end user to choose between
available authentication mechanisms for two-factor authentication. It should be more intuitive to log in with OTP or WebAuthn
considering the fact that user can have more OTP or WebAuthn credentials. There is also better support for passwordless WebAuthn authentication.
Finally, we did some bugfixing related to the authentication flows.
Finally, we did some work on defects related to the authentication flows.
== Other improvements

View file

@ -31,7 +31,7 @@ button means in this context.
Required::
For a flow to be evaluated as successful, all required elements in the flow must evaluate as successful. This means that all _Required_ elements in the flow
must be sequentially executed, from top to bottom, unless one the the elements causes the flow to fail. However, this is only true for the current flow.
must be sequentially executed, from top to bottom, unless one of the elements causes the flow to fail. However, this is only true for the current flow.
Any _Required_ element within a sub-flow is only processed if that sub-flow is entered.
Alternative::
When a flow contains only _Alternative_ elements, only a single element must evaluate as successful for the flow to evaluate as successful.
@ -117,7 +117,7 @@ depending on how the executions they contain evaluate (and this includes the eva
depends on the Requirement of each execution and sub-flow.
Fully understanding this requires a more complete explanation of how requirements work when evaluating a flow, and this also applies to sub-flows.
Take a look at the <<_execution-requirements, execution requirements section>> above for more details.
Refer to the <<_execution-requirements, execution requirements section>> above for more details.
Note that after adding an execution, you should check that the Requirement is set to the correct value. Even if there is only a single possible Requirement, it
can happen that it is not set.
@ -172,16 +172,16 @@ image:images/Passwordless-browser-login.png[]
After entering the username, the way this flow works is the following:
* If the user has any WebAuthn passwordless credentials recorded, he will be able to use any of them to log in directly. This is the password-less login.
The user also has a way allowing him to select "Password with OTP". He can do this because the "WebAuthn Passwordless" execution and the "Password with OTP"
* If the user has any WebAuthn passwordless credentials recorded, that user will be able to use any of them to log in directly. This is the password-less login.
The user can instead select "Password with OTP". The user can do this because the "WebAuthn Passwordless" execution and the "Password with OTP"
flow are set to _Alternative_. Were they set to _Required_ the user would have to enter WebAuthn, password, and OTP.
* If the user selects `Try another way` link on the screen with "WebAuthn passwordless" authentication, he can choose between "Password" and
"Security Key" (WebAuthn passwordless). When selecting password, the user will need to continue and login with his OTP as well.
If the user doesn't have any WebAuthn credentials, he will have to first enter his
* If the user selects `Try another way` link on the screen with "WebAuthn passwordless" authentication, the user can choose between "Password" and
"Security Key" (WebAuthn passwordless). When selecting the password, the user will need to continue and log in with the assigned OTP as well.
If the user has no WebAuthn credentials, he will have to first enter his
password, and then his OTP. If the user has no OTP credential, he will be asked to record one.
It is important to note that since the WebAuthn Passwordless execution is set to _Alternative_ instead of _Required_, this flow will never ask the user to register a WebAuthn credential. For a user
to have a Webauthn credential, he must have a required action added to him by an administrator. This is done first by making sure that that the `Webauthn Register Passwordless`
to have a Webauthn credential, that user must have a required action added by an administrator. This is done first by making sure that the `Webauthn Register Passwordless`
required action is enabled in the realm (see the <<_webauthn,WebAuthn>> documentation), and then by setting the required action by using the `Credential Reset` part of a
user's <<_user-credentials,Credentials>> management menu.

View file

@ -68,10 +68,10 @@ image:images/webauthn-browser-flow-conditional-with-OTP.png[]
==== Authenticate with WebAuthn Authenticator
After registering their WebAuthn authenticator, the user carries out the following operations
After registering a WebAuthn authenticator, the user carries out the following operations
assuming that authentication flow configuration above with the conditional subflow using `WebAuthn Authenticator` was used:
- Open the login form. User must authenticate with username and password.
- Open the login form. The user must authenticate with a username and password.
- The user's browser asks the user to authenticate by their WebAuthn authenticator.
==== Managing WebAuthn as an administrator

View file

@ -1,7 +1,7 @@
[[_auth_spi]]
== Authentication SPI
{project_name} comes out of the box with a bunch of different authentication mechanisms: kerberos, password, otp and others.
{project_name} includes a range of different authentication mechanisms: kerberos, password, otp and others.
These mechanisms may not meet all of your requirements and you may want to plug in your own custom ones.
{project_name} provides an authentication SPI that you can use to write new plugins.
The admin console supports applying, ordering, and configuring these new mechanisms.
@ -821,7 +821,7 @@ a different credential or execution.
Adding an Authenticator to a flow must be done in the admin console.
If you go to the Authentication menu item and go to the Flow tab, you will be able to view the currently defined flows.
You cannot modify built in flows, so, to add the Authenticator we've created you have to copy an existing flow or create your own.
I'm hoping the UI is intuitive enough so that you can figure out for yourself how to create a flow and add the Authenticator. For
Our hope is that the user interface is sufficiently clear so that you can determine how to create a flow and add the Authenticator. For
more details, see the `Authentication Flows` chapter in link:{adminguide_link}[{adminguide_name}] .
After you've created your flow, you have to bind it to the login action you want to bind it to.