Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Service Account User always triggers UPDATE USER in keycloak during import #878

Open
srose opened this issue Jun 7, 2023 · 2 comments · May be fixed by #1246
Open

Service Account User always triggers UPDATE USER in keycloak during import #878

srose opened this issue Jun 7, 2023 · 2 comments · May be fixed by #1246
Assignees
Labels

Comments

@srose
Copy link
Contributor

srose commented Jun 7, 2023

Current Behavior

When importing a user configuration that represent a service account, they must have a serviceAccountClientId attribute. This attribute points to the clientId of the client to which this user belongs.
When importing, the user is retrieved and compared, the retrieved user does not contain the serviceAccountClientId attribute. Therefore, the comparison between the user being imported and the existing user always hits as a change and an update is called even though there is no change.

Expected Behavior

The overall idea of keycloak-config-cli means, that api-calls are only triggered in case of a real change.

Steps To Reproduce

1. Definition of a service-account-user (together with a client) in yaml/json
2. Run Import
3. Change the file, but not the user definition to make the import logic start again
4. Run Import
5. See UPDATE USER Event for the service-account-user not changed.

Environment

  • Keycloak Version: 21.1.1
  • keycloak-config-cli Version: 5.6.1
  • Java Version: 17

Anything else?

Would be great to get some discussion/adivce:

  • Should keycloak return the filed?
  • Should the import ignore the field when checking for changes?
  • ?
@srose srose added the bug label Jun 7, 2023
@Motouom Motouom moved this from Todo to Ready for Dev in os-competence-center-board Nov 28, 2024
@AssahBismarkabah AssahBismarkabah self-assigned this Dec 17, 2024
@AssahBismarkabah AssahBismarkabah moved this from Ready for Dev to In Progress in os-competence-center-board Dec 17, 2024
@AssahBismarkabah
Copy link
Collaborator

Hi @srose
thanks for reporting this issue ;)
the complete realm export from keycloak has some other properties which if not defined in your configuration will still be used by kccli realm-Representation during a realm import.

I created a fix for your use case with the user by excluding the attribute from keycloak
it is worth noting that the issue might persist for other properties if not explicitly defined in your JSON import.

@AssahBismarkabah AssahBismarkabah linked a pull request Jan 7, 2025 that will close this issue
1 task
@AssahBismarkabah AssahBismarkabah linked a pull request Jan 7, 2025 that will close this issue
1 task
@AssahBismarkabah AssahBismarkabah moved this from In Progress to Review in os-competence-center-board Jan 7, 2025
@Motouom
Copy link
Collaborator

Motouom commented Jan 8, 2025

When applying a JSON or YAML configuration to Keycloak, a comparison is made between the realm defined in the Keycloak console and the configuration you are attempting to import. This process can lead to unintended updates due to additional configurations that Keycloak automatically includes during the import process.

For example, if you apply a simple and empty realm configuration like this:

{
  "realm": "simple"
}

At first glance, it may seem like you’ve only created an empty realm. However, if you export this same realm after the import, you’ll notice that Keycloak has added extra configurations beyond what you initially defined. These additional configurations are automatically provided by Keycloak and can cause unwanted or unnecessary updates during subsequent imports.

It’s important to understand that these changes are inherent to how Keycloak operates. While some of these attributes can be safely ignored, others may require proper handling or adjustments in your configuration to prevent issues. For example, certain scenarios can be addressed correctly or fixed, as demonstrated in specific cases like #883

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Development

Successfully merging a pull request may close this issue.

3 participants