nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

registering my own IdentityService

christoph_retti

Hi, I have written my own identity service like

public class CspIdentityService implements IdentityService, org.activiti.engine.impl.interceptor.Session {
 …
}
‍‍‍‍

and bootstrap the activiti engine using spring

  <bean id="activiti.processEngineConfiguration" class="org.activiti.spring.SpringProcessEngineConfiguration">
    …
    <property name="identityService" ref="activiti.identityService" />
    …
  </bean>

  <bean id="activiti.identityService" class="biz.i2z.connector.activiti.service.identity.CspIdentityService">
    …
  </bean>
‍‍‍‍‍‍‍‍‍‍

I also see some of my identity service methods getting called but for some reasons fetching a users tasks only work
when the groups the tasks is assigned to is also created using the excitivi explorer in the engine persistency store itself.

In the Activiti In Action book the LDAP identity service is implemented by two classes that extend the existing
org.activiti.engine.impl.persistence.entity.UserManager and org.activiti.engine.impl.persistence.entity.GroupManager
and are configured with the activiti engine using a factory approach like

<bean id="processEngineConfiguration" class="org.activiti.engine.impl.cfg.StandaloneInMemProcessEngineConfiguration">
  <property name="customSessionFactories">
    <list>
      <bean class="org.bpmnwithactiviti.chapter10.ldap.LDAPUserManagerFactory">
        …
      </bean>
      <bean class="org.bpmnwithactiviti.chapter10.ldap.LDAPGroupManagerFactory">
        …
      </bean>
    </list>
  </property>
</bean>
‍‍‍‍‍‍‍‍‍‍‍‍‍

So my question is do I really have to use this approach for my identity service to work?

I really do not want to extend from undocumented classes and also prefer to implement well-known interfaces
instead of extending existing classses.

best regards, Chris

Find more posts tagged with

Comments

frederikherema1

Chris,

yes, you have to use those classes. The API that is exposed (IdentityService) isn't sufficient for in-engine usage and hides some complexity. That's the reason the internal classes need to be adjusted, as you're altering internal behavior…

christoph_retti

Hi, I tried to change my implementation so that I can extend from UserManager and GroupManager but I face some problems

(a) in the UserManager class there is the method
public UserEntity findUserById(String userId)that has to return a org.activiti.engine.impl.persistence.entity.UserEntity. Everywhere else it is sufficient to use the interface org.activiti.engine.identity.User
and this would tie my implementation to activities own persistence layer. Is it really neccessary to use the entity class here or is it just a mistake that
you don't use the User interface here?

(b) also in the UserManager you have the methods

public IdentityInfoEntity findUserInfoByUserIdAndKey(String userId, String key)<br>public List<String> findUserInfoKeysByUserIdAndType(String userId, String type)<br>

that use internal entities

Also I do not really know what you try to query here?

Having a look at the example org.bpmnwithactiviti.chapter10.ldap.LDAPUserManager I can see that this extends the UserManager but does not
change these internal methods. So I am asking if this methods are not used at all or what problems it could cause if I don't implement them?

© In the GroupManager we have similar behaviour with the method
public GroupEntity findGroupById(String groupId)also using an entity

So what is the preferred approach to implement ons own security realm here?

Going with the UserManager and GroupManager is ok if there is no other way (and anyway I would prefer to have an interface here) but there should really
be no link to the internal persistence classes!

regards, Chris

frederikherema1

You can safely implement those methods, returning UserEntity objects that aren't really entities in the ACT_ID_* tables. Don't recall why the entities are used instead of the Interfaces themselves…

You say that it's sufficient to have the User-interface, have you checked all usages of that inside the IdentityService? If so, we should perhaps depend on User instead of UserEntity in the next versions op activiti to make extending more transparent.

Anyway, the approach you're taking is definitely the right one when it comes to extending the identity-mgmt in activiti.