we have a comepletely external usermanagement system and do not want any relation (besides a string) to the actorID. For us it is perfect and it gives us very loose coupling.
Good for you,
But I think it just makes it harder if you want to add a more tighter link. For example when you want a foreign key relation between actorId and user or role table.
I guess in your case you are able to determine from your actor id:
1) if it is a role or user (or something else)
2) What the primary key is of the role and user
In this case you certainly need an extra query for retrieving roles and users corresponding with the task instances you want, which you can avoid if you have a tighter coupling.
When adding the extra table I think you have the best of both worlds no?
1: Correct, and besides that there are no clashes between user/role/group values.
2: Correct but we kind of use the string as the primary key (see 1)
We indeed have adapted the identity module so it uses an additional query. We also want this since it makes the group membership dynamic.
Before extending the identity module in jBPM (you can do it yourself atm) we should wait what 4.0 will bring. Big chance it will be redesigned and intergrate e.g. with the portal which in turn can use opensso so...
Looking forward to see how this one evolves.
could you please explain how you managed it to use your own identity component?
please help. i need this information. it's urgent.