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.KeycloakAuthenticatorValve"/>
</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
