LDAP user registry authentication and JAX-RS multipart payloads new in Open Liberty 21.0.0.5

Austin Bailey on May 14, 2021

announcements , release , security , jakarta-ee , java-ee ,

Post available in languages:

Open Liberty 21.0.0.5 comes complete with a new Kerberos authentication method, allowing for the use of an LDAP user registry to easily and quickly authorize connections originating from the same source. Also included is the ability to create and exchange multipart payloads using JAX-RS clients and services.

In Open Liberty 21.0.0.5:

LDAP connection support for Kerberos authentication
Build multipart payloads for your JAX-RS client and services

View the list of fixed bugs in 21.0.0.5.

Run your apps using 21.0.0.5

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>21.0.0.5</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[21.0.0.5,)'
}

Or if you’re using Docker:

FROM open-liberty

Or take a look at our Downloads page.

LDAP connection support for Kerberos authentication

LDAP bind operations are used to authenticate clients (and the users or applications behind them) to the directory server. This establishes an authorization identity that is used for subsequent operations that are processed on that connection, and specifies the LDAP protocol version that the client uses. Before this update, the LdapRegistry element supported binding either anonymously or by using simple authentication with a user (bindDN) and password (bindPassword). This update adds an option to bind to LDAP: GSSAPI/Kerberos. Kerberos is an authentication mechanism that allows a client and service to mutually authenticate by a Key Distribution Center (KDC). In Open Liberty 21.0.0.5, you can use either a Kerberos credential cache (ccache) or a Kerberos keytab file.

To update an LdapRegistry to use the GSSAPI/Kerberos option, you can set the bind authentication mechanism type using the new LdapRegistry attribute, bindAuthMechanism:

bindAuthMechanism="GSSAPI"

You also need the Kerberos principal or Service Principal Name:

krb5Principal="[email protected]"

If you are using a Kerberos credential cache (ticket cache or ccache) to store the Kerberos credentials, add the ticket cache file name to the LdapRegistry with the new attribute, krb5TicketCache:

krb5TicketCache="${server.config.dir}/security/krb5-user1.cc"

If you are using a custom Kerberos configuration file (krb.conf or krb.ini), set the file name using the global Kerberos configuration element:

<kerberos configFile="${server.config.dir}/security/krb5.conf"/>

If you are using a Kerberos keytab file to store encrypted keys for principals, set the file using the global Kerberos configuration element:

<kerberos keytab="${server.config.dir}/security/krb5.keytab" configFile="${server.config.dir}/security/krb5.conf"/>

If the Kerberos configuration file is not defined, Open Liberty will attempt to resolve by using the JDK default locations and the operating system default locations.

For the Kerberos credentials, the locations are checked in the following order: the ticket cache (if provided), the configured keytab file, and finally the JDK default location.

The following example shows how to configure the LdapRegistry element using a ticket cache and custom Kerberos config file:

<kerberos keytab="${server.config.dir}/security/krb5.keytab" configFile="${server.config.dir}/security/krb5.conf"/>

<ldapRegistry id="LDAP" realm="SampleLdapADRealm" host="ldap_hostname" port="389" ignoreCase="true" baseDN="DC=example,DC=com" bindAuthMechanism="GSSAPI" krb5Principal="[email protected]" krb5TicketCache="${server.config.dir}/security/krb5-user1.cc" ldapType="Custom" />

The following example shows how to configure an LDAP Registry using a keytab and custom Kerberos config file:

<kerberos keytab="${server.config.dir}/security/krb5.keytab" configFile="${server.config.dir}/security/krb5.conf" />

<ldapRegistry id="LDAP" realm="SampleLdapADRealm" host="ldap_hostname" port="389" ignoreCase="true" baseDN="DC=example,DC=com" bindAuthMechanism="GSSAPI" krb5Principal="[email protected]" ldapType="Custom" />

For more information on LdapRegistry, see the LDAP User Registry documentation.

