> > Can we assume Java8 for this attempt? > Oh and more important: Will the integration work based on TomEE7 (would > require Java7) or the upcoming TomEE8? > I'd say we should focus on TomEE8 and Java8
MicroProfile specs are defined in Java 8, so TomEE8 seems the only option. regards Rudy On 15 February 2018 at 09:37, Mark Struberg <strub...@yahoo.de.invalid> wrote: > > > > Am 15.02.2018 um 07:50 schrieb Romain Manni-Bucau <rmannibu...@gmail.com > >: > > > > 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. > > > No, there is no meta discussion. This is about reusability in other > projects. As clearly stated as that. > I think we can easily get this done by splitting it in a core part and > then a second part which exposes the JsonWebToken as Principal in various > EE apis. The overall structure will become way cleaner imo as it would be > highly modular without adding too much overhead. > > > > > I'd probably lean towards getting a prototype done with the mutual > > understanding this part of the discussion is still open. > > +1 > > > Once we have code > > in hand, we can have a more informed discussion and circle back to reuse. > > -1 You have to design with reuse in mind. > I'm not talking about making it overcomplicated and unecessarily modular, > but just address the things we know already. > > > > >> 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. > > Thanks for pointing me to this. > 'integration points'. Even the spec indicates that the EE part is merely > integration work. > That might be a lot of work of course. But it would be cool if getting the > JsonWebToken would merely be one line of code which is in the mp-jwt-core > package. > > > > > 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. > > Oki, I will start a discussion over at MicroProfile. > Thinking about a JsonWebTokenBuilder or something. > > > > > 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. > > JWT doesn't even require oauth2, isn't? > Of course oauth2 _could_ be the payload. But that's no necessity for > everyone. > Most users will not need that actually. But they might be more interested > in having a radius like single sign on via JWT. > At least that's what I hear from my customers. > > > > > > >> * 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. > > Fine for me. This can easily be extendd afterwards IF we need it. > > > > > >> * 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 > > ;). > > What do you mean here? I totally don't get that. Derailing? > > > > > > > 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. > > > > +1 for JsonWebTokan as immutable. Snce we do not create it but only make > it accessible. > > > > > 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. > > hmm, java-to-string would not be possible. The config API only has > String->Java. > Because the least common denominator (or 'storage') for the config is > always String. > And from there you convert it to a target Java type. > > But why do we need java-to-string? We do not WRITE JsonWebTokens, do we? > We only read them. Which is string-to-java then, right? > And by using JSON-P and JSON-B we could probably defer this as well. > > > > > > 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. > > Yes, I had a talk wiht Andres about this as well. > It's a bit more complicated. > For example Andres needs this for the UI. > So while in theory both (Config and UI) needs a conversion from > string->java it might still work totally different. > In the config area you want your string representation to be as portable > as possible. Means you betterl _always_ use ISO or any other _fixed_ format. > Whereas in the UI area it's exactly the other way around. You almost > always want the string representation to be for the users Locale and > desired language. So even for the same server this might differ even for > each request. > > Back to JsonWebToken. This is really more like config. The string > representation is better off being a fixed format. > > > Makes sense (and without any "context" please, this pollutes config spec > > and makes it sadly not that portable :(). > > Well as explained there is a kind of 'context'. I agree it's not that > obvious, but there are reasons why even Stephen Coleburn failed to come up > with a good Converter API for many years now. > > Btw, with Lambdas any conversion A->B is just a Function anyway. > Can we assume Java8 for this attempt? > > Oh and more important: Will the integration work based on TomEE7 (would > require Java7) or the upcoming TomEE8? > I'd say we should focus on TomEE8 and Java8 > > > > > -David > > LieGrue, > strub > >
