Le 15 févr. 2018 01:35, "David Blevins" <david.blev...@gmail.com> a écrit :

I understand there's kind of a meta conversation going on that all roads
and discussions need to end at there being something to put a
microprofile-jwt git repo.  I wave a white flag and gently request a
respite from that as I don't want everything I write to be read as if I'm
attempting to steer for or against.

I'm 100% supportive of reuse.  And there could be something of value to
reuse in the end.  But at this moment if there was a microprofile-jwt git,
even if that repo was in TomEE, I'm not sold at this point there would be
enough code there to justify it.

I'd probably lean towards getting a prototype done with the mutual
understanding this part of the discussion is still open.  Once we have code
in hand, we can have a more informed discussion and circle back to reuse.

> On Feb 14, 2018, at 11:57 AM, Mark Struberg <strub...@yahoo.de.INVALID>
wrote:
>
> If you want to have JWT working for ALL EE things then it's not
MicroProfile-JWT anymore, isn't?
> It would be much more. Not bad of course, but still way beyond of what
MicroProfile-JWT defines.

Chapter 7 "Mapping MP-JWT Tokens to Java EE Container APIs" defines about
11 different integration points across JAX-RS, EJB, Servlets, JACC etc. As
only JAX-RS is a required part of a MicroProfile server and the other parts
are optional, at least 7 out of the 11 integration points are also optional.

There are tests for much of them in the MicroProfile JWT TCK. The tests are
also optional, but we'd definitely want to run and pass them as well as
contribute to them if they are incomplete.

If the spec is incomplete and we did miss an EE integration point,
definitely want to update the spec to cover it.  Scott and I and the other
folks who worked on the spec did our best to try and enumerate the ones we
could think of, but we may have missed some.

> Oh and I assume it does also include a way to _create_ JsonWebTokens,
right?

The token creation would be done by an OAuth provider, which is outside the
MP JWT specification.

The specification does have requirements that define what the token should
look like, but they're all very minimal so that we could be as compatible
as possible with as many existing OAuth provider implementations as
possible.

Effectively it says the JWT must be signed with an RSA private key the
OAuth Provider owns and assumes the MicroProfile server has been given the
public key.  How that public key is passed is also outside the
specification, but generally, it'll be on disk or sitting in the docker
image somewhere.


> * JSON-P on the json side.

Agree.  This is definitely mandatory to implement the MP JWT spec as claims
can be injected as JsonObject, etc.

> * crypto: Whether to use the JCE built-in crypto or an external lib
should be pluggable. We just need to add a smallish SPI with a few methods.

Agree to disagree on this one :)  JCE is an abstraction with two well known
impls (OpenJDK and BouncyCastle).  It's 3-4 lines to check a signature, so
not much complexity to abstract.

> * JsonWebToken and a way to get 'the' JWT for a single Request. That
might be a provider interface or a @RequestScoped CDI bean.

MP JWT spec requires there to be a dependent scoped producer for
JsonWebToken.  The bean getting JsonWebToken injected must be
RequestScoped.  Currently section 7.1.3 forbids injection into beans that
are not @RequestScoped.


Any waynto have a fixed spec saying it is not portable to not do so? Having
a deployment exception for a so common case is very rude and not justified
technically. Also using provider as a woraround is not mainstream and
generally way too slow.

Not that supporting CharSequence can be a smooth workaround for app scope
;).


With that in mind, I would probably implement JsonWebToken as an immutable
class -- i.e. get the token, then create the JsonWebToken and track that in
the request.  So ultimately the producer of JsonWebToken needs to get the
token from the request rather than the JsonWebToken implementation itself.


It is backed by jsonp so immutable by definition no?


Not yet discussed, but part of the spec is Claims can be injected as any
java type using the same conversion rules as MP Config.

Xbean-reflect has a large set of code for java-to-string conversion.  I
suspect geronimo-config as it's own implementation of java-to-string
conversion.  There's probably some opportunity for reuse consolidation
there.

Potentially even an option for a "Conversion" spec.  Andres was talking
about it at the last JCP EC event in London.  His JSR-377 (Desktop
Application Framework) apparently has similar needs.


Makes sense (and without any "context" please, this pollutes config spec
and makes it sadly not that portable :().



-David

Reply via email to