To enable this new function in your app, add the LDAP User Registry 3.0 feature to your server.xml file:

<featureManager>
  <feature>ldapRegistry-3.0</feature>
</featureManager>

Build multipart payloads for your JAX-RS client and services

Often, a RESTful service or client will need to send multiple disparate pieces of data in the same request, for example, uploading a resume/CV with a picture and text for name and address. This is usually done using multipart/form-data.

While Liberty currently has APIs to enable users to receive multipart/form-data payloads, it does not have any APIs to enable users to send multipart payloads - until now. With the new AttachmentBuilder API, users can now send multipart requests from their JAX-RS clients or send multipart payloads as responses from their JAX-RS resources.

To send a multipart request, you will need to enable the jaxrs-2.0 or jaxrs-2.1 feature. Presumably, if you are already using JAX-RS, one of these features will already be enabled. To send a multipart payload, you must send an instance of List<IAttachment>. Each object in that list represents a single attachment part. Here is an example of creating and sending a multipart request from a JAX-RS client:

List<IAttachment> attachments = new ArrayList<>();

attachments.add(AttachmentBuilder.newBuilder("blogPost")
                                 .inputStream(new FileInputStream("/path/to/yesterdaysBlogPost.xml"))
                                 .fileName("myRenamedBlogPost.asciidoc")
                                 .contentType("text/asciidoc")
                                 .contentId("myBlogPostID")
                                 .header("X-PriorityLevel", "Medium")
                                 .build());

attachments.add(AttachmentBuilder.newBuilder("file1")
                                 .inputStream("some.xml", new FileInputStream("/path/to/myPicture.png"))
                                 .contentType("image/png")
                                 .build());

attachments.add(AttachmentBuilder.newBuilder("authorName")
                                 .inputStream(new ByteArrayInputStream("John Doe".getBytes()))
                                 .build());

Response response = client.target(BLOG_SITE_URI)
                          .request()
                          .post(Entity.entity(attachments, MediaType.MULTIPART_FORM_DATA));

For more information vist:

multipart/form-data RFC 7578

Notable bugs fixed in this release

We’ve spent some time fixing bugs. The following sections describe just some of the issues resolved in this release. If you’re interested, here’s the full list of bugs fixed in 21.0.0.5.

Application context path can not end with a slash

Within Open Liberty you are able to retrieve the current context path by calling ServletContext.getContextPath(), the Jakarta EE specification states that this method should return a string that begins with a / character and does not end with a / character. Prior to Open Liberty 21.0.0.5, it was possible for this method to return a context root with a / appended to it, this behaviour has been corrected and will now always remove any trailing / characters.
JDBC kerberos problems on IBM JDK 8

With the release of Open Liberty 21.0.0.5 the following issues have been resolved when using JDBC kerberos with an IBM Java 8 installation:
- Fixed needing to use a file:/ URL pattern for keytab and ccache files.
- Fixed incorrectly identifying when a password is set.
- Fixed various problems related to interactive vs non-interactive modes.
- Fixed Received fatal alert: protocol_version error.
Ensure MP Config properties from the application are visible when mpOpenApi-2.0 runs filters

When using mpOpenApi-2.0, OpenAPI filters can look up MicroProfile Config values from a microprofile-config.properties file included in the application. Previously this functionality did not work and MicroProfile Config would erroneously report that the configuration property did not exist. This behaviour has been corrected and OpenAPI filters will now function as expected.
Correct the synchronization when mpOpenApi-2.0 processes applications

Prior to the release of Open Liberty 21.0.0.5, when using mpOpenApi-2.0, starting two applications concurrently could occasionally produce a number of errors and ultimately OpenAPI documentation may not be created correctly for either application. This behaviour has now been corrected and OpenAPI documentation will be created for one of the applications.

For more information visit the MicroProfile OpenAPI documentation

Get Open Liberty 21.0.0.5 now

Available through Maven, Gradle, Docker, and as a downloadable archive.

See all blog posts