[Apiman-user] Forwarding HTTP requests to service implementations secured by OAuth
Eric Wittmann
eric.wittmann at redhat.com
Tue Dec 1 10:43:48 EST 2015
You are correct - from a security standpoint I don't think it matters.
I do think 460 is related - we should ensure that potentially security
sensitive information is not returned unless the requesting user has the
appropriate permission.
On 12/1/2015 9:16 AM, Ton Swieb wrote:
> 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
> <mailto: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>
> <mailto: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>>
> >> <mailto: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>>
> >> <mailto: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>
> <mailto:Apiman-user at lists.jboss.org
> <mailto:Apiman-user at lists.jboss.org>>
> > https://lists.jboss.org/mailman/listinfo/apiman-user
> >
>
>
>
>
More information about the Apiman-user
mailing list