Yes, works fine on client side...ends up being rather abstract with
properties and I'd prefer to see auth more prominent. Either way, not
a big issue...I yield on the client side.
As for server side, I'd still prefer to see something more declarative
on the resources. Specifically, I'd like to see something that deals
with the multiple parties involved with OAuth 2.0. Now maybe the
answer is "We don't want to have anything OAuth related in the API".
If that isn't the case, then it seems there ought to be two types of
annotations...one for permitting roles that the resource owner is in,
and the other for permitting roles from the scopes on the token.
Any suggestions on existing solutions for this?
-Casey
On Mon, Dec 15, 2014 at 7:36 AM, Santiago Pericas-Geertsen
<Santiago.PericasGeertsen_at_oracle.com> wrote:
>
> On Dec 12, 2014, at 7:04 PM, Casey Lee <cplee_at_nektos.com> wrote:
>
> 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.
>
>
> What about using properties [1]? These should be available to filters and
> interceptors precisely for the purpose that you describe. That is, once a
> Feature is enabled, properties can be used to further configure it, even on
> a per-invocation basis.
>
> -- Santiago
>
> [1]
> https://jax-rs-spec.java.net/nonav/2.0-rev-a/apidocs/javax/ws/rs/client/Invocation.Builder.html#property(java.lang.String,%20java.lang.Object)
>