Jetspeed 2
  1. Jetspeed 2
  2. JS2-491

Enhance J2 LDAP Security Documentation

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1-dev
    • Fix Version/s: 2.1-dev, 2.1
    • Component/s: Security
    • Labels:
      None

      Description

      From Davy De Waele email to the list:

      Judging from the recent activity on the mailing list I noticed some
      interest in using LDAP & Jetspeed

      Some thoughts come to mind:

      1. The instructions located at
      http://portals.apache.org/jetspeed-2/multiproject/jetspeed-security/ldap
      .html are really only applicable for people who are building jetspeed
      from source.
      Due to the fact that the security-spi-ldap*.xml files shown there are
      coming from SVN (interface changes, additional objects in the
      configuration files that are not in the 2.0 binary release), users who
      have installed jetspeed2 via the installer attempting to follow these
      instructions will run into configuration issues.

      What would be the best way to address this?

      I think we should make a difference between users who are familiar with
      Maven, SVN, compiling/building/deploying, and users who just want to
      get
      the thing up & running using the installer.

      Shouldn't we put this information into perspective by:

      a) Clearly indicating that this is only intended for people building
      from source
      b) Provide an additional manual on what needs to be done starting from
      a
      binary release (2.0 version)

      The user would have to

      • copy the security-spi-ldap*.xml files (we provide
        downloadable spring XML files acting as examples)
      • remove their default security-spi-atn.xml
      • restart tomcat
      • preparing their LDAP server

      As far as LDAP support goes, we should provide instructions on how
      existing LDAP servers can be used with jetspeed. We can also provide
      downloadable schema files & LDIF sample data for all major vendors +
      documentation)

      I could provide such manuals for OpenLDAP,SunDS and ApacheDS.

      2. The major problem that users will be facing today is that encrypted
      passwords are not supported in the jetspeed2.0 release. Given that this
      functionality has been committed to the codebase, how do you feel
      towards providing a downloadable JAR file to users that would act as a
      replacement for their current jetspeed-security-2.0.jar - doesn't have
      to be anything official, could be included as a link in the
      documentation)

      The user would have to

      • replace his jetspeed-security-2.0.jar
      • restart tomcat

      The user would have support for encrypted passwords and group/role
      membership via LDAP.

      3. OpenLDAP schema file

      I had to add groupOfUniqueNames as a parent to the jetspeed-2-group and
      jetspeed-2-role objectClasses in order for the group/role assignment to
      work in OpenLDAP.
      ApacheDS doesn't really care when objects are created in the LDAP tree
      containing attributes that aren't defined in the LDAP schema. OpenLDAP
      does I've attached the new jetspeed.schema file.

      1. ldap_patch_with_jdk_fix.patch
        326 kB
        Davy De Waele
      2. jetspeed-ldap-final.patch
        217 kB
        Davy De Waele
      3. jetspeed LDAP.doc
        655 kB
        Davy De Waele
      4. jetspeed2-ldap-11102006.patch
        378 kB
        Davy De Waele

        Issue Links

          Activity

          David Le Strat created issue -
          Hide
          Eduardo Millan added a comment -

          Hi Davy,

          I am having some experience with LDAP and Jetspeed2, connecting to Apache DS, IBM Tivoli directory server and Lotus Domino and I could give you my experience about that if you want.

          The reality is that usually our customers have a LDAP solution already on. So, they dont want to modify their LDAP user hierarchy to accomodate newer objectClasses or identifiers. On issue illustrating this is that they want for example tu use the "sn" attribute instead the "uid" one. Or they want to use the "inetPerson" objectClass attribute instead the "jetspeed-2-user" one.

          I am giving it an eye to extract those identifiers to an external file, maybe using jakarta-commons-configuration. What is your oppinion about this?

          Thanks in advance.

          Show
          Eduardo Millan added a comment - Hi Davy, I am having some experience with LDAP and Jetspeed2, connecting to Apache DS, IBM Tivoli directory server and Lotus Domino and I could give you my experience about that if you want. The reality is that usually our customers have a LDAP solution already on. So, they dont want to modify their LDAP user hierarchy to accomodate newer objectClasses or identifiers. On issue illustrating this is that they want for example tu use the "sn" attribute instead the "uid" one. Or they want to use the "inetPerson" objectClass attribute instead the "jetspeed-2-user" one. I am giving it an eye to extract those identifiers to an external file, maybe using jakarta-commons-configuration. What is your oppinion about this? Thanks in advance.
          Hide
          Eduardo Millan added a comment -

          Maybe this kind of configuration data could be moved to:

          • secutity-spi-ldap.xml

          and have the LdapBindingConfig.java source file modified?

          Thanks.

          Show
          Eduardo Millan added a comment - Maybe this kind of configuration data could be moved to: secutity-spi-ldap.xml and have the LdapBindingConfig.java source file modified? Thanks.
          Hide
          Stephen Greenlee added a comment -

          Hi Davy and Eduardo,

          Eduardo and I have been discussing the issues around LDAP configuration and production Directory Servers. As Eduardo noted above, customers already have a LDAP server running (NDS, ADS, Sun etc...) and there is some reluctance to make changes to an existing schema to accomodate Jetspeed.

          Ideally, both role and group assignments in Jetspeed should map to groups on the ldap server (at least in Active Directory) as most basic directory servers for Network Operating Systems assign roles based on logicical group assignments. For example, in Active Directory, the administrator role is assigned by adding a user to an administrator group. Having looked at both JIRA for J2 and the mailing lists, it's unclear to me how I should now proceed for configuring LDAP on Active Directory.

          I have tried following the directions on http://portals.apache.org/jetspeed-2/multiproject/jetspeed-security/ldap.html but I need further giudance on configuration.

          Anyone that can provide guidance or their own personal experince would be of tremendous help. If I don't hear anything via JIRA in a day or two, I may cross-post this to the dev mailing list. I don't like doing this but wish to move forward.

          Thanks

          Show
          Stephen Greenlee added a comment - Hi Davy and Eduardo, Eduardo and I have been discussing the issues around LDAP configuration and production Directory Servers. As Eduardo noted above, customers already have a LDAP server running (NDS, ADS, Sun etc...) and there is some reluctance to make changes to an existing schema to accomodate Jetspeed. Ideally, both role and group assignments in Jetspeed should map to groups on the ldap server (at least in Active Directory) as most basic directory servers for Network Operating Systems assign roles based on logicical group assignments. For example, in Active Directory, the administrator role is assigned by adding a user to an administrator group. Having looked at both JIRA for J2 and the mailing lists, it's unclear to me how I should now proceed for configuring LDAP on Active Directory. I have tried following the directions on http://portals.apache.org/jetspeed-2/multiproject/jetspeed-security/ldap.html but I need further giudance on configuration. Anyone that can provide guidance or their own personal experince would be of tremendous help. If I don't hear anything via JIRA in a day or two, I may cross-post this to the dev mailing list. I don't like doing this but wish to move forward. Thanks
          Hide
          Aaron Evans added a comment -

          I agree that folks usually have an existing LDAP installation and want to use their existing schema and it needs to be somewhat configurable, or at the very least, some documentation showing how to adapt the SPI components to a custom schema.

          In my case, I created new ATN and ATZ SPI components for using my custom OpenLDAP schema, so I am not using any of the LDAP components provided by J2.

          The second thing that ought to be easily configurable is the hashing algorithm that is employed for passwords and any prefix/suffix string that should be used. For example, for SunDS, you might want your hashing algorithm to be SHA-1 and for the

          {SHA}

          prefix to be pre-pended to the password string for LDAP storage.

          Show
          Aaron Evans added a comment - I agree that folks usually have an existing LDAP installation and want to use their existing schema and it needs to be somewhat configurable, or at the very least, some documentation showing how to adapt the SPI components to a custom schema. In my case, I created new ATN and ATZ SPI components for using my custom OpenLDAP schema, so I am not using any of the LDAP components provided by J2. The second thing that ought to be easily configurable is the hashing algorithm that is employed for passwords and any prefix/suffix string that should be used. For example, for SunDS, you might want your hashing algorithm to be SHA-1 and for the {SHA} prefix to be pre-pended to the password string for LDAP storage.
          Hide
          Davy De Waele added a comment -

          I think we need the following properties in jetspeed if we want to allow for a flexible LDAP integration approach.
          The following properties will allow jetspeed to interact with a number of different LDAP schemas, as the user can now decide what filters to use, where groups/users/roles are stored, how group & role membership should be handled , what objectClasses to use for users/groups/roles....

          Let me know if somebody is interested in a security patch that takes these properties into account, and removes the dependency with custom objectClasses & attributes.

          1. Ldap Configuration.
            org.apache.jetspeed.ldap.initialContextFactory=com.sun.jndi.ldap.LdapCtxFactory
            org.apache.jetspeed.ldap.ldapServerName=localhost
            org.apache.jetspeed.ldap.ldapServerPort=389
            org.apache.jetspeed.ldap.rootDn=cn=Directory Manager
            org.apache.jetspeed.ldap.rootPassword=adminadmin
            org.apache.jetspeed.ldap.rootContext=o\=Company3
          1. define the filters needed to search for roles/groups/users
            org.apache.jetspeed.ldap.RoleFilter=(&(objectclass=ldapsubentry) (objectclass=nsroledefinition))
            org.apache.jetspeed.ldap.GroupFilter=(objectclass=groupOfUniqueNames)
            org.apache.jetspeed.ldap.UserFilter=(&(objectclass=inetorgperson)(objectclass=organizationalPerson))

          org.apache.jetspeed.ldap.UserAuthenticationFiler=(&(uid=%u)(objectclass=inetorgperson))

          1. define the way role membership occurs
          2. if RoleMembershipAttributes is used, membership attr will be stored on role
          3. if UserRoleMembershipAttributes is used, membership attr will be stored on user
            org.apache.jetspeed.ldap.RoleMembershipAttributes=
            org.apache.jetspeed.ldap.UserRoleMembershipAttributes=nsroledn
          1. define the way group membership occurs
          2. if GroupMembershipAttributes is used, membership attr will be stored on group
          3. if UserGroupMembershipAttributes is used, membership attr will be stored on user
            org.apache.jetspeed.ldap.GroupMembershipAttributes=uniqueMember
            org.apache.jetspeed.ldap.UserGroupMembershipAttributes=
          1. define the path to roles,groups and users
          2. needs to be defined without the defaultsearchbase
            org.apache.jetspeed.ldap.RoleFilterBase=
            org.apache.jetspeed.ldap.GroupFilterBase=
            org.apache.jetspeed.ldap.UserFilterBase=ou\=People\,ou\=OrgUnit1
          1. objectClasses used for role/group/user entries
            org.apache.jetspeed.ldap.RoleObjectClasses=top\,ldapsubentry\,nsroledefinition\,nssimpleroledefinition\,nsmanagedroledefinition
            org.apache.jetspeed.ldap.GroupObjectClasses=top\,groupofuniquenames
            org.apache.jetspeed.ldap.UserObjectClasses=top\,person\,organizationalPerson\,inetorgperson
          1. define the ID attribute used to define roles/groups/users
            org.apache.jetspeed.ldap.RoleIdAttribute=cn
            org.apache.jetspeed.ldap.GroupIdAttribute=cn
            org.apache.jetspeed.ldap.UserIdAttribute=uid
          Show
          Davy De Waele added a comment - I think we need the following properties in jetspeed if we want to allow for a flexible LDAP integration approach. The following properties will allow jetspeed to interact with a number of different LDAP schemas, as the user can now decide what filters to use, where groups/users/roles are stored, how group & role membership should be handled , what objectClasses to use for users/groups/roles.... Let me know if somebody is interested in a security patch that takes these properties into account, and removes the dependency with custom objectClasses & attributes. Ldap Configuration. org.apache.jetspeed.ldap.initialContextFactory=com.sun.jndi.ldap.LdapCtxFactory org.apache.jetspeed.ldap.ldapServerName=localhost org.apache.jetspeed.ldap.ldapServerPort=389 org.apache.jetspeed.ldap.rootDn=cn=Directory Manager org.apache.jetspeed.ldap.rootPassword=adminadmin org.apache.jetspeed.ldap.rootContext=o\=Company3 define the filters needed to search for roles/groups/users org.apache.jetspeed.ldap.RoleFilter=(&(objectclass=ldapsubentry) (objectclass=nsroledefinition)) org.apache.jetspeed.ldap.GroupFilter=(objectclass=groupOfUniqueNames) org.apache.jetspeed.ldap.UserFilter=(&(objectclass=inetorgperson)(objectclass=organizationalPerson)) org.apache.jetspeed.ldap.UserAuthenticationFiler=(&(uid=%u)(objectclass=inetorgperson)) define the way role membership occurs if RoleMembershipAttributes is used, membership attr will be stored on role if UserRoleMembershipAttributes is used, membership attr will be stored on user org.apache.jetspeed.ldap.RoleMembershipAttributes= org.apache.jetspeed.ldap.UserRoleMembershipAttributes=nsroledn define the way group membership occurs if GroupMembershipAttributes is used, membership attr will be stored on group if UserGroupMembershipAttributes is used, membership attr will be stored on user org.apache.jetspeed.ldap.GroupMembershipAttributes=uniqueMember org.apache.jetspeed.ldap.UserGroupMembershipAttributes= define the path to roles,groups and users needs to be defined without the defaultsearchbase org.apache.jetspeed.ldap.RoleFilterBase= org.apache.jetspeed.ldap.GroupFilterBase= org.apache.jetspeed.ldap.UserFilterBase=ou\=People\,ou\=OrgUnit1 objectClasses used for role/group/user entries org.apache.jetspeed.ldap.RoleObjectClasses=top\,ldapsubentry\,nsroledefinition\,nssimpleroledefinition\,nsmanagedroledefinition org.apache.jetspeed.ldap.GroupObjectClasses=top\,groupofuniquenames org.apache.jetspeed.ldap.UserObjectClasses=top\,person\,organizationalPerson\,inetorgperson define the ID attribute used to define roles/groups/users org.apache.jetspeed.ldap.RoleIdAttribute=cn org.apache.jetspeed.ldap.GroupIdAttribute=cn org.apache.jetspeed.ldap.UserIdAttribute=uid
          Hide
          Vitaly Baranovsky added a comment -

          I'm and my company is very interesting in this properties.

          We have Domino Directory Server with all our users. We want use jetspeed-2 for our new site. But we have a problem with jetspeed connection to our Domino Directory Server. Because we have our users at o=mycompany, without ou. So, we haven't users org unit. And all our users have object class DominoPerson. So, we must move our users to some org unit and apply class jetspeed-2-user to all our user accounts, if we want to use jetspeed-2.

          And there is another big problem. We can't log in jetspeed-2 because Domino stores its passwords using hashing algorithm

          So, I think, many users will need for enhanced jetspeed-2 LDAP support.

          Show
          Vitaly Baranovsky added a comment - I'm and my company is very interesting in this properties. We have Domino Directory Server with all our users. We want use jetspeed-2 for our new site. But we have a problem with jetspeed connection to our Domino Directory Server. Because we have our users at o=mycompany, without ou. So, we haven't users org unit. And all our users have object class DominoPerson. So, we must move our users to some org unit and apply class jetspeed-2-user to all our user accounts, if we want to use jetspeed-2. And there is another big problem. We can't log in jetspeed-2 because Domino stores its passwords using hashing algorithm So, I think, many users will need for enhanced jetspeed-2 LDAP support.
          Hide
          Eivinn Hustveit added a comment -

          I think that Jetspeed should not in any case be dependent on a specific LDAP implementation. Still, the actual implementation of the ldap-schema can not be provided for every possible LDAP server. My hope is that the LDAP documentation would be so generalized that anyone would be able to find out how to get Jetspeed working with their current setup.

          With the current implementation there are a few critical limitations if run in a production environment:

          • does not follow LDAP redirects
          • does not reconnect when connection is lost

          Re Vitaly Baranovsky> Wouldn't the LDAP server check, and hash, the passwords when a user tries to login? In my experience the hashing/encryption of passwords is transparent to the Jetspeed LDAP component.

          Show
          Eivinn Hustveit added a comment - I think that Jetspeed should not in any case be dependent on a specific LDAP implementation. Still, the actual implementation of the ldap-schema can not be provided for every possible LDAP server. My hope is that the LDAP documentation would be so generalized that anyone would be able to find out how to get Jetspeed working with their current setup. With the current implementation there are a few critical limitations if run in a production environment: does not follow LDAP redirects does not reconnect when connection is lost Re Vitaly Baranovsky> Wouldn't the LDAP server check, and hash, the passwords when a user tries to login? In my experience the hashing/encryption of passwords is transparent to the Jetspeed LDAP component.
          Hide
          Stephen Greenlee added a comment -

          Davy,

          We would be interested in working with your LDAP patches as well. Domino would be an excellent start and we have Active Directory in mind as well. I agree that many of us would like LDAP support without custom objectClasses and attribues. Do you really want to modify the default AD schema and lose MS support? Not to mention, I think that many IT staffers responsible for AD in a company would not allow it anyway.

          It seems that there is enough interest here that maybe you can supply the patches to JIRA or some other place to download?

          Great work

          Show
          Stephen Greenlee added a comment - Davy, We would be interested in working with your LDAP patches as well. Domino would be an excellent start and we have Active Directory in mind as well. I agree that many of us would like LDAP support without custom objectClasses and attribues. Do you really want to modify the default AD schema and lose MS support? Not to mention, I think that many IT staffers responsible for AD in a company would not allow it anyway. It seems that there is enough interest here that maybe you can supply the patches to JIRA or some other place to download? Great work
          Hide
          Eduardo Millan added a comment -

          Well, folks

          Currently, we have an implementation of J2 LDAP Security working against Lotus Domino, and we think it's not difficult to modify it or program it in order to access MS AD as well. Only that, the packe names are different, and that I don't like very much how it's implemented originally in J2, IMHO it extra-uses the inheritance.

          Anyone interested in working on this? I'd like to share the sources.

          Show
          Eduardo Millan added a comment - Well, folks Currently, we have an implementation of J2 LDAP Security working against Lotus Domino, and we think it's not difficult to modify it or program it in order to access MS AD as well. Only that, the packe names are different, and that I don't like very much how it's implemented originally in J2, IMHO it extra-uses the inheritance. Anyone interested in working on this? I'd like to share the sources.
          Hide
          Vitaly Baranovsky added a comment -

          2 Eduardo Millan: Yes!!! We are very interesting in implementation of J2 LDAP Security working against Lotus Domino!! Can you share you sources?
          Thanks!

          Show
          Vitaly Baranovsky added a comment - 2 Eduardo Millan: Yes!!! We are very interesting in implementation of J2 LDAP Security working against Lotus Domino!! Can you share you sources? Thanks!
          Hide
          Davy De Waele added a comment -

          This patch contains a new implementation for the ldap security module.

          It allows for the LDAP to be configured through a property file (or spring config file) that has the following properties, allowing for an easy LDAP integration with a variety of different vendors.

          1. Ldap Configuration.

          org.apache.jetspeed.ldap.initialContextFactory=com.sun.jndi.ldap.LdapCtxFactory
          org.apache.jetspeed.ldap.ldapServerName=localhost
          org.apache.jetspeed.ldap.ldapServerPort=10389
          org.apache.jetspeed.ldap.rootDn=uid\=admin\,ou\=system
          org.apache.jetspeed.ldap.rootPassword=secret
          org.apache.jetspeed.ldap.rootContext=o\=sevenSeas
          #org.apache.jetspeed.ldap.defaultDnSuffix=
          #org.apache.jetspeed.ldap.ou.users=people
          #org.apache.jetspeed.ldap.ou.groups=groups
          #org.apache.jetspeed.ldap.ou.roles=roles

          1. define the filters needed to search for roles/groups/users
            #org.apache.jetspeed.ldap.RoleFilter=(&(objectclass=ldapsubentry) (objectclass=nsroledefinition))
            org.apache.jetspeed.ldap.RoleFilter=(objectClass=groupOfUniqueNames)
            org.apache.jetspeed.ldap.GroupFilter=(objectclass=organization)
            org.apache.jetspeed.ldap.UserFilter=(objectclass=inetorgperson)

          org.apache.jetspeed.ldap.UserAuthenticationFiler=(&(uid=%u)(objectclass=inetorgperson))

          1. define the way role membership occurs for a user
          2. if RoleMembershipAttributes is used, membership attr will be stored on role
          3. if UserRoleMembershipAttributes is used, membership attr will be stored on user
            org.apache.jetspeed.ldap.RoleMembershipAttributes=member
            org.apache.jetspeed.ldap.UserRoleMembershipAttributes=
          1. define the way group membership occurs for a user
          2. if GroupMembershipAttributes is used, membership attr will be stored on group
          3. if UserGroupMembershipAttributes is used, membership attr will be stored on user
            org.apache.jetspeed.ldap.GroupMembershipAttributes=
            org.apache.jetspeed.ldap.UserGroupMembershipAttributes=uniqueMember
          1. define the way group membership occurs for a role
          2. if GroupMembershipAttributes is used, membership attr will be stored on group
          3. if UserGroupMembershipAttributes is used, membership attr will be stored on user
            org.apache.jetspeed.ldap.GroupMembershipForRoleAttributes=uniqueMember
            org.apache.jetspeed.ldap.RoleGroupMembershipAttributes=
          1. define the default search base. (=rootContext)
            org.apache.jetspeed.ldap.DefaultSearchBase=o\=sevenSeas
          1. define the path to roles,groups and users
          2. needs to be defined without the defaultsearchbase
            org.apache.jetspeed.ldap.RoleFilterBase=ou\=Roles\,ou\=OrgUnit1
            org.apache.jetspeed.ldap.GroupFilterBase=ou\=Groups\,ou\=OrgUnit1
            org.apache.jetspeed.ldap.UserFilterBase=ou\=People\,ou\=OrgUnit1

          org.apache.jetspeed.ldap.RoleObjectClasses=top\,groupOfUniqueNames
          org.apache.jetspeed.ldap.GroupObjectClasses=top\,organization
          org.apache.jetspeed.ldap.UserObjectClasses=top\,person\,organizationalPerson\,inetorgperson

          1. define the ID attribute used to search roles/groups/users
            org.apache.jetspeed.ldap.RoleIdAttribute=cn
            org.apache.jetspeed.ldap.GroupIdAttribute=cn
            org.apache.jetspeed.ldap.UserIdAttribute=uid

          As you can see, filters and objectClasses can now be configured, and no jetspeed specific object classes or attributes need to be used.

          The provided config files in the patch (components/security/src/test/JETSPEED-INF/directory/config
          ) have been tested on apacheds,openldap and sunds

          I'm going to try and get it up & running with Lotus Domino and Active Directory today (hasn't been tested yet).

          Feel free to try out the patch and let me know if you have any problems

          Show
          Davy De Waele added a comment - This patch contains a new implementation for the ldap security module. It allows for the LDAP to be configured through a property file (or spring config file) that has the following properties, allowing for an easy LDAP integration with a variety of different vendors. Ldap Configuration. org.apache.jetspeed.ldap.initialContextFactory=com.sun.jndi.ldap.LdapCtxFactory org.apache.jetspeed.ldap.ldapServerName=localhost org.apache.jetspeed.ldap.ldapServerPort=10389 org.apache.jetspeed.ldap.rootDn=uid\=admin\,ou\=system org.apache.jetspeed.ldap.rootPassword=secret org.apache.jetspeed.ldap.rootContext=o\=sevenSeas #org.apache.jetspeed.ldap.defaultDnSuffix= #org.apache.jetspeed.ldap.ou.users=people #org.apache.jetspeed.ldap.ou.groups=groups #org.apache.jetspeed.ldap.ou.roles=roles define the filters needed to search for roles/groups/users #org.apache.jetspeed.ldap.RoleFilter=(&(objectclass=ldapsubentry) (objectclass=nsroledefinition)) org.apache.jetspeed.ldap.RoleFilter=(objectClass=groupOfUniqueNames) org.apache.jetspeed.ldap.GroupFilter=(objectclass=organization) org.apache.jetspeed.ldap.UserFilter=(objectclass=inetorgperson) org.apache.jetspeed.ldap.UserAuthenticationFiler=(&(uid=%u)(objectclass=inetorgperson)) define the way role membership occurs for a user if RoleMembershipAttributes is used, membership attr will be stored on role if UserRoleMembershipAttributes is used, membership attr will be stored on user org.apache.jetspeed.ldap.RoleMembershipAttributes=member org.apache.jetspeed.ldap.UserRoleMembershipAttributes= define the way group membership occurs for a user if GroupMembershipAttributes is used, membership attr will be stored on group if UserGroupMembershipAttributes is used, membership attr will be stored on user org.apache.jetspeed.ldap.GroupMembershipAttributes= org.apache.jetspeed.ldap.UserGroupMembershipAttributes=uniqueMember define the way group membership occurs for a role if GroupMembershipAttributes is used, membership attr will be stored on group if UserGroupMembershipAttributes is used, membership attr will be stored on user org.apache.jetspeed.ldap.GroupMembershipForRoleAttributes=uniqueMember org.apache.jetspeed.ldap.RoleGroupMembershipAttributes= define the default search base. (=rootContext) org.apache.jetspeed.ldap.DefaultSearchBase=o\=sevenSeas define the path to roles,groups and users needs to be defined without the defaultsearchbase org.apache.jetspeed.ldap.RoleFilterBase=ou\=Roles\,ou\=OrgUnit1 org.apache.jetspeed.ldap.GroupFilterBase=ou\=Groups\,ou\=OrgUnit1 org.apache.jetspeed.ldap.UserFilterBase=ou\=People\,ou\=OrgUnit1 org.apache.jetspeed.ldap.RoleObjectClasses=top\,groupOfUniqueNames org.apache.jetspeed.ldap.GroupObjectClasses=top\,organization org.apache.jetspeed.ldap.UserObjectClasses=top\,person\,organizationalPerson\,inetorgperson define the ID attribute used to search roles/groups/users org.apache.jetspeed.ldap.RoleIdAttribute=cn org.apache.jetspeed.ldap.GroupIdAttribute=cn org.apache.jetspeed.ldap.UserIdAttribute=uid As you can see, filters and objectClasses can now be configured, and no jetspeed specific object classes or attributes need to be used. The provided config files in the patch (components/security/src/test/JETSPEED-INF/directory/config ) have been tested on apacheds,openldap and sunds I'm going to try and get it up & running with Lotus Domino and Active Directory today (hasn't been tested yet). Feel free to try out the patch and let me know if you have any problems
          Davy De Waele made changes -
          Field Original Value New Value
          Attachment jetspeed-ldap-final.patch [ 12340983 ]
          Hide
          Aaron Evans added a comment -

          Nice work Davy! This is great!

          I like how you can control roles via group membership or by user attributes so that you can use SunOne out of the box or OpenLDAP (that doesn't support nsroledefintion). Also, the flexibility around object classes and how searches are done is great.

          -aaron

          Show
          Aaron Evans added a comment - Nice work Davy! This is great! I like how you can control roles via group membership or by user attributes so that you can use SunOne out of the box or OpenLDAP (that doesn't support nsroledefintion). Also, the flexibility around object classes and how searches are done is great. -aaron
          Hide
          David Sean Taylor added a comment -

          patch applied
          im going to leave this issue open since:

          a) it needs testing by others
          b) hoping for some docs

          Show
          David Sean Taylor added a comment - patch applied im going to leave this issue open since: a) it needs testing by others b) hoping for some docs
          Hide
          Ate Douma added a comment -

          The patch breaks Jetspeed on Java 1.4 as it uses Java 5 API:

          • javax.naming.ldap.LdapName
          • javax.naming.directory.SearchResults.getNameInNamespace()

          As I need to be able to build trunk on Java 1.4, I'm going to comment out these dependencies WHICH WILL BREAK THE LDAP support!!!

          Davy. see if you can fix the Java 5 dependencies so it can compile and run on Java 1.4 again.

          Show
          Ate Douma added a comment - The patch breaks Jetspeed on Java 1.4 as it uses Java 5 API: javax.naming.ldap.LdapName javax.naming.directory.SearchResults.getNameInNamespace() As I need to be able to build trunk on Java 1.4, I'm going to comment out these dependencies WHICH WILL BREAK THE LDAP support!!! Davy. see if you can fix the Java 5 dependencies so it can compile and run on Java 1.4 again.
          Hide
          Davy De Waele added a comment -

          I've created a new patch for the ldap security module

          This release contains

          jdk1.4 compatibility fix
          bugfixes
          sample LDAP setups for apacheds,sunds,openldap and domino (LDIFs & jetspeed configs)

          I'm currently working on the docs describing the various configuration parameters that are in the
          spring config file.

          However, please have a look at the spring configuration files & properties files contained in the security test
          package as they contain example setups for different LDAP vendors. You should be able to run them out
          of the box.

          If you don't wanna build jetspeed, I can provide an updated jetspeed-security-2.1-dev.jar.

          The jetspeed security interfaces have been stable for quite some time, so you should be able to just plugin an
          updated JAR and spring config file.

          If someone needs help in setting this up with an existing ldap schema, or just wants to play around with jetspeed2/LDAP, let me know.

          Show
          Davy De Waele added a comment - I've created a new patch for the ldap security module This release contains jdk1.4 compatibility fix bugfixes sample LDAP setups for apacheds,sunds,openldap and domino (LDIFs & jetspeed configs) I'm currently working on the docs describing the various configuration parameters that are in the spring config file. However, please have a look at the spring configuration files & properties files contained in the security test package as they contain example setups for different LDAP vendors. You should be able to run them out of the box. If you don't wanna build jetspeed, I can provide an updated jetspeed-security-2.1-dev.jar. The jetspeed security interfaces have been stable for quite some time, so you should be able to just plugin an updated JAR and spring config file. If someone needs help in setting this up with an existing ldap schema, or just wants to play around with jetspeed2/LDAP, let me know.
          Davy De Waele made changes -
          Attachment ldap_patch_with_jdk_fix.patch [ 12343732 ]
          Hide
          Davy De Waele added a comment -

          The jetspeed2-ldap-11102006.patch contains a number of bugfixes and additional sample LDIF and Jetspeed configurations.

          After applying the patch, look into the following folder for sample LDIF & Jetspeed configurations

          D:\PROJECTS\ECLIPSE\JETSPEED2\jetspeed-2\components\security\src\test\JETSPEED-INF\directory\config

          There, you'll find samples for openldap, apacheds, sunds and lotus domino.

          Let me know if you have any problems with the patch.

          Show
          Davy De Waele added a comment - The jetspeed2-ldap-11102006.patch contains a number of bugfixes and additional sample LDIF and Jetspeed configurations. After applying the patch, look into the following folder for sample LDIF & Jetspeed configurations D:\PROJECTS\ECLIPSE\JETSPEED2\jetspeed-2\components\security\src\test\JETSPEED-INF\directory\config There, you'll find samples for openldap, apacheds, sunds and lotus domino. Let me know if you have any problems with the patch.
          Davy De Waele made changes -
          Attachment jetspeed2-ldap-11102006.patch [ 12344804 ]
          Hide
          Davy De Waele added a comment -

          I've also written up some documentation describing the new LDAP configuration, and the properties in security-spi-ldap.xml.

          Sorry for the MS Word format... Efforts are on the way to convert it into xdoc format

          If you have any problems or questions, don't hesitate to contact me.

          Show
          Davy De Waele added a comment - I've also written up some documentation describing the new LDAP configuration, and the properties in security-spi-ldap.xml. Sorry for the MS Word format... Efforts are on the way to convert it into xdoc format If you have any problems or questions, don't hesitate to contact me.
          Davy De Waele made changes -
          Attachment jetspeed LDAP.doc [ 12344805 ]
          Ate Douma made changes -
          Assignee Ate Douma [ adouma ]
          Ate Douma made changes -
          Link This issue blocks JS2-567 [ JS2-567 ]
          Hide
          Ate Douma added a comment -

          Davy,

          I've finally was able to complete the doc->xdoc translation and thus committed your patch (NB: with some small enhancements) and the new ldap documentation.
          Thanks a lot!

          All,

          The provided testcases fail using ApacheDS because of two critical bugs detected as well as reported:

          • DIRSERVER-782 : Restart required after changing password
          • DIRSERVER-783 : Adding another value to an attribute results in the value to be added twice

          So, for the time being, ApacheDS (1.0.0) cannot be used reliably with Jetspeed and the waiting is for release 1.0.1 (soon they say, and it should have the above issues fixed).

          OpenLDAP works fine though, and Davy reported success with Domino and SunDS too.

          Show
          Ate Douma added a comment - Davy, I've finally was able to complete the doc->xdoc translation and thus committed your patch (NB: with some small enhancements) and the new ldap documentation. Thanks a lot! All, The provided testcases fail using ApacheDS because of two critical bugs detected as well as reported: DIRSERVER-782 : Restart required after changing password DIRSERVER-783 : Adding another value to an attribute results in the value to be added twice So, for the time being, ApacheDS (1.0.0) cannot be used reliably with Jetspeed and the waiting is for release 1.0.1 (soon they say, and it should have the above issues fixed). OpenLDAP works fine though, and Davy reported success with Domino and SunDS too.
          Ate Douma made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Fix Version/s 2.1 [ 12310617 ]
          Ate Douma made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Gavin made changes -
          Link This issue blocks JS2-567 [ JS2-567 ]
          Gavin made changes -
          Link This issue is depended upon by JS2-567 [ JS2-567 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Resolved Resolved
          303d 17h 18m 1 Ate Douma 08/Dec/06 01:57
          Resolved Resolved Closed Closed
          1761d 19h 40m 1 Ate Douma 04/Oct/11 22:37

            People

            • Assignee:
              Ate Douma
              Reporter:
              David Le Strat
            • Votes:
              2 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development