Add special config for Web Modeler application/client

[ingorichtsmeier]

Description

Using Web Modeler in a cluster with Keycloak as OIDC provider cause trouble at login.

This pull request adds a hint to separate between confidential and public clients/applications. This separation is already available in the MS Entra configuration section.

I've also added a sentence how to apply this setting in Keycloak.

Benefit: Most users will use Keycloak as a generic provider, and it's not perfectly clear, how the general terminology from the OAuth specification is used in the Keycloak user interface.

Downside: It is not a clean, generic description anymore.

As I have struggled some hours to resolve the issue in my configuration, I think it's worth to mention Keycloak here explicitly. The rest of the description was OK to apply.

When should this change go live?

• This is a bug fix, security concern, or something that needs urgent release support.
• This is already available but undocumented and should be released within a week.
• This on a specific schedule and the assignee will coordinate a release with the DevEx team. (apply hold label or convert to draft PR)
• This is part of a scheduled alpha or minor. (apply alpha or minor label)
• There is no urgency with this change and can be released at any time.

PR Checklist

• My changes are for an already released minor and are in /versioned_docs directory.
• My changes are for the next minor and are in /docs directory (aka /next/).

• My changes require an Engineering review, and I've assigned the Engineering DRI or delegate.
• My changes require a technical writer review, and I've assigned @camunda/tech-writers as a reviewer.

[conceptualshark]

Hey @ingorichtsmeier, these pages are for any OIDC provider other than keycloak, and this section is for a generic/bring-your-own-provider setup. We do have the following page for Keycloak: https://docs.camunda.io/docs/self-managed/identity/user-guide/configuration/connect-to-an-existing-keycloak/

The guide for Keycloak does mention client authentication, but does not call out web modeler specifically. Would this be more appropriate added there?

[ingorichtsmeier]

Hi @conceptualshark, as said in my initial comment, many customers use Keycloak, but are not able to connect to it in the ways that we describe in "Connect to an existing Keycloak". The reason is, that the prerequisite "Access to Keycloak Admin Console" will not be granted to any application in the company.

Then we are on the track of using Keycloak as an OIDC provider. The admins will create the clients and share the client secrets with the Camunda installation team. This is much less invasive than granting admin access.

The guide for Keycloak does mention client authentication, but does not call out web modeler specifically. Would this be more appropriate added there?

Yes, it should be mentioned there, too. I haven't tried this config by myself, and expect using the Web Modeler with this setup will fail as well. But I would put this improvement into another pull request, as it requires different testing beforehand.

What do you think about my proposal?

[conceptualshark]

@ingorichtsmeier I think I need a little more context to understand this ask; I'm still not sure why adding it to the non-Keycloak guide is the most helpful place to have this information.

• the prerequisite "Access to Keycloak Admin Console" will not be granted to any application in the company.

A user, not the application, must have console access to create the clients and access the secrets, which seems in line with your next step:

• The admins will create the clients and share the client secrets with the Camunda installation team.

Do the admins creating the clients do so in the Keycloak console, following the existing Keycloak guide? The difference I see in your explanation is steps 11 and 12 would be done by the Camunda installation team, not necessarily the same Keycloak admin, but if the Client authentication toggle is only in the UI, it would make the most sense to be documented there.