Context

We (Consulting) experience an increasing number of tickets and questions around SSO and Camunda. With the ContainerBasedAuthenticationFilter, it is now quite easy for users to implement SSO.

However, this only solves the problem of authentication. Often users ask how to integrate with the IdentityService once SSO is figured out.

I have seen different approaches and workarounds for the identity part in recent missions:

• No IdP: basically, let the default DatabaseIdentityProvider in place with only the admin user configured. This is possible if users don't need to query the IdentityService. Limitations are:
  • whenever someone accesses the web apps, a warning will show up in the logs, because the authenticated user cannot be found by the IdentityService
  • it is not unlikely that the web apps display user ids that look like c2c51960-2609-4f27-a434-9ea15a1acad3
  • users are forced to implement SSO for Optimize, because otherwise Optimize uses an IdentityService query to authenticate users. (there is a FR to improve SSO in Optimize, see OPT-2395)

• use the ldap plugin as an IdentityProvider:
  • this only works if there is some LDAP-compatible system available - which is not always the case (e.g. Azure Active Directory, other cloud-based identity services)
  • LDAP configuration needs to be maintained twice - for the SSO (e.g. keycloak) and the engine plugin (even more for setups with multiple engines)

• implement a custom IdentityProvider. This is not a very straightforward task, because:
  • the current implementations (DB/LDAP) heavily rely on internal APIs (Querys, CommandContext)
  • that means deep understanding of the engine internals is needed
  • and we don't guarantee that the internal APIs don't change in the future
  • further, some of the query criteria are not supported by other systems. There is a community implementation for a keycloak IdentityProvider that basically fetches a big list of users and filters them on the client side because keycloak doesn't have all the query criteria exposed as APIs

Proposal

I think two options are worth discussing here:

• provide an easier-to-use plugin point for custom IdPs that abstracts the internal APIs better
• provide a supported generic IdP implementation for Open ID Connect. Most of the IAM systems nowadays support OIDC and SAML as the two standard protocols. OIDC is the one that seems to be more popular with new projects. I don't know if it's possible to come up with an implementation that can be configured to work with a majority of the services out there, but I could imagine it is, since OIDC specifies that there must be an API endpoint for UserInfo.

Hint

Feel free to change the description and add comments as you like. My main intention for this ticket is to have a spot for a streamlined discussion about the topic.