MP-JWT - Addressing problem that apps using MP-JWT are never portable

40 views
Skip to first unread message

Arjan Tijms

unread,
Mar 16, 2018, 4:21:39 PM3/16/18
to Eclipse MicroProfile
Hi,

Currently MP-JWT requires mandatory configuration to be done in a vendor specific way. I wonder why this was specified that way.

This makes every application that uses MP-JWT non-portable by the very definition of the spec, which is something that I'm sure few users would expect from a modern spec. I think we should address this as soon as possible, as it makes MP-JWT quite awkward to use in practice.


Kind regards,
Arjan Tijms

Emily Jiang

unread,
Mar 19, 2018, 6:35:55 AM3/19/18
to Eclipse MicroProfile
I do agree that using MP Config to specify the issuer is a better way.

Emily

Werner Keil

unread,
Mar 19, 2018, 12:02:08 PM3/19/18
to Eclipse MicroProfile
Shouldn't we "eat our own dogfood"? ;-)

I mentioned, that some of the individual specs and technologies are not always well-connected and coordinated last week during the JavaLand get-togethers and workshops.

Kind Regards,
Werner

Jean-Louis Monteiro

unread,
Mar 20, 2018, 4:58:14 AM3/20/18
to MicroProfile
Hi,

Yes I agree that configuration needs to be addressed.
That said, this is clearly stated in the spec itself

  1. A future MP-JWT specification may define how an MP-JWT implementation makes use of the MicroProfile Config specification to allow for configuration of the issuer, issuer public key and expiration clock skew. Additional requirements for validation of the required MP-JWT claims may also be defined.


I believe some more things have to be clarified.

On the TomEE implementation I did I plan to give it a try with MP-Config for the configuration of MP-JWT.

Happy to contribute to the discussion and help.

Jean-Louis





--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/636691c1-4f5f-4eef-8efa-d2ffda95be60%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Scott Stark

unread,
Mar 22, 2018, 1:29:02 PM3/22/18
to Eclipse MicroProfile
Yes, we have discussed in general that we needed to be standardizing the use of config across MP features in the past, but this was not addressed in 1.0. I have demonstrated the use of the config API in forks of the current microprofile conference application, where the signer PrivateKey is injected via @Config along with a o.e.m.c.s.Converter<PrivateKey> implementation:


I'll add this to the agenda for tomorrow's hangout.

arjan tijms

unread,
Mar 22, 2018, 4:58:51 PM3/22/18
to microp...@googlegroups.com
Hi,

On Thursday, March 22, 2018, Scott Stark <sst...@redhat.com> wrote:
Yes, we have discussed in general that we needed to be standardizing the use of config across MP features in the past, but this was not addressed in 1.0. 

I’d personally would have emphasised “basic authentication” first for JWT, making sure just authentication works in a fully portable way, and then leave all the variations of injecting the token and its fields to the next version, but what’s done is done, so let's now see how we can best fix this ;)


I have demonstrated the use of the config API in forks of the current microprofile conference application, where the signer PrivateKey is injected via @Config along with a o.e.m.c.s.Converter<PrivateKey> implementation:

That example shows injecting the private key for generating the token, which is nice and of course important too, but what I was actually referring to is configuration of the authentication mechanism for the application protected by the JWT authentication mechanism.

My proposal would be to use something like this:

@JWTAuthenticationMechanismDefinition(
    publicKey = “#{somePlace.someKey}”
    acceptedIssuers = “#{somePlace.someIssues}”
    // other standard attributes here, e.g. preEmptive, clock skew, etc 
}

The annotation's attributes should be EL enabled then, so that the values can be retrieved from external sources, as well as provided directly. The scope for the EL expressions would be MP Config (possibly via an implicit object), and CDI beans.

I've just added this and a couple of other points to the agenda for tomorrow.

Kind regards,
Arjan Tijms


 


I'll add this to the agenda for tomorrow's hangout.


On Friday, March 16, 2018 at 1:21:39 PM UTC-7, Arjan Tijms wrote:
Hi,

Currently MP-JWT requires mandatory configuration to be done in a vendor specific way. I wonder why this was specified that way.

This makes every application that uses MP-JWT non-portable by the very definition of the spec, which is something that I'm sure few users would expect from a modern spec. I think we should address this as soon as possible, as it makes MP-JWT quite awkward to use in practice.


Kind regards,
Arjan Tijms

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/QS247S7O7nY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

Scott Stark

unread,
Mar 22, 2018, 10:56:20 PM3/22/18
to Eclipse MicroProfile
The public key configuration is injected into the WildflySwarm MP-JWT implementation using the config api/spi. I'm adding comments to the meeting agenda to these items.


On Thursday, March 22, 2018 at 1:58:51 PM UTC-7, Arjan Tijms wrote:
Hi,

Reply all
Reply to author
Forward
0 new messages