IdentityService based on Spring Security

[Matthias Brenner]

Camunda provides the database based IdentityService and an implementation which uses LDAP. This can be introduced with the appropriate maven dependency and a modified configuration.

I want to use Spring Security as IdentityService and probably later on for authorization. Cloning the LDAP identity services and replacing the LDAP code with an appropriate Spring implementation should provide the requested functionality.

@Camunda developers: Is this the appropriate procedure, will you support us by implementing this feature?

Implementing the service this way would also ensure, that there can be single point of responsibility in the application providing authentication and authorization based on Spring functionality. At the moment I did not check how I could introduce authorization by Spring into Camunda. Therefore this request only deals with authentication.

The interesting thing on Spring Security is, that it supports quite a lot of authentication systems e.g.

• LDAP
• various HTTP based authentication systems
• JAAS
• Kerberos
• many others

So this plugin could open the system for may customer requests.

[Daniel Meyer]

Hi Matthias,

Thank you for this input.

Couple of years ago when we started work on the web applications, we also experimented with Spring Security. It was our first impulse to "just integrate with Spring Security and be done with it".

We also created a prototype implementation but found some limitations:

- Authentication:

It was possible to use Spring Security as Http Request authenticator.

The only problem we had: the camunda webapp can manage multiple process engines / connect to multiple process engines in a single HTTP Session. This is used for multi tenancy [1].

It was unclear to us how we could manage multiple authentications with spring security.

- Authorization:

It was possible  to use Spring Security as Http Request authorizer (ie. determine whether a given request can be performed given the current authetication or not.)

However there were two problems:

-- We wanted to have integrate authorization at a "lower level". In Camunda authorization also works on the Java API level [2].

-- While some authorization concerns can be realized by simply forbidding some requests: example: POST /task/{id}/complete, others cannot. Example: GET /task/?createdAfter=2012-12-12. The latter request must only return tasks which the currently authenticated user is authorized to "see". This cannot be implemented efficiently at any level higher than the database. Ie. you cannot simply fetch all tasks and then remove those that the current user is not authorized to see for perfromance reasons and also paging etc...

- User / Group Repository

We already had an API for user / group access (cf. "IdentityService"). So the question was: is Spring Security a provider for that or is that a provider for Spring Security. Both options lead to problems.

These are some of the reasons why er did not go with spring security but rather implemented a minimal set of components ourselves.

Having said that: if you find a way to integrate spring security, maybe not for all of the above mentioned aspects but for some, we will assist you by answering questions here in the forums.

You can also provide the resulting code as community maintained extension to others.

Regards,

Daniel

[1] http://docs.camunda.org/7.3/guides/user-guide/#cockpit-dashboard-multi-tenancy

[2] http://docs.camunda.org/7.3/guides/user-guide/#process-engine-authorization-service

[Matthias Brenner]

Hello Daniel,
thank you for the answer.

Despite the problems you explained, we will go for the next step and implement a replacement for the IdentityService.

How should we start? Will you provide a repository or shall we start in our own environment?

Kind regards
Matthias

[j...@atlas.cz]

If you need authorities you can call anywhere (+ null checks): SecurityContextHolder.getContext().getAuthentication().getAuthorities()
Simillarily you can call SecurityContextHolder.getContext().getAuthentication().getDetails

I expect you have your own Authentication class, hence you can store there whatever you need.

[Matthias Brenner]

Hello,

looking deeper into the source code, I recognized, that there is probably some missunderstanding regarding the identity service.

The LDAP plugin does not implement the interface IdentityService. It is a plugin and the the engine directs requests to the LDAP plugin. So at the first step, we should discuss, whether we should implement an identity service or a spring security plugin.

We will provide the source code to Camunda, is there a contact partner who can support us during development. I invite you to participate at all development decisions.

Kind regards
Matthias

[Daniel Meyer]

Hi Matthias,

Probably it would be best to start by provide an implementation for the
org.camunda.bpm.engine.impl.identity.ReadOnlyIdentityProvider SPI.

Daniel

[Matthias Brenner]

Hello Daniel,
we propose the following architecture:

We write a delegating proxy for the existing DbIdentityServiceProvider. All requests to identity relevant stuff will be forwarded to the existing provider.

The only call we provide an own implementation will be checkPassword(String, String); We use this call to read all security relevant information from Spring Security and update the Camunda DB.

This should solve the performance problems which might raise if we would use access to Spring Security through all calls. The limitation is, that security information will only be updated during login of the user.

Do you have any notes to this procedure or do you agree with the architecture?

Kind regards
Matthias

[Daniel Meyer]

Hi Matthias,

sounds good! You could also think about providing a pull request which extracts the checkPassword(String, String) into a seperate SPI interface so that you can exchange only that one.

WDYT?

Daniel

[Matthias Brenner]

Hello Daniel,
the process of implementing access to Spring Security is almost done. We specialized the DbReadOnlyIdentityServiceProvider and use the class DbIdentityServiceProvider as delegate to forward all requests we do not overwrite. The only method we implemented is

public boolean checkPassword(String userId, String password)

The remaining stuff is unchanged.

Missing at the moment is a job which updates all users, groups and memberships within a configurable timespan. This is necessary, because user may leave groups without performing an login. In this case the regularly running job will provide Camunda with the information.

Now I want to know, whether the implications are OK.

• If we do like this, there is no chance to setup local users (the plugin is a specialization of DbReadOnlyIdentityServiceProvider). If this would be required for administration purpose, the implementation should be able to distinguish between local and remotely defined users.
  
• If the security service behind Spring Security is down (e.g. LDAP) no authentication will be possible.
• Between changes of LDAP information and propagation of the change to the system is a time gap, defined by the regularly running job.
  

Now we start working on the job.

Kind regards

Matthias

[Daniel Meyer]

Hi Matthias,

sounds good so far. I think that it will be crucial to document the mechanisms and provide setup instructions.

Regards,

Daniel