Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Moving MicroProfile JWT to Jakarta Security?
Sorry just sending again from the correct address.

On Tue, Nov 15, 2022 at 1:29 PM Darran Lofthouse <dlofthou@xxxxxxxxxx> wrote:
On Fri, Nov 11, 2022 at 8:06 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,

On Fri, Nov 11, 2022 at 8:38 PM Scott Stark <starksm64@xxxxxxxxx> wrote:
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).

Could this be worth looking into?  Without looking at MicroProfile Jakarta EE already has more than one way to define common authentication mechanisms.

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?  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 -->
      
Kind regards,
Arjan Tijms
 
If everything in an implementation is CDI based, there is no reason why alternatives cannot be configured to adapt to the runtime. 

On Nov 11, 2022 at 12:31:48 PM, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi

On Fri, Nov 11, 2022 at 6:15 PM Scott Stark <starksm64@xxxxxxxxx> wrote:
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

Back to the top