We changed the version numbering of our Liberty releases.

But what’s new in this release?

WebSphere Application Server is Java EE 7 certified

Java EE 7 applications are now fully supported on WebSphere Application Server traditional (WAS traditional). So Java EE 7 applications that you developed on Liberty will run on WAS now too.

For other download options, see Where can I download WebSphere Application Server V9?

Migration Toolkit updates

As usual, the Migration Toolkit team are hot on the case of making it easy to move applications (and configurations) to Liberty from WebSphere Application Server and from other Java application servers, as well as between versions of WebSphere Application Server. In particular, there are migration toolkit updates for V9 and Java EE 7 with a fresh look for our binary scanner reports.

Runtime updates

dashDB service plug-in

dashDB is built on DB2 database and is available as a service in cloud offerings such as IBM Bluemix. You can use dashDB for your Liberty applications.

OSGi Applications

We now support the latest OSGi R6 API for developing and deploying OSGi Applications on Liberty.

We support OSGi libraries making it easy to make Liberty libraries accessible from OSGi applications. This enables the use of custom resource adapter APIs and the MongoDB and CouchDB features which require the application to be able to call the same client libraries that the runtime is using.

Server package file permissions

The server package tool now encodes the file permissions into the produced ZIP file. When you unzip the package the scripts in the bin folder will be executable.

Security updates

Automatic mapping of a role name to a group name for authorization

Java EE application roles are now automatically mapped to a group of the same name in the user registry if no binding is present. This eliminates the requirement to specify bindings when role names are the same as group names. Configuration of the user registry is now optional. For example, when custom or external authentication is configured and the authorization is handled by a third party or using the automatic role to group name mapping described above, the user registry will not need to be configured.

Enhanced password utilities

You are now able to invoke the PasswordUtil class in your application for encrypting or decrypting sensitive data.

class in your application for encrypting or decrypting sensitive data. You can use the SecurityUtility command line tool to encrypt passwords using a custom encryption provider.

SAML tokens

The samlWeb-2.0 feature has been updated to accept SAML tokens in HTTP request headers as authentication tokens. SAML token propagation is commonly used in service to service calls, for example, proxy servers or restful clients propagate SAML tokens to downstream services. The configuration for SAML propagation is very similar to SAML web browser SSO. You configure the samlWeb-2.0 feature, then add inboundPropagation="required" to the samlWebSso20 configuration.

OpenID Connect client and server updates

OpenID Connect client now accepts OAuth 2.0 bearer access tokens in HTTP request headers as authentication tokens. The token propagation is compliant with standards: OAuth 2.0 Token Introspection The OAuth 2.0 Authorization Framework: Bearer Token Usage This enhancement allows your Liberty server, as an OAuth 2.0 resource server, to serve a non-browser client, such as a RESTful client. The configuration for OAuth token inbound propagation is very similar to configuring Liberty as an OpenID Connect client and relying party. You need to configure an openidConnectClient-1.0 feature. In the openidConnectClient element, add inboundPropagation="required" and validationEndpointUrl="the introspection endpoint URL in the authorization server" . Optionally, you can configure a single Liberty OpenID Connect client instance to serve both the browser client and a non-browser client by adding inboundPropagation="supported" to the configuration. If a request contains a valid OAuth 2.0 bearer access token, the Liberty OpenID Connect client will automatically authenticate the client with the access token. If, however, a request does not contain an access token or the access token is invalid, the Liberty OpenID Connect client will continue to redirect the user to the OpenID Connect provider.

OpenID Connect client is updated to support JSON web key (JWK), so Liberty Openid Connect clients can dynamically download JWK from the OpenID Connect provider. To configure JWK for openidConnectClient-1.0 , add jwkEndpointUrl to the element in server.xml .

OpenID Connect client is updated to support implicit grant type. The implicit grant type is required if the Openid Connect client and provider are in a different firewall and can not connect to the Openid Connect provider that is required for the authorizeation code grant type. To enable implicit grant type, add grantType="implicit" to the element in server.xml .

OpenID Connect server now supports JSON web key (JWK) to publish public keys used in ID Token signatures. With JWK enabled, the Liberty OpenidConnect Provider dynamically generates and publishes an RSA key pair used by the ID Token signature. The JWK endpoint is formatted like: https://op.com:443/oidc/endpoint/[openidConnectProvider configuration id]/jwk and can be found via discovery. To enable JWK in the Liberty OpenID Connect provider, add jwkEnabled="true" in the OpenID Connect provider configuration. Also updated to support SPI for userinfo and token introspection, and you can develop Liberty user features to customize userinfo and token introspection.

WebSphere Developer Tools updates

Support for Eclipse Neon

Eclipse Neon support is now live for all WebSphere tools, including updated Liberty and traditional tools, and new tools for v9! Try WebSphere Developer Tools on Eclipse Neon.

Create a server in WDT for Liberty running in a remote Docker container

Now you can work with a Liberty server running in a remote Docker container on Linux or MAC OS from your local machine. Deploy, modify, and debug applications as if you were working with a local Liberty server.

In the new server wizard, select IBM -> WebSphere Application Server Liberty and fill in the remote host name:



Create a runtime if you have not already done so and then in the New Remote Liberty Server page, select Server in a Docker container, fill in the remote logon information and click Next:



Select the Docker container to use and fill in the Liberty server security credentials. If you don’t have a user defined then WDT will create it for you using the name and password you specify. Note that the HTTP and HTTPS ports must be mapped to the host when you create your container:



Click the Verify button to establish a connection and then click Finish. You now have a workspace representation of your Liberty server running in a remote Docker container.

Policy support for JAX-WS 2.2 without a WSDL

In WDT, a new Policy Attachment wizard has been added to create a policy attachment file.

When you use Liberty JAX-WS, you can apply policies without having to use a WSDL. The WDT Policy Attachment wizard enables you to easily choose the endpoint reference or WSDL policy subject to which a policy will be applied, and generate the policy attachment file based on your selections. Launch the wizard from a JAX-WS service or client node under the Services folder of a containing project or from the Services view.





Admin Center updates