Thanks David,

I've started to look into our SecurityService interface as well.
It would need to evolve at some point. The couple username + password is
not the best to support many authentication mechanisms.

The realm interface in Tomcat is not the best either because it has like 5
or 6 strongly typed signatures and you can't add more.
Basically currently, I'll pass the token into the username parameter and
leave the password empty.

But would be great to think about a better abstraction to represent the
credentials.

On the prototype side, I'll definitely use Nimbus to start.
Don't want to address all problems at once.

Rudy has one implementation based on JASPIC, probably a good opportunity to
look at it.








--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

On Wed, Feb 14, 2018 at 5:30 PM, David Blevins <david.blev...@gmail.com>
wrote:

>
> > On Feb 13, 2018, at 3:43 AM, John D. Ament <johndam...@apache.org>
> 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 <strub...@yahoo.de.INVALID>
> 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 <strub...@yahoo.de.INVALID>
> 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 <rdebussc...@gmail.com>
> 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
>
>

Reply via email to