Security in Jakarta EE has long been under used and under specified. The existing set of specifications ranged from overly complex to non-existent. The result was almost nobody used standards for security. Java EE 8 changed that with JSR 375, the Java EE Security API. Its evolution Jakarta Security facilitates portable application security that integrates with container security. Allowing an application to provide authentication mechanisms like OAuth or OpenID Connect and that mechanism is treated just like built-in container mechanisms like FORM. Existing security mechanisms like the container-based access to a URL defined by web.xml constraints, and things like @RolesAllowed and HttpServletRequest.isUserInRole automatically work as expected. It depends on CDI, and the lower level SPIs Jakarta Authentication and Jakarta Authorization.
Jakarta Authorization defines an SPI for authorization modules, which are permission repositories for subject based security by checking if a subject has given permissions, and algorithms to transform security constraints for containers including Jakarta Servlets or Enterprise Beans into these permissions. Jakarta Authentication defines an SPI for authentication that interacts with a caller and a container’s environment to obtain the caller’s credentials, validate them and pass an authenticated identity (e.g. name, groups,...) to the container.
This hands-on session is intended to get attendees up to speed with the current state of Jakarta Security specs, demonstrate Compatible Implementations like Eclipse Soteria, Eleos and Exousia as well as others including Glassfish or Tomcat. We will ask the audience for their opinion and thoughts what else they would like to see in the Jakarta EE Security specs with Jakarta EE 10 and beyond.