Keith West wrote:
- where is this "Administrator" user id configured in the human task service? Is this hard-coded into the code somewhere, or can it be modified in a property or configuration file to change it to an allowed user id?
it is configured as part of the HT work item handler used to integrate with human task. depending on the usage scenario you could override that with custom handler especially if you embed jbpm in your application
Keith West wrote:
- Instead of a specific user, can the human task service be configured to utilize any user from a particular group?
similar as in question 1, you could override that with custom handler where you would use Group for administrator instead of user
Keith West wrote:
- Can the human task service be configured to use the LDAP configured within the JBOSS AS 7 container vs having all of its own separate LDAP configuration?
- Related, can it be configured to utilize the RoleMappingLoginModule?
yes, you could use JAAS based user group callback that relies on information given by login module but only when you use local task service as it must be within same context as the actual request. When using hornetq or mina the context is not propagated with the integration request and thus JAAS will not have enough information to proceed.
Appreciate your response to these questions.
I was hoping that there would be some type of configuration approach vs custom coding to allow one to supply a different user that is needed for human task service to work with the jbpm-console. What we're trying to do is get all of the various web-based components of jBPM to work within the confines of our environments - in this case our LDAP. i.e. wanting to make the out of the box web components work without getting into too much customization.
Which HT work item handler is the Administrator user configured in - and is there no way to externalize that so it's not hardcoded?
Unfortunately there is no such configuration but feel free to file jira for it.
All HT handlers do the same as they share common class. Alternatively you could make a small extension to the actual LDAPUserGroupCallback class where in existsUser method you would always return true when Administrator user is given and that would workaround this limitation.
Hi Keith west,
There is one workaround is there.
Insted of puting the "Administaror" entry in the LDAP table . Put the "Administaror" user in the ORGANIZATIONALENTITY table.
Instead of a small extension to LDAPUserGroupCallback, could I instead just clone this class, and make the change to the clone, and then when I startup the system supply a reference to the cloned usercallback vs the LDAP one, as discussed in the jBPM User Guide?
I'd rather take this approach vs modifying the existing code as being a newbie to the open source side of jBPM, I'm not familiar with how to build all the software yet.
The suggestion to have Administrator in the OrganizationalEntity table seems to imply that even if I have configured jBPM to utilize LDAP, it would somehow still access the database tables? Administrator user is actually in the OrganizationalEntity table, and I get the error indicated by the original post.Maybe some other option I can set to have it fallback to using database table if it doesn't find Administrator in LDAP?
Keith, this is exactly what I meant by "small extension" which essentially is new class that extends the default LDAPUserGroupCallbackImpl and just overloads existsUser method. THen you could register it via web.xml of human task web app.
adding it directly to db won't solve the issue as any way user group callback is always asked for checks of user and groups when task is created. And if user is not known to the callback it will be filtered out.
So, I downloaded the LDAPUserGroupCallbackImpl code. Renamed the class to FedExUserGroupCallbackImpl. Added some code in to get the "Administrator" user id from a property (not hardcoded), and then in "existsUser", added a check to see if the userId to be checked is the admin user (from a property), then return true immediately.
At this point I tried a couple things to see if it wold work. First created a jar with this class in it, and put that jar into the JBOSS AS 7.2 deployment directory, and added the following to the server startup:
This didn't work - I got the following error in the server log:
2013-10-10 03:52:04,614 ERROR [org.jbpm.task.identity.UserGroupCallbackManager] (ServerService Thread Pool -- 55) Error trying to create callback: org.jbpm.task.identity.FedExLDAPUserCallBackImpl from
[Module "deployment.jbpm-human-task-war.war:main" from Service Module Loader]
I then inserted the jar into the lib directory of the jbpm human task war. Still didn't work, same error. I then added the FedExUserGroupCallbackImpl class to the jbpm-human-task-core-5.4.0.Final.jar, in the org/jbpm/task/identity directory. Still didn't work, same error.
Finally, I just decided to replace the existing LDAPUserGroupCallbackImpl class file with the modified code. I then removed the startup property (jbpm.usergroup.callback), and started the server. This worked. I can now login to jbpm-console with an ldap userid/password, start a process that assigns a human task to someone in LDAP, login to jbpm-console as that person using their user id/pass from LDAP, and complete the task.
While this works, I'm a bit concerned that I could not create my own separate user callback using the exact same code in the same java package. I had initially hoped to be able to use a different company-specific package, but abandoned that early on. Did I reference the class file correctly with the command line property? Is there some other step I'm missing?
1 of 1 people found this helpful
It should be completely fine to bundle the class in separate file that should be placed inside jbpm-human-task.war/WEB-INF/lib next configure the right class by altering the web.xml of jbpm-human-taks.war/WEB-INF and specify input param value for user.group.callback.class, see here the web.xml.
the ldap configuration (property file) should remain the same regardless if you use default LDAP callback impl or your own as your own extends it so it will do the initialization exactly same way. Check if you have properly called super constructors, etc from within you custom callback class.
to reiterate on the coding I did - I cloned the existing LDAPUserGroupCallbackImpl code, and just added a couple lines to check for Administrator, and log what user was being checked. I tried your suggestion with the web.xml, and left in the command line property, and got some interesting results. When I did both, I still got the error listed above in the server log, but then I also got the log output from my cloned class indicating it was loaded. So, I removed the command line option from the startup, and the initial create callback error no longer appeared in the log.
I get from this that the command line approach doesn't work, but good news is making the modification you suggested to the web.xml allowed my cloned class to be used, and worked. Appreciate the help!