[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] Moving MicroProfile JWT to Jakarta Security?
|
Hi,
On Tuesday, November 15, 2022, Darran Lofthouse <
darran.lofthouse@xxxxxxxxx> wrote:
Sorry just sending again from the correct address.
The web.xml has the login config section to activate the mechanisms defined in the servlet specification, Jakarta Security then had it's own set of annotations to activate a second set of mechanisms.
Maybe these two could be more closely aligned?
This has been a long standing concern and has indeed been discussed before.
Jakarta Security does actually align them from its point of view. It explicitly states its FORM and BASIC authentication mechanisms have to be follow the Servlet ones exactly, and furthermore that implementations should be able (and are there for allowed) to satisfy both the Servlet and Security requirements with the same actual code.
Piranha Cloud actually does this. In the Micro distribution the authentication mechanisms from Soteria are used for Servlet and can be activated by the web.xml elements. Soteria has special support for this and the setup passes both the Servlet and Jakarta Security TCKs.
Kind regards,
Arjan Tijms
MP JWT made it possible for the login config to be specified as an annotation but the mechanism can still be specified in the web.xml or the annotation. For Jakarta Security maybe it could also be possible to map the web.xml to the selected mechanism as well. Then mechanisms could be activated either by name or the *Definition annotation.
and have those demonstrate why or why can't the MP JWT spec be used as a transitive dependency.
I'm not sure about that last one, as it looks like what I proposed in the initial post, but which was more or less rejected in the cacophony of protest. Do you mean that the Jakarta security spec, and specifically the Jakarta Security API jar directly has the MP JWT spec / api as a dependency?
E.g.
<dependencies>
<dependency>
<groupId>jakarta.servlet</groupId>
<artifactId>jakarta.servlet-api</artifactId>
<version>6.0.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>jakarta.interceptor</groupId>
<artifactId>jakarta.interceptor-api</artifactId>
<version>2.1.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>
org.eclipse.microprofile.jwt</groupId>
<artifactId>
microprofile-jwt-auth-api</artifactId>
<version>2.1</version>
<scope>provided</scope>
</dependency>
<!-- other dependencies -->
If everything in an implementation is CDI based, there is no reason why alternatives cannot be configured to adapt to the runtime.
Hi
For specification projects in a related space, the existence of more than one needs to be justified. There is a reason everyone involved in specification/standards work raises this well trodden satire out at some point:
So what do you propose instead then? Having a Jakarta Full-profile or so that includes both EE and MP?
As a Jakarta EE user, we can now freely use Form, Basic, Open ID Connect, but not JWT. Even when a MP profile JWT implementation is added, it's not necessarily based on Jakarta Security. Even in a Jakarta EE server that already includes MP components, its JWT implementation does not necessarily have to be Jakarta Security based. Meaning, things like additional identity stores, interceptors, etc are not being picked up for JWT or may even clash.
Kind regards,
Arjan Tijms
jakartaee-platform-dev mailing list
jakartaee-platform-dev@eclipse.org
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
jakartaee-platform-dev mailing list
jakartaee-platform-dev@eclipse.org
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
