You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a realm configuration file with a custom browser authentication flow enabled. When we change the realm config by setting the realmDisplayName and applying the realm config, then keycloak-config-cli will detect the changed config file and perform the necessary Keycloak Admin REST API calls. However, with the current implementation, Keycloak will DELETE and then RE-CREATE the custom authentication flow, even though the initial changes were completely unrelated and the auth flow did not change.
Consequently, if a user implicitly executes the custom auth flow during login, which frequently happens on an intensively used system, those users will experience errors and cannot complete the login.
Expected Behavior
A realm configuration change should have as little impact as possible.
Non-auth flow related changes to a realm config should be detected and NOT trigger a recreation of the auth flow.
Steps To Reproduce
1. Create a realm config file with a realm with a custom browser auth flow
1. Apply the realm config to Keycloak
1. Use a test driver like JMeter or a browser automation tool to simulate logins with like 10 Logins / Second.
1. Change the realm config by setting the realmDisplayName
1. Apply the realm config file
1. Observe DELETE & CREATE actions for the custom browser auth flow
1. Observe login errors in the test driver
Environment
Keycloak Version: 21.0.1
keycloak-config-cli Version: 5.6.1
Java Version: 17
Anything else?
I think this could be solved by supporting more fine-grained auth-flow updates.
First fetching the auth flows (with their executions, and configs) and comparing those with the current configuration. If the config are equivalent, the tool can skip the update of the auth flow.
Other changes like config-only changes could be updated indivually without recreating the flow.
The text was updated successfully, but these errors were encountered:
I recently came across this issue and digged a little deeper:
keycloak-config-cli will only recreate the flows when withing the configuration json a change for the flow OR any subflow can be detected. To do the comparison, config-cli will load the partial export of the realm and deep compare each JSON Object of an authentication flow with the corresponding one in the provided config. The "id" is excluded for the comparison of course.
It is important to note, that the partialExport response also contains a field called autheticatorFlow (typo intended ;)) in the authenticationExecutions and also a "description": "", property will be present even though in the import non was provided.
For me adding these properties and making sure they match the JSON that Keycloak returns on partialExport was enough to make config-cli not delete and recreate the flows every time.
Current Behavior
We have a realm configuration file with a custom browser authentication flow enabled. When we change the realm config by setting the realmDisplayName and applying the realm config, then keycloak-config-cli will detect the changed config file and perform the necessary Keycloak Admin REST API calls. However, with the current implementation, Keycloak will DELETE and then RE-CREATE the custom authentication flow, even though the initial changes were completely unrelated and the auth flow did not change.
Consequently, if a user implicitly executes the custom auth flow during login, which frequently happens on an intensively used system, those users will experience errors and cannot complete the login.
Expected Behavior
A realm configuration change should have as little impact as possible.
Non-auth flow related changes to a realm config should be detected and NOT trigger a recreation of the auth flow.
Steps To Reproduce
Environment
Anything else?
I think this could be solved by supporting more fine-grained auth-flow updates.
First fetching the auth flows (with their executions, and configs) and comparing those with the current configuration. If the config are equivalent, the tool can skip the update of the auth flow.
Other changes like config-only changes could be updated indivually without recreating the flow.
The text was updated successfully, but these errors were encountered: