This article takes a look at the state of security support in Java EE 6, with a focus on applications that wish to do their own authentication and the usage of the JASPI/JASPIC/JSR 196 API. Update: the further reading section has been moved to my ZEEF page about JASPIC . This contains links to articles, background, questions and answers, and more. Declarative security is easy In Java EE it has always been relatively straightforward to specify to which resources security constraints should be applied. For web resources (Servlets, JSP pages, etc) there is the <security-constraint> element in web.xml, while for EJB beans there's the @RolesAllowed annotation. Via this so called 'declarative security' the programmer can specify that only a user having the given roles is allowed access to the protected web resource, or may invoke methods on the protected bean. The declarative model has a programmatic counterpart via methods like HttpServletRequest#isUserInR...
In this article we take a look at the latest April 2015 beta version of IBM's Liberty server, and specifically look at how well it implements the Java EE authentication standard JASPIC. The initial version of Liberty implemented only a seemingly random assortment of Java EE APIs, but the second version that we looked at last year officially implemented the (Java EE 6) web profile. This year however the third incarnation is well on target to implement the full profile of Java EE 7. This means IBM's newer and much lighter Liberty (abbreviated WLP), will be a true alternative for the older and incredibly obese WebSphere (abbreviated WAS) where it purely concerns the Java EE standard APIs. From having by far the most heavyweight server on the market (weighing in at well over 2GB), IBM can now offer a server that's as light and small as various offerings from its competition. For this article we'll be specifically looking at how well JASPIC works on Liberty. Please ta...
A while ago we looked at which implementation components the various Java EE servers were using. At the time this concerned mostly Java EE 6 servers, with a few Java EE 7 ones thrown in for good measure. Fast forward 6 years, and we have arrived at Jakarta EE 8 essentially (a re-licensing of Java EE 8 ). Most servers from the previous instalment have Jakarta EE 8 versions out. WebLogic has its Java EE 8 version officially out, with a Jakarta EE 8 version coming soon (there is no technical difference between these two really). TomEE has started to implement Java EE 8 and in its latest version has gotten quite far, but is not there yet. Resin remained at Java EE 6 with seemingly no plans to update these . JOnAS has disappeared off the face of the earth , and so has Geronimo as server (though as a provider of APIs and their implementations it has stayed alive). Without further ado, here's the matrix of Java EE 8/Jakarta EE 8 implementation components used by Java EE/Jakarta EE ...
Comments
Post a Comment