2:03 a.m.
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(a)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(a)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(a)lists.jboss.org
>> >> <mailto:Apiman-user@lists.jboss.org>
>> >> https://lists.jboss.org/mailman/listinfo/apiman-user
>> >>
>> >>
>> >
>> > _______________________________________________
>> > Apiman-user mailing list
>> > Apiman-user(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/apiman-user
>> >
>>
>
>
6:55 a.m.
New subject: Forwarding HTTP requests to service implementations secured by OAuth
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(a)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(a)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(a)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(a)lists.jboss.org
<mailto:Apiman-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
8:16 a.m.
New subject: Forwarding HTTP requests to service implementations secured by OAuth
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(a)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(a)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(a)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(a)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(a)lists.jboss.org
> <mailto:Apiman-user@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/apiman-user
> >
>
>
>
>
9:43 a.m.
New subject: Forwarding HTTP requests to service implementations secured by OAuth
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(a)redhat.com
<mailto: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(a)redhat.com <mailto:eric.wittmann@redhat.com>
<mailto: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(a)redhat.com <mailto:marc.savy@redhat.com>
<mailto:marc.savy@redhat.com <mailto:marc.savy@redhat.com>>
>> <mailto: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(a)lists.jboss.org
<mailto:Apiman-user@lists.jboss.org>
<mailto:Apiman-user@lists.jboss.org
<mailto:Apiman-user@lists.jboss.org>>
>> <mailto: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(a)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
>
3779
days inactive
3779
days old
3 comments
2 participants
participants (2)
-
Eric Wittmann -
Ton Swieb