11 Replies Latest reply on Jan 30, 2009 5:55 AM by tom.baeyens

    LDAP assignment handler

    aguizar

      During a recent consulting gig I developed an LDAP-based assignment handler. It is not meant to fit arbitrary directory arrangements. Instead, it was designed to be a companion to the LDAP login module provided by JBoss AS, although they are configured separately. It will cover simple directory arrangements out of the box, and should be a good starting point for folks facing more complex arrangements.

      In the login model, users reside under an organizational unit, say ou=People,dc=jbpm,dc=org. Roles are defined in another organizational unit, e.g. ou=Roles,dc=jbpm,dc=org. In the assignment model, groups take the place of roles. They are defined in their own organizational unit as well, for example ou=Groups,dc=jbpm,dc=org, although they may be the same as roles if that makes sense to the user.

      An LdapService was introduced to manage the connection to the directory. The connection is established with properties read from a classpath resource specified by the string entry resource.ldap.properties in jbpm.cfg.xml. Below is a sample properties file. Notice the similarity with the login module configuration options.

      java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
      java.naming.provider.url=ldap\://localhost\:389/
      java.naming.security.authentication=simple
      java.naming.security.principal=uid\=adminUser,ou\=People,dc\=example,dc\=com
      java.naming.security.credentials=adminUser
      usersCtxDN=ou\=People,dc\=example,dc\=com
      userAttributeID=uid
      passwordAttributeID=userPassword
      groupsCtxDN=ou\=Groups,dc\=example,dc\=com
      groupAttributeID=cn
      memberAttributeID=member
      matchOnUserDN=true

      LdapAssignmentHandler extends ExpressionAssignmentHandler so the usual assignment expressions can be used on top of an LDAP server. Right now only users and groups are supported. Memberships, group types, and group hierarchies were out of the scope of the requirements, tough support for them might be added via search controls and extended attributes.

      The source code is available on the CVS branch jpdl_3_2_2_IS. I believe this would make an interesting addition to the product. What do you all think?

        • 1. Re: LDAP assignment handler
          tom.baeyens

           

          "alex.guizar@jboss.com" wrote:
          It is not meant to fit arbitrary directory arrangements. Instead, it was designed to be a companion to the <a href="http://labs.jboss.com/file-access/default/members/jbossas/freezone/docs/Server_Configuration_Guide/beta422/html/Using_JBoss_Login_Modules-LdapLoginModule.html">LDAP login module</a> provided by JBoss AS, although they are configured separately. It will cover simple directory arrangements out of the box, and should be a good starting point for folks facing more complex arrangements.


          that approach is a very good idea. we indeed cannot build configurable support for all LDAP configurations. but we can do it for simple configurations. and users with more complex configurations can just take our LDAP code as an example to start customizing.

          "alex.guizar@jboss.com" wrote:
          The source code is available on the CVS branch <a href="http://fisheye.jboss.com/browse/~br=jpdl_3_2_2_IS/JBPM/jbpm.3/identity/src/main/java/org/jbpm/identity/ldap">jpdl_3_2_2_IS</a>. I believe this would make an interesting addition to the product. What do you all think?


          commit it to trunk and reference it in less then 20 lines from the userguide. kind of like you did here.

          then add it to the task project in tempranillo.

          • 2. Re: LDAP assignment handler
            kukeltje

             

            that approach is a very good idea.
            I agree, just like the db based module is now... I did the same btw.

            What I personally do not get is the role of the IdentityService in this whole picture. My implementation is based on replacing the IdentityService. That is what I (as a jbpm user) want. The expressionAssignmentHandler does not need to change in this case. It needed some cleaning-up, but not a lot. I know replacing just the ExpressionAssignmentHandler is easier, but it feels dirty. There should be a better (=more clean) approach for this in the PVM imo...





            • 3. Re: LDAP assignment handler
              tom.baeyens

              if i understand you correctly, you would want to introduce an IdentityService session facade between the expression assignment handler and the identity component.

              that way, people would just have to implement the identity service session facade instead of the assignment handler and the link to their own identity component.

              right ?

              here's why i'm in doubt:

              * to make it pluggable for LDAP as well, all the relations would have to be navigated over the session facade as well. that on itself is not a big deal, but it breaks a bit the simplicity that we get by systematically using the hibernate persistence architecture.

              in this case we would not be able to use object navigation and hibernate's the lazy loading, but instead we would have to invoke e.g. the getGroupsForUser(userId, groupType) on the session facade.

              * secondly not all identity components have a model that is exposable as the model that we assume when building the session facade interface. so in some cases it would work and in some cases the models are too far apart.

              * we would need to document which methods are used by which features. as users probably don't have to implement all of the methods in the session facade. e.g. suppose that a user only uses the email functionality, which needs userid-to-email-resolving. then this user might find himself implementing all the methods used by the assignment expression handler that he might not even use.

              i see pros and cons. not yet a clear direction that we should take. more input is welcome.

              • 4. Re: LDAP assignment handler
                aguizar

                @Ronald

                How is replacing the IdentityService useful? The IdentityService is used by the IdentityLoginModule to authenticate users. Conversely, the ExpressionAssignmentHandler invokes ExpressionSession to resolve group memberships.

                The responsibilities of IdentityService and ExpressionSession overlap to such degree that IdentitySession implements both. For some reason, they currently are separate interfaces. I believe ExpressionSession should be merged into IdentityService and the latter turned into a context service (i. e. a subinterface of org.jbpm.svc.Service) configurable in jbpm.cfg.xml.

                The reason to subclass ExpressionAssignmentHandler is that it explicitly instantiates IdentitySession in method getExpressionSession(). No other changes were introduced. If ExpressionSession was merged into IdentityService and the latter was an actual context service, then no subclassing would be needed.

                Is this the kind of cleanup you did?

                @Tom

                The facade between the ExpressionAssignmentHandler and the identity component already exists, it is the ExpressionSession. However, one cannot specify a different implementation of the session without subclassing the handler. We need to address this, as well as the overlap with IdentityService.

                Relationship navigation could also be implemented by returning hand-made proxies just like those generated by Hibernate. However, the navigation requirements imposed on implementors would be made implicit instead of stated explicitly as methods in the facade. I believe explicit is better.

                Identity components that cannot be exposed as our model are out of scope, but they can always use the existing model as a starting point.

                Earlier I proposed merging ExpressionSession into IdentityService. On a second thought, the separation between the interfaces also corresponds to the separate requirements of each client of the identity service. Identity implementors could choose to implement only those interfaces that correspond to the features in use.

                • 5. Re: LDAP assignment handler
                  kukeltje

                  @Tom,

                  right ?


                  right

                  * to make it pluggable for LDAP as well, all the relations would have to be navigated over the session facade as well. that on itself is not a big deal, but it breaks a bit the simplicity that we get by systematically using the hibernate persistence architecture.
                  So? Ditch it... (just kidding) I bet in real live few people will use the identity service as it is. Isn't that why Alex had to build an ldap impl?

                  I have no real preference but it really needs cleaning up

                  @Alex
                  Is this the kind of cleanup you did?

                  Exactely... IdentitySession got ditched, IdentityService configurable via jbpm.cfg.xml but the difficult part is the User and Group object dependency. If I create interfaces for those (they moved from the identity project to the core in my case), hibernate complains about the mappings and I'm to little a hibernate expert to fix that at the moment...


                  Earlier I proposed merging ExpressionSession into IdentityService. On a second thought, the separation between the interfaces also corresponds to the separate requirements of each client of the identity service. Identity implementors could choose to implement only those interfaces that correspond to the features in use.


                  Hmmm I think I understand what you mean, but because of simplicity, I'd still merge them.

                  • 6. Re: LDAP assignment handler
                    tom.baeyens

                     

                    "alex.guizar@jboss.com" wrote:
                    The facade between the ExpressionAssignmentHandler and the identity component already exists, it is the ExpressionSession. However, one cannot specify a different implementation of the session without subclassing the handler. We need to address this, as well as the overlap with IdentityService.


                    i wasn't aware that there was an expression session. indeed that needs cleaning up.

                    "kukeltje" wrote:
                    Hmmm I think I understand what you mean, but because of simplicity, I'd still merge them.


                    i'm still chewing on it, but i think this could be a great summary of the whole discussion :-)

                    Great input, guys. I'll keep you posted on the progress.

                    • 7. Re: LDAP assignment handler
                      bdavis

                      Why was this handler removed? Is it incompatible with 3.2.5GA+?

                      • 8. Re: LDAP assignment handler
                        kukeltje

                        it was never in the code...

                        • 9. Re: LDAP assignment handler
                          aguizar

                          It was just deleted from the old CVS repository along with everything else, to prevent further commits there. Back then, it was in a branch and never reached the trunk, not because of incompatibility or quality issues, just because other priorities surfaced and I moved on. Now is as good time as any other to bring it back and finally merge it into the trunk.

                          • 10. Re: LDAP assignment handler
                            kukeltje

                            to bad we are not leveraging seam or other existing jboss projectds.... so much duplicate work now..... it's a pity (and in the end a pita to maintain)

                            • 11. Re: LDAP assignment handler
                              tom.baeyens

                              i'm integrating the new jboss identity component atm. which has bindings to db and ldap