Bug 1110206 - LDAPUserGroupCallbackImpl and LDAPUserInfoImpl do not support SUB_TREE search scope
Summary: LDAPUserGroupCallbackImpl and LDAPUserInfoImpl do not support SUB_TREE search...
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss BPMS Platform 6
Classification: Retired
Component: jBPM Core
Version: 6.0.1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: CR1
: ---
Assignee: Alessandro Lazarotti
QA Contact: Radovan Synek
URL:
Whiteboard:
Depends On:
Blocks: 1115481
TreeView+ depends on / blocked
 
Reported: 2014-06-17 08:45 UTC by Hisao Furuichi
Modified: 2020-03-27 20:13 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-27 20:13:10 UTC
Type: Feature Request
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker BPMSPL-83 0 Major Verified [GSS-RFE] SUB_TREE search scope support by LDAPUserGroupCallbackImpl & LDAPUserInfoImpl 2016-06-06 19:14:47 UTC
Red Hat Issue Tracker JBPM-4367 0 Major Resolved LDAPUserGroupCallbackImpl and LDAPUserInfoImpl do not support SUB_TREE search scope 2016-06-06 19:14:47 UTC

Description Hisao Furuichi 2014-06-17 08:45:31 UTC
Description of problem:
If ldap(AD)'s structure is like this:
===
- com
  - sample
    - Business Unit 1 
      - Subunit 1.1 
        - user 1
        - user 2
    - Business Unit 2
      - Subunit 2.1
        - user 3
===
we can not find all of users in this structure by Using appropriate base DN, "com.sample", because default search scope used by LDAPUserGroupCallbackImpl is "one"[1]. Therefore, setting base DN to the root DN does not work. 

Although we can use a custom LDAPUserGroupCallbackImpl, this is a common use case for ldap search, so I report it as bug.

[1] Default is search one level
http://docs.oracle.com/javase/7/docs/api/javax/naming/directory/SearchControls.html#SearchControls()

Steps to Reproduce:
1. prepare ldap tree like this:
===
- com
  - sample
    - Business Unit 1 
      - Subunit 1.1 
        - user 1
        - user 2
    - Business Unit 2
      - Subunit 2.1
        - user 3
===
2. find users

Actual results:
LDAPUserInfoImpl can find either "user 1 and 2" or "user 3"

Expected results:
LDAPUserInfoImpl can find all of users.

Comment 3 Maciej Swiderski 2014-07-17 15:06:24 UTC
change merged into master with slight changes to be only used when actually is set in properties.

jbpm
master:
https://github.com/droolsjbpm/jbpm/commit/dd2b435682fbc1c702a24d6085bf0091a7d82f17

Comment 7 Tomas Livora 2014-08-12 08:27:16 UTC
https://gitlab.mw.lab.eng.bos.redhat.com/bxms/brms/blob/2df19b26eea173e81e774dad3f60a9c97bb61c0c/test-jbpm-regression/src/test/java/com/bpms/customer/BZ1110206LdapUserGroupCallbackSearchScopeTest.java

https://gitlab.mw.lab.eng.bos.redhat.com/bxms/brms/blob/2df19b26eea173e81e774dad3f60a9c97bb61c0c/test-jbpm-regression/src/test/java/com/bpms/customer/BZ1110206LdapUserInfoSearchScopeTest.java

Maciej, great job! According to the results of the tests listed above both components are working as expected. However, I am not sure if the default search scope should be OBJECT_SCOPE when it is not possible to parse the value of 'ldap.search.scope' property. If this property is not set, ONELEVEL_SCOPE is used (as it was in the previous versions). I would recommend to unify this behavior and use ONELEVEL_SCOPE in both cases. What do you think?

Comment 8 Maciej Swiderski 2014-08-27 05:28:51 UTC
Tomas, that's a valid point as when SearchControls object is created with default constructor it does use ONELEVEL_SCOPE so when parsing fails it should do the same. I'll make a change. Thanks a lot!

Comment 11 Tomas Livora 2014-09-15 08:22:41 UTC
Verified on BPMS 6.0.3 CR1

Comment 12 JBoss JIRA Server 2014-09-21 11:06:20 UTC
Maciej Swiderski <swiderski.maciej> updated the status of jira JBPM-4367 to Resolved

Comment 13 JBoss JIRA Server 2014-10-30 13:33:08 UTC
Kris Verlaenen <kris.verlaenen> updated the status of jira BPMSPL-83 to Resolved


Note You need to log in before you can comment on or make changes to this bug.