Purpose of IdentityService

Camunda 7 Topics Discussion & Questions
1

Hello,

could somebody please explain why there is the identity service? What is its purpose?

  • In the camunda GUI, I know of no places where I could walk through the user directory. When assigning permissions, I have to type the user and group names manually, there is no dropdown lists

  • In the process code (Java Delegates), in async jobs, the identity service does not deliver any information (as. e.g. discussed here)

  • if the application code wants to know the user and its memberships it could install all the necessary pieces (e.g. servlet filters etc.) at the application level and integrate any technologies it needs.

So my question is: why is there the IdentityService in the camunda engine? How does the engine use it?

Thank you for any information.

1 Like
2

Admin uses the identity service heavily, e.g. to display lists of users, groups, memberships etc.

In Cockpit & Tasklist, whever you see a full user name, the identity service is used. Furthermore it is used when authorizations are evaluated, e.g. if you log in as a user, the identity service is used to resolve your groups and all authorizations for your user as well as your groups are applied to all of your actions.

3

Thank you @thorben for the quick reply. From it, I still fail to understand why the identity service should be integrated into the engine. For the cases you described, the integration into the GUI (e.g. the code of the application that uses/calls the engine) would be enough IMO.

4

Out of intereset, I looked into the Flowable project, another BPM system of activiti ancestry. In their implementation, they removed some services, see here.

IdentityService is still there, AuthorizationService (e.g.) has disappeared.

5

AuthorizationService was built by us after we forked Activiti, so I assume the Flowable codebase never had it.

6

Ah… Thank you for the info! But the question still remains: Why does the process engine need all these services? The engine should not need them IMO. The GUIs that call the engine API (e.g. cockpit or REST-API) should need them.

7

That’s a tough question because the answer is rather subjective. As written above, certain functionality has to be in the core engine from our point of view, because it integrates with the rest of the engine via classes/features that are not public API. Other may not strictly be required there, nevertheless we have decided to build it into the core engine at some point (e.g. also based on the decision that the core engine should have such features, which is again a subjective design decision).

Cheers,
Thorben

8

I’ve inspected the code. Indeed, e.g. the AuthorizationService occurs only in some tests and in the implementation of the REST API (and in admin user bootstrap plugin, but it does not count IMO). Hence it should be possible to get rid of this (and some other) services in the engine and move them into web apps. This would also reduce the REST API.

But this would be a major untertaking, not worth without a big need.

9

Hi @fml2,

the benefit of having the authorization built in the core engine is security.

Independent of the API (Java or REST), every identified call is checked if the caller is allowed to access the result.

Hope this helps, Ingo

10

I’m not sure the permissions are checked in the Java API. My understanding is that the Java API just does what it’s told to. It has no notion of a “user”. Only the outer tiers have as they also provide authentication infrastructure.

My experience is that I can call any Java API (e.g. within a web app) without having to worry about the current user.

Could you please point me to the right docs? Thank you!

11

I believe there are some configuration to enable authorization even for custom code . Below are the springboot properties.

amunda.bpm.authorization .enabled Enables authorization Camunda default value
.enabled-for-custom-code Enables authorization for custom code Camunda default value
.authorization-check-revokes Configures authorization check revokes Camunda default value

https://docs.camunda.org/manual/7.13/user-guide/spring-boot-integration/configuration/#camunda-engine-properties

1 Like
12

This is a valid point I forgot about. The application can configure itself so that it not always will be allowed to do anything it wants. He-he. I have to read up on how the application can provide to the engine the information about the current user.

13

Hi @fml2,

identityService.setAuthenticatedUserId("john");
// now invoke the engine API
taskService.createTaskQuery().processDefinitionKey("invoice").list();

will do the trick. The user Id is saved as thread local and can be checked before the engine hits the database.

Hope this helps,

Ingo

1 Like
14

Yes, I see that it’s done in ProcessEngineAuthenticationFilter (which is presumably used in the REST API).

Interestingly, ContainerBasedAuthenticationFilter (which is used in the cockpit IIUC) does not set the authenticated user for the identity service. Does this mean that the cockpit as a web app takes over the auth control and does not rely on the infrastructure present in the engine?

15