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