[jax-rs-spec users] Re: JAX-RS Security

From: arjan tijms <>
Date: Mon, 15 Dec 2014 18:19:19 +0100


On Mon, Dec 15, 2014 at 5:42 PM, Santiago Pericas-Geertsen
<> wrote:
> On Dec 13, 2014, at 9:13 AM, Bill Burke <> wrote:
>> * There is no way to override and propagate principal/role mappings (SecurityContext) to other nested component calls.
> Can you elaborate on the SecurityContext propagation issue?

What I guess was meant here is that the caller/user principal and
optionally any groups/roles that were set in a JASPIC auth module or a
Servlet proprietary module, are automatically propagated to things
like EJB components and (when setup correctly) to remote servers when
EJB remoting is used, as well if I'm not mistaken to container managed
threads such as those offered by Java EE concurrency and the JCA

If a JAX-RS SecurityContext is overriden to provide JAX-RS components
the user principal and the isUserInRole check, then only JAX-RS knows
about this. If you call an EJB from within a JAX-RS resource then any
authentication details will be lost there. E.g. @RolesAllowed and
getCallerPrincipal and isCallerInRole in the EJBContext won't work.
Code using the HttpServletRequest for these things also won't work,
unless you also override/wrap that one, but then it still wouldn't
propagate to EJB and container managed threads.

Kind regards,
Arjan Tijms

> -- Santiago
>> On 12/13/2014 8:54 AM, Markus KARG wrote:
>>> Thank you for that explanation. In fact I always assumed that due to JAAS' modular concept it would be possible to provide some JAAS module to the client which under the hood does OAuth. Maybe I was wrong with that, but as you seem to be an expert with that, I'd like you to check this before we invent something completely new.
>>> Regards
>>> -Markus
>>> -----Original Message-----
>>> From: Casey Lee []
>>> Sent: Samstag, 13. Dezember 2014 01:19
>>> To:
>>> Subject: Re: JAX-RS Security
>>> Fair question. Let's consider client side first. For authentication, JAAS provides a pluggable way of collecting the credentials from the user. However with OAuth 2.0, we don't want the client app to collect the credentials...we want the client app to redirect the resource owner to an authorization server to authenticate and grant access to the client app. I don't think this type of authorization on the client side lines up with JAAS.
>>> On the server side, I think there is more opportunity for integration, ideally with the annotations that are already available. Another challenge though is that OAuth brings another party to the transaction. Rather than just AuthN/AuthZ of the client by the resource, we also have to AuthZ the resource owner who is using the client. Specifically, we need to authorize that the resource owner has access to the resource AND that the client has been granted access to the resource on behalf of the resource owner.
>>> I don't want to reinvent the wheel if it's already there...I'll give JAAS another look and see if any other folks are having better luck with using it with OAuth 2.0.
>>> -Casey
>>> On Fri, Dec 12, 2014 at 2:45 PM, Markus KARG <> wrote:
>>>> Casey,
>>>> I am not a security guy at all, so please don't mind if the question is dumb, but doesn't JAAS already define interfaces for authentication providers? If so, we could use those instead of reinventing the wheel.
>>>> Regards
>>>> -Markus
>>>> -----Original Message-----
>>>> From: Casey Lee []
>>>> Sent: Freitag, 12. Dezember 2014 17:53
>>>> To:
>>>> Subject: JAX-RS Security
>>>> I have some opinions on opportunities for adding security to JAX-RS.
>>>> First, on the client side I'd love to see a method added to Invocation.builder to add an implementation of a new interface named AuthorizationProvider. This would allow implementations of AuthorizationProvider to be created for specific types of OAuth2AuthorizationProvider or BasicAuthorizationProvider. These providers would be responsible for applying necessary Authorization header (or query params?) to the invocation. What are the thoughts on adding some standard providers to the API? OAuth 2.0 for example is something that has become ubiquitous, but has a steep learning curve for developers to use properly.
>>>> On the server side aren't the JSR-250 security annotations supported by JAX-RS? Or is that only implemented by some specific vendors?
>>>> Seems that those solve course grained security (by role). We have chosen to leverage those annotations and treat OAuth 2.0 scopes as roles. Would it make sense to have a more OAuth 2.0 specific solution (@ScopesAllowed)?
>>>> -Casey
>> --
>> Bill Burke
>> JBoss, a division of Red Hat