[ldap-sdk-announce] UnboundID LDAP SDK for Java 5.1.1

[Neil W. <nei...@pi...>]

We have just released version 5.1.1 of the UnboundID LDAP SDK for Java
<https://github.com/pingidentity/ldapsdk>. It is available for download
from GitHub <https://github.com/pingidentity/ldapsdk/releases> and
SourceForge <https://sourceforge.net/projects/ldap-sdk/files/>, and it is
available in the Maven Central Repository
<https://search.maven.org/search?q=g:com.unboundid%20AND%20a:unboundid-ldapsdk&core=gav>.
The release notes <https://docs.ldap.com/ldap-sdk/docs/release-notes.html>
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
   <https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html>, 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 <https://tools.ietf.org/rfc/rfc4180.txt>
   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 <https://docs.ldap.com/specs/rfc7628.txt>.



   -

   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
   <https://docs.ldap.com/specs/draft-ietf-kitten-gss-sanon-01.txt>,
   draft-melnikov-scram-2fa
   <https://docs.ldap.com/specs/draft-melnikov-scram-2fa-01.txt>, and
   draft-melnikov-scram-sha3-512
   <https://docs.ldap.com/specs/draft-melnikov-scram-sha-512-00.txt> 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.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._