<div dir="ltr"><div>Hi Eric, Marc,<br><br></div><div>Thanks for getting back to me.<br></div><div><br></div><div>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.<br><br></div><div>What role does someone need to read the custom header policy configuration?<br></div><div><br></div><div>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.<br></div><div><div><br></div><div><div>Regards,<br><br></div><div>Ton<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-11-30 15:25 GMT+01:00 Eric Wittmann <span dir="ltr"><<a href="mailto:eric.wittmann@redhat.com" target="_blank">eric.wittmann@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Fair point. Although BASIC Auth probably isn't recommended either. :)<br>
<br>
On 11/30/2015 8:37 AM, Marc Savy wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'll take any further stuff to the ticket - but, my understanding is<br>
that Server-To-Server OAuth2 isn't particularly recommended (Mutual TLS<br>
or similar is preferred).<br>
<br>
That being said, I think you could argue we're just acting as a client<br>
by proxy, so perhaps it's okay.<br>
<br>
On 30/11/2015 13:33, Eric Wittmann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Right - at this point a custom policy is probably the only reasonable<br>
approach.<br>
<br>
I've added OAuth support between the Gateway and back-end API as a<br>
feature request here:<br>
<br>
<a href="https://issues.jboss.org/browse/APIMAN-811" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/APIMAN-811</a><br>
<br>
-Eric<br>
<br>
On 11/30/2015 6:31 AM, Marc Savy wrote:<br>
> Hi Ton,<br>
><br>
> Sorry, I forgot to reply to this.<br>
><br>
> In essence, you are correct. There's no in-built mechanism to achieve<br>
> what you want (i.e. gateway acting as an OAuth2 *client*).<br>
><br>
> You could indeed use the simple header policy to store a long-lived<br>
> token, but this should not be considered a particularly secure approach<br>
> (particularly if there's a chance that the token could be exposed<br>
> somehow - e.g. by a user looking at the policy config in the UI).<br>
><br>
> The second issue, which you are undoubtedly aware of, is that there is<br>
> no mechanism to auto-refresh those token(s) once expired.<br>
><br>
> Another option which you could explore is to create a custom policy<br>
> which does the periodic refreshing of tokens for you.<br>
><br>
> Regards,<br>
> Marc<br>
><br>
> On 18/11/2015 15:11, Ton Swieb wrote:<br>
>> Hi Marc,<br>
>><br>
>> That is correct.<br>
>><br>
>> Regards,<br>
>><br>
>> Ton<br>
>><br>
>> 2015-11-18 16:02 GMT+01:00 Marc Savy <<a href="mailto:marc.savy@redhat.com" target="_blank">marc.savy@redhat.com</a><br>
>> <mailto:<a href="mailto:marc.savy@redhat.com" target="_blank">marc.savy@redhat.com</a>>>:<br>
>><br>
>> Hi Ton,<br>
>><br>
>> Just to clarify. From what I understand, you're trying to secure<br>
>> communications between the apiman gateway and back-end service<br>
>> using<br>
>> OAuth2/OpenID Connect?<br>
>><br>
>> I.e. You are *not* OAuth2 simply between the client to the apiman<br>
>> gateway.<br>
>><br>
>> Regards,<br>
>> Marc<br>
>><br>
>> On 18/11/2015 14:34, Ton Swieb wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> I am using Apiman 1.1.8.Final and I want to use a backend<br>
>> service in<br>
>> Apiman which is secured by OAuth.<br>
>> So instead of securing the Apiman side of the service, using<br>
>> the<br>
>> Keycloak OAuth plugin, Apiman needs forward calls to a<br>
service<br>
>> implementation that is secured by OAuth. I have got an OAuth<br>
>> token with<br>
>> a very long time to live (days/weeks/months) which I can use.<br>
>><br>
>> Currently I only see the option to configure BASIC<br>
>> Authentication or<br>
>> MTLS/Two-Way-SSL on the service implementation.<br>
>> Would it be possible to add the HTTP Simple Header policy to<br>
>> the<br>
>> service<br>
>> and set the Authorization header with "Bearer........." or<br>
will<br>
>> that be<br>
>> stripped off by Apiman when forwarding the call to the<br>
backend<br>
>> service?<br>
>><br>
>> Kind regards,<br>
>><br>
>> Ton<br>
>><br>
>><br>
>> _______________________________________________<br>
>> Apiman-user mailing list<br>
>> <a href="mailto:Apiman-user@lists.jboss.org" target="_blank">Apiman-user@lists.jboss.org</a><br>
>> <mailto:<a href="mailto:Apiman-user@lists.jboss.org" target="_blank">Apiman-user@lists.jboss.org</a>><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/apiman-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/apiman-user</a><br>
>><br>
>><br>
><br>
> _______________________________________________<br>
> Apiman-user mailing list<br>
> <a href="mailto:Apiman-user@lists.jboss.org" target="_blank">Apiman-user@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/apiman-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/apiman-user</a><br>
><br>
</blockquote>
<br>
</blockquote>
</blockquote></div><br></div></div></div></div>