Does Keycloak v26.2.x step-up flow with AuthenticationFlowSelectorExecutor and ACRCondition work correctly with separate ACR to LOA flows? #39801

samuli-rukkila · 2025-05-19T08:26:06Z

samuli-rukkila
May 19, 2025

I'm in a process of enabling step-up authentication to our Keycloak instance. In our case, we'll have following ACRs (to LOAs) present:

basic (email + password | microsoft | google) -> 1
enhanced (previous + SMS otp) -> 2
strong (Signicat external identity provider) -> 3

Keycloak documentation states that:

Step-up authentication with Level of Authentication conditions is intended for use cases where each level requires all authentication methods from the preceding levels. For instance, level X must always include all authentication methods required by level X-1. For use cases where a specific level, such as level 3, requires a different authentication method from the previous levels, it may be more appropriate to use mapping of ACR to a specific flow. For more details, see Using Client Policies to Select an Authentication Flow.

In our case, if user authenticates via Signicat (strong authentication), other auth methods shouldn't be executed at all.

Seems like in keycloak 26.2.0 they released the Dynamic Authentication Flow selection using Client Policies -feature which looks like it should handle our case too.

Current implementation

For the first two LOAs, the flow is quite simple:

Then for the 3rd LOA, I have then created a new client policy, which forwards requests with acr=strong to a separate flow.

Client policy:

[
  {
    "name": "acr-eid-policy",
    "description": "When requesting acr=strong (LOA 3), this policy is triggered",
    "enabled": true,
    "conditions": [
      {
        "condition": "acr-condition",
        "configuration": {
          "acr-property": "strong"
        }
      }
    ],
    "profiles": [
      "eid-acr-to-signicat-pic"
    ],
    "global": false
  }
]

Client profile:

 {
    "name": "eid-acr-to-signicat-pic",
    "description": "Client profile to forward authorize requests with acr=strong to Signicat identity provider (personal identifier code -variant)",
    "executors": [
      {
        "executor": "auth-flow-enforcer",
        "configuration": {
          "auth-flow-alias": "signicat-loa3-flow",
          "auth-flow-loa": null
        }
      }
    ],
    "global": false
  }

The signicat-loa3-flow is quite simple, it fowards user to Signicat external IDP:

Lastly, the Signicat has post-login flow like this:

The actual problem (and the workaround)

Seems like the biggest problem is that the main authentication flow doesn't include LOA 3 step-flow. In this case if user first authenticates via Signicat (acr=strong) and application only asks for a lower auth (acr=mfa for example), user will be forwarded to the normal browser flow and will be asked for BOTH email + password and SMS MFA, even though user LOA is higher.

This seems to be because the AcrStore.java tries to find the LOA 3 in the main browser flow and since it's not found from that flow, Keycloak sets the maxAge to 0, effectively making the auth process start again:

            if (levelMaxAge == null) {
                logger.warnf("No condition found for level '%d' in the authentication flow", entry.getKey());
                levelMaxAge = 0;
            }

Is this how it should work, have I misunderstood this new feature incorrectly?

Current workaround

For the current workaround, I have added a disabled 3rd LOA flow in the main browser flow, like this:

With this, its possible to first authenticate via Signicat (and get acr=strong) and then user lower level LOAs.

Navigation Menu

Repository navigation

Does Keycloak v26.2.x step-up flow with AuthenticationFlowSelectorExecutor and ACRCondition work correctly with separate ACR to LOA flows? #39801

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 0 comments

Select a reply

Uh oh!

Does Keycloak v26.2.x step-up flow with AuthenticationFlowSelectorExecutor and ACRCondition work correctly with separate ACR to LOA flows? #39801

Uh oh!

Uh oh!

samuli-rukkila May 19, 2025

Current implementation

The actual problem (and the workaround)

Current workaround

Replies: 0 comments

samuli-rukkila
May 19, 2025