On Fri, Dec 12, 2014 at 12:05 PM, Santiago Pericas-Geertsen
<Santiago.PericasGeertsen_at_oracle.com> wrote:
> Hi Casey,
>
> On Dec 12, 2014, at 11:53 AM, Casey Lee <cplee_at_nektos.com> wrote:
>
>> 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 authz...like
>> OAuth2AuthorizationProvider or BasicAuthorizationProvider. These
>> providers would be responsible for applying necessary Authorization
>> header (or query params?) to the invocation.
>
> Have you found the existing extension points in JAX-RS insufficient? In particular, a Feature was intended to be used as a way to register providers to accomplish tasks like this on a Client. Of course, it could be that the extensions points that we have are too generic and we need something more specific for security.
The challenge with this approach is that the feature is configured for
an instance of a Client which are heavy and should be shared. We want
to share Client instances across many different Invocations...but each
invocation may need different credentials or tokens. Currently we
need to add the Authorization header via Invocation.Builder.header()
since a different header must be added for each invocation.
>
>> On the server side aren't the JSR-250 security annotations supported
>> by JAX-RS? Or is that only implemented by some specific vendors?
>
> Not in the spec, but implementations support some annotations. Definitely an area for us to work on, but we also need to keep an eye on the new Security JSR. Hence, why we should wait a bit until diving into this.
>
>> 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)?
>
> Possibly, but this is why we need to liaison with the Security JSR to avoid duplication.
I'd be interested in helping with this coordination with Security JSR
if you are looking for a volunteer :)
-Casey