Clarify the documentation about step-up authentication (#29735)

closes #28341

Signed-off-by: mposolda <mposolda@gmail.com>


Co-authored-by: andymunro <48995441+andymunro@users.noreply.github.com>
This commit is contained in:
Marek Posolda 2024-05-21 19:46:27 +02:00 committed by GitHub
parent a74b084d9d
commit 6dc28bc7b5
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
3 changed files with 6 additions and 1 deletions

Binary file not shown.

Before

Width:  |  Height:  |  Size: 101 KiB

After

Width:  |  Height:  |  Size: 55 KiB

View file

@ -381,6 +381,11 @@ condition found in the authentication flow, such as the Username/Password in the
and that level expired, the user is not required to re-authenticate, but `acr` in the token will have the value 0. This result is considered as authentication and that level expired, the user is not required to re-authenticate, but `acr` in the token will have the value 0. This result is considered as authentication
based solely on `long-lived browser cookie` as mentioned in the section 2 of OIDC Core 1.0 specification. based solely on `long-lived browser cookie` as mentioned in the section 2 of OIDC Core 1.0 specification.
NOTE: During the first authentication of the user, the first configured subflow with the *Conditional - Level Of Authentication* is always executed (regardless of the requested level) as
the user does not yet have any level. Therefore, we recommend that the first level subflow contains the minimal required authenticators for user authentication. In addition, ensure that the subflows with different values of *Conditional - Level Of Authentication* are ordered starting with the lowest as shown
in the example above. For example, if you configure a subflow with level 2 and then add another subflow with level 1, the level 2 subflow will be always asked during the first authentication, which may
not be the desired behavior.
NOTE: A conflict situation may arise when an admin specifies several flows, sets different LoA levels to each, and assigns the flows to different clients. However, the rule is always the same: if a user has a certain level, it needs only have that level to connect to a client. It's up to the admin to make sure that the LoA is coherent. NOTE: A conflict situation may arise when an admin specifies several flows, sets different LoA levels to each, and assigns the flows to different clients. However, the rule is always the same: if a user has a certain level, it needs only have that level to connect to a client. It's up to the admin to make sure that the LoA is coherent.
*Example scenario* *Example scenario*

View file

@ -416,7 +416,7 @@ public class DefaultAuthenticationFlow implements AuthenticationFlow {
if (authenticator.requiresUser()) { if (authenticator.requiresUser()) {
if (authUser == null) { if (authUser == null) {
throw new AuthenticationFlowException("authenticator: " + factory.getId(), AuthenticationFlowError.UNKNOWN_USER); throw new AuthenticationFlowException("authenticator '" + factory.getId() + "' requires user to be set in the authentication context by previous authenticators, but user is not set yet", AuthenticationFlowError.UNKNOWN_USER);
} }
if (!authenticator.configuredFor(processor.getSession(), processor.getRealm(), authUser)) { if (!authenticator.configuredFor(processor.getSession(), processor.getRealm(), authUser)) {
if (factory.isUserSetupAllowed() && model.isRequired() && authenticator.areRequiredActionsEnabled(processor.getSession(), processor.getRealm())) { if (factory.isUserSetupAllowed() && model.isRequired() && authenticator.areRequiredActionsEnabled(processor.getSession(), processor.getRealm())) {