Payara Server and Payara Micro 5.182 are here, the second release of the Payara Platform 5 series.
For this release, the focus has been on security related features and updating our MicroProfile support.
Java EE ships with an API that allows for custom authorization modules. Briefly, authorization modules execute the logic behind simple declarative security constraints like @RolesAllowed or <security-constraint> in web.xml, which usually translate into questions like: "Does the current caller have permission to do X", with X being executing a method or accessing a URL. Authorization modules are the artefacts in Java EE that are given the opportunity to answer that question.
Authorization modules in Java EE are specified by the JACC spec, which happens to be the most unknown spec in Java EE. One of the biggest issues with that spec is arguably the fact that a custom authorization module can't be easily installed via application code (like we can do for a Servlet filter or a JASPIC authentication module, for example). Instead, such authorization module (called a "JACC Provider") has to be installed into the server itself, which is a different process for each server. This barrier has likely contributed much to developers not taking advantage of JACC, even when they do have a need for its functionality.
Payara Server and Payara Micro 5.182 have now taken a first step to resolve this issue with the introduction of a Payara API that allows a JACC provider to be installed from the application. With this API, the Payara Platform sails ahead of an anticipated similar API that will be potentially added to the JACC spec itself in a future revision. An example is available in the Java EE samples repo.
The OAuth2 protocol is a popular mechanism to authenticate callers of a web application. It allows callers to actually authenticate with a trusted third party, which will then essentially vouch for the caller being authenticated (vouching that callers indeed are the ones they say they are). Note though that technically OAuth2 is an authorization protocol and that authentication is sort of a side effect (if you're authorised for something, you must have been authenticated). Using OAuth2 relieves websites of storing and guarding passwords themselves, and relieves callers of (a part of) the burden of having to create accounts at each website. OAuth2 is the protocol that's often powering the "login with Facebook, Google, Twitter, etc" buttons that have become quite ubiquitous on the Internet.
An Oauth2 authentication mechanism was originally slated for inclusion in the initial version of the EE Security API (JSR 375), but due to timing constraints had to be left out.
Payara Server and Payara Micro 5.182 now ship with a ready to use OAuth2 authentication mechanism, which is fully based on the EE Security APIs. An example is available in the Java EE samples repo.
Yubikey is quite a different mechanism than Oauth2 for authenticating callers. Yubikey is a hardware authentication device for generating tokens often used to log into more sensitive primary accounts, e.g. the kinds of accounts you would afterwards use to login with OAuth2 on other sites.
Payara Server and Payara Micro 5.182 now ship with a ready-to-use Yubikey authentication mechanism and Yubikey identity store, which is fully based on the EE Security APIs.
Password Alias Inject
Password aliases stored in Payara Server can now be found and injected using the MicroProfile Config API. This allows passwords to be accessed programmatically without hard coding the value. This in turn can help with JDBC application security by obscuring database passwords.
SNI SSL Support
In previous versions of Payara Server and Payara Micro only one SSL certificate per IP address could be used, which would be problematic if multiple domains resolved to the same IP address. The Payara Platform now supports Server Name Indication (SNI). SNI is an extension to TLS, where the caller doesn't just indicate the IP address it's connecting to, but the domain name as well.
Multiple SSL certificates can now be provided for the same IP address, which means IP addresses being shared by separate domain names can now have their own SSL certificates.
Let's Encrypt is a well-known CA (certificate authority) providing free certificates for TLS (HTTPS). Previous versions of the Payara Platform didn't know this CA, so users had to add certificates to Payara's truststore manually. Payara Server and Payara Micro 5.182 have added Let's Encrypt as a trusted CA to the default truststore (cacerts), so Payara Platform users don't need to do this manually anymore.
MicroProfile 1.3 Support
Payara Server and Payara Micro 5.182 include an update for compatibility with MicroProfile 1.3, with the following APIs:
- JAX-RS 2.0
- CDI 2
- JSON-P 1.0
- Common Annotations 1.2
- Microprofile Config 1.2 (updated 1.1 → 1.2)
- Microprofile Open API 1.0 (new)
- Microprofile OpenTracing 1.0 (new)
- Microprofile Rest Client 1.0 (new)
- Microprofile Metrics 1.1 (updated 1.0 → 1.1)
Payara Server Port Autobinding
In previous versions, Payara Micro has had the ability to autobind to a range of ports. With 182, this capability is also now included in Payara Server. This means that Payara Server instances can now be started with the same port range of Payara Micro instances. It also means that starting many Payara Micro instances will have a much lower chance of collision due to startup times.
Hazelcast Based 2nd Level Caching Provider for EclipseLink
The Java EE persistence API (JPA) has a standard feature for globally caching entities based on their identity. Using such cache, called the 2nd Level Cache, can greatly reduce the load on a database.
Payara Server and Payara Micro have had Hazelcast, an in-memory data grid, built-in for some time now, but didn't support it for usage as a 2nd Level Caching provider for JPA. Payara Server and Payara Micro 5.182 now combine these two, and allow Hazelcast to be used as a 2nd Level Caching provider for EclipseLink. This was made possible by community member Sven Diedrichsen.
For Payara Server and Payara Micro 5.182 the following components have been updated:
- Jersey 2.27
- Weld 3.0.4.Final
- Hibernate Validator 6.0.9.Final
- Jackson-databind 2.9.5
As usual, a set of various bugs have been fixed, including a rare race condition in Grizzly initialisation, sending asadmin commands from Admin console to Payara Micro instance(s), injection in a second war in an ear and many more. See the full release notes for additional details on those.