11 Replies Latest reply on Oct 10, 2013 11:11 AM by Keith West

    jbpm-human-task-war-5.4 and LDAP - questions Re "Administrator" user...

    Keith West Newbie

      I have been working through each of the jBPM 5.4 components getting them configured to use our corporate LDAP. I have configured JBOSS AS 7.2 to access our Corporate lDAP in the standlone.xml - using "LdapExtLoginModule" for the user/group access, and RoleMappingLoginModule to map our LDAP roles to those needed by each of the components. jbpm-form-builder and jbpm-console are working fine with this configuration - i.e. I can login with user ids from LDAP that have been assigned to groups recognized by those components. drools-guvnor is running into an issue that I have noted in another discussion - (Problem Configuring Guvnor with LDAP...).

       

      For the human task service, I have everything configured to work with LDAP per the user manual and a number of web posts, but when starting a process in the jbpm-console that invokes a Human task, am getting the following error in the server log:

       

      2013-10-08 02:01:57,965 DEBUG [org.jbpm.task.identity.LDAPUserGroupCallbackImpl] (Thread-77) Seaching for user existence with filter (uid=Administrator) on context ou=people,o=fedex,c=us

      2013-10-08 02:01:57,968 ERROR [stderr] (Thread-77) org.jbpm.task.service.CannotAddTaskException: There are no known Business Administrators, task cannot be created according to WS-HT specification

       

      I understand from these error messages that the human task service requires a user called "Administrator" to be configured in LDAP. However, our company uses numeric user ids (employee #'s) in our LDAP. I don't believe I'll be allowed to have such a non-numeric user added.

       

      Given this, I have several questions...

       

      - 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?

       

      - Instead of a specific user, can the human task service be configured to utilize any user from a particular group?

       

      - 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?

       

      Thanks,

      Keith

        • 1. Re: jbpm-human-task-war-5.4 and LDAP - questions Re "Administrator" user...
          Maciej Swiderski Master

          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.

           

          HTH

          • 2. Re: jbpm-human-task-war-5.4 and LDAP - questions Re "Administrator" user...
            Keith West Newbie

            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?

             

            Thanks,

            Keith

             

             


            • 3. Re: jbpm-human-task-war-5.4 and LDAP - questions Re "Administrator" user...
              Maciej Swiderski Master

              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.

               

              HTH

              • 4. Re: jbpm-human-task-war-5.4 and LDAP - questions Re "Administrator" user...
                Shiju John Newbie

                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.

                • 5. Re: jbpm-human-task-war-5.4 and LDAP - questions Re "Administrator" user...
                  Keith West Newbie

                  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.

                  • 6. Re: jbpm-human-task-war-5.4 and LDAP - questions Re "Administrator" user...
                    Keith West Newbie

                    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?

                    • 7. Re: jbpm-human-task-war-5.4 and LDAP - questions Re "Administrator" user...
                      Maciej Swiderski Master

                      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.

                       

                      HTH

                      • 8. Re: jbpm-human-task-war-5.4 and LDAP - questions Re "Administrator" user...
                        Maciej Swiderski Master

                        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.

                        • 9. Re: jbpm-human-task-war-5.4 and LDAP - questions Re "Administrator" user...
                          Keith West Newbie

                          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:

                             

                               -Djbpm.usergroup.callback=org.jbpm.task.identity.FedExLDAPUserCallBackImpl

                           

                          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?

                           

                          Thoughts?

                           

                          THX!

                          Keith

                          • 10. Re: jbpm-human-task-war-5.4 and LDAP - questions Re "Administrator" user...
                            Maciej Swiderski Master

                            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.

                             

                            HTH

                            1 of 1 people found this helpful
                            • 11. Re: jbpm-human-task-war-5.4 and LDAP - questions Re "Administrator" user...
                              Keith West Newbie

                              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!

                               

                              THX

                              Keith