Jakarta EE Security Specifications

The security functionality in Jakarta EE has long been underused and under-specified. The few specifications that existed were often overly complex. As a result, few people used security standards. Java EE 8 changed that with the Java EE Security API specification (JSR 375). Today, that specification has evolved to become Jakarta Security, and it facilitates portable application security integrated with container security.

Jakarta EE Security Involves Three Specifications

The story of security in Jakarta EE started with lower-level security in Java SE. Java was originally designed for embedded and IoT usage, such as inside set-top boxes, and it relied on code-based security, which protects the user’s computer by limiting code permissions to only certain files. 

Jakarta EE, however, provides concrete security through three main specifications:

• Jakarta Authentication
• Jakarta Authorization 
• Jakarta Security

These three specifications provide an integrated security solution for Jakarta EE that transparently backs the declarative security model. They provide the functionality that, in early Jakarta EE versions, was provided by the vendor.

Jakarta EE supports a hybrid security model. An application, or its server/runtime, can be configured to use the standard interfaces and associated configuration or interfaces that are specific to a server or runtime (Figure 1).

Figure 1: Jakarta EE Hybrid Security Model 

Jakarta EE implementations also typically offer the ability to: 

• Ship custom versions of security artefacts within the application archive
• Install security artefacts separately on the server 
• Use a default security artefact in a way that’s transparent to the application 

The options available depend on the implementation being used. For example, Eclipse GlassFish might support different options for security artefacts than other Jakarta EE implementations.

Jakarta Authentication Extends the Jakarta Security Framework

Jakarta Authentication is a general low-level Service Provider Interface (SPI). SPIs are implemented by the user to extend a framework or application. In this case, the Jakarta Security framework. The concept is roughly analogous to a plug-in or extension, a different approach to APIs, which are called by an application.

Jakarta Authentication primarily provides SPIs and very few APIs. The SPIs are low-level, meaning their implementations in Jakarta EE are not beans and are not eligible for injection or for decoration. The Jakarta Authentication SPIs are also general because they don’t refer to a specific Jakarta EE technology, such as Jakarta Servlet or Jakarta RESTful Web Services.

Jakarta Authorization Enables Library Writing and System Integration

Jakarta Authorization also defines a low-level SPI. It is mainly targeted at library writers and system integrators rather than developers building applications. As an SPI, Jakarta Authorization mainly consists of interfaces to be implemented, which will then be called by the system. There are very few elements in Jakarta Authorization that would qualify as APIs.

Jakarta Security Bridges Gaps 

Jakarta Security bridges some of the gaps that were traditionally left unspecified and required vendor-specific solutions. This allows applications to treat authentication mechanisms, such as OAuth or OpenID Connect, the same way as built-in container mechanisms, such as FORM or container-based access to a URL. It also ensures features such as @RolesAllowed and isUserInRole automatically work as expected. 

Jakarta Security depends on Jakarta Contexts and Dependency Injection (CDI), as well as two lower level SPIs: Jakarta Authentication and Jakarta Authorization.

The specification primarily provides easy-to-install and easy-to-use versions of the authentication mechanism and the identity store. The authentication mechanism manages the interactions between a user and a server in a particular environment, such as HTTP. The identity store verifies credentials, such as usernames and passwords, and may also return data associated with those credentials, such as a different username and groups the user is in.

Here’s how all three specifications work together, with a particular emphasis on Jakarta Security (Figure 2).

Figure 2: Jakarta EE Security Specification Interactions

Jakarta EE 10 and Beyond 

In the current version of Jakarta Authentication, one cannot distinguish between mandatory authentication because of a call to HttpServletRequest#authenticate or because the current request is protected. Jakarta EE 10 is working to introduce a boolean value to check whether authenticate() was called or not. 

It is further anticipated that Jakarta EE 10 or beyond will add default methods to the AuthConfigProvider, avoiding boilerplate-code and allowing to only override/implement the methods you really need. Similar for PolicyConfiguration in Jakarta Authorization.

Jakarta EE 10 or beyond will support multiple HttpAuthenticationMechanisms mapped to different URL patterns. It’s also considered to add the HttpAuthenticationMechanismWrapper to the API of Jakarta Security, as well as annotation literals in annotations like @RememberMe.

Additionally, it is considered to add a convenience mechanism to simplify CDI integration, like a @RolesAllowed alternative. Better alignment between Jakarta Security and Expression Language is also considered.

Future versions of Jakarta Authorization will allow the registration of policy providers programmatically. As the Policy class is deprecated for removal in JDK 17, Jakarta EE 10 will deprecate it as well. This means future versions of Jakarta Authorization will almost certainly replace Policy with a new type of its own.

Jakarta EE 10 will contain an additional authentication mechanism for OpenID Connect.

Get Involved in Jakarta Security Projects 

We encourage everyone to get involved and participate in the future of Jakarta EE security projects at the Eclipse Foundation. To get started, subscribe to the project mailing lists and visit the GitHub pages:

• Jakarta Authentication
• Jakarta Authorization
• Jakarta Security

For more insight into Jakarta EE, you can also visit jakarta.ee, Arjan Tijms’ committer profile, or his blog.