UnboundID LDAP SDK for Java 5.1.1

We have just released version 5.1.1 of the UnboundID LDAP SDK for Java. It is available for download from GitHub and SourceForge, and it is available in the Maven Central Repository. The release notes provide a pretty comprehensive overview of what’s changed since the 5.1.0 release, but here’s a summary:

Server-Agnostic Updates

• We have added new @NotNull and @Nullable annotation types and updated the entire LDAP SDK codebase to mark all non-primitive fields, parameters, and method return values to indicate whether they may be null. These annotations will appear in the generated Javadoc documentation, and they will also be available at runtime for introspection by IDEs and other tools.

• We have improved the logic used to validate certificate hostnames. The LDAP SDK now does a better job of handling hostnames with wildcards, and it does a better job of handling cases in which the connection was established with an IP address rather than a hostname. There is also an option to indicate whether to treat a certificate’s subject alternative name extension (if present) as the only authoritative source of allowed hostnames or to also allow looking at the CN attribute in the certificate subject DN even if the certificate contains a subject alternative name extension.

• We fixed an issue that could prevent command-line tools that support subcommands from performing all appropriate validation when running in interactive mode. The command-line tool’s interactive mode framework neglected to perform required, dependent, and exclusive argument set validation for the selected subcommand, which could cause the tool to run with an inappropriate set of arguments.

• We fixed issues in the code used to format strings in the comma-separated values (CSV) format. Previously, all ASCII control characters and all non-ASCII characters were silently dropped from the output. They are now included, but the value will be in quotes (and may span multiple lines if the value to format includes line breaks). Further, it had previously used the backslash character to escape any double quotes in the data (\"), but RFC 4180 indicates that each double-quote character should be escaped by preceding it with another double quote character (""). The LDAP SDK now uses the RFC-specified behavior as the default, but it is possible to fall back to the former backslash-based encoding if desired or needed for backward compatibility.

• We updated ldapsearch to add multi-valued-csv and multi-valued-tab-delimited output formats. The existing csv and tab-delimited output formats only include the first value for multi-valued attributes, while the multi-valued variants use the vertical bar character (|) as a delimiter between values.

• We updated the ldappasswordmodify command-line tool to default to using the password modify extended operation if it is unable to retrieve the server’s root DSE while attempting to determine which method to use to change the password. The tool would previously exit with an error if the --passwordChangeMethod argument was not provided and it couldn’t retrieve the root DSE to determine an appropriate method.

• We updated the authrate command-line tool so that the --filter argument is not required if the --bindOnly argument is provided.

• Updated the ldapcompare tool so that it always uses an exit code of zero (corresponding to the LDAP success result code) by default if all compare operations are processed successfully, regardless of whether the assertions matched or did not match the target entries. Previously, the tool would use an exit code of 5 or 6 (corresponding to the LDAP compareFalse and compareTrue result codes, respectively) if only a single compare assertion was processed and completed with the corresponding result code. However, returning a nonzero exit code by default can cause problems with scripts that invoke the tool and expect that a nonzero result code indicates that an error occurred. The new --useCompareResultCodeAsExitCode argument can be used to request the previous behavior.

• We updated the ldapcompare tool to allow reading the raw assertion value from a file. If this option is used, then the attribute name or OID should be followed by a colon, a less-than sign, and the path to the file from which the value should be read (for example, “cn:</path/to/asserted-cn-value.txt”). If this option is used, then the exact bytes of the file (including line breaks) will be used as the assertion value for the compare operation.

• We updated the ldifsearch tool so that all non-LDIF output is written as LDIF comments (preceded by the octothorpe character, #) so that it will not interfere with the ability to parse the remaining output as LDIF.

• We added support for the OAUTHBEARER SASL mechanism, as described in RFC 7628.

• We updated the LDAP command-line tool framework to add support for authenticating with additional SASL mechanisms, including OAUTHBEARER, SCRAM-SHA-1, SCRAM-SHA-256, and SCRAM-SHA-512.

• We fixed issues with the ldifsearch, ldifmodify, and ldif-diff tools that could arise if they were run in a manner that would cause the output to be both compressed and encrypted. The tool incorrectly attempted to compress the output after it was encrypted rather than before, making the compression ineffective and the output incompatible with tools that expect compression to be applied before encryption.

• We fixed an issue with the ldifsearch tool that could prevent it from properly finalizing the output when using compression or encryption, potentially leaving buffered data unwritten.

• We fixed an issue with the ldifmodify tool that caused it to use a nonzero exit code if it was only used to add new entries to a previously empty source LDIF file.

• We updated the ldifmodify tool to use lenient mode by default when applying modifications. It would previously reject attempts to add attribute values that already existed or remove attribute values that do not exist, but this could cause problems with applications that did not expect this behavior, as a legacy version of the tool used lenient mode by default. A new --strictModifications argument has been added that can request the strict validation mode if desired.

• We updated the LDAP SDK’s command-line tool framework so that when displaying an example command that is split across multiple lines, it will use an appropriate continuation character for the underlying platform. It previously always used the backslash character (\), which is correct for UNIX-based systems, but it will now use the caret character (^) when running on Windows systems.

• We fixed an issue with the ldifsearch tool that caused its usage output to include example arguments and descriptions intended for use with the ldif-diff tool.

• We fixed an issue in the manage-certificates tool usage output that caused the generate-certificate-signing-request subcommand’s --key-size-bits argument to use the wrong description.

• We updated the documentation to include the latest versions of the draft-kitten-gss-sanon, draft-melnikov-scram-2fa, and draft-melnikov-scram-sha3-512 drafts in the set of LDAP-related specifications.

Updates Specific to the Ping Identity Directory Server

• We added support for a new “get recent login history” control that can be included in a bind request to indicate that the bind response (if authentication was successful) should include information about other recent successful and failed authentication attempts for that user. The ldapsearch and ldapmodify commands have been updated to provide support for this control. We also updated support for the password modify extended operation, the manage-account command-line tool, and the ds-pwp-state-json virtual attribute to provide support for retrieving a user’s recent login history.

• We updated support for the password modify extended operation, the manage-account tool, and the ds-pwp-state-json virtual attribute to provide support for retrieving state information about password validation performed during bind operations, including the time that validation was last performed and whether the account is locked because the bind password failed validation.

• We updated support for the ds-pwp-state-json virtual attribute to provide support for retrieving information about the quality requirements that the user’s password must satisfy.

• We updated the set of potential authentication failure reasons to include an additional failure type for cases in which a password used in a bind request failed to satisfy one or more of the configured password validators.

• We added a new password policy state account usability error that may be used if an account is locked because the user attempted to authenticate with a password that failed to satisfy one or more of the configured password validators.

• We added a new password policy state account usability warning that may be used if an account contains a password that is encoded with a deprecated password storage scheme.

• We updated the collect-support-data tool to add the ability to specify the amount of data to capture from each log file to be included in the support data archive. We have also updated client-side support for the administrative task and extended operation that may be used to invoke collect-support-data processing against a remote server to include support for the new arguments.