> 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
