2018-02-15 13:30 GMT+01:00 Rudy De Busscher <[email protected]>: > > > > 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. >
CDI 2 is the constraint more than java 8 which works on TomEE 7 ;). That said converters should still be scannable so java 8 or not is maybe not the main challenge - not even sure there is a challenge to be honest, just a clean definition without any redefinition of what is a "context" works :). > > regards > Rudy > > > On 15 February 2018 at 09:37, Mark Struberg <[email protected]> > wrote: > > > > > > > > Am 15.02.2018 um 07:50 schrieb Romain Manni-Bucau < > [email protected] > > >: > > > > > > Le 15 févr. 2018 01:35, "David Blevins" <[email protected]> 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 <[email protected] > > > > > 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 > > > > >
