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)