Hide Forgot
Description of problem: Currently jBPM5 does not support JAAS roles query for getting the list of roles a user belongs to in order to use this in querying for potential tasks. Instead a separate callback mechanism has been provided. It is highly desirable to use standard JAAS, as that would allow for out-of-the-box support for LDAP, database, PicketLink, and other standard login modules. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I would like to expand and clarify: Currently the jBPM Console uses JAAS for authentication, but not for authorization / access to tasks. So for example if you login to jBPM Console as admin, and start a process with a user task assigned to actorId = admin, the process will throw and exception. The current jBPM5 solution for this is to add a jbpm.usergroup.callback.properties file like this one https://github.com/droolsjbpm/jbpm/blob/master/jbpm-installer/task-service/resources/org/jbpm/jbpm.usergroup.callback.properties to the folder brms-standalone-5.3.0/jboss-as/server/default/deploy/jbpm-human-task.war/WEB-INF/classes/org/jbpm/task/service before starting the application server. Generally speaking I don't think adding a folder (service) and a file to a vendor product's war file is a good thing to ask user's to do. It could create support problems for Red Hat, and it is a bit of a pain for the user. At the very least the folder and file should exist. I would also suggest that the value be there by default; and users comment it out if necessary. Second, the default value should use JAAS, not on validation. That is the users roles should be accessed through a standard JAAS query and used to create their group task list. Finally, I would prefer to see a custom (non-JAAS) implementation of this configurable on the task within the process definition,(this could be in addition to a global mechanism). This would be equivalent to the jBPM3 "assignment handler". In jBPM3 you could assign a task in the process definition to a user, group, swimlane (all of which jBPM5 support), or define a custom assignment handler. A customer assignment handler could then, for example, use drools to assign the task to a specific user bases on any number of attributes of the task, process, or user. A custom integration point at the process level would make more sense to me, since a customer might have one process or even one task within a process that used standard group assignment, but another process and / or tasks within the process that used custom rules based assignment.
Just as reference to not forgot about already done things: An initial implementation can be found here: https://github.com/mswiderski/jbpm/commit/2115019775a915996a5462e715ecf847a5a8085e It makes console rely on JAAS and it is independent of the underlying mechanism, user, roles property files, LDAP, etc. It it based on retrieving user that is currently logged on with all roles (s)he has. As second part, LDAP based UserGroupCallback is provided as this is most likely the most common user repository. With this user can configure both jbpm console and task server to rely on the same LDAP user registry.
pull request available at: https://github.com/droolsjbpm/jbpm/pull/69
Update status to ON_QA. Please verify them against ER6.
I'm not sure whether to mark this as verified or not. True, if you're not using the usergroupcallback mechanism in the human task service, the groups, at least are accessed via whatever is configured for the Console. Meaning, if my Console is configured to use jaas authentization with policy using props/user.properties and props/roles.properties, human task service uses roles mappings defined in props/roles.properties. But at the same time, it needs the user defined in some properties or mvel file that you specified in the web.xml. This leads to exceptions when you assign tasks to users not defined in that file. So this part didn't really get fixed. Of course, I can get around that by using the usergroupcallback mechanism for the human task service. I don't think this is the right way to do it though. The reason for that is that we're trying to make the human task service use the same users and roles that we have already configured for the console app. So it is not exactly correct to make the user configure it twice. Furthermore if we can get the roles mappings via jaas we should get the users the same way and not throw exceptions. Although I don't like the inconsistency in this, the human task service can now be configured to use the same users and roles that the console does, all via the usergroupcallback. And that part has certainly improved - you drop your implementation in the WEB-INF/classes/ and edit the web.xml accordingly. My point is - it works, just not exactly the way I'd like it to. Still, I'm more inclined to mark it as fixed, verified. Jeff, you reported this, what do you think of this solution? Anyone any thoughts on this?
Asking Jeff for his comment. I'd be inclined to mark this verified as well.
No reaction from Jeff up 'till now. I think we can mark this as verified. We can always open a new bug report for any remaining issues.
I thought I had responded to this earlier. Yes we tested the use of JAAS with jBPM Console and DatabaseServerLoginMOdule and it worked.