The UnboundID LDAP SDK for Java <https://github.com/pingidentity/ldapsdk>
is a fast, powerful, user-friendly, and completely free Java library for
communicating with LDAP directory servers and performing other LDAP-related
processing. We have just released version 5.0.0 of the LDAP SDK, and it is
available for download from GitHub
<https://github.com/pingidentity/ldapsdk/releases> and SourceForge
<https://sourceforge.net/projects/ldap-sdk/files/>, as well as from the Maven
Central Repository
<https://search.maven.org/search?q=g:com.unboundid%20AND%20a:unboundid-ldapsdk&core=gav>.
The release notes are available online at
https://docs.ldap.com/ldap-sdk/docs/release-notes.html.
The most significant change in this new release is that the LDAP SDK is now
available under the terms of the Apache License, Version 2.0
<https://github.com/pingidentity/ldapsdk/blob/master/LICENSE.md>, which is
a very permissive OSI-approved open source license. Although it was already
open source under the terms of the GNU GPLv2
<https://raw.githubusercontent.com/pingidentity/ldapsdk/master/LICENSE-GPLv2.txt>
and LGPLv2.1
<https://raw.githubusercontent.com/pingidentity/ldapsdk/master/LICENSE-LGPLv2.1.txt>,
the Apache License imposes fewer restrictions on how you can use the LDAP
SDK. You are no longer required to offer to redistribute the source code
(even if you want to use a modified version), and there’s no longer any
concern about whether you need to keep the LDAP SDK jar file as a separate
component. The Apache License is well respected and is often seen as more
compatible and easier to use in non-open-source software than the GNU
license, so we hope that this will make it easier to use in your
applications, whether open source or proprietary. The LDAP SDK is still
available for use under the terms of the GPLv2 and LGPLv2.1 (as well as the
non-open-source UnboundID LDAP SDK Free Use License
<https://raw.githubusercontent.com/pingidentity/ldapsdk/master/LICENSE-UnboundID-LDAPSDK.txt>),
but we recommend that new users consider using it under the Apache License.
Aside from adding the new license, we made several code changes in this
release as well. They include:
-
The LDAP SDK offers an LDAPConnectionDetailsJSONSpecification
<https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/util/json/LDAPConnectionDetailsJSONSpecification.html>
class that allows you to define a JSON file with all of the settings needed
to create and authenticate individual LDAP connections or connection pools.
We’ve updated this class so that it’s now possible to indicate that when
establishing a connection that is secured with SSL or StartTLS, the LDAP
SDK should automatically trust any certificates signed by an authority in
the JVM’s default set of trusted issuers. This was already the default
behavior if you didn’t provide your own trust store (or choose to blindly
trust all certificates, which isn’t recommended for production use), but
it’s now possible to use this option in conjunction with a provided trust
store so that it’s possible to trust a certificate either through that
trust store or through the JVM’s default set of trusted issuers.
-
The KeyStoreKeyManager
<https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/util/ssl/KeyStoreKeyManager.html>
can be used to obtain a certificate from a key store file if one is needed
during TLS negotiation. We have updated this class to provide an option to
better validate that the key store can actually be used by this purpose
with the settings that you provide. If you use this option and supply the
alias of the certificate you wish to use, then the key manager will now
verify that the alias exists in the key store, that it’s associated with a
private key entry (as opposed to a trusted certificate entry, which only
contains the public portion of a certificate and isn’t suitable for use if
you need to present that certificate to the peer), and that all of the
certificates in the chain are currently within their validity window. If
you don’t specify a certificate alias, then the validation will make sure
that the key store contains at least one private key entry in which all of
the certificates in the chain are within their validity window.
-
The TrustStoreTrustManager
<https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/util/ssl/TrustStoreTrustManager.html>
can be used in the course of determining whether to trust a certificate
presented by a peer during TLS negotiation. We have improved performance
and concurrency for this trust manager by eliminating unnecessary
synchronization that forced interaction with the trust store to be
single-threaded.
-
We fixed an issue that could interfere with GSSAPI authentication
<https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/GSSAPIBindRequest.html>
if a JAAS login module configuration was loaded and cached by the JVM
before the login attempt. In such cases, the cached configuration could be
used instead of the one that was intended.
-
The LDAPDebuggerRequestHandler
<https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/listener/LDAPDebuggerRequestHandler.html>
can be used to log detailed information about LDAP requests and responses
that pass through an application using the LDAP SDK’s LDAPListener
<https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/listener/LDAPListener.html>
framework (including the in-memory directory server
<https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/listener/InMemoryDirectoryServer.html>
and the ldap-debugger
<https://docs.ldap.com/ldap-sdk/docs/tool-usages/ldap-debugger.html>
command-line tool). We fixed an issue that could cause messages to be held
up in an internal buffer rather than immediately written out as soon as
they’re logged. In some cases, this could significantly delay the
appearance of these messages or could prevent them from being written out
at all if the amount of data to be logged was never enough to fill that
internal buffer.
-
We added a new JSONAccessLogRequestHandler
<https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/listener/JSONAccessLogRequestHandler.html>
to the LDAPListener framework. This can log information about requests and
responses as JSON objects, which are both human-readable and
machine-parseable. While the existing AccessLogRequestHandler
<https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/listener/AccessLogRequestHandler.html>
produces output that can be parsed programmatically to some extent, it is
more optimized for human readability.
-
The LDAP SDK offers debugging logging support
<https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/util/Debug.html>
that can be helpful in diagnosing problems whose cause may not otherwise be
readily apparent. Previously, the debug messages were logged in a form that
was primarily intended to be human-readable rather than machine-parseable.
They are now written in a JSON format that is both human-readable and
machine-parseable.
-
The manage-certificates
<https://docs.ldap.com/ldap-sdk/docs/tool-usages/manage-certificates.html>
command-line tool provides a utility for interacting with certificate key
and trust stores in the Java JKS format or the standard PKCS #12 format.
When displaying detailed information about certificates in a key or trust
store, the tool may not have been able to properly decode public key
information for certificates with 384-bit elliptic curve public keys, and
it also may not have been able to properly decode a subject alternative
names extension that included one or more directoryName values. While it
was still possible to display most of the information about the affected
certificates, the updated version can now provide the full details about
those elements.
-
The Ping Identity Directory Server
<https://www.pingidentity.com/en/platform/directory/directory-overview.html>
includes a collect-support-data utility that can be used to gather a
variety of information from a server installation that can be very useful
for troubleshooting problems, tuning performance and scalability, and
better understanding the environment in which the server is running.
Previously, this utility could only be invoked by logging into the system
on which the server instance is running and running the command-line tool.
We have now added a couple of additional mechanisms for running the
utility. It can now be invoked via an administrative task
<https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/unboundidds/tasks/CollectSupportDataTask.html>
(either as an individual event that is requested by a remote client or as a
recurring task that runs on a regular basis) that will create the resulting
support data archive in a specified location on the system (which may be a
shared filesystem for easier exfiltration). It can also be invoked
via an extended
operation
<https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/unboundidds/extensions/CollectSupportDataExtendedRequest.html>
that will run the tool and stream its output and the resulting support data
archive back to the client in the form of intermediate response messages.
Further, although the logic for actually collecting all of this support
information remains in the server, we have added the collect-support-data
<https://docs.ldap.com/ldap-sdk/docs/tool-usages/collect-support-data.html>
command-line tool to the LDAP SDK so that it is easier to invoke the tool
against a remote server without needing to install the server software on
the client system.
-
The Ping Identity Directory Server provides a monitor backend that
authorized clients can use to obtain a wealth of useful information about
the state of the server, and the LDAP SDK includes support for retrieving
and parsing the information in these monitor entries. We have updated the
LDAP SDK’s support for the general monitor
<https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/unboundidds/monitors/GeneralMonitorEntry.html>
(that is, the top-level “cn=monitor” entry) to make it easier to obtain
information about the cluster with which the server is associated, the
location of the server instance, and a unique identifier that was generated
for the server when the instance was initially configured.
-
The LDAP SDK offers a Version
<https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/Version.html>
class that provides version information for the LDAP SDK, including the
version number and information about the repository (e.g., the repository
URL and revision ID) from which the LDAP SDK source code was obtained. This
information was previously only offered as public static final constants,
but referencing these constants from third-party applications could lead to
unexpected behavior thanks to a “feature” of the Java compiler that will
directly imbed the values of those constants (even if they come from a
separate library) in the Java bytecode that it generates. This means that
if your application references these LDAP SDK version constants and you
compile it against one version of the LDAP SDK, then those version
constants will be placed directly into the compiled bytecode. If you
upgrade the LDAP SDK version that you use without recompiling your
application (e.g., by just replacing the LDAP SDK jar file with a newer
version), the code referencing the LDAP SDK version would still have the
old values. To address this, we have updated the Version class to provide
methods for obtaining the values of all the version constants. If you use
these methods to obtain the values rather than referencing the constants
directly, then you will always get the correct LDAP SDK version information
even if you update the LDAP SDK without recompiling your application.
--
_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._
|