2015-12-01 13:55 GMT+01:00 Eric Wittmann <eric.wittmann@redhat.com>:

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 "Service Read" 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.

-Eric

On 12/1/2015 3:03 AM, Ton Swieb wrote:

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
<mailto: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>
>> <mailto: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>
>> <mailto: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
<mailto:Apiman-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/apiman-user
>