initialize-benchmark-entities.sh fail to create clients

[burigolucas]

Describe the bug

The function create_oidc_client in the script initialize-benchmark-entities.sh has a hard-coded clientId and secret name failing to create clients required for benchmarking.

Version

26.1

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Anything else?

No response

[mhajas]

@burigolucas Unfortunately, I needed to revert changes introduced in #1134. It seems there was a misunderstanding about the purpose of -c parameter for initialize-benchmark-entities.sh.

This script is creating two clients, one with service account enabled, and the second without. CLIENT_ID variable is supposed to be used only for the first one. We cannot use the same as clientId needs to be different for the second client. Feel free to open a PR where you add another parameter for the script with the input defaulting to client-0 if you need this.

[burigolucas]

Hi @mhajas, thanks for getting back to me. There are a few points that needs to be revised:

1. Both function create_service_enabled_client_assign_roles and create_oidc_client create clients with service account enabled. I propose we change the function create_oidc_client in order to not enable the service account.
2. Hard-coding a clientId breaks the script when executing it a second time since the client already exists.

I propose the following changes:

• add a parameter -s for the service account name, with default value of gatling
• use the parameter -c for the oidc client, with default value of client-0

Finally, we need to agree on how to handle duplicated entries. Right now, the script will exit after failed to create a client that already exists, therefore not creating the user. We could either always check if it exists before creating the entity like it is done for the realm, but this will be very slow. Another option is to only try creating the entity if the parameter is set. The a user can easily use the script several times, for example in a loop, to create multiple entities in the same realm. For the service account, I propose we check if it exists first, like it is done for the realm as I assume there is no need to create many such entities.

What do you think?

[mhajas]

1. Both function create_service_enabled_client_assign_roles and create_oidc_client create clients with service account enabled. I propose we change the function create_oidc_client in order to not enable the service account.

I am afraid we can't do this. This can be a breaking change for some users. People can use the client-0 also for client credentials grant.

• add a parameter -s for the service account name, with default value of gatling
• use the parameter -c for the oidc client, with default value of client-0

I like your suggestion, however, I am again afraid this may be a breaking change for people using this script. I would prefer keeping -c as is and add one more parameter for setting name for currently hardcoded clientId.

Maybe we can go with -t as testing client id?

Finally, we need to agree on how to handle duplicated entries. Right now, the script will exit after failed to create a client that already exists, therefore not creating the user. We could either always check if it exists before creating the entity like it is done for the realm, but this will be very slow. Another option is to only try creating the entity if the parameter is set. The a user can easily use the script several times, for example in a loop, to create multiple entities in the same realm. For the service account, I propose we check if it exists first, like it is done for the realm as I assume there is no need to create many such entities.

We could add one more boolean option that enables behavior that checks whether client exists before creating it.
Another idea is to add an option to admin client cli that considers 409 response code as success for create command when specified.

Also, I am not sure I understand the slowness concerns you have. Do you use this script to create many clients? Have you considered using Keycloak dataset provider for that? It should be much faster than admin client.