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...
Despite being almost ten years old, the JPA specification to this day has rather poor support for basic paging/sorting/filtering. Paging/sorting/filtering is used in a lot of (CRUD) applications where the result from a query is shown in a table, and where the user can scroll through the results one page at a time, and where this result can be sorted by clicking on any of the table column headers. In order to support this a number of things are generally needed: The total number of rows (or entities) in the full result must be known There should be support for an offset in the full result and a limit for the amount of rows that will be obtained The column (attribute) on which to sort must be dynamically added to the query Search expressions must be dynamically added to the query As it appears, only offset/limit is directly supported in JPA. A sorting column can only be added dynamically when using the overly verbose and hard to work with Criteria API. Search expressions...
Jakarta Security was introduceed as Java EE Security in Java EE 8. It facilitates portable application security that fully integrates with container security. This means that an application can provide an authentication mechanism, say for OATH2 or Auth0 and that mechanism is treated just like build-in container mechanisms like FORM. All existing security code, such as the container determining access to a URL based on web.xml constraints, and things like @RolesAllowed and HttpServletRequest.isUserInRole automatically work as expected. One of the compatible implementations of Jakarta Security is Soteria . Soteria has been designed as a standalone library, that can be integrated with multiple servers. It depends on CDI, and the lower level SPIs Jakarta Authentication and Jakarta Authorization . Soteria worked on Tomcat before , but there were some issues. For one, when adding a CDI implementation like Weld to Tomcat, the BeanManager ends up in the JNDI location java:comp/env/BeanM...
Comments
Post a Comment