Derby
  1. Derby
  2. DERBY-4975

LDAPAuthenticationTest does not heed port number, and other quirks

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 10.8.1.2
    • Fix Version/s: None
    • Component/s: Test
    • Urgency:
      Normal
    • Bug behavior facts:
      Security

      Description

      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.

        Activity

        Dag H. Wanvik created issue -
        Hide
        Knut Anders Hatlen added a comment -

        All the suggestions sound like good improvements to me. Also, the test requires one user that's parametrizable (derbyTesting.ldapUser) and one hard-wired user (kathy). We could probably make both users parametrizable.

        Show
        Knut Anders Hatlen added a comment - All the suggestions sound like good improvements to me. Also, the test requires one user that's parametrizable (derbyTesting.ldapUser) and one hard-wired user (kathy). We could probably make both users parametrizable.
        Myrna van Lunteren made changes -
        Field Original Value New Value
        Labels derby_triage10_8
        Urgency Normal
        Rick Hillegas made changes -
        Affects Version/s 10.8.1.1 [ 12316356 ]
        Affects Version/s 10.8.1.0 [ 12315561 ]
        Rick Hillegas made changes -
        Affects Version/s 10.8.1.2 [ 12316362 ]
        Affects Version/s 10.8.1.1 [ 12316356 ]
        Gavin made changes -
        Workflow jira [ 12542749 ] Default workflow, editable Closed status [ 12801005 ]

          People

          • Assignee:
            Unassigned
            Reporter:
            Dag H. Wanvik
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development