Keycloak call /auth/admin/realms/Test-Realm/users?max=250 is taking over 2 minutes

[MarvinKern]

Hi, I am using the camunda-platform-7-keycloak 7.17.0 version in a java springboot project with camunda version 7.14.0 to launch the camunda cockpit/tasklist. Everything was working fine, but at some point the loading of the tasklist processes for some filters took a long time (about 2 minutes). Its not for all filters, only for some and I am not sure which criteria causes it to take so much time. The filter that takes so much time to load has only 9 open tasks. I activated the debugging logs to see what takes so much time. The result is, that the keycloak call to /auth/admin/realms/GEFA-Intranet/users?max=250 takes over 2 minutes. However I am asking myself why we would need this call? Couldn´t the plugin make a much more specific call instead of just loading 250 users from keycloak? This call is not even loading the users that we need in the process, it´s just loading every user, even the ones that don´t have roles that are needed for this process.

In the code I found the interesting part in the class KeycloakUserService with the method createUserSearchFilter. There the call for Keycloak is created. It seems that this method is adding some arguments to make a specific call to Keycloak, but somehow in our case this call isn´t specified anymore, so we are loading just all users.

Do you have any idea why the method is not creating a more specific call anymore for keycloak?

Tanks in advance for your help.

[VonDerBeck]

Hi @MarvinKern,

the Keycloak Identity Provider has no influence on how the IdentityService of Camunda is used from the outside. If someone - in this case the tasklist - says "give me all users" the plugin requests all users... The mentioned method creates the user search filter according to the arguments given by the IdentityService API, there is no magic behind that.

So this is not an issue with the plugin itself, but more about the implementation of the Camunda Tasklist. As you already mentioned this condition is filter specific. So you can either optimize your filter or check if this is Tasklist specific and in a newer version of Camunda the behaviour has been optimized (e.g. check the Release Notes).

[MarvinKern]

@VonDerBeck Thanks for your really quick answer.

In one of my filters that is really slow I defined one group that has the rights to read the filter. I would expect the tasklistk / keycloak plugin to only call for users from keycloak that are in that group, but like I mentioned its calling for all users. Whats also strange to me is, that we have the same application in 3 different environments, but only in one of the environment the filters are really slow. So I have the feeling its not about the definition of the filter, its maybe more about the tasks themselves, but I am really not could be wrong with them.

[MarvinKern]

I found out, that the calls that are made to Keycloak are dependant on the assigned persons to a tasks. There are 2 scenarios:

1. I have several tasks in my filter, but only one person (TestUser) is assigned to those tasks, the plugin is making following calls: /auth/admin/realms/Test-Realm/users?email=TestUser /auth/admin/realms/Test-Realm/groups?max=250

2. I have several tasks in my filter and different persons are assigned to the tasks, the plugin is making following call: /auth/admin/realms/Test-Realm/users?max=250

@VonDerBeck One quick win for me would be to have the maximum size of the users, which is currently set to 250 by default, configurable. Do you think that is an option?

[VonDerBeck]

@MarvinKern: restricting the maximum number of results in a query is easy - just have a look at the configuration options. maxResultSize does the job. Just try it and let us know. The other option is to check Keycloak configuration itself. Are there some synchronization options leading to higher load than required? ...?

[MarvinKern]

Sorry for the late response. We solved this issue with the help of configuring the maxResultSize attrbute to 50 and setting the cachEnabled to true :)

[VonDerBeck]

👍