> On Mar 28, 2018, at 1:22 AM, Matthew Broadhead
> <[email protected]> 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
