[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] Moving MicroProfile JWT to Jakarta Security?
|
Correct, no explicit mentioning of MP Config. But since there is no Jakarta Config (it is long overdue), the only option you have is MP Config today.
There is no explicit dependency on MP config API. There are references to configuration property names that have to be resolved against some configuration implementation. Again, with proper CDI configuration this could be either Jakarta or MP config.
When we directly depend on the MicroProfile JWT specification, we also bring in MicroProfile Config. That is something that is not desired since we have the Jakarta Config effort going on.
Hi,
Start with the Jakarta Security requirements around JWT
That's certainly something we can start with. The requirements are essentially that within a Jakarta EE environment the authentication mechanism MUST enable a CDI bean based on HttpAuthenticationMechanism, and MUST use the Jakarta Authentication SPI to set the authenticated identity, and that it SHOULD use an IdentityStore for token validation. The actual spec text should be a little more elaborate and provide some examples, but that's what it essentially boils down to.
Furthermore, it would be a nice-to-have to have an annotation like BasicAuthenticationMechanismDefinition instead of LoginConfig that accepts EL expressions (there's no EL dependency needed for that, as the attributes are simply of type string).
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@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
