Security in Jakarta EE has long been under-used and under-specified. Existing specifications ranged from overly complex to non-existent. The result: few people used security standards. Java EE 8 changed that with JSR 375. Its evolution Jakarta Security facilitates portable application security integrated with container security. Allowing applications to treat authentication mechanisms like OAuth or OpenID Connect same as built-in container mechanisms like FORM or container-based access to a URL and features like @RolesAllowed and isUserInRole automatically work as expected. It depends on CDI, and lower level SPIs Jakarta Authentication and Jakarta Authorization.
Jakarta Authorization defines an SPI for authorization based security checking if a subject has given permissions and algorithms to transform security constraints for containers including Servlets or Enterprise Beans into them. Jakarta Authentication defines an SPI for authentication that interacts with 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 state of Jakarta Security specs, demonstrate compatible implementations like Soteria, Exousia and others including Eclipse Glassfish or Tomcat. During Q&A we will ask the audience for their opinion and thoughts what else they would like to see in the Security specs with Jakarta EE 11 and beyond.
