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.
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
bluemixLogCollector-1.1features. 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 import bluemixLog
wlp/bin/bluemixUtility bind yourServer bluemixLog
Please note that
logmetCollector-1.0released in previous beta versions, is now
- 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
- You are now able to invoke the
PasswordUtilclass in your application for encrypting or decrypting sensitive data. The
SecurityUtilitycommand line tool also supports this custom encryption.
openidConnectClient-1.0now 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.0feature. In the
validationEndpointUrl=“the introspection endpoint URL in the authorization server”.
openidConnectClient-1.0has 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 V184.108.40.206 release in June 2015:
- April 2016 beta
- March 2016 beta
- February 2016 beta
- January 2016 beta
- December 2015 beta
- November 2015 beta
- October 2015 beta
- September 2015 beta
- August 2015 beta
- July 2015 beta
- June 2015 beta