THIS REPOSITORY IS UNMAINTAINED !!

We switched to Camunda Zeebe and therefore have no need for this integration anymore. Habe a look at https://github.com/camunda-community-hub/camunda-platform-7-keycloak, which supports more recent versions aof camunda.

Camunda SSO for WebApps / REST-API

Enables SSO to Web-Apps / REST-API. Uses https://github.com/camunda/camunda-bpm-identity-keycloak as Identity-Provider, so there is no need to configure groups in Camunda

Runs as a fully configurable docker-image based on the Tomcat-Distribution of camunda.

Issues with Camunda Groups and the Keycloak identity-plugin

Unfortunately it is not possible to user Keycloak-Roles only with the keycloak-identity-plugin. Basically it boils down to the fact that keycloak can only retrieve directly assigned users of a role.

See details camunda-community-hub/camunda-platform-7-keycloak#3

Groups alone are not working for Keycloak-Service-Accounts, so we need roles anyway. Our approach is to have both groups and roles with the same name. Roles are added to the corresponding groups (This is a little bit cumbersome) For those that don't use the REST-API - you can skip the roles alltogether.

Keycloak Configuration

For Details see: https://github.com/camunda/camunda-bpm-identity-keycloak

AND/OR

• Create confidential client with service-accounts enabled
• Add valid Redirect-URL (Base-URL of your camunda webapp, eg https://my.domain.org/camunda/*
• Give the client the permission to query users&groups and to view users
• Be sure that roles are added to your JWT (this is the default behaviour of Keycloak)
• Create camunda-admin role in your client
• Create Camunda-Admin group, assign the camunda-admin role to it
• Add user(s) to the admin-group

Service-Account REST-API Client

If you have a "machine" client that has to connect to the REST-API, do the following

• Create confidential client with service-accounts enabled only (no standard flow)
• enable service-accounts
• Add the required roles to this service-account
• Be sure that roles are added to your JWT (this is the default behaviour of Keycloak)

The roles have to exists as groups in Keycloak. If you don't have the identity-plugin configured to use goup-names (useGroupPathAsCamundaGroupId), you have send the internal-id of the group in the claim manually.

Build Docker-Image

Allthough it is possible to run it non-dockerized, this README will focus on how to build the docker-image.

Requirement: Build this PLUGIN and either push it to a maven-repository that is available to you, or build and install it on your local box.

 mvn install
 cd ./docker
 make

This builds a docker-image based on camunda/camunda-bpm-platform:tomcat-7.14.0.

It builds the image with the following name camunda-7.14.x-identity-keycloak:

All options to Make

Option	Description	Default
DOCKER_CMD	Which docker cmd to use	docker
BASE	Base-Image	camunda/camunda-bpm-platform:tomcat-7.14.0
CAMUNDA_RELEASE	Used to get thrid-party-libs depending on camunda-version. Do not touch	7.14.x
DOCKER_REPO	Used in target docker_tag to prefix the built image	some-repo.org
DOCKER_ORG	Used in target docker_tag to prefix the built image	witcom
DOCKER_RELEASE	Tag for the built image	1.3
DOCKER_BUILD_ARGS	Additional build-args	-
IDENTITY_KEYCLOAK_RELEASE	Version of identity-plugin to use	2.0.0
AUTH_KEYCLOAK_RELEASE	Version of this plugin to use	1.3

Run

Just pass the needed ENV-Vars. See Configuration

docker run --rm -p 8080:8080 \
 -e KEYCLOAK_BASE_URL=https://xxx/auth \
 -e KEYCLOAK_REALM=witcom \
 -e KEYCLOAK_CLIENT_ID=camunda-resource-server \
 -e KEYCLOAK_CLIENT_SECRET=SECRET \
 camunda-7.14.x-identity-keycloak:1.3.0

Configuration

The SSO-Plugin can be configured by setting env-variables (except the keycloak-client-configuration, which has to done with the keycloak.json file) In the docker-image this is done automagically ;-)

It re-uses some of the variables introduced by camunda-bpm-identity-keycloak

Variable	Description	Used in camunda-bpm-identity-keycloak ?
KEYCLOAK_EMAIL_AS_ID	Whether to use the Keycloak email attribute as Camunda's user ID. Default is false. Both keycloak-identity-service AND SSO-Plugin have to be configured identical.	YES
KEYCLOAK_USERNAME_AS_ID	Whether to use the Keycloak preferred-username attribute as Camunda's user ID. Default is false. In the default case the plugin will use the internal Keycloak ID as Camunda's user ID. Both keycloak-identity-service AND SSO-Plugin have to be configured identical. Note:takes precedence over KEYCLOAK_EMAIL_AS_ID	YES
KEYCLOAK_CLIENT_ID	Camunda Keycloak-Resource-server	YES
KEYCLOAK_FILTER_CLAIM_GROUPS	Defines in which claim of the Access-Token the client's groups are listed. You only need that if you don't use keycloak default roles	NO