Hi Eric, Marc,

Thanks for getting back to me.

Good point about the security implications of using the custom header policy. I am assuming that the credentials configured for the endpoint like basic auth en mutal SSL are better secured then the configuration of a policy.

What role does someone need to read the custom header policy configuration?

I am aware that refreshing the token will not be possible with the current setup. This should not be a problem for now. The tokens will have a long time to live.

Regards,

Ton

2015-11-30 15:25 GMT+01:00 Eric Wittmann <eric.wittmann@redhat.com>:
Fair point.  Although BASIC Auth probably isn't recommended either. :)

On 11/30/2015 8:37 AM, Marc Savy wrote:
I'll take any further stuff to the ticket - but, my understanding is
that Server-To-Server OAuth2 isn't particularly recommended (Mutual TLS
or similar is preferred).

That being said, I think you could argue we're just acting as a client
by proxy, so perhaps it's okay.

On 30/11/2015 13:33, Eric Wittmann wrote:
Right - at this point a custom policy is probably the only reasonable
approach.

I've added OAuth support between the Gateway and back-end API as a
feature request here:

https://issues.jboss.org/browse/APIMAN-811

-Eric

On 11/30/2015 6:31 AM, Marc Savy wrote:
> Hi Ton,
>
> Sorry, I forgot to reply to this.
>
> In essence, you are correct. There's no in-built mechanism to achieve
> what you want (i.e. gateway acting as an OAuth2 *client*).
>
> You could indeed use the simple header policy to store a long-lived
> token, but this should not be considered a particularly secure approach
> (particularly if there's a chance that the token could be exposed
> somehow - e.g. by a user looking at the policy config in the UI).
>
> The second issue, which you are undoubtedly aware of, is that there is
> no mechanism to auto-refresh those token(s) once expired.
>
> Another option which you could explore is to create a custom policy
> which does the periodic refreshing of tokens for you.
>
> Regards,
> Marc
>
> On 18/11/2015 15:11, Ton Swieb wrote:
>> Hi Marc,
>>
>> That is correct.
>>
>> Regards,
>>
>> Ton
>>
>> 2015-11-18 16:02 GMT+01:00 Marc Savy <marc.savy@redhat.com
>> <mailto:marc.savy@redhat.com>>:
>>
>>      Hi Ton,
>>
>>      Just to clarify. From what I understand, you're trying to secure
>>      communications between the apiman gateway and back-end service
>> using
>>      OAuth2/OpenID Connect?
>>
>>      I.e. You are *not* OAuth2 simply between the client to the apiman
>>      gateway.
>>
>>      Regards,
>>      Marc
>>
>>      On 18/11/2015 14:34, Ton Swieb wrote:
>>
>>          Hi,
>>
>>          I am using Apiman 1.1.8.Final and I want to use a backend
>> service in
>>          Apiman which is secured by OAuth.
>>          So instead of securing the Apiman side of the service, using
>> the
>>          Keycloak OAuth plugin, Apiman needs forward calls to a
service
>>          implementation that is secured by OAuth. I have got an OAuth
>>          token with
>>          a very long time to live (days/weeks/months) which I can use.
>>
>>          Currently I only see the option to configure BASIC
>> Authentication or
>>          MTLS/Two-Way-SSL on the service implementation.
>>          Would it be possible to add the HTTP Simple Header policy to
>> the
>>          service
>>          and set the Authorization header with "Bearer........." or
will
>>          that be
>>          stripped off by Apiman when forwarding the call to the
backend
>>          service?
>>
>>          Kind regards,
>>
>>          Ton
>>
>>
>>          _______________________________________________
>>          Apiman-user mailing list
>>          Apiman-user@lists.jboss.org
>> <mailto:Apiman-user@lists.jboss.org>
>>          https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>