Re: [jakartaee-platform-dev] [es-dev] Moving MicroProfile JWT to Jakarta

["reza_rahman@xxxxxxxxx" <reza_rahman@xxxxxxxxx>]

The namespace swapping around business is definitely very unfortunate. At this point I sort of see it as a necessary evil that won’t go on indefinitely. Personally Config and JWT are the only parts of the MicroProfile platform that it would be awkward if they are not a part of Jakarta EE. The rest can pretty much stay where it is. It just builds cleanly on top of Jakarta EE without any need for mind bending circular version dependencies.

 

---

From: es-dev <es-dev-bounces@xxxxxxxxxxx> on behalf of Daniel Pfeifer <daniel@xxxxxxxxxx>
Sent: Tuesday, November 15, 2022 2:59 PM
To: es developer discussions <es-dev@xxxxxxxxxxx>
Subject: Re: [es-dev] Moving MicroProfile JWT to Jakarta Security?

 

Sounds good, so for the realistic option we are in agreement. :)

To define a spec (which I believe is a good way: Compete on implementation, not specification) does take time, I agree. But most of us have become accustomed with the fact that sometimes tech in general moves faster than the spec-process. We built stuff as "spec-compliant" as possible and then had a path to modify accordingly once our needs have become spec (for the real clever specs there was even an "escape-path" by allowing config to specify what happens)

The jakarta.*-situation is different though, because large amounts of code (and yes, also Spring) are built around javax-specs. This can quickly become more than a simple "we'll just fix this small thing"-task, but a "OK, we have to fix a lot"-task.

And sorry for having a rant-like appearance but for me and my perhaps humble needs it is quite relevant to find a way back how Jakarta EE was built previously. Perhaps I'd like to see a faster iteration-cycle (because tech simply moves ever faster), but still based on the traditional idea that we all compete on implementation, not specification. Not every corner case will be covered for sure, but fixing a single-digit percent of your code when deciding on a new implementation (or upgrading) is a lot different than fixing close to all of your code for no clear gain at all (i.e. even if you stay with the same middleware and just want to keep your stuff fresh).

/Daniel

On 15 Nov 2022, at 20:22, Werner Keil <werner.keil@xxxxxxxxx> wrote:

Daniel,

Thanks for your summary and suggestions.

Not sure, if your CC to the platform list worked, because I cannot see it there yet, but I'll reply here for now, and may propagate it over there, too should you not be subscribed to both.

Of your two suggestions:

* Rip off the band-aid now but then this should be MicroProfile-wide (probably won't happen) and make Jakarta EE adopt a faster pace like MP.

* Make a "competing" implementation in Jakarta Security and let MicroProfile JWT fade with time (and document a migration path).

I would prefer the second one, because especially MP JWT has not gone at a fast pace at all.

MP JWT 1.1 was released Jun 1, 2018

1.2 was released Dec 22, 2020, over 2 1/2 years later.

And all 2.0 did on Jan 13, 2022 was to change the Jakarta EE namespace from "javax" to "jakarta". Not a single feature, it's merely 1.3 worthy for that reason.

Several features of Spring Security OAuth JWT like JOSE headers (that exist since 2015, before MP JWT even started) were never applied in MicroProfile.

I know well that defining stuff takes time, finding the right terms in JSR 375 (now Jakarta Security) took several months, but we took our time and compared not just Spring Security or similar frameworks at the time, we asked a number of people, 

while in a project that caters for a smaller audience like most MP specs that is the reason why some features may be missing because the 1 or 2 really active contributors and the company they work for may not see it as important enough for their customers or use case. And if they are tied up with other work then the spec becomes practically inactive and nothing new is added.

Werner

On Tue, Nov 15, 2022 at 8:00 PM Daniel Pfeifer <daniel@xxxxxxxxxx> wrote:

Hi,

don't mean to impose and don't represent anyone but myself. Simply have contributed some smaller things to MP-JWT implementations (and suggested new features that I had hoped would make it to the final spec) and use JWT/OIDC/SAML extensively in customer applications.

I personally would like to see that Jakarta Security does gain support for JWT, OIDC-flows and perhaps even SAML (as it is fairly widely used).

Now when it comes to MicroProfile I realize that we might have another javax.*->jakarta.*-situation on our hands and I am starting to doubt developers will find it fun one more time to live in the "in-between"-times. There are simply too many public and customer-internal libraries that refer to javax and to fix this really takes ages (and no: Converters or Migrators don't really do much for me, there are applications that have _a lot_ of code with _a lot_ of dependencies and fixing all this does take a long time).

I am very much in favour to integrate MicroProfile JWT into Jakarta Security but I am afraid of the namespace changes again. MicroProfile is still fresh with a bunch of my customers (now that is probably not a good indicator for how it is worldwide, but still). Now telling people again that they have to dig through every library, ever import et cetera won't really help Jakarta EE or MicroProfile.

Companies and their employees have sometimes spent millions in cash ( pick a currency ;) ) and thousands of hours to build software that solves a _business case_ and Java has traditionally always been a stable platform to retain ROI on made investments so this should very much be considered when going ahead to make future decisions on the path of MicroProfile and Jakarta EE.

Since no one person has the power to change the laws of nature ( i.e. "Java" ;) ) I am seeing two ways forward:

* Rip off the band-aid now but then this should be MicroProfile-wide (probably won't happen) and make Jakarta EE adopt a faster pace like MP.

* Make a "competing" implementation in Jakarta Security and let MicroProfile JWT fade with time (and document a migration path).

The latter is the one I find most realistic right now.

Just my 2 cents on this and I really wanted to remind everyone here on the tremendous value to businesses to have a stable platform (which Java EE has been for 20 years after all).

/Daniel

PS.: If you against all odds find value in external help then just reach out, all this is really close to my heart in order to deliver good and long-living solutions to my clients.

On 5 Nov 2022, at 16:24, reza_rahman@xxxxxxxxx wrote:

This is honestly another sticky situation caused by the very unfortunate set of events in the Java EE 8 time frame. There are no non-contentious solutions to it now that will make everyone happy. Just for context, I expressed a clear need to solve both OIDC Connect and JWT in Java EE 8. It was way past due even then.

I don’t think directly referencing MicroProfile in a Jakarta EE specification is a realistic possibility. I believe we had sufficient debate on this topic for Configuration and it is a settled matter now.

It is also very clear these technologies in practical terms are inextricably linked, especially for cloud native applications that need to use both OIDC Connect and JWT in the sample application (a very common scenario that in my estimate now falls in the 80% use case).

I think the least confusing option for end users with a view towards sensible future maintenance is incorporating JWT into Jakarta Security and deprecating it in MicroProfile. Trying to focus on end-to-end usability on such closely related things is bound to be a hazard across two different specification efforts that are hardly aligned.

A workable but obviously less than optimal solution is somehow address integration with JWT in Jakarta Security in some kind of generic way basically targeting MicroProfile JWT but still not referencing it directly. Frankly my head hurts thinking about how you do that exactly. Maybe it’s just that you specify how there can be multiple authentication/authorization mechanisms in a single application that Jakarta Security recognizes via some kind of underlying extension mechanism and go through a similar exercise on the MicroProfile side where MicroProfile can reference that Jakarta Security extension mechanism directly.

My preference would be to first see if consensus can be achieved to move MicroProfile JWT to Jakarta Security for the reasons above I think the second strategy should be plan B if reasonable consensus cannot be achieved on the long term optimal first solution. Plan B could also be a stop gap for some period of time to keep the peace if that’s the practical thing to do for now.

 

---

From: es-dev <es-dev-bounces@xxxxxxxxxxx> on behalf of arjan tijms <arjan.tijms@xxxxxxxxx>
Sent: Friday, November 4, 2022 3:12 PM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>; es developer discussions <es-dev@xxxxxxxxxxx>
Subject: [es-dev] Moving MicroProfile JWT to Jakarta Security?

 

Hi,

In Jakarta Security we had long ago planned to include a JWT authentication mechanism. Some prototypes from around 2016 are still testimony to that.

Meanwhile, MicroProfile has specified JWT, and a couple of implementations of it (such as Payara, OmniFaces and SmallRye) are internally based on Jakarta Security

We have discussed moving or copying MP specs to EE before, but nothing concrete has been established. Therefore I wonder how to proceed here. 

Do we copy over the MP JWT spec to a section in Jakarta Security and somehow keep them in sync?

Or do we reference the MP JWT spec from the Jakarta Security spec with text like: a compliant implementation should provide an authentication mechanism that behaves exactly like MP JWT with the following differences…

Or something else?

Thoughts?

Kind regards,

Arjan Tijms

_______________________________________________
es-dev mailing list
es-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/es-dev

_______________________________________________
es-dev mailing list
es-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/es-dev

_______________________________________________
es-dev mailing list
es-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/es-dev