> > 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? 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? LieGrue, strub [1] https://github.com/eclipse/microprofile-jwt-auth/blob/master/api/src/main/java/org/eclipse/microprofile/jwt/JsonWebToken.java > Am 14.02.2018 um 17:30 schrieb David Blevins <[email protected]>: > > >> On Feb 13, 2018, at 3:43 AM, John D. Ament <[email protected]> wrote: >> >> The JWT spec is weird, because it defined non MP runtime behavior in >> addition to MP runtime behavior; so there may be more integration work in a >> fuller app server like TomEE. > > Agreed. I'd describe the MicorProfile JWT spec as almost all integration. > > There are also optional integration parts for EJB which I think we'd > definitely implement. > >> On Feb 13, 2018, at 6:53 AM, Mark Struberg <[email protected]> wrote: >> >> I know JWT a bit and I wonder whether doing the signing part is just a bit >> of Json (JSON-P) + commons-crypto? >> After all JWT is especially designed to be lightweight and straight forward. > > Agreed. We could definitely get by with JSON-P and even the built-in JVM > crypto. No need for commons-crypto. > > The MicroProfile JWT specification is intentionally "opinionated" about the > JWT format and only allows for compact JWTs and RSA signatures. The actual > JOSE specifications allow for much greater flexibility and options, which is > why libraries like Nimbus exist. > > That said, I would still probably prototype with Nimbus and cut it out only > after everything works. Just to make sure I was focusing on the right part > of the problem. > >> On Feb 13, 2018, at 7:58 AM, Mark Struberg <[email protected]> wrote: >> >> I'm more worried about the authorisation and authentication interface. >> Anything EE security seems way too heavyweight for me. This might work out >> for TomEE, but would kill it's use in any more lightweight approach. > >> On Feb 13, 2018, at 11:27 AM, Rudy De Busscher <[email protected]> wrote: >> >> I used JASPIC as it seemed to most natural way to feed the EE system >> with authorisation >> and authentication into the system. >> >> But probably need deep integration with server code because otherwise, the >> JWT authentication mechanism is an all or nothing system, which is not the >> best solution (maybe less a problem with MicroServices but if you want to >> use it in a more general way it is an obstacle) > > These last two are very related. JASPIC would be great, but TomEE > (specifically the OpenEJB part) doesn't implement it. All of the EJB calls > for isCallerInRole etc are wired in and fed through this interface. > > https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/spi/SecurityService.java > > 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. > > > -David >
