Ordering executions with keycloak_authentication_execution

[leventyalcin]

Hi there,

In the documentation it stresses how the execution order works as it follows

Note

Due to limitations in the Keycloak API, the ordering of authentication executions within a flow must be specified using depends_on. Authentication executions that are created first will appear first within the flow.

If the realm or the resource is created for the first time, it works perfectly. However, those orders doesn't have Save button after making a change and change is applied immediately if a person drags&drops any of the items in the list accidentally. Also, the next terraform apply wouldn't fix that problem unless the execution flow is deleted and terraform applied again.

I'd like to point out I can see there is "priority" object in the realm exports.

  "authenticationFlows": [
    {
      "id": "69bb5c2f-a321-4c95-92f5-2bc6a0c5822a",
      "alias": "Account verification options",
      "description": "Method with which to verity the existing account",
      "providerId": "basic-flow",
      "topLevel": false,
      "builtIn": true,
      "authenticationExecutions": [
        {
          "authenticator": "idp-email-verification",
          "authenticatorFlow": false,
          "requirement": "ALTERNATIVE",
          "priority": 10,
          "autheticatorFlow": false,
          "userSetupAllowed": false
        },
        {
          "authenticatorFlow": true,
          "requirement": "ALTERNATIVE",
          "priority": 20,
          "autheticatorFlow": true,
          "flowAlias": "Verify Existing Account by Re-authentication",
          "userSetupAllowed": false
        }
      ]
    }
]

Also, Keycloak admin API documentation suggests that it accepts priority in here.

I believe this can be implemented in the provider end.

Thanks,
Levent.

[gim-]

Hi. You are right, the Keycloak's Admin API documentation does imply that you can provide a full executor representation.
But in reality only few fields are actually used to create/update an executor. Providing a priority in the request body has no effect.

The method responsible for the priority looks like this:

private int getNextPriority(AuthenticationFlowModel parentFlow) {
    List<AuthenticationExecutionModel> executions = realm.getAuthenticationExecutionsStream(parentFlow.getId())
            .collect(Collectors.toList());
    return executions.isEmpty() ? 0 : executions.get(executions.size() - 1).getPriority() + 1;
}

And the API endpoint handlers always use that. This can be seen in the Keycloak's source code:

• https://github.com/keycloak/keycloak/blob/ea4155bbcd55c53eb154b5567a2f41ef989dbcf0/services/src/main/java/org/keycloak/services/resources/admin/AuthenticationManagementResource.java#L565
• https://github.com/keycloak/keycloak/blob/ea4155bbcd55c53eb154b5567a2f41ef989dbcf0/services/src/main/java/org/keycloak/services/resources/admin/AuthenticationManagementResource.java#L511
• https://github.com/keycloak/keycloak/blob/ea4155bbcd55c53eb154b5567a2f41ef989dbcf0/services/src/main/java/org/keycloak/services/resources/admin/AuthenticationManagementResource.java#L822

Meaning that it's impossible to set explicit priority value for an executor in a flow with current Keycloak Admin API implementation.

[leventyalcin]

Hi,

Thanks for spending time on this and explaning it very well.

Actually, I realised how priority has no impact on the API end after creating this whilst having a deep dive on Keycloak's API code. What they only offer is increase/decrease priority endpoints. Which is almost impossible to implement (at least in a clean and tidy way instead of creating too many hacky solutions).

Thus, I commented on an another issue (linked to this one) on the Keycloak's repo and explained it to them. However, a bot commented 4 days ago with saying there are too many issues at the moment and we cannot prioritise this currently.

I didn't want to close this one for not to loose the track of it. You could be aware the issue is solved on the other end and this could progress.

Cheers,
Levent.

[gim-]

I believe this can be closed as a duplicate of #296