We propagate to EJB the principal so we should have it working without a lot - never said "no" - of effort for all synchronous cases. I'm pretty sure it will be broken for the async - but natural user - flow (@Suspended or plain AsyncContext, EE Concurrency utilities will not work for servlet case - can need a fix - but would if called from an EJB IIRC) but this seems out of the spec too, no?
You are right the Jacc integration can need a few more love to match the spec but we own this code and have the principal at that moment so i'm sure we can make it running, even without being jwt specific which can benefit all the alternative solutions user base. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> 2018-02-14 22:43 GMT+01:00 David Blevins <david.blev...@gmail.com>: > > On Feb 14, 2018, at 11:34 AM, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > > > If jsonp it can be @appscoped too technically > > I was definitely advocating for that and AppScoped was supported, but it > got axed at the finish line the week before the 1.0 spec went final. We > decided to cut scope (pun intended) to get something out the door and come > back and add this later. > > > > 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. > > > > Cant jaspic work? > > Not sure to be honest. > > One place I suspect will be tough is the EJB isCallerInRole checks we do > are effectively handled by our JACC code (or was). That code expects we > know all the users that exist and their permissions at startup time. > During the Assembler phase the JaccPermissionsBuilder will build a > permissions object for each role the user has. The JACC provider then > becomes effectively an in memory database of permissions objects. This > again, goes against the JWT concept as the user and the roles are in the > token and there is no state in the server. > > Not sure how we'll need to handle that or if JASPIC helps. > > > https://github.com/apache/tomee/blob/master/container/ > openejb-core/src/main/java/org/apache/openejb/assembler/classic/ > JaccPermissionsBuilder.java > > > Also a jwt for an ejb without a request > > means....something to define ;). > > That's all defined in chapter 12 > > ... the spec may or may not have only 10 chapters :) > > > -David > > > >
