DZone/Java EE Guardians Survey Results: Security

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.

Published by Reza Rahman

Reza Rahman is Principal Program Manager for Java on Azure at Microsoft. He works to make sure Java developers are first class citizens at Microsoft and Microsoft is a first class citizen of the Java ecosystem. Reza has been an official Java technologist at Oracle. He is the author of the popular book EJB 3 in Action. Reza has long been a frequent speaker at Java User Groups and conferences worldwide including JavaOne and Devoxx. He has been the lead for the Java EE track at JavaOne as well as a JavaOne Rock Star Speaker award recipient. He was the program chair for the inaugural JakartaOne conference. Reza is an avid contributor to industry journals like JavaLobby/DZone and TheServerSide. He has been a member of the Java EE, EJB and JMS expert groups over the years. Reza implemented the EJB container for the Resin open source Java EE application server. He helps lead the Philadelphia Java User Group. Reza is a founding member of the Jakarta EE Ambassadors. Reza has over a decade of experience with technology leadership, enterprise architecture and consulting. He has been working with Java EE technology since its inception, developing on almost every major application platform ranging from Tomcat to JBoss, GlassFish, WebSphere and WebLogic. Reza has developed enterprise systems for well-known companies like eBay, Motorola, Comcast, Nokia, Prudential, Guardian Life, USAA, Independence Blue Cross, Anthem, CapitalOne and AAA using Java EE and Spring.

Leave a Reply

%d bloggers like this: