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.

[ingorichtsmeier]

Hi @conceptualshark, I've removed to mention Keycloak from this pull request. I came to the conclusion, that the generic description with OIDC terms is good enough.

Could please review the changes and merge them, if they are OK?

[conceptualshark]

To make this additionally generic, would the following be appropriate?:

Suggested change

	2. For all components except Web Modeler, the application has to be of confidential access type. For Web Modeler, which is a single page web application, the application has to be of public access type.
	2. For all Components, ensure the appropriate application type is used:
	- **Operate, Tasklist, Optimize, Identity:** Web apps requiring confidential access/a confidential client
	- **Modeler, Console:** Single-page applications requiring public access/a public client
	except Web Modeler, ensure the application is confidential. For Web Modeler, which is a single page web application, the application has to be of public access type.

I've added Console here as it's listed as a single-page app so I expect it would have the same requirements as Web Modeler - do you know if this assumption is correct? I think this bridges the gap between the original Keycloak ask and also remaining generic for other OIDC providers which might require a version of this information.

[ingorichtsmeier]

Hi @conceptualshark, I haven't used Console in my self-managed setup so far, but it is mentioned in the MS Entra section. It should be correct to add it here.
Your change improved it a lot, let's go to master!
Thank you!

[conceptualshark]

👍 I've backported the suggested changes, and only added Console to the list to /next and 8.6. This looks good on my end, but let me know if you'd like any additional technical review before merging.

[ingorichtsmeier]

Hi @conceptualshark,

let me know if you'd like any additional technical review before merging.

No, let's go to main and bring this to the public.