[Apiman-user] Forwarding HTTP requests to service implementations secured by OAuth

[Ton Swieb]

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 at 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 at redhat.com
>>> >> <mailto:marc.savy at 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 at lists.jboss.org
>>> >> <mailto:Apiman-user at lists.jboss.org>
>>> >>          https://lists.jboss.org/mailman/listinfo/apiman-user
>>> >>
>>> >>
>>> >
>>> > _______________________________________________
>>> > Apiman-user mailing list
>>> > Apiman-user at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/apiman-user
>>> >
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151201/f07c8df9/attachment-0001.html