[Apiman-user] Forwarding HTTP requests to service implementations secured by OAuth
Ton Swieb
ton at finalist.nl
Tue Dec 1 09:16:59 EST 2015
Hi Eric,
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.
Is this related to https://issues.jboss.org/browse/APIMAN-460?
2015-12-01 13:55 GMT+01:00 Eric Wittmann <eric.wittmann at 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 at redhat.com
>> <mailto: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>
>> >> <mailto: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>
>> >> <mailto: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
>> <mailto: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/1064b322/attachment-0001.html
More information about the Apiman-user
mailing list