Here’s the latest WebSphere Liberty beta and WebSphere Developer Tools (WDT).

Thanks to your support for our regular beta programme, we are able to release new Liberty features every few months. Most recently, in April.

Look out for more betas over the coming months.

Get it now! Give feedback on dWAnswers

What’s in the WebSphere Liberty beta for May?

  • Log Consolidation with Logstash and Bluemix Log Collector
    You can now configure your Liberty servers to send messages, trace, access logs, FFDC, and garbage collection events to either Logstash or the Bluemix log collector service using the logstashCollector-1.1 and bluemixLogCollector-1.1 features. Use the Logstash collector feature if you want to send events to your own Logstash server. Use the Bluemix log collector feature if you want to send your events to Bluemix. To set up a Liberty server to send events to Bluemix, run the following 3 commands:

    wlp/bin/bluemixUtility login
    wlp/bin/bluemixUtility import bluemixLog
    wlp/bin/bluemixUtility bind yourServer bluemixLog

    Please note that logmetCollector-1.0 released in previous beta versions, is now bluemixLogCollector-1.1.

  • Updates to security features
    • Support for 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, the user registry will not need to be configured.
    • Various usability enhancements to the PasswordUtil class.
    • You are now able to invoke the PasswordUtil class in your application for encrypting or decrypting sensitive data. The SecurityUtility command line tool also supports this custom encryption.
    • openidConnectClient-1.0 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 rely on client authentication from 3rd party authorization servers.

      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”.

    • openidConnectClient-1.0 has also been updated to accept a valid OAuth 2.0 bearer access token as an authentication token without redirecting the request to the OpenID Connect provider. If a request contains a valid OAuth 2.0 bearer access token, then the Liberty OpenID Connect Client will automatically validate the access token, and create an authenticated subject based on the token validation result.

      If a request does not contain an access token or the access token is invalid, Liberty OpenID Connect Client will continue to redirect the user to the OpenID Connect provider. This function enables your Liberty server to serve both the browser client and a non-browser client, such as a RESTful client.
      To enable this function, add inboundPropagation=”supported” to the configuration.

What’s already in there?

The April 2016 beta included new updates to the samlWeb-2.0 feature, as well as updates to both openidConnectServer-1.0 and openidConnectClient-1.0.

Take a look at the previous beta announcements for a full list of stuff added since the V8.5.5.6 release in June 2015:

Get it now! Give feedback on dWAnswers

Join The Discussion

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