I’m going to integrate Camunda Spring Boot Starter with Keycloak (http://www.keycloak.org/). I know I’m not the only one (@Ashutosh is a good example). I think I have to create own implementation of Identity Provider (tell me if I’m wrong). I’d say it’s also necessary to create filter for REST API. Do you guys have any ready to use solution? Or any experience with that?
Keycloak provides a WildFly/JBoss plugin. So, it’s not too difficult to manage access controls, via KeyCloak, for any application on that platform.
From my experience, the tricky part is integrating Camunda’s role-based participant assignment. This is where the correct role is sourced (by name), applied, and referenced during “task ownership” and “completion” activities.
Though KeyCloak also provides a slick web-UI for user/role mapping, not sure you’d want this to replace Camunda (given training overhead, confusion, etc., etc). My early workaround (before KeyCloak) was to config’ WildFly to RBAC (role based access control) and set the DB lookup those fields/tables Camunda uses for this purpose. The goal here is to allow Camunda admins to manage users/groups/roles via Camunda while supporting seamless integration to WildFly’s RBAC.
Where I left off in my investigation:
- KeyCloak works very well for managing SSO type access into WildFly and it’s hosted application (the easy part)
- Setup a simple JAX-RS/ReST client to access and user’s information. This information is then passed into Camunda via APIs. Noting that I used Java 8 w/Camunda’s generous CDI integration. This is more in-line with traditional Java 8, RestEasy.
- Though I did try out Camunda’s recommended approach to 3rd party access controls (from my memory… via filtering/interceptors), I did not like this solution as it didn’t blend well with Camunda’s user admin features.
Adding KeyCloak to this mix: I still need to integrate Camunda’s user/group admin controls with some form of external registry. I want to preserve full functionality - this means I need to integrate provided Camunda CRUD controls, via LDAP API calls or direct KeyCloak - this is an open question…
NOTE: KeyCloak provides OpenID w/o requiring external integration with OAuth2 providers. This is CRITICAL as I seriously wanted to avoid these dependencies (i.e. avoid external “cloud” providers - at least during dev/devops cycles).
Thank you @garysamuelson. This is more than enough. I’ve decided to write my own Keycloak client. I can easily get a user / all users / a group / all groups. I’m going to implement ReadOnlyIdentityProvider interface. I’m quite sure (tell me if I’m wrong) that WritableIdentityProvider is beeing used only by Camunda Cockpit Webapp. Do you know to connect users and groups?
You have to implement the interface GroupQuery, especially method groupMember(String groupMemberUserId)
Have a look at the example of the DbGroupQueryImpl and it’s super classes to get an impression how it may work.
Hope this helps,
I’m interested in how the solution pans out.
Another interesting problem I’ve found with most (or all) contemporary identity management frameworks is that they have very little built-in concept (as features) for long running, business transactions. This means that when a user’s identity requires some form of carry-forward (similar to SSO), we’re stuck with custom integration code.
- user A starts a process.
- We then use a “surrogate” identity for system/sub-system service requests (classic SOA “fan-out” into infrastructure).
Step #2 is similar to how we call on JDBC connectors using user/pass credentials stored within the container. For example, we tend to not apply user A credentials for database access.
Ideally, we avoid single-point identities for blanket access into data-stores. Unfortunately, this is a common approach.
What I’ve done to solve this problem is to add BPM-specific policies (supporting long-running business transactions) to the identity/risk manager. These policies allow BPM task implementations to “call-back” and check policies prior to picking up fresh tokens for pass-through into SOA. The identity/risk manager has final say-so on what’s allowed forward. Though this slows down execution… we’re able to centrally manage access/risk. MOST importantly is that we remove potential short-ciruiting of access policies via Camunda proprietary user/group registry. Noting that Camunda’s built-in registry isn’t the problem here as it’s perfect for most requirements.
I have some findings here on Keycloak integration, please share your thoughts.
First of all, why we need Keycloak integration:
- central user/groups administration
- singe sign-in / sign-out
- easy LDAP integration
I think, there are several things to implement:
- Authenticate requests with Keycloak token.
- Authorization support utilities: user/group queries
- Optional: admin operations: CRUD users, groups, membership.
The parts 2 and 3 is documented and can be done with a custom ReadOnly/WritableIdentityProvider wrapping a Keycloak API client.
I searched through source code of
camunda-bpm-spring-boot-starter-webapp-core and found these:
registerFilter("Authentication Filter", AuthenticationFilter.class, "/*");
registerServlet("Admin Api", AdminApplication.class, "/api/admin/*");
Is there anything missing?
I can probably just ignore
UserAuthenticationResource registration and simply throw exception from
checkPassword. What about
AuthenticationFilter? May be we need a PR here to make
CamundaBpmWebappInitializer more flexible?