@Matthew: with JWT you get a self contained token you validate without any remote call, you just need to put @LoginConfig (from the MP spec, not the servlet one) or the equivalent in the web.xml to activate it. To configure it you can use mp-config to set the certificate which validate the JWT signature (and optionally the date validation range).
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-03-29 12:59 GMT+02:00 Matthew Broadhead <matthew.broadh...@nbmlaw.co.uk >: > thanks for the more detailed explanation and it is good that @RolesAllowed > will finally work. > by "configuration of an oauth endpoint" i meant that the user could define > an endpoint in config that would allow TomEE to use that as as a security > provider. i.e. not using TomEE itself as a security provider. > in keycloak a realm client has a "keycloak OIDC JSON" file that is created > through the user interface. this is dropped into the webapp and a valve > has to be setup in context.xml > <Context path="/your-context-path"> > <Valve className="org.keycloak.adapters.tomcat.KeycloakAuthenticato > rValve"/> > </Context> > i just wondered if it was similar. are there any docs? > > > On 29/03/2018 04:00, David Blevins wrote: > >> On Mar 28, 2018, at 1:22 AM, Matthew Broadhead < >>> matthew.broadh...@nbmlaw.co.uk> wrote: >>> >>> would it allow configuration of an oauth endpoint in TomEE and then >>> defining security-constraint in the web.xml of a webapp? seems like a good >>> plan if it drops the need for 3rd party libs >>> >> Very close. It wouldn't provide an endpoint that creates JWT tokens, but >> it would provide functionality for JWT tokens to be *validated* when passed >> to TomEE in the "Authorization" header of any HTTP request. >> >> But, absolutely yes that validation would be done without the need for >> any third-party libraries. The assumption is that TomEE would need to be >> given the RSA public key corresponding to the private key the token server >> used to create the JWT. >> >> After validation, there are three groups of additional features to make >> things convenient for developers: >> >> - Identity: The server is required to propagate the JWT `sub` to >> getCallerPrinciple() and similar existing calls in various Java EE apis >> >> - Permissions: `@RolesAllowed` finally becomes useful as the server is >> required to honor the JWT `scopes` claim in uses of `@RolesAllowed` and >> `isCallerInRole()` >> >> - Claims: Any other values of the incoming JWT can be injected into >> your code via CDI `@Inject @Claim("foo")` as a handful of different data >> types. I.e. you can use it as a secure cookie if you want and do not need >> to write any parsing code. >> >> You still need something to create the tokens, which could be done with >> an API Gateway or some code you write. You wouldn't put that code on all >> microservices as the power of JWT is that there's one source of identity >> that the enterprise trusts so that should be some fairly small set of very >> secure servers who hold the private key and do not share it. >> >> Hope that puts some color on it. We'll want to document the feature and >> this is a good start, so more questions the better. >> >> >> -David >> >> >
