WebSphere Liberty is Java EE 8 compatible and is now available to download. WebSphere Liberty is built on the open source Open Liberty project.

Java EE 8 updates include reactive client and server-side events in JAX-RS 2.1, asynchronous events in CDI 2.0, Servlet 4.0 including HTTP/2 support, JSF 2.3 and JPA 2.2.

As well as the Java EE 8 updates, you can now deploy your Spring Boot applications to Liberty, control certificate mapping to users, document your RESTful APIs with OpenAPI, more simply manage collective security, and configure single logout for single sign-on (SSO) applications.

Join our free webcast

Learn about Liberty V18.0.0.2, try it out, and ask questions of the team (choose the date that suits your timezone):

Download WebSphere Liberty 18.0.0.2 now

Download WebSphere Liberty 18.0.0.2 Ask a question on Stack Overflow

What’s new in WebSphere Liberty 18.0.0.2?


Full support for Java EE 8 with convenience features

WebSphere Liberty is the first Java EE 8 compatible application server! In fact, we’re so first that they’ve not had a chance to update the official page yet…

WebSphere Liberty is built on the Open Liberty open source project, which contains the full Java EE 8 implementation (along with MicroProfile 1.3). To find out more about the Java EE 8 features, see the Open Liberty 18.0.0.2 blog post.

Quickly enable Java EE 8 (Full or Web profile) with convenience features

You can download Liberty with Java EE 8 Web Profile runtime (and with the Java 8 SDK) or Liberty with Java EE 8 Full Platform runtime.

You can enable all of the Java EE 8 features (or the more lightweight set of Web Profile features) with a single feature in your server.xml. Just add the relevant feature definition to your server.xml.

For Java EE 8 Web Profile:

<featureManager>
    <feature>webProfile-8.0</feature>
</featureManager>

Or for Java EE 8 Full Platform:

<featureManager>
    <feature>javaee-8.0</feature>
</featureManager>

Enable single logout of SAML sessions in your web app

Liberty as a SAML service provider is now equipped with the SAML single logout function which allows users to terminate all the login sessions established using SAML Web single sign-on (SSO). This single logout function can be initiated from either the service provider or the identity provider. Single logout improves security by avoiding abandoned login sessions, and can simplify administration by providing a centralized way to log out.

Using SAML Web SSO, the user logs in to the identity provider once and receives unlimited access to different web applications without additional login prompts. It is not easy for the end user to be aware of all the opened web sessions and, as a result, they can end up with orphaned log-in sessions which might pose a security risk.

This SAML single logout (SLO) function enables near-simultaneous logout of an end user. It also allows the users to terminate all their login sessions with one click of a mouse button and can be initiated from service provider or identity provider.

To enable the SSO feature in the server.xml:

<featureManager>
   <feature>samlWeb-2.0</feature>
</featureManager>

To configure the Liberty service provider (SP) for SAML single logout:

For identity provider initiated logout, no additional configuration is required. An SLO endpoint URL is published in the client’s metadata, and SLO-capable identity providers can read the metadata and call it.

To configure the Liberty service provider (SP) for SAML single logout, add a samlWebSso20 element to server.xml with spLogout="true":

    <server>
     <samlWebSso20 id="sp2" ... spLogout="true" />
     ...
    </server>

Subsequent calls to HttpServletRequest.logout() or ibm_security_logout are then upgraded to perform SAML single logout.

The SingleLogoutService URL is https://:/ibm/saml20//slo. That URL will also be included in in the Liberty SP’s metadata, available at https://:/ibm/saml20//samlmetadata

For more info:

Document RESTful APIs in your Java apps with OpenAPI

The new OpenAPI 3.1 (openapi-3.1) feature is an extension of the MicroProfile OpenAPI 1.0 (mpOpenAPI-1.0) feature. In addition to providing support for the MicroProfile OpenAPI 1.0 specification, this feature also provides an aggregated view of APIs from multiple applications deployed in the server.

To enable the OpenAPI 3.1 feature, add the feature definition to your server.xml:


           <featureManager>
                  <feature>openapi-3.1</feature>
          </featureManager>

Then use one of the documentation methods specified in this section of the specification for each of your applications. You can view the generated aggregated OpenAPI document in the endpoint /api/docs, or view the rendered user interface in the endpoint /api/explorer.

Customize the URL path of the public endpoints by using MicroProfile Configuration. For example, setting the mp.openapi.extensions.liberty.public.url property to /my/custom changes the location of the aggregated document endpoint from /api/docs to /my/custom/docs. Similarly, the location of the rendered user interface changes from /api/explorer to /my/custom/explorer.

You can designate APIs as private by setting the mp.openapi.extensions.liberty.public property to false at the application level. This setting hides APIs from the public endpoint view. Setting the mp.openapi.extensions.liberty.enable.private.url property to true makes private APIs available at the following private endpoints: /ibm/api/docs (aggregated document) and /ibm/api/explorer (UI).

For more info:

Manage high availability servers with Liberty collectives

18.0.0.2 introduces a new single collective SSH key model which makes collective administration simpler and more secure. Previously, each collective member would have its own SSH key pair and its private key would be stored in the collective repository. Now, a single SSH key pair can be shared by all members of a collective without the storage of private keys. Also, z/OS users can now use SAF keyrings for remote authentication throughout the collective.

Starting in 18.0.0.2, the single collective SSH key model is used by default. When a collective controller is created, the single collective-wide key pair is generated without having to configure or specify anything. When members join the collective, it receives the public key form the controller and adds it to its authorized keys file. Alternatively, rather than generating a new SSH key pair, users can specify an existing key pair or SAF keyring to use when creating the controller.

For more info:

Download Liberty 18.0.0.2 Ask a question on Stack Overflow


Built on Open Liberty

We’d love you to get involved in any way that you can, such as testing the code in ways that you use Liberty and raising issues on GitHub, or create pull requests on the code and documentation. You can contribute to discussions about Open Liberty on the mailing list.

Join The Discussion

Your email address will not be published. Required fields are marked *