Hi Bernd,
we had the very same requirement, too. We wanted Activiti to base on an already existing proprietary user database instead of its own one.
There is a ProcessEngineConfiguration.setIdentitySession() API that allows for setting a custom implementation of the identity service (although, the default implementation is then created unnecessary).
The problem here is: Activiti accesses the IdentitySession (not IdentityService) implementation internally from many places (via commandContext.getIdentitySession()), so it was of no help to customize the IdentityService, but we had to implement our custom IdentitySession instead. Otherwise, Activiti would still use the default implementation which accesses the user/group information from the Activiti database in many places.
In order to configure the custom IdentitySession, we extended the ProcessEngineFactoryBean (since we use Spring to configure the engine) and set the custom IdentitySession using the following "hack":
@Override
public ProcessEngine getObject() throws Exception {
processEngineConfiguration.getSessionFactories().put(IdentitySession.class, new SessionFactory() {
@Override
public Session openSession() {
return (Session) identitySession;
}
});
return super.getObject();
}
In my opinion, we should streamline not only the configuration, but also the concept of the services and the sessions so that customizing one implementation and configuring it via a proper way is possible. This could be done, e.g.
a) by providing a clean way to configure a custom IdentitySession and keep Activiti accessing the IdentitySession directly
b) keep the current configuration option for the IdentityService, but make sure Acitivit never accesses the IdentitySession directly
c) any other clean way that works 😉
(Disclaimer: all information bases on 5.0.beta1 and might have changed since)
I hope this helps.
Regards,
Christian