Jakarta Authentication defines a general low-level SPI for authentication mechanisms, which are controllers that interact with a caller and a container’s environment to obtain the caller’s credentials, validate these, and pass an authenticated identity (such as name and groups) to the container.
Jakarta Authentication consists of several profiles, with each profile telling how a specific container (such as Jakarta Servlet) can integrate with- and adapt to this SPI.
The goal of this release is to create a(n additional) Servlet Container Lite profile, and a REST profile. The existing SOAP profile is to be marked as stable. We’d like to update the Java 1.4 API to Java 5 (introduce generics) and clarify some spec text.
The items are further explained below:
1.1 Clarify that the application Jakarta EE component namespaces (java:app, java:comp, etc) should be available from within a ServerAuthModule.
Practical use case: obtaining application scoped data sources, EJB beans and other resources.
Example: new InitialContext().lookup(“java:app/myds”)
1.2 Clarify that the CDI default scopes for web components (@RequestScoped, @SessionScoped, etc) should be available from within a SAM.
Practical use case: obtaining application scoped identity stores
Example: CDI.current().select(SomeBean.class); // SomeBean is @RequestScoped
The spec text regarding how the “register session” feature should work is unclear. The spec lead under the JCP clarified this feature at various occasions and made the remark that the spec should have said something about the groups. These clarifications should be added to the spec text.
The TCK is not optimally testing the basics yet, and a few simple (but crucial) tests should be added.
Jakarta Authentication’s API is still limited to Java SE 1.4. which feels curiously out of place in Jakarta EE 9, let alone Jakarta EE 10.
In practice this mostly boils down to adding generic parameters for the various maps Jakarta Authentication passes around. Where it makes sense default methods for interfaces could be considered.
A ServerAuthModule can be called at the start of a request or following a call to request#authenticate().
A simple key in the message info map would suffice to distinguish between those two cases. Various implementations already have such a key in place, or have e.g. a boolean for this in the runtime method just before the ServerAuthModule is invoked.
The end user of Jakarta Authentication, as well as integrators such as Jakarta Security implementations almost always just care about registering a ServerAuthModule. Yet the AuthConfigFactory only accepts an AuthConfigProvider, which is essentially a “wrapper-wrapper-wrapper-wrapper” of a ServerAuthModule to the end user. A new method should be added to the AuthConfigFactory to only register a ServerAuthModule.
The JDK version required will be aligned with Jakarta EE 10.
The Specification Committee Ballot concluded successfully on 2021-06-15 with the following results.
| Representative | Representative for: | Vote |
|---|---|---|
| Kenji Kazumura | Fujitsu | +1 |
| Dan Bandera, Kevin Sutter | IBM | +1 |
| Ed Bratt, Dmitry Kornilov | Oracle | +1 |
| Andrew Pielage, Matt Gill | Payara | +1 |
| Scott Stark, Mark Little | Red Hat | +1 |
| David Blevins, Jean-Louis Monteiro | Tomitribe | +1 |
| Ivar Grimstad | EE4J PMC | +1 |
| Marcelo Ancelmo, Martijn Verburg | Participant Members | +1 |
| Werner Keil | Committer Members | +1 |
| Dr. Jun Qian | Enterprise Members | +1 |
| Total | 10 |
The ballot was run in the jakarta.ee-spec mailing list.