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.
Anyway, I asked myself how to 'slice' this the right way. And imo the natural interfaces would be somthing like * JSON-P on the json side. * 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. * JsonWebToken and a way to get 'the' JWT for a single Request. That might be a provider interface or a @RequestScoped CDI bean. Oh and I assume it does also include a way to _create_ JsonWebTokens, right? Could not find this part in the microprofile-jwt discussion/source. Anyone? But apart from that that's it! Everything else - including HttpServletRequest Principal, EJB isUserInRole, etc is an integration aspect in other parts! The microprofil-jwt impl is perfectly agnostic to TomEE nor anything else. The integration and propagation to all the other EE parts is an integration task into TomEE. If we cut it that way we have a rather cleanish API which we can easily maintain in the future. If we start to bake in TomEE features into the mp-jwt core then welcome to monolith scariness I'd say. > to be injected into @RequestScoped beans not injected INTO, but the information itself is provided as @RequestScoped bean. Of course you can inject it into anything actually. > That part will be a bit tricky, but effectively we need a dependent-scoped > producer that can find the JWT data in the active request. Perhaps by > looking in the ThreadContext. Yes, of course the JWT is request scoped. Taken from a HTTP header in a ServletFilter usually. wdyt? LieGrue, strub > Am 14.02.2018 um 19:19 schrieb David Blevins <david.blev...@gmail.com>: > >> On Feb 14, 2018, at 8:49 AM, Mark Struberg <strub...@yahoo.de.INVALID> wrote: >> >>> >>> I think one of the things we'll find most puzzling about how to do the >>> integration is that the Tomcat flavor of this is written assuming the users >>> exist in a Tomcat Realm. The whole point of JWT is that they do not and >>> the server has no such state. >>> >>> https://github.com/apache/tomee/blob/master/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/TomcatSecurityService.java >>> >>> I think we'll grapple with questions like "should we support some local >>> override if the user happens to exist locally?" Certainly, we could. I >>> might suggest we don't for the first prototype and add that later. >> >> Didn't think about this yet, but I assume that's because their contract is >> to keep HttpServletRequest#getUserPrincipal() and #isUserInRole working, >> even for JWT? > > Correct. > >> Don't know from the back of my mind about the MicroProfile-JWT contract. But >> MicroProfile NOT being based on Servlets I assume they have just an >> @Inject-able org.eclipse.microprofile.jwt.JsonWebToken [1]. >> >> While this extends Principal I still think it will be hard to tweak >> HttpServletRequest to work with it. >> But do we? > > We do, yes. > > You're correct in that MicroProfile itself doesn't include Servlets, EJB, > etc. but making sure JWTs worked for those things is definitely what we were > trying to do in defining the spec. The goal is that 100% of the security > concepts in Java EE would work against a JWT; EJB isCallerInRole, EJB > @RolesAllowed, Servlet getCallerPrincipal, exposing a JWT as a Principal, a > few new Java EE Security calls, etc. > > The fact that MicroProfile itself doesn't require the specs for all the touch > points we needed/wanted was handled by effectively making all those things > optional. Despite them being optional, we tried to phrase it like "if you do > implement it, it should work like this" and there are TCK tests to go along > with a good chunk of it. > > We were very much trying to define EE security as it pertains to JWT, while > doing our best to navigate the Java EE and MicroProfile relationship. > > Now that EE is moving to Eclipse, EE Security and MicroProfile JWT security > are highly likely to meld in some way. > > > -David
