As some of you are aware, the Java EE Guardians and DZone jointly conducted a community survey to help determine Java EE 8 features prior to JavaOne 2016. You may also be aware that we shared the results of that survey with Oracle before the details of the renewed Java EE 8 scope was announced. Now is a great time to start analyzing those results a bit more. I’ve already done a high level summary of the results. I’ve also done a deeper dive into the responses for HTTP/2 and Servlet 4 as well as Java SE 8 alignment. In this entry I’ll take a look at the responses for revamping Java EE security.
Here is how the survey phrased the question:
“Java EE security is one of the last areas left to be revamped in the way most other APIs such as EJB 3 have been changed radically. As a result Java EE security is very highly dependent on things like vendor-specific GUI console wizards, vendor-specific configuration or command-line administrative tools. Pluggability, extensibility and customization is also currently challenging when the security features that already come with the application server are not sufficient.
This situation is the primary driver for the proliferation of third-party security frameworks in server-side Java such as Shiro and Keycloak. The Java EE Security API has been slated to solve these issues in Java EE 8. As an example securing a Java EE application could be as simple as writing the following annotation:
@DataBaseIdentityStore(
lookup=”java:app/MyDB”,
userQuery=”SELECT password FROM principals WHERE username=?”,
rolesQuery=”SELECT role FROM roles where username=?”, …)
How important is it to revamp the Java EE security API?”.
The following graphic shows how the community responded. Support for revamping Java EE security is clearly fairly strong. 47% said it is very important while another 30% said it is important. Only about 5% said it is not important. It is the case though that support is not as strong as it is for example for Servlet 4 and Java SE 8 alignment. I think this generally makes sense. While there are decent options for Java EE security, HTTP/2 support and being able to effectively use Java SE 8 is far more foundational. If you are interested to learn a bit more about the Java EE Security API, a great place to start is the actual working specification draft.
Here are some representative comments from participants in the order that people filled in the survey: “One of the areas where no real standardization is done yet because you always need to have application server specific configuration”, “The currently available security features in Java EE don’t comprise a full end-to-end solution, to really secure an application one has to rely on vendor specific features”, “I always found it quite challenging to work with JAAS and the vendor specific configuration required to get it to work in different containers. I am really looking forward to simpler and better integrated solutions”, “Would be nice to get this into the app and out of the app’s XXXX.xml and container configuration. It would seem to be a step in the right direction to making apps more fully portable”.
It is important to note that in the original survey that helped launch Java EE 8, security related questions rank extremely high. Somewhat surprisingly Oracle’s own Java EE 8/9 survey did not directly include any questions on Java EE security. It did pose questions on OAuth/OpenID support which ranked extremely high. Judging by Oracle’s actions taken to move Java EE 8 forward, it seems they basically took for granted that Java EE security was important and the OAuth/OpenID question may have been more geared towards Java EE 9 (there are many such questions on the Oracle survey). The Java EE Security API is now moving ahead strongly to a completion date of around summer. It is sticking largely to the original scope defined for Java EE 8 while deferring OAuth/OpenID support to maintain delivery schedule (Oracle did in fact consider pulling in OAuth/OpenID support based on survey feedback).
Please do stay tuned as I further analyze specific topics in the survey. In addition to my write-up, I would encourage you to look at these survey results yourself and get involved in Java EE 8. You can certainly do so by becoming a part of the Java EE Guardians.