LDAPAuthenticationTest does not heed port number, and other quirks
------------------------------------------------------------------
Key: DERBY-4975
URL: https://issues.apache.org/jira/browse/DERBY-4975
Project: Derby
Issue Type: Bug
Components: Test
Affects Versions: 10.8.0.0
Reporter: Dag H. Wanvik
Priority: Minor
The test fails unless Java system property "derbyTesting.ldapPort" is supplied,
but it is not used, so the test cannot be used against an LDAP serves that uses
anything than 389 (default port).
Additionally, the test property "derbyTesting.dnString" is not what it purports
to be, since the parameter given is used as a value for "o=" when doing a
search. The property should contain the entire relevant dn (distinguised name)
string which is the root of the lookup, I think, e.g.
-DderbyTesting.dnString="o=myOrg" or
-DderbyTesting.dnString="dc=example,dc=com"
cf. e.g. http://www.ldapman.org/articles/intro_to_ldap.html (quote):
"The top level of the LDAP directory tree is the base, referred to as the "base
DN." A base DN usually takes one of the three forms:"
- o=foobar.com (base DN derived from the company's Internet presence)
- o="FooBar, Inc.", c=US (base DN in X.500 format)
- dc=foobar, dc=com (base DN derived from the company's DNS domain
components)
This will make the test more independent of actual LDA server organization.
Similarly, the test specifies that ou=People should be used. I this this should
be parameterizable as well.
The attempt to store the dn locally using the "derby.user.<user>" (to avoid
lookup) doesn't seem to be working. I think there is a bug in
LDAPAuthenticationSchemeImpl as well in this regard:
#authenticateUser:
:
// Retrieve the user's DN (Distinguished Name)
// If we're asked to look it up locally, do it first
// and if we don't find it, we go against the LDAP
// server for a look-up (search)
//
if (useUserPropertyAsDN)
userDN =
authenticationService.getProperty(
org.apache.derby.iapi.reference.Property.USER_PROPERTY_PREFIX);
The lookup happens against the property "derby.user.", the username is not
appended first, so userDN always returns null, and search ensues before bind.
I'll file a separate issue for this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
