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.
> 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.
-- Santiago