Questions On Camunda Integration

Camunda 7 Topics Discussion & Questions
1

Hi,

I have some questions:

  • How can camunda be integrated in an application so the user base will be the one from the application, not from camunda. So I don’t have to create 2 accounts for each user?
  • I have a task management module in my application. Can I integrate camunda in a way that generates the users’ tasks in my application, rather than getting the user tasks from the REST API?

Thanks

2

Yes. And, the application would be a lot less “chatty”. To paraphrase, you simply want Camunda to directly send work-requests into your application. This approach in contrast to your application needing to do some sort of polling and querying to figured out what gets done next.

The advantage of Camunda directly sending or originating events, rather than waiting to be asked, is that you better encapsulate and preserve system boundaries.

1 Like
3

Centralized user-registry (LDAP) is the more-typical approach to avoiding multiple identity stores/databases. Another option is setting up a “trusted environment” or “trusted server” relationship whereby one server can “assert” an identity while it’s making an outside request. Ideally, all associated servers all use the same, centralized LDAP provider

Basically, the approach/technologies - to name a few:
These supported by many Application servers…

  • Centralized LDAP provider. This is your openLDAP or Active Directory solution. All your application servers then use this single source of user and group information. From here you have your basic group membership (i.e. organizational hierarchy). Many LDAP providers also now support role-based access - meaning users are granted access per their role-relationship to assigned tasks. Here’s a somewhat dated but relevant article (pdf).

  • Identity Assertion. This approach has one server simply telling another server information about the originating request owner - or, who is making the initiating request. This approach should also include a centralized LDAP/identity-store. Web-services (and a few others) support this technology.

  • Single Sign-on (SSO) and Identity Pass-through. An encrypted token is passed between the servers. For websphere, this is often an LTPA/LTPA2. These are also called “cookies”. On the recieving server of one of these tokens/cookies reviews (decrypts) and then looks up the user’s identity. Both servers need to share the same LDAP provider. EJB solutions directly pass the “subject” during inter-host communication.

  • EJB and JAAS is also a natural fit - though, has fallen somewhat out-of-favor. It’s a little on the complex side and gradually becoming a lost-art (example: most are now favoring ReST instead of RMI). JAAS still comes into play with ReST (etc). I’m currently verifying this capability on the Wildfly platform. I can see the “subject” getting reset after an authenticated ReST service invocation. But, I’ve traditionally used EJB to pass “subject” between app-servers (per memory… since I don’t see much EJB these days).

  • Certificate Authentication. The requesting server uses an encryption key that identifies itself as “trusted”. This is also called key-based authentication (or something similar).

  • etc… Noting that “risk management”, though similar topic, covers additional methods and technologies (i.e. SiteMinder, KeyCloak, etc.)

4