-
1. Re: Identity module as an implementation of a service?
First things noted:
- Is the IdentityLoginModule still used?
- Can I change the IdentityService to be a real service?
- Rename the IdentitySession to DBIdentityService and the IdentyiSessionFactory to DBIdentityServiceFactory?
browsing any further through the identity code.... does it need cleaning up? Old classes there? Older ideas? JbpmSession... methods only used in tests.... Maybe one or two classes are used to emulate/mock the real loginmodule... could someone please comment before I go further... -
2. Re: Identity module as an implementation of a service?
the identity module is pluggable in the interfaces AssignmentHandler and some other that i don't remember.
the difficulty of defining a service for the identity component is that such a service interface would have to adopt a certain model between users, groups, roles, permissions and perhaps other things. the problem is that you cannot find a single model that matches all the models in any organisation. so with the service approach you end up mapping the users user-role model onto the model defined in the jbpm identity service. somehting which will be problematic in many cases.
ideally, there would be a 2 level approach. an identity service, for wihch you could plug different implementations (e.g. DB or LDAP based) and if the model is too different, people could still write their own assignment handlers and the other interface i don't remember. but even that has its problems as the navigation of the relations is in case of DB/hibernate based on lazy loading, whereas in an LDAP you would have to put the relation navigation methods in the service interface.
i realize this might be too little explanation for a lot of reasoning. feel free to ask more info or to challenge the reasoning.
regards, tom. -
3. Re: Identity module as an implementation of a service?
"kukeltje" wrote:
browsing any further through the identity code.... does it need cleaning up? Old classes there? Older ideas? JbpmSession... methods only used in tests.... Maybe one or two classes are used to emulate/mock the real loginmodule... could someone please comment before I go further...
it definitely needs cleaning up. basis is ok, though. but the current api is not clear and not very user friendly. also we need some web pages for maintaining the identity data like crud-operations on users, groups and memberships...
not sure if we need to do this cleanup before 4.0. as this will be tricky excercise to change it without breaking the interface. there was no real interface defined for the identity code. so people will have used it in various ways. so you'll break backwards compatibility very easily.