From guydavis.ca at gmail.com  Sat Jan  2 10:32:13 2016
From: guydavis.ca at gmail.com (Guy Davis)
Date: Sat, 2 Jan 2016 08:32:13 -0700
Subject: [Apiman-user] Integration with separate Keycloak server?
In-Reply-To: <783054167.3536583.1451560765738.JavaMail.zimbra@redhat.com>
References: <CAAgmn1qQhSvHW64rjtorR-ncDPtRL2Pu7xM-mfPUFpj6JT0pkA@mail.gmail.com>
	<567338B3.1050706@redhat.com>
	<CAAgmn1o0LraKiJ13uHBBXgJqcOqL_CNcWqJ6uzd2FP0w8PvYQA@mail.gmail.com>
	<783054167.3536583.1451560765738.JavaMail.zimbra@redhat.com>
Message-ID: <CAAgmn1pxdGwtYR1pzdvnD7k1tDd6AazHad01oJZSRvscn0eFAg@mail.gmail.com>

Hi Marc,

Yes!  Thanks for the workaround.  After your report, I went back and
imported the default 'apiman
<https://raw.githubusercontent.com/apiman/apiman/master/distro/data/src/main/resources/data/apiman-realm.json>'
realm into my Keycloak 1.7 server.  In this case, I was able to login to
/apimanui with no 403 error. Since my production deployment will involve
multiple apps, I had setup APIMan to be secured in our single realm, all
under a single KC Client named 'apiman' with client roles of 'apiuser,
apipublisher, and apiadmin'.  After much trial and error I discovered the
difference in my multi-app setup and the APIMan example realm was the level
of the roles.  In particular, if the apiman roles are declared on the
apiman client itself, then role mapping them to users won't allow login.
However, if the apiman roles are realm-wide roles, then a role mapping
seems to work and users can login.

It's unfortunate that a single application like APIMan should require it's
own realm-wide roles for security, not KC-client level roles.  None of the
other apps that I have secured with Keycloak seem to require more than
KC-client level roles.  So I consider this a defect in Keycloak, likely due
to the use of the old Keycloak adapter in the APIMan 1.1.9 bundle.  I look
forward to an upcoming release of APIMan with updated Keycloak integration.

Best regards,
Guy

On Thu, Dec 31, 2015 at 4:19 AM, Marc Savy <msavy at redhat.com> wrote:

> Hi,
>
> I actually tried this about a week or fortnight ago (see the thread with
> pblair), and I got it working pretty easily.
>
> The only thing I had to change was in the Keycloak console, where I
> enabled 'Direct API Grants' on the apiman gateway api clients (or similar
> wording, I'm on mobile), and everything worked fine despite adaptor version
> mismatches.
>
> Regards,
> Marc
>
> ----- Original Message -----
> From: Guy Davis <guydavis.ca at gmail.com>
> To: Eric Wittmann <eric.wittmann at redhat.com>
> Cc: apiman-user at lists.jboss.org
> Sent: Thu, 31 Dec 2015 01:00:23 -0500 (EST)
> Subject: Re: [Apiman-user] Integration with separate Keycloak server?
>
> Hi Eric,
>
> Thanks for the quick response.  I tried this using a separate Keycloak
> 1.7.0 server and am encountering errors that, after debugging thru the
> Keycloak OAuth flow, seem linked to the use of the earlier version of the
> Keycloak adapter which is bundled with APIMan 1.1.9.  Do you have an
> planned release date for a Keycloak 1.7.0 compatible version of APIMan?
> Continued successful integration between these two projects is a big
> benefit.
>
> If try to use APIMan 1.1.9 with the Keycloak 1.7.0 adapter for Wildfly, I
> encounter a problem in
> io.apiman.manager.ui.server.wildfly8,KeyCloakBearerTokenGenerator where the
> use of:
>
>     org.keycloak.util.Time,getTime()
>
> errors out at runtime with ClassNotFoundException as this class was dropped
> from the Keycloak 1.7.0 API.
>
> Thanks again.
> Guy
>
> On Thu, Dec 17, 2015 at 3:35 PM, Eric Wittmann <eric.wittmann at redhat.com>
> wrote:
>
> > This is absolutely possible.  Have a look through the production guide
> and
> > see if it helps:
> >
> > http://www.apiman.io/latest/production-guide.html
> >
> > If you continue to have issues let us know so that we can update the
> > guide.  We already have at least one update to make:
> >
> > https://issues.jboss.org/browse/APIMAN-842
> >
> > -Eric
> >
> > On 12/17/2015 3:48 PM, Guy Davis wrote:
> >
> >> Good day,
> >>
> >> I currently have a test instance of Wildfly 9 running both Keycloak 1.5
> >> and Apiman 1.1.8.  I'm using Keycloak 1.5 as Apiman makes a Keycloak
> >> getTime() call somewhere that was removed in Keycloak 1.6's adapters.
> >>
> >> So I'm seeing that trying to put Keycloak and Apiman in the same Wildfly
> >> container is probably not a good plan going forward due to
> >> incompatibilities as each project progresses.
> >>
> >> Today, I noticed that Hawkular announced
> >> <
> >>
> http://www.hawkular.org/blog/2015/12/16/hawkular-1.0.0.Alpha8-released.html
> >> >
> >> that they now allow startup of their container with a property pointing
> >> to a remote Keycloak server.
> >>
> >> Is this possible with Apiman today?  If not, is it on the roadmap?  I'd
> >> like to upgrade to Keycloak 1.7
> >> <http://blog.keycloak.org/2015/12/keycloak-170final-released.html>
> >> following
> >> this approach with Keycloak, Apiman, and Hawkular all in their own
> >> containers.
> >>
> >> By the way, I'm really stoked to see the excellent integration and
> >> progress being made by all these projects!  Keep up the good work.
> >>
> >> Thanks,
> >> Guy
> >>
> >>
> >> _______________________________________________
> >> Apiman-user mailing list
> >> 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/20160102/98389c84/attachment-0001.html 

From msavy at redhat.com  Sat Jan  2 11:22:02 2016
From: msavy at redhat.com (Marc Savy)
Date: Sat, 2 Jan 2016 11:22:02 -0500 (EST)
Subject: [Apiman-user] Integration with separate Keycloak server?
In-Reply-To: <CAAgmn1pxdGwtYR1pzdvnD7k1tDd6AazHad01oJZSRvscn0eFAg@mail.gmail.com>
References: <CAAgmn1qQhSvHW64rjtorR-ncDPtRL2Pu7xM-mfPUFpj6JT0pkA@mail.gmail.com>
	<567338B3.1050706@redhat.com>
	<CAAgmn1o0LraKiJ13uHBBXgJqcOqL_CNcWqJ6uzd2FP0w8PvYQA@mail.gmail.com>
	<783054167.3536583.1451560765738.JavaMail.zimbra@redhat.com>
	<CAAgmn1pxdGwtYR1pzdvnD7k1tDd6AazHad01oJZSRvscn0eFAg@mail.gmail.com>
Message-ID: <1390682710.3853109.1451751722182.JavaMail.zimbra@redhat.com>

Hi Guy,

Would you mind filing a JIRA (https://issues.jboss.org/browse/APIMAN) with your issues as described here (feel free to refer to your email in the archives http://lists.jboss.org/pipermail/apiman-user/)

This sounds like an issue we should pay attention to and ensure is resolved satisfactorily when we move to a newer version of Keycloak. 

Regards,
Marc

----- Original Message -----
From: Guy Davis <guydavis.ca at gmail.com>
To: Marc Savy <msavy at redhat.com>
Cc: apiman-user at lists.jboss.org
Sent: Sat, 02 Jan 2016 10:32:13 -0500 (EST)
Subject: Re: [Apiman-user] Integration with separate Keycloak server?

Hi Marc,

Yes!  Thanks for the workaround.  After your report, I went back and
imported the default 'apiman
<https://raw.githubusercontent.com/apiman/apiman/master/distro/data/src/main/resources/data/apiman-realm.json>'
realm into my Keycloak 1.7 server.  In this case, I was able to login to
/apimanui with no 403 error. Since my production deployment will involve
multiple apps, I had setup APIMan to be secured in our single realm, all
under a single KC Client named 'apiman' with client roles of 'apiuser,
apipublisher, and apiadmin'.  After much trial and error I discovered the
difference in my multi-app setup and the APIMan example realm was the level
of the roles.  In particular, if the apiman roles are declared on the
apiman client itself, then role mapping them to users won't allow login.
However, if the apiman roles are realm-wide roles, then a role mapping
seems to work and users can login.

It's unfortunate that a single application like APIMan should require it's
own realm-wide roles for security, not KC-client level roles.  None of the
other apps that I have secured with Keycloak seem to require more than
KC-client level roles.  So I consider this a defect in Keycloak, likely due
to the use of the old Keycloak adapter in the APIMan 1.1.9 bundle.  I look
forward to an upcoming release of APIMan with updated Keycloak integration.

Best regards,
Guy

On Thu, Dec 31, 2015 at 4:19 AM, Marc Savy <msavy at redhat.com> wrote:

> Hi,
>
> I actually tried this about a week or fortnight ago (see the thread with
> pblair), and I got it working pretty easily.
>
> The only thing I had to change was in the Keycloak console, where I
> enabled 'Direct API Grants' on the apiman gateway api clients (or similar
> wording, I'm on mobile), and everything worked fine despite adaptor version
> mismatches.
>
> Regards,
> Marc
>
> ----- Original Message -----
> From: Guy Davis <guydavis.ca at gmail.com>
> To: Eric Wittmann <eric.wittmann at redhat.com>
> Cc: apiman-user at lists.jboss.org
> Sent: Thu, 31 Dec 2015 01:00:23 -0500 (EST)
> Subject: Re: [Apiman-user] Integration with separate Keycloak server?
>
> Hi Eric,
>
> Thanks for the quick response.  I tried this using a separate Keycloak
> 1.7.0 server and am encountering errors that, after debugging thru the
> Keycloak OAuth flow, seem linked to the use of the earlier version of the
> Keycloak adapter which is bundled with APIMan 1.1.9.  Do you have an
> planned release date for a Keycloak 1.7.0 compatible version of APIMan?
> Continued successful integration between these two projects is a big
> benefit.
>
> If try to use APIMan 1.1.9 with the Keycloak 1.7.0 adapter for Wildfly, I
> encounter a problem in
> io.apiman.manager.ui.server.wildfly8,KeyCloakBearerTokenGenerator where the
> use of:
>
>     org.keycloak.util.Time,getTime()
>
> errors out at runtime with ClassNotFoundException as this class was dropped
> from the Keycloak 1.7.0 API.
>
> Thanks again.
> Guy
>
> On Thu, Dec 17, 2015 at 3:35 PM, Eric Wittmann <eric.wittmann at redhat.com>
> wrote:
>
> > This is absolutely possible.  Have a look through the production guide
> and
> > see if it helps:
> >
> > http://www.apiman.io/latest/production-guide.html
> >
> > If you continue to have issues let us know so that we can update the
> > guide.  We already have at least one update to make:
> >
> > https://issues.jboss.org/browse/APIMAN-842
> >
> > -Eric
> >
> > On 12/17/2015 3:48 PM, Guy Davis wrote:
> >
> >> Good day,
> >>
> >> I currently have a test instance of Wildfly 9 running both Keycloak 1.5
> >> and Apiman 1.1.8.  I'm using Keycloak 1.5 as Apiman makes a Keycloak
> >> getTime() call somewhere that was removed in Keycloak 1.6's adapters.
> >>
> >> So I'm seeing that trying to put Keycloak and Apiman in the same Wildfly
> >> container is probably not a good plan going forward due to
> >> incompatibilities as each project progresses.
> >>
> >> Today, I noticed that Hawkular announced
> >> <
> >>
> http://www.hawkular.org/blog/2015/12/16/hawkular-1.0.0.Alpha8-released.html
> >> >
> >> that they now allow startup of their container with a property pointing
> >> to a remote Keycloak server.
> >>
> >> Is this possible with Apiman today?  If not, is it on the roadmap?  I'd
> >> like to upgrade to Keycloak 1.7
> >> <http://blog.keycloak.org/2015/12/keycloak-170final-released.html>
> >> following
> >> this approach with Keycloak, Apiman, and Hawkular all in their own
> >> containers.
> >>
> >> By the way, I'm really stoked to see the excellent integration and
> >> progress being made by all these projects!  Keep up the good work.
> >>
> >> Thanks,
> >> Guy
> >>
> >>
> >> _______________________________________________
> >> Apiman-user mailing list
> >> Apiman-user at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/apiman-user
> >>
> >>
>
>


From eric.wittmann at redhat.com  Mon Jan  4 08:46:43 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 4 Jan 2016 08:46:43 -0500
Subject: [Apiman-user] Integration with separate Keycloak server?
In-Reply-To: <CAAgmn1o0LraKiJ13uHBBXgJqcOqL_CNcWqJ6uzd2FP0w8PvYQA@mail.gmail.com>
References: <CAAgmn1qQhSvHW64rjtorR-ncDPtRL2Pu7xM-mfPUFpj6JT0pkA@mail.gmail.com>
	<567338B3.1050706@redhat.com>
	<CAAgmn1o0LraKiJ13uHBBXgJqcOqL_CNcWqJ6uzd2FP0w8PvYQA@mail.gmail.com>
Message-ID: <568A77C3.4070605@redhat.com>

Just to add something to this part of the conversation - we will 
certainly be updating our Keycloak support soon.  Certainly as part of 
the apiman 1.2.x line of development.  Perhaps as early as 1.2.1.Final.

-Eric

On 12/31/2015 1:00 AM, Guy Davis wrote:
> Hi Eric,
>
> Thanks for the quick response.  I tried this using a separate Keycloak
> 1.7.0 server and am encountering errors that, after debugging thru the
> Keycloak OAuth flow, seem linked to the use of the earlier version of
> the Keycloak adapter which is bundled with APIMan 1.1.9.  Do you have an
> planned release date for a Keycloak 1.7.0 compatible version of APIMan?
> Continued successful integration between these two projects is a big
> benefit.
>
> If try to use APIMan 1.1.9 with the Keycloak 1.7.0 adapter for Wildfly,
> I encounter a problem in
> io.apiman.manager.ui.server.wildfly8,KeyCloakBearerTokenGenerator where
> the use of:
>
>      org.keycloak.util.Time,getTime()
>
> errors out at runtime with ClassNotFoundException as this class was
> dropped from the Keycloak 1.7.0 API.
>
> Thanks again.
> Guy
>
> On Thu, Dec 17, 2015 at 3:35 PM, Eric Wittmann <eric.wittmann at redhat.com
> <mailto:eric.wittmann at redhat.com>> wrote:
>
>     This is absolutely possible.  Have a look through the production
>     guide and see if it helps:
>
>     http://www.apiman.io/latest/production-guide.html
>
>     If you continue to have issues let us know so that we can update the
>     guide.  We already have at least one update to make:
>
>     https://issues.jboss.org/browse/APIMAN-842
>
>     -Eric
>
>     On 12/17/2015 3:48 PM, Guy Davis wrote:
>
>         Good day,
>
>         I currently have a test instance of Wildfly 9 running both
>         Keycloak 1.5
>         and Apiman 1.1.8.  I'm using Keycloak 1.5 as Apiman makes a Keycloak
>         getTime() call somewhere that was removed in Keycloak 1.6's
>         adapters.
>
>         So I'm seeing that trying to put Keycloak and Apiman in the same
>         Wildfly
>         container is probably not a good plan going forward due to
>         incompatibilities as each project progresses.
>
>         Today, I noticed that Hawkular announced
>         <http://www.hawkular.org/blog/2015/12/16/hawkular-1.0.0.Alpha8-released.html>
>         that they now allow startup of their container with a property
>         pointing
>         to a remote Keycloak server.
>
>         Is this possible with Apiman today?  If not, is it on the
>         roadmap?  I'd
>         like to upgrade to Keycloak 1.7
>         <http://blog.keycloak.org/2015/12/keycloak-170final-released.html>
>         following
>         this approach with Keycloak, Apiman, and Hawkular all in their own
>         containers.
>
>         By the way, I'm really stoked to see the excellent integration and
>         progress being made by all these projects!  Keep up the good work.
>
>         Thanks,
>         Guy
>
>
>         _______________________________________________
>         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
>
>

From eric.wittmann at redhat.com  Mon Jan  4 11:26:15 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 4 Jan 2016 11:26:15 -0500
Subject: [Apiman-user] How to update backend implementation URL for
 published Service without changing the version
In-Reply-To: <CAG9c92J9MRSqQvUMK2ARiUmLRedt6SfVzuPZCGMG-JoqhTEeig@mail.gmail.com>
References: <CAG9c92J9MRSqQvUMK2ARiUmLRedt6SfVzuPZCGMG-JoqhTEeig@mail.gmail.com>
Message-ID: <568A9D27.2070400@redhat.com>

Hi Sanjay, thanks for the questions.

Currently there is no easy way to update the backend implementation 
endpiont URL without creating a new version of the service.

However, if this is a one-off sort of thing then you may be able to get 
it done.  It depends mostly on what configuration you are using.  But 
I'll explain based on the most recent 1.1.x release (1.1.9.Final) with 
its default configuration.

The Manager and Gateway are decoupled, resulting in the duplication of 
*some* of the data (including the endpoint URL).  So when you "publish" 
a service from the Manager, the Gateway is given information about the 
service.  This information is stored in the Gateway's "registry".  By 
default the registry implementation is elasticsearch.  So if you wanted 
to change the endpoint URL for a service, you would need to update that 
information in your Database (you did this) *and* in elasticsearch.

It's actually not that difficult to update the information in 
elasticsearch.  You'll need to find the correct record and then update 
it.  If you're using the default installation, then ES is running on 
port 19200.  If you want to change the following service:

Organization:  Example
Service ID:    MyService
Version:       1.0

Then you might do something like this:

curl -XGET 
http://localhost:19200/apiman_gateway/service/Example:MyService:1.0/_source

You could then take that JSON result, modify the bits you want to 
change, and then update it like so (as an example - please replace the 
JSON below with the JSON you get back from the GET above):

curl -XPUT 
http://localhost:19200/apiman_gateway/service/Example:MyService:1.0 -d '
{
   "endpoint" : "http://UPDATED-ENDPOINT-HERE",
   "endpointType" : "rest",
   "publicService" : true,
   "organizationId" : "Example",
   "serviceId": "MyService",
   "version" : "1.0",
   "endpointProperties": [],
   "policies":[]
}
'

Once this is done you'll have to restart apiman so that the Gateway 
picks up the changes.

Note: we are making some changes in apiman 1.2.x that will make all of 
this easier under some circumstances.  In particular, as of apiman 
1.2.0.Final you will be able to re-publish "Public" services (now called 
APIs).  So if the API is public then you can simply make changes and 
then republish those changes to the Gateway.  If the API is *not* public 
then the current semantics are the same:  you cannot make changes and 
republish because that may violate contracts that consumers have made 
with your API.

-Eric


On 12/29/2015 12:19 PM, Sanjay Melinamani wrote:
> Hi All,
> I am using APIMAN 1.1.9 and for an existing API that I have published to
> consumers, I like to change its backend implementation end point URL
> without changing the API service version.
> I updated the backend implementation URL in database table
> "service_versions". I can see the updated URL from UI but still the
> gateway is using the old implementation URL specified.
> Does it cache the implementation URL once the service is published ? Is
> there anyway I can update  the implementation URL for an existing service?
>
> Appreciate your time and help.
>
> Thanks
> Sanjay
>
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From mssanjay at gmail.com  Tue Jan  5 01:45:42 2016
From: mssanjay at gmail.com (Sanjay Melinamani)
Date: Tue, 5 Jan 2016 01:45:42 -0500
Subject: [Apiman-user] How to update backend implementation URL for
 published Service without changing the version
In-Reply-To: <568A9D27.2070400@redhat.com>
References: <CAG9c92J9MRSqQvUMK2ARiUmLRedt6SfVzuPZCGMG-JoqhTEeig@mail.gmail.com>
	<568A9D27.2070400@redhat.com>
Message-ID: <CAG9c92LdKqinw_YjK3LutiUn2+7jKcQW7DkYTd6=YsCHvzNYSQ@mail.gmail.com>

Thanks Eric for your reply! makes sense...

I tried to use the two CURL commands.

GET worked and I was able to see the end point being used.
curl -XGET
http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
{"endpoint":"http://OLD_URL
","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}



But the PUT failed as below..

curl -XPUT
http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source -d
'{"endpoint":"http://NEW_URL
","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}'

No handler found for uri [/apiman_gateway/service/prism:osa:1.0/_source]
and method [PUT]


Thanks again for your time

Sanjay


On Mon, Jan 4, 2016 at 11:26 AM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> Hi Sanjay, thanks for the questions.
>
> Currently there is no easy way to update the backend implementation
> endpiont URL without creating a new version of the service.
>
> However, if this is a one-off sort of thing then you may be able to get it
> done.  It depends mostly on what configuration you are using.  But I'll
> explain based on the most recent 1.1.x release (1.1.9.Final) with its
> default configuration.
>
> The Manager and Gateway are decoupled, resulting in the duplication of
> *some* of the data (including the endpoint URL).  So when you "publish" a
> service from the Manager, the Gateway is given information about the
> service.  This information is stored in the Gateway's "registry".  By
> default the registry implementation is elasticsearch.  So if you wanted to
> change the endpoint URL for a service, you would need to update that
> information in your Database (you did this) *and* in elasticsearch.
>
> It's actually not that difficult to update the information in
> elasticsearch.  You'll need to find the correct record and then update it.
> If you're using the default installation, then ES is running on port
> 19200.  If you want to change the following service:
>
> Organization:  Example
> Service ID:    MyService
> Version:       1.0
>
> Then you might do something like this:
>
> curl -XGET
> http://localhost:19200/apiman_gateway/service/Example:MyService:1.0/_source
>
> You could then take that JSON result, modify the bits you want to change,
> and then update it like so (as an example - please replace the JSON below
> with the JSON you get back from the GET above):
>
> curl -XPUT
> http://localhost:19200/apiman_gateway/service/Example:MyService:1.0 -d '
> {
>   "endpoint" : "http://UPDATED-ENDPOINT-HERE",
>   "endpointType" : "rest",
>   "publicService" : true,
>   "organizationId" : "Example",
>   "serviceId": "MyService",
>   "version" : "1.0",
>   "endpointProperties": [],
>   "policies":[]
> }
> '
>
> Once this is done you'll have to restart apiman so that the Gateway picks
> up the changes.
>
> Note: we are making some changes in apiman 1.2.x that will make all of
> this easier under some circumstances.  In particular, as of apiman
> 1.2.0.Final you will be able to re-publish "Public" services (now called
> APIs).  So if the API is public then you can simply make changes and then
> republish those changes to the Gateway.  If the API is *not* public then
> the current semantics are the same:  you cannot make changes and republish
> because that may violate contracts that consumers have made with your API.
>
> -Eric
>
>
>
> On 12/29/2015 12:19 PM, Sanjay Melinamani wrote:
>
>> Hi All,
>> I am using APIMAN 1.1.9 and for an existing API that I have published to
>> consumers, I like to change its backend implementation end point URL
>> without changing the API service version.
>> I updated the backend implementation URL in database table
>> "service_versions". I can see the updated URL from UI but still the
>> gateway is using the old implementation URL specified.
>> Does it cache the implementation URL once the service is published ? Is
>> there anyway I can update  the implementation URL for an existing service?
>>
>> Appreciate your time and help.
>>
>> Thanks
>> Sanjay
>>
>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> 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/20160105/c4d88083/attachment-0001.html 

From eric.wittmann at redhat.com  Tue Jan  5 08:01:19 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 5 Jan 2016 08:01:19 -0500
Subject: [Apiman-user] How to update backend implementation URL for
 published Service without changing the version
In-Reply-To: <CAG9c92LdKqinw_YjK3LutiUn2+7jKcQW7DkYTd6=YsCHvzNYSQ@mail.gmail.com>
References: <CAG9c92J9MRSqQvUMK2ARiUmLRedt6SfVzuPZCGMG-JoqhTEeig@mail.gmail.com>
	<568A9D27.2070400@redhat.com>
	<CAG9c92LdKqinw_YjK3LutiUn2+7jKcQW7DkYTd6=YsCHvzNYSQ@mail.gmail.com>
Message-ID: <568BBE9F.2000504@redhat.com>

Drop the /_source from the PUT command. :)

-Eric

On 1/5/2016 1:45 AM, Sanjay Melinamani wrote:
> Thanks Eric for your reply! makes sense...
>
> I tried to use the two CURL commands.
>
> GET worked and I was able to see the end point being used.
> curl -XGET
> http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
> {"endpoint":"http://OLD_URL","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}
>
>
>
> But the PUT failed as below..
>
> curl -XPUT
> http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source -d
> '{"endpoint":"http://NEW_URL","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}'
>
> No handler found for uri [/apiman_gateway/service/prism:osa:1.0/_source]
> and method [PUT]
>
>
> Thanks again for your time
>
> Sanjay
>
>
> On Mon, Jan 4, 2016 at 11:26 AM, Eric Wittmann <eric.wittmann at redhat.com
> <mailto:eric.wittmann at redhat.com>> wrote:
>
>     Hi Sanjay, thanks for the questions.
>
>     Currently there is no easy way to update the backend implementation
>     endpiont URL without creating a new version of the service.
>
>     However, if this is a one-off sort of thing then you may be able to
>     get it done.  It depends mostly on what configuration you are
>     using.  But I'll explain based on the most recent 1.1.x release
>     (1.1.9.Final) with its default configuration.
>
>     The Manager and Gateway are decoupled, resulting in the duplication
>     of *some* of the data (including the endpoint URL).  So when you
>     "publish" a service from the Manager, the Gateway is given
>     information about the service.  This information is stored in the
>     Gateway's "registry".  By default the registry implementation is
>     elasticsearch.  So if you wanted to change the endpoint URL for a
>     service, you would need to update that information in your Database
>     (you did this) *and* in elasticsearch.
>
>     It's actually not that difficult to update the information in
>     elasticsearch.  You'll need to find the correct record and then
>     update it.  If you're using the default installation, then ES is
>     running on port 19200.  If you want to change the following service:
>
>     Organization:  Example
>     Service ID:    MyService
>     Version:       1.0
>
>     Then you might do something like this:
>
>     curl -XGET
>     http://localhost:19200/apiman_gateway/service/Example:MyService:1.0/_source
>
>     You could then take that JSON result, modify the bits you want to
>     change, and then update it like so (as an example - please replace
>     the JSON below with the JSON you get back from the GET above):
>
>     curl -XPUT
>     http://localhost:19200/apiman_gateway/service/Example:MyService:1.0 -d '
>     {
>        "endpoint" : "http://UPDATED-ENDPOINT-HERE",
>        "endpointType" : "rest",
>        "publicService" : true,
>        "organizationId" : "Example",
>        "serviceId": "MyService",
>        "version" : "1.0",
>        "endpointProperties": [],
>        "policies":[]
>     }
>     '
>
>     Once this is done you'll have to restart apiman so that the Gateway
>     picks up the changes.
>
>     Note: we are making some changes in apiman 1.2.x that will make all
>     of this easier under some circumstances.  In particular, as of
>     apiman 1.2.0.Final you will be able to re-publish "Public" services
>     (now called APIs).  So if the API is public then you can simply make
>     changes and then republish those changes to the Gateway.  If the API
>     is *not* public then the current semantics are the same:  you cannot
>     make changes and republish because that may violate contracts that
>     consumers have made with your API.
>
>     -Eric
>
>
>
>     On 12/29/2015 12:19 PM, Sanjay Melinamani wrote:
>
>         Hi All,
>         I am using APIMAN 1.1.9 and for an existing API that I have
>         published to
>         consumers, I like to change its backend implementation end point URL
>         without changing the API service version.
>         I updated the backend implementation URL in database table
>         "service_versions". I can see the updated URL from UI but still the
>         gateway is using the old implementation URL specified.
>         Does it cache the implementation URL once the service is
>         published ? Is
>         there anyway I can update  the implementation URL for an
>         existing service?
>
>         Appreciate your time and help.
>
>         Thanks
>         Sanjay
>
>
>
>
>         _______________________________________________
>         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
>
>

From pblair at clearme.com  Tue Jan  5 11:50:50 2016
From: pblair at clearme.com (Paul Blair)
Date: Tue, 5 Jan 2016 16:50:50 +0000
Subject: [Apiman-user] Login failure message shows password in the clear
Message-ID: <D2B15E99.10F44%pblair@clearme.com>

I'm setting up a new gateway in apiman. I put in the wrong password for the configuration endpoint credentials, and this is what I got on the "New Gateway" screen:

Gateway Configuration Invalid
Something has gone wrong when testing the Gateway. Hopefully the details (below) will help you figure out what.

{"data":"<html><head><title>Error</title></head><body>Unauthorized</body></html>","status":401,"config":{"method":"PUT","transformRequest":[null],"transformResponse":[null],"data":{"name":"The Gateway","description":"Gateway to back-end services","configuration":"{\"endpoint\":\"https://[GATEWAY_URI]/apiman-gateway-api/\",\"username\":\"apimanager\",\"password\":\"api-manager$65454\"}","type":"REST"},"url":"https://[APIMAN_URI]/apiman/gateways","headers":{"Accept":"application/json, text/plain, */*","Content-Type":"application/json;charset=utf-8","Authorization":"Bearer [TOKEN]"}},"statusText":"Unauthorized"}

Granted that only a mistaken password is shown, this still doesn't seem secure, and also makes me wonder if the credential may be exposed in other similar places. Should I raise an issue on this?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160105/05c9244b/attachment.html 

From ldimaggi at redhat.com  Tue Jan  5 12:17:34 2016
From: ldimaggi at redhat.com (Leonard Dimaggio)
Date: Tue, 5 Jan 2016 12:17:34 -0500
Subject: [Apiman-user] Login failure message shows password in the clear
In-Reply-To: <D2B15E99.10F44%pblair@clearme.com>
References: <D2B15E99.10F44%pblair@clearme.com>
Message-ID: <CA+qK+9=kHL_o9VUApq+tbVMwzC38zBojCDQoMgT-nbqQY_RdMA@mail.gmail.com>

Hi Paul.

Which release of apiman are you using? Can you also attach a screenshot of
the Gateway as you are creating it?

Thanks!

On Tue, Jan 5, 2016 at 11:50 AM, Paul Blair <pblair at clearme.com> wrote:

> I'm setting up a new gateway in apiman. I put in the wrong password for
> the configuration endpoint credentials, and this is what I got on the "New
> Gateway" screen:
>
> *Gateway Configuration Invalid*
> Something has gone wrong when testing the Gateway. Hopefully the details
> (below) will help you figure out what.
>
> {"data":"<html><head><title>Error</title></head><body>Unauthorized</body></html>","status":401,"config":{"method":"PUT","transformRequest":[null],"transformResponse":[null],"data":{"name":"The Gateway","description":"Gateway to back-end services","configuration":"{\"endpoint\":\"https://[GATEWAY_URI]/apiman-gateway-api/\",\"username\":\"apimanager\",\*"password\":\"api-manager$65454\"*}","type":"REST"},"url":"https://[APIMAN_URI]/apiman/gateways","headers":{"Accept":"application/json, text/plain, */*","Content-Type":"application/json;charset=utf-8","Authorization":"Bearer [TOKEN]"}},"statusText":"Unauthorized"}
>
> Granted that only a mistaken password is shown, this still doesn't seem secure, and also makes me wonder if the credential may be exposed in other similar places. Should I raise an issue on this?
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
>


-- 
Len DiMaggio (ldimaggi at redhat.com)
JBoss by Red Hat
314 Littleton Road
Westford, MA 01886  USA
tel:  978.392.3179
cell: 781.472.9912
http://www.redhat.com
http://community.jboss.org/people/ldimaggio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160105/be35b8ed/attachment.html 

From eric.wittmann at redhat.com  Tue Jan  5 12:30:13 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 5 Jan 2016 12:30:13 -0500
Subject: [Apiman-user] Login failure message shows password in the clear
In-Reply-To: <D2B15E99.10F44%pblair@clearme.com>
References: <D2B15E99.10F44%pblair@clearme.com>
Message-ID: <568BFDA5.90209@redhat.com>

Yes please raise a JIRA issue for this.

Thanks!

-Eric

On 1/5/2016 11:50 AM, Paul Blair wrote:
> I'm setting up a new gateway in apiman. I put in the wrong password for
> the configuration endpoint credentials, and this is what I got on the
> "New Gateway" screen:
>
> *Gateway Configuration Invalid*
> Something has gone wrong when testing the Gateway. Hopefully the details
> (below) will help you figure out what.
>
> {"data":"<html><head><title>Error</title></head><body>Unauthorized</body></html>","status":401,"config":{"method":"PUT","transformRequest":[null],"transformResponse":[null],"data":{"name":"The Gateway","description":"Gateway to back-end services","configuration":"{\"endpoint\":\"https://[GATEWAY_URI]/apiman-gateway-api/\",\"username\":\"apimanager\",\*"password\":\"api-manager$65454\"*}","type":"REST"},"url":"https://[APIMAN_URI]/apiman/gateways","headers":{"Accept":"application/json, text/plain, */*","Content-Type":"application/json;charset=utf-8","Authorization":"Bearer [TOKEN]"}},"statusText":"Unauthorized"}
>
> Granted that only a mistaken password is shown, this still doesn't seem
> secure, and also makes me wonder if the credential may be exposed in
> other similar places. Should I raise an issue on this?
>
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From pblair at clearme.com  Tue Jan  5 13:23:05 2016
From: pblair at clearme.com (Paul Blair)
Date: Tue, 5 Jan 2016 18:23:05 +0000
Subject: [Apiman-user] Login failure message shows password in the clear
In-Reply-To: <568BFDA5.90209@redhat.com>
Message-ID: <D2B1741D.10F4A%pblair@clearme.com>

Ticket including screenshot is here:
https://issues.jboss.org/browse/APIMAN-876

Version is 1.1.9.Final.

On 1/5/16, 12:30 PM, "Eric Wittmann" <eric.wittmann at redhat.com> wrote:

>Yes please raise a JIRA issue for this.
>
>Thanks!
>
>-Eric
>
>On 1/5/2016 11:50 AM, Paul Blair wrote:
>> I'm setting up a new gateway in apiman. I put in the wrong password for
>> the configuration endpoint credentials, and this is what I got on the
>> "New Gateway" screen:
>>
>> *Gateway Configuration Invalid*
>> Something has gone wrong when testing the Gateway. Hopefully the details
>> (below) will help you figure out what.
>>
>> 
>>{"data":"<html><head><title>Error</title></head><body>Unauthorized</body>
>></html>","status":401,"config":{"method":"PUT","transformRequest":[null],
>>"transformResponse":[null],"data":{"name":"The
>>Gateway","description":"Gateway to back-end
>>services","configuration":"{\"endpoint\":\"https://[GATEWAY_URI]/apiman-g
>>ateway-api/\",\"username\":\"apimanager\",\*"password\":\"api-manager$654
>>54\"*}","type":"REST"},"url":"https://[APIMAN_URI]/apiman/gateways","head
>>ers":{"Accept":"application/json, text/plain,
>>*/*","Content-Type":"application/json;charset=utf-8","Authorization":"Bea
>>rer [TOKEN]"}},"statusText":"Unauthorized"}
>>
>> Granted that only a mistaken password is shown, this still doesn't seem
>> secure, and also makes me wonder if the credential may be exposed in
>> other similar places. Should I raise an issue on this?
>>
>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>



From pblair at clearme.com  Tue Jan  5 16:05:17 2016
From: pblair at clearme.com (Paul Blair)
Date: Tue, 5 Jan 2016 21:05:17 +0000
Subject: [Apiman-user] Flood of requests to Keycloak when accessing apiman UI
Message-ID: <D2B19A3B.110EB%pblair@clearme.com>

We are testing setting up a configuration where the API gateway, the API manager UI, and Keycloak are all behind their own load balancers on AWS. Keycloak is clustered using JDBC_PING.

When I try to access the apimanui URL after logging in via Keycloak, sometimes the admin page is rendered; sometimes it isn't and I have to refresh it a few times. I see a flood of requests coming into both of the Keycloak instances.

>From what I can see, after the POST to Keycloak happens, there is a sequence of 302 redirects that eventually results in a successful GET to index.html. After that, however, each request for a resource on the page ? css, javascript, fonts, whatever ? also gets a 302 and is redirected to Keycloak and redirected back before the request is successful. I'm getting the impression from what I'm seeing that the bearer token is not being received by the browser and/or submitted with requests.

Below is an example from the browser request log. All the browser requests are to various subdomains of us-west-2.elb.amazonaws.com (the load balancers); the instances of apiman and Keycloak are all on subdomains of us-west-2.compute.amazonaws.com. There is currently no session affinity set up in the load balancers for Keycloak, the apiman gateway, or the apiman management UI.

Any ideas on what might be causing this?

*** Part 1: Browser login via Keycloak and request for index.html ***

POST https://[KEYCLOAK]/auth/realms/apiman/login-actions/authenticate?code=[CODE-01]&execution=[EXECUTION-01]
  Cookie:"KC_RESTART=[RESTART-01]"
Response: 302
  Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/authenticate?code=[CODE-01]"

GET https://[KEYCLOAK]/auth/realms/apiman/login-actions/authenticate?code=[CODE-01]
  Cookie:"KC_RESTART=[RESTART-01]"
Response: 302
  Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=[CODE-02]"

GET https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=[CODE-02]
  Cookie:"KC_RESTART=[RESTART-01]"
Response: 302
  Location:"https://[API_MANAGER]/apimanui/index.html?state=[STATE-01]"
  Set-Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-01]; Version=1; Path=/auth/realms/apiman; HttpOnly
              KEYCLOAK_SESSION=apiman/[KC_SESS-01]; Version=1; Expires=Wed, 06-Jan-2016 06:09:59 GMT; Max-Age=36000; Path=/auth/realms/apiman
              KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/apiman; HttpOnly"

GET https://[API_MANAGER]/apimanui/index.html?state=[STATE-01]&code=[CODE-03]
  Cookie:"OAuth_Token_Request_State=[STATE-01]"
Response: 302
  Location:"https://[API_MANAGER]/apimanui/index.html"
  Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01]; path=/apimanui
              OAuth_Token_Request_State=; Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:00 GMT"

GET https://[API_MANAGER]/apimanui/index.html
  Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01]"
Response: 302
  Location:"https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?response_type=code&client_id=apimanui&redirect_uri=https%3A%2F%2F[API_MANAGER]%2Fapimanui%2Findex.html&state=[STATE-02]&login=true"
  Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02]; path=/apimanui
              OAuth_Token_Request_State=[STATE-02]; secure"

GET https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?response_type=code&client_id=apimanui&redirect_uri=https://[API_MANAGER]/apimanui/index.html&state=[STATE-02]&login=true
  Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-01]; KEYCLOAK_SESSION=apiman/[KC_SESS-01]"
Response: 302
  Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=[CODE-04]"
  Set-Cookie:"KC_RESTART=[RESTART-02]; Version=1; Path=/auth/realms/apiman; HttpOnly"

GET https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=[CODE-04]
  Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-01]; KEYCLOAK_SESSION=apiman/[KC_SESS-01]; KC_RESTART=[RESTART-02]"
Response: 302
  Location:"https://[API_MANAGER]/apimanui/index.html?state=[STATE-02]&code=[CODE-05]"
  Set-Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-02]; Version=1; Path=/auth/realms/apiman; HttpOnly
              KEYCLOAK_SESSION=apiman/[KC_SESS-01]; Version=1; Expires=Wed, 06-Jan-2016 06:10:00 GMT; Max-Age=36000; Path=/auth/realms/apiman
              KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/apiman; HttpOnly"

GET https://[API_MANAGER]/apimanui/index.html?state=[STATE-02]&code=[CODE-05]
  Cookie:"OAuth_Token_Request_State=[STATE-02]; JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02]"
Response: 200
  Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01]; path=/apimanui"

*** Part 2: Subsequent requests for resources (here, bootstrap-select.css) ***

GET https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstrap-select.css?cid=2015-10-23_16:50
  Cookie:"OAuth_Token_Request_State=[STATE-02]; JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01]"
Response: 302
  Location:"https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?response_type=code&client_id=apimanui&redirect_uri=https%3A%2F%2F[API_MANAGER]%2Fapimanui%2Flibs%2Fbootstrap-select%2Fbootstrap-select.css?cid%3D2015-10-23_16%3A50&state=[STATE-03]&login=true"
  Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02]; path=/apimanui
              OAuth_Token_Request_State=[STATE-03]; secure"

GET https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?response_type=code&client_id=apimanui&redirect_uri=https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstrap-select.css?cid=2015-10-23_16:50&state=[STATE-03]&login=true
  Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-03]; KEYCLOAK_SESSION=apiman/[KC_SESS-01]"
Response: 302
  Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=[CODE-06]"
  Set-Cookie:"KC_RESTART=[RESTART-03]; Version=1; Path=/auth/realms/apiman; HttpOnly"

GET https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=[CODE-06]
  Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-03]; KEYCLOAK_SESSION=apiman/[KC_SESS-01]; KC_RESTART=[RESTART-03]"
Response: 302
  Location:"https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstrap-select.css?cid=2015-10-23_16:50&state=[STATE-03]&code=[CODE-07]"
  Set-Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-04]; Version=1; Path=/auth/realms/apiman; HttpOnly
              KEYCLOAK_SESSION=apiman/[KC_SESS-01]; Version=1; Expires=Wed, 06-Jan-2016 06:10:02 GMT; Max-Age=36000; Path=/auth/realms/apiman
              KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/apiman; HttpOnly"

GET https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstrap-select.css?cid=2015-10-23_16:50&state=[STATE-03]&code=[CODE-07]
  Cookie:"OAuth_Token_Request_State=445/4a12cbb7-c16d-42a5-90c7-cf296616674a; OAuth_Token_Request_State=[STATE-02]; JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02]"
Response: 400
  Set-Cookie:"OAuth_Token_Request_State=; Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:00 GMT"

*** Meanwhile, in Keycloak ? the logs have the following segment repeatedly: ***

DEBUG [org.keycloak.protocol.oidc.utils.RedirectUtils] (default task-23) replacing relative valid redirect with: https://[API_MANAGER]/apimanui/*
DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default task-23) AUTHENTICATE
DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default task-23) authenticator: auth-cookie
DEBUG [org.keycloak.services.managers.AuthenticationManager] (default task-23) token active - active: true, issued-at: 1,452,019,157, not-before: 1,452,014,329
DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default task-23) authenticator SUCCESS: auth-cookie
DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default task-23) execution is processed

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160105/4d932d31/attachment.html 

From pblair at clearme.com  Tue Jan  5 17:53:55 2016
From: pblair at clearme.com (Paul Blair)
Date: Tue, 5 Jan 2016 22:53:55 +0000
Subject: [Apiman-user] Should the apiman-gateway-api client have direct
 access grants enabled?
Message-ID: <D2B1B3B2.111F0%pblair@clearme.com>

Today I've been having a lot of trouble creating a gateway. When I put in the gateway name, description, configuration endpoint and configuration endpoint credentials, I kept getting "Authentication to the gateway failed. Perhaps check that your credentials are correct."  I was able to log in to Keycloak using the apimanager credentials, so I know they are correct.

In the Keycloak log I see:

WARN  [org.keycloak.events] type=LOGIN_ERROR, realmId=apiman, clientId=apiman-gateway-api, userId=null, ipAddress=[x.x.x.x], error=not_allowed, grant_type=password, auth_method=oauth_credentials, client_auth_method=client-secret

I couldn't figure out why the userId should be null. The apimanager user has the apipublisher role, the apiman-gateway-api client has the proper valid redirect URI and uses the openid-connect protocol with a confidential access type, and the application configurations are using the correct client secret.

I was finally able to fix the issue by enabling direct access grants on the apiman-gateway-api client.  Should this be part of the default configuration for apiman-gateway-api in the apiman-realm.json, file, or is there something I'm misssing?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160105/d0bbe90e/attachment-0001.html 

From marc.savy at redhat.com  Wed Jan  6 04:52:32 2016
From: marc.savy at redhat.com (Marc Savy)
Date: Wed, 6 Jan 2016 09:52:32 +0000
Subject: [Apiman-user] Should the apiman-gateway-api client have direct
 access grants enabled?
In-Reply-To: <D2B1B3B2.111F0%pblair@clearme.com>
References: <D2B1B3B2.111F0%pblair@clearme.com>
Message-ID: <568CE3E0.2040904@redhat.com>

I presume you're still using the newer version of Keycloak than our
quickstarts ship with? If you recall, I mentioned you needed to enable
direct grants for the apiman-gateway-api client on newer KCs.

We're going to be moving to a newer version of Keycloak fairly soon, but
perhaps we can document that quirk in the meanwhile. However, I think we
could add the direct grants to our sample realm definition, and it
shouldn't break. I'll test it out now.

On 05/01/2016 22:53, Paul Blair wrote:
> Today I've been having a lot of trouble creating a gateway. When I put
> in the gateway name, description, configuration endpoint and
> configuration endpoint credentials, I kept getting "Authentication to
> the gateway failed. Perhaps check that your credentials are correct."  I
> was able to log in to Keycloak using the apimanager credentials, so I
> know they are correct.
>
> In the Keycloak log I see:
>
>     WARN  [org.keycloak.events] type=LOGIN_ERROR, realmId=apiman,
>     clientId=apiman-gateway-api, *userId=null*, ipAddress=[x.x.x.x],
>     error=not_allowed, grant_type=password,
>     auth_method=oauth_credentials, client_auth_method=client-secret
>
>
> I couldn't figure out why the userId should be null. The apimanager user
> has the apipublisher role, the apiman-gateway-api client has the proper
> valid redirect URI and uses the openid-connect protocol with a
> confidential access type, and the application configurations are using
> the correct client secret.
>
> I was finally able to fix the issue by enabling direct access grants on
> the apiman-gateway-api client.  Should this be part of the default
> configuration for apiman-gateway-api in the apiman-realm.json, file, or
> is there something I'm misssing?
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>


From eric.wittmann at redhat.com  Wed Jan  6 08:44:49 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Wed, 6 Jan 2016 08:44:49 -0500
Subject: [Apiman-user] Flood of requests to Keycloak when accessing
 apiman UI
In-Reply-To: <D2B19A3B.110EB%pblair@clearme.com>
References: <D2B19A3B.110EB%pblair@clearme.com>
Message-ID: <568D1A51.6040206@redhat.com>

Can you remind me what your configuration for the API Manager is?  I 
think you're deploying into Wildfly, correct?

To be honest I'm not very familiar with how the keycloak adapters work, 
so I'm guessing here.  But based on the little bit of KC integration 
code we've written for apiman I'm betting that you need to have session 
affinity enabled for the manager UI.  Otherwise there's no way for a 
given request from the browser to be authenticated without redirecting 
to the login page.

Note that I have created the following JIRA that would help with the 
flood of auth redirects:

https://issues.jboss.org/browse/APIMAN-877

But even so it likely wouldn't fix the underlying problem, which is that 
without session affinity it may take some luck for you to successfully 
log in and view the UI (since there are a few redirects happening as 
part of the login process).

As for the Gateway - you shouldn't need session affinity enabled there, 
because there is currently no redirect based authentication happening 
(e.g. we're using BASIC Auth to authenticate into the Gateway API from 
the Manager).

-Eric


On 1/5/2016 4:05 PM, Paul Blair wrote:
> We are testing setting up a configuration where the API gateway, the API
> manager UI, and Keycloak are all behind their own load balancers on AWS.
> Keycloak is clustered using JDBC_PING.
>
> When I try to access the apimanui URL after logging in via Keycloak,
> sometimes the admin page is rendered; sometimes it isn't and I have to
> refresh it a few times. I see a flood of requests coming into both of
> the Keycloak instances.
>
>  From what I can see, after the POST to Keycloak happens, there is a
> sequence of 302 redirects that eventually results in a successful GET to
> index.html. After that, however, each request for a resource on the page
> ? css, javascript, fonts, whatever ? also gets a 302 and is redirected
> to Keycloak and redirected back before the request is successful. I'm
> getting the impression from what I'm seeing that the bearer token is not
> being received by the browser and/or submitted with requests.
>
> Below is an example from the browser request log. All the browser
> requests are to various subdomains of us-west-2.elb.amazonaws.com (the
> load balancers); the instances of apiman and Keycloak are all on
> subdomains of us-west-2.compute.amazonaws.com. There is currently no
> session affinity set up in the load balancers for Keycloak, the apiman
> gateway, or the apiman management UI.
>
> Any ideas on what might be causing this?
>
> *** Part 1: Browser login via Keycloak and request for index.html ***
>
>     POST
>     https://[KEYCLOAK]/auth/realms/apiman/login-actions/authenticate?code=[CODE-01]&execution=[EXECUTION-01]
>        Cookie:"KC_RESTART=[RESTART-01]"
>     Response: 302
>
>     Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/authenticate?code=[CODE-01]"
>     GET
>     https://[KEYCLOAK]/auth/realms/apiman/login-actions/authenticate?code=[CODE-01]
>        Cookie:"KC_RESTART=[RESTART-01]"
>     Response: 302
>
>     Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=[CODE-02]"
>     GET
>     https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=[CODE-02]
>        Cookie:"KC_RESTART=[RESTART-01]"
>     Response: 302
>        Location:"https://[API_MANAGER]/apimanui/index.html?state=[STATE-01]"
>        Set-Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-01]; Version=1;
>     Path=/auth/realms/apiman; HttpOnly
>                    KEYCLOAK_SESSION=apiman/[KC_SESS-01]; Version=1;
>     Expires=Wed, 06-Jan-2016 06:09:59 GMT; Max-Age=36000;
>     Path=/auth/realms/apiman
>                    KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970
>     00:00:10 GMT; Max-Age=0; Path=/auth/realms/apiman; HttpOnly"
>
>     GET
>     https://[API_MANAGER]/apimanui/index.html?state=[STATE-01]&code=[CODE-03]
>        Cookie:"OAuth_Token_Request_State=[STATE-01]"
>     Response: 302
>        Location:"https://[API_MANAGER]/apimanui/index.html"
>        Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01]; path=/apimanui
>                    OAuth_Token_Request_State=; Max-Age=0; Expires=Thu,
>     01-Jan-1970 00:00:00 GMT"
>
>     GET https://[API_MANAGER]/apimanui/index.html
>        Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01]"
>     Response: 302
>
>     Location:"https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?response_type=code&client_id=apimanui&redirect_uri=https%3A%2F%2F[API_MANAGER]%2Fapimanui%2Findex.html&state=[STATE-02]&login=true"
>        Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02]; path=/apimanui
>                    OAuth_Token_Request_State=[STATE-02]; secure"
>
>     GET
>     https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?response_type=code&client_id=apimanui&redirect_uri=https://[API_MANAGER]/apimanui/index.html&state=[STATE-02]&login=true
>        Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-01];
>     KEYCLOAK_SESSION=apiman/[KC_SESS-01]"
>     Response: 302
>
>     Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=[CODE-04]"
>        Set-Cookie:"KC_RESTART=[RESTART-02]; Version=1;
>     Path=/auth/realms/apiman; HttpOnly"
>
>     GET
>     https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=[CODE-04]
>        Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-01];
>     KEYCLOAK_SESSION=apiman/[KC_SESS-01]; KC_RESTART=[RESTART-02]"
>     Response: 302
>
>     Location:"https://[API_MANAGER]/apimanui/index.html?state=[STATE-02]&code=[CODE-05]"
>        Set-Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-02]; Version=1;
>     Path=/auth/realms/apiman; HttpOnly
>                    KEYCLOAK_SESSION=apiman/[KC_SESS-01]; Version=1;
>     Expires=Wed, 06-Jan-2016 06:10:00 GMT; Max-Age=36000;
>     Path=/auth/realms/apiman
>                    KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970
>     00:00:10 GMT; Max-Age=0; Path=/auth/realms/apiman; HttpOnly"
>
>     GET
>     https://[API_MANAGER]/apimanui/index.html?state=[STATE-02]&code=[CODE-05]
>        Cookie:"OAuth_Token_Request_State=[STATE-02];
>     JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02]"
>     Response: 200
>        Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01]; path=/apimanui"
>
>
> *** Part 2: Subsequent requests for resources (here,
> bootstrap-select.css) ***
>
>     GET
>     https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstrap-select.css?cid=2015-10-23_16:50
>        Cookie:"OAuth_Token_Request_State=[STATE-02];
>     JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01]"
>     Response: 302
>
>     Location:"https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?response_type=code&client_id=apimanui&redirect_uri=https%3A%2F%2F[API_MANAGER]%2Fapimanui%2Flibs%2Fbootstrap-select%2Fbootstrap-select.css?cid%3D2015-10-23_16%3A50&state=[STATE-03]&login=true"
>        Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02]; path=/apimanui
>                    OAuth_Token_Request_State=[STATE-03]; secure"
>
>     GET
>     https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?response_type=code&client_id=apimanui&redirect_uri=https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstrap-select.css?cid=2015-10-23_16:50&state=[STATE-03]&login=true
>        Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-03];
>     KEYCLOAK_SESSION=apiman/[KC_SESS-01]"
>     Response: 302
>
>     Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=[CODE-06]"
>        Set-Cookie:"KC_RESTART=[RESTART-03]; Version=1;
>     Path=/auth/realms/apiman; HttpOnly"
>
>     GET
>     https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=[CODE-06]
>        Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-03];
>     KEYCLOAK_SESSION=apiman/[KC_SESS-01]; KC_RESTART=[RESTART-03]"
>     Response: 302
>
>     Location:"https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstrap-select.css?cid=2015-10-23_16:50&state=[STATE-03]&code=[CODE-07]"
>        Set-Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-04]; Version=1;
>     Path=/auth/realms/apiman; HttpOnly
>                    KEYCLOAK_SESSION=apiman/[KC_SESS-01]; Version=1;
>     Expires=Wed, 06-Jan-2016 06:10:02 GMT; Max-Age=36000;
>     Path=/auth/realms/apiman
>                    KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970
>     00:00:10 GMT; Max-Age=0; Path=/auth/realms/apiman; HttpOnly"
>
>     GET
>     https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstrap-select.css?cid=2015-10-23_16:50&state=[STATE-03]&code=[CODE-07]
>
>     Cookie:"OAuth_Token_Request_State=445/4a12cbb7-c16d-42a5-90c7-cf296616674a;
>     OAuth_Token_Request_State=[STATE-02];
>     JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02]"
>     Response: 400
>        Set-Cookie:"OAuth_Token_Request_State=; Max-Age=0; Expires=Thu,
>     01-Jan-1970 00:00:00 GMT"
>
>
> *** Meanwhile, in Keycloak ? the logs have the following segment
> repeatedly: ***
>
>     DEBUG [org.keycloak.protocol.oidc.utils.RedirectUtils] (default
>     task-23) replacing relative valid redirect with:
>     https://[API_MANAGER]/apimanui/*
>     DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default
>     task-23) AUTHENTICATE
>     DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default
>     task-23) authenticator: auth-cookie
>     DEBUG [org.keycloak.services.managers.AuthenticationManager]
>     (default task-23) token active - active: true, issued-at:
>     1,452,019,157, not-before: 1,452,014,329
>     DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default
>     task-23) authenticator SUCCESS: auth-cookie
>     DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default
>     task-23) execution is processed
>
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From mssanjay at gmail.com  Wed Jan  6 12:57:04 2016
From: mssanjay at gmail.com (Sanjay Melinamani)
Date: Wed, 6 Jan 2016 12:57:04 -0500
Subject: [Apiman-user] How to update backend implementation URL for
 published Service without changing the version
In-Reply-To: <568BBE9F.2000504@redhat.com>
References: <CAG9c92J9MRSqQvUMK2ARiUmLRedt6SfVzuPZCGMG-JoqhTEeig@mail.gmail.com>
	<568A9D27.2070400@redhat.com>
	<CAG9c92LdKqinw_YjK3LutiUn2+7jKcQW7DkYTd6=YsCHvzNYSQ@mail.gmail.com>
	<568BBE9F.2000504@redhat.com>
Message-ID: <CAG9c92J9x30cfw6dFW2qG7wD+E7NcDAwT0LZ=OJ++AnbmC0jJA@mail.gmail.com>

Thanks  a ton! Worked like a charm :)

Sanjay


On Tue, Jan 5, 2016 at 8:01 AM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> Drop the /_source from the PUT command. :)
>
> -Eric
>
> On 1/5/2016 1:45 AM, Sanjay Melinamani wrote:
>
>> Thanks Eric for your reply! makes sense...
>>
>> I tried to use the two CURL commands.
>>
>> GET worked and I was able to see the end point being used.
>> curl -XGET
>> http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
>> {"endpoint":"http://OLD_URL
>> ","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}
>>
>>
>>
>> But the PUT failed as below..
>>
>> curl -XPUT
>> http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source -d
>> '{"endpoint":"http://NEW_URL
>> ","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}'
>>
>> No handler found for uri [/apiman_gateway/service/prism:osa:1.0/_source]
>> and method [PUT]
>>
>>
>> Thanks again for your time
>>
>> Sanjay
>>
>>
>> On Mon, Jan 4, 2016 at 11:26 AM, Eric Wittmann <eric.wittmann at redhat.com
>> <mailto:eric.wittmann at redhat.com>> wrote:
>>
>>     Hi Sanjay, thanks for the questions.
>>
>>     Currently there is no easy way to update the backend implementation
>>     endpiont URL without creating a new version of the service.
>>
>>     However, if this is a one-off sort of thing then you may be able to
>>     get it done.  It depends mostly on what configuration you are
>>     using.  But I'll explain based on the most recent 1.1.x release
>>     (1.1.9.Final) with its default configuration.
>>
>>     The Manager and Gateway are decoupled, resulting in the duplication
>>     of *some* of the data (including the endpoint URL).  So when you
>>     "publish" a service from the Manager, the Gateway is given
>>     information about the service.  This information is stored in the
>>     Gateway's "registry".  By default the registry implementation is
>>     elasticsearch.  So if you wanted to change the endpoint URL for a
>>     service, you would need to update that information in your Database
>>     (you did this) *and* in elasticsearch.
>>
>>     It's actually not that difficult to update the information in
>>     elasticsearch.  You'll need to find the correct record and then
>>     update it.  If you're using the default installation, then ES is
>>     running on port 19200.  If you want to change the following service:
>>
>>     Organization:  Example
>>     Service ID:    MyService
>>     Version:       1.0
>>
>>     Then you might do something like this:
>>
>>     curl -XGET
>>
>> http://localhost:19200/apiman_gateway/service/Example:MyService:1.0/_source
>>
>>     You could then take that JSON result, modify the bits you want to
>>     change, and then update it like so (as an example - please replace
>>     the JSON below with the JSON you get back from the GET above):
>>
>>     curl -XPUT
>>     http://localhost:19200/apiman_gateway/service/Example:MyService:1.0
>> -d '
>>     {
>>        "endpoint" : "http://UPDATED-ENDPOINT-HERE",
>>        "endpointType" : "rest",
>>        "publicService" : true,
>>        "organizationId" : "Example",
>>        "serviceId": "MyService",
>>        "version" : "1.0",
>>        "endpointProperties": [],
>>        "policies":[]
>>     }
>>     '
>>
>>     Once this is done you'll have to restart apiman so that the Gateway
>>     picks up the changes.
>>
>>     Note: we are making some changes in apiman 1.2.x that will make all
>>     of this easier under some circumstances.  In particular, as of
>>     apiman 1.2.0.Final you will be able to re-publish "Public" services
>>     (now called APIs).  So if the API is public then you can simply make
>>     changes and then republish those changes to the Gateway.  If the API
>>     is *not* public then the current semantics are the same:  you cannot
>>     make changes and republish because that may violate contracts that
>>     consumers have made with your API.
>>
>>     -Eric
>>
>>
>>
>>     On 12/29/2015 12:19 PM, Sanjay Melinamani wrote:
>>
>>         Hi All,
>>         I am using APIMAN 1.1.9 and for an existing API that I have
>>         published to
>>         consumers, I like to change its backend implementation end point
>> URL
>>         without changing the API service version.
>>         I updated the backend implementation URL in database table
>>         "service_versions". I can see the updated URL from UI but still
>> the
>>         gateway is using the old implementation URL specified.
>>         Does it cache the implementation URL once the service is
>>         published ? Is
>>         there anyway I can update  the implementation URL for an
>>         existing service?
>>
>>         Appreciate your time and help.
>>
>>         Thanks
>>         Sanjay
>>
>>
>>
>>
>>         _______________________________________________
>>         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/20160106/78f43c46/attachment-0001.html 

From mssanjay at gmail.com  Thu Jan  7 02:58:02 2016
From: mssanjay at gmail.com (Sanjay Melinamani)
Date: Thu, 7 Jan 2016 02:58:02 -0500
Subject: [Apiman-user] How to update backend implementation URL for
 published Service without changing the version
In-Reply-To: <CAG9c92J9x30cfw6dFW2qG7wD+E7NcDAwT0LZ=OJ++AnbmC0jJA@mail.gmail.com>
References: <CAG9c92J9MRSqQvUMK2ARiUmLRedt6SfVzuPZCGMG-JoqhTEeig@mail.gmail.com>
	<568A9D27.2070400@redhat.com>
	<CAG9c92LdKqinw_YjK3LutiUn2+7jKcQW7DkYTd6=YsCHvzNYSQ@mail.gmail.com>
	<568BBE9F.2000504@redhat.com>
	<CAG9c92J9x30cfw6dFW2qG7wD+E7NcDAwT0LZ=OJ++AnbmC0jJA@mail.gmail.com>
Message-ID: <CAG9c92LHPHFnSr0krXAB0UXM_DxzbftSSf+Vtr7fQSb+qLArwA@mail.gmail.com>

Hi Eric,
Even after the restart, gateway is still using the OLD service
implementation URL. Do I have to rebuild the index, clear cache or do
something else??
When grepped for old URL, I can still see it in indices folder of elastic
search. I tried to clear cache and used refresh commands but did not work!

Appreciate if you can provide some more guidance here.

Thanks
Sanjay


On Wed, Jan 6, 2016 at 12:57 PM, Sanjay Melinamani <mssanjay at gmail.com>
wrote:

> Thanks  a ton! Worked like a charm :)
>
> Sanjay
>
>
> On Tue, Jan 5, 2016 at 8:01 AM, Eric Wittmann <eric.wittmann at redhat.com>
> wrote:
>
>> Drop the /_source from the PUT command. :)
>>
>> -Eric
>>
>> On 1/5/2016 1:45 AM, Sanjay Melinamani wrote:
>>
>>> Thanks Eric for your reply! makes sense...
>>>
>>> I tried to use the two CURL commands.
>>>
>>> GET worked and I was able to see the end point being used.
>>> curl -XGET
>>> http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
>>> {"endpoint":"http://OLD_URL
>>> ","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}
>>>
>>>
>>>
>>> But the PUT failed as below..
>>>
>>> curl -XPUT
>>> http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source -d
>>> '{"endpoint":"http://NEW_URL
>>> ","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}'
>>>
>>> No handler found for uri [/apiman_gateway/service/prism:osa:1.0/_source]
>>> and method [PUT]
>>>
>>>
>>> Thanks again for your time
>>>
>>> Sanjay
>>>
>>>
>>> On Mon, Jan 4, 2016 at 11:26 AM, Eric Wittmann <eric.wittmann at redhat.com
>>> <mailto:eric.wittmann at redhat.com>> wrote:
>>>
>>>     Hi Sanjay, thanks for the questions.
>>>
>>>     Currently there is no easy way to update the backend implementation
>>>     endpiont URL without creating a new version of the service.
>>>
>>>     However, if this is a one-off sort of thing then you may be able to
>>>     get it done.  It depends mostly on what configuration you are
>>>     using.  But I'll explain based on the most recent 1.1.x release
>>>     (1.1.9.Final) with its default configuration.
>>>
>>>     The Manager and Gateway are decoupled, resulting in the duplication
>>>     of *some* of the data (including the endpoint URL).  So when you
>>>     "publish" a service from the Manager, the Gateway is given
>>>     information about the service.  This information is stored in the
>>>     Gateway's "registry".  By default the registry implementation is
>>>     elasticsearch.  So if you wanted to change the endpoint URL for a
>>>     service, you would need to update that information in your Database
>>>     (you did this) *and* in elasticsearch.
>>>
>>>     It's actually not that difficult to update the information in
>>>     elasticsearch.  You'll need to find the correct record and then
>>>     update it.  If you're using the default installation, then ES is
>>>     running on port 19200.  If you want to change the following service:
>>>
>>>     Organization:  Example
>>>     Service ID:    MyService
>>>     Version:       1.0
>>>
>>>     Then you might do something like this:
>>>
>>>     curl -XGET
>>>
>>> http://localhost:19200/apiman_gateway/service/Example:MyService:1.0/_source
>>>
>>>     You could then take that JSON result, modify the bits you want to
>>>     change, and then update it like so (as an example - please replace
>>>     the JSON below with the JSON you get back from the GET above):
>>>
>>>     curl -XPUT
>>>     http://localhost:19200/apiman_gateway/service/Example:MyService:1.0
>>> -d '
>>>     {
>>>        "endpoint" : "http://UPDATED-ENDPOINT-HERE",
>>>        "endpointType" : "rest",
>>>        "publicService" : true,
>>>        "organizationId" : "Example",
>>>        "serviceId": "MyService",
>>>        "version" : "1.0",
>>>        "endpointProperties": [],
>>>        "policies":[]
>>>     }
>>>     '
>>>
>>>     Once this is done you'll have to restart apiman so that the Gateway
>>>     picks up the changes.
>>>
>>>     Note: we are making some changes in apiman 1.2.x that will make all
>>>     of this easier under some circumstances.  In particular, as of
>>>     apiman 1.2.0.Final you will be able to re-publish "Public" services
>>>     (now called APIs).  So if the API is public then you can simply make
>>>     changes and then republish those changes to the Gateway.  If the API
>>>     is *not* public then the current semantics are the same:  you cannot
>>>     make changes and republish because that may violate contracts that
>>>     consumers have made with your API.
>>>
>>>     -Eric
>>>
>>>
>>>
>>>     On 12/29/2015 12:19 PM, Sanjay Melinamani wrote:
>>>
>>>         Hi All,
>>>         I am using APIMAN 1.1.9 and for an existing API that I have
>>>         published to
>>>         consumers, I like to change its backend implementation end point
>>> URL
>>>         without changing the API service version.
>>>         I updated the backend implementation URL in database table
>>>         "service_versions". I can see the updated URL from UI but still
>>> the
>>>         gateway is using the old implementation URL specified.
>>>         Does it cache the implementation URL once the service is
>>>         published ? Is
>>>         there anyway I can update  the implementation URL for an
>>>         existing service?
>>>
>>>         Appreciate your time and help.
>>>
>>>         Thanks
>>>         Sanjay
>>>
>>>
>>>
>>>
>>>         _______________________________________________
>>>         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/20160107/330a5cd8/attachment.html 

From marc.savy at redhat.com  Thu Jan  7 06:58:10 2016
From: marc.savy at redhat.com (Marc Savy)
Date: Thu, 7 Jan 2016 11:58:10 +0000
Subject: [Apiman-user] Should the apiman-gateway-api client have direct
 access grants enabled?
In-Reply-To: <568CE3E0.2040904@redhat.com>
References: <D2B1B3B2.111F0%pblair@clearme.com> <568CE3E0.2040904@redhat.com>
Message-ID: <568E52D2.2050405@redhat.com>

I've updated the realm definition. As previously indicated, it seems to
work fine with the version of KC that ships with our quickstart set-ups,
in addition to 'fixing' newer ones.

Paul: if you could try it out that'd be great. It's a tiny change, but
it's one of those areas that could have more impact that initially
anticipated :-).

Check out the PR here - https://github.com/apiman/apiman/pull/318

On 06/01/2016 09:52, Marc Savy wrote:
> I presume you're still using the newer version of Keycloak than our
> quickstarts ship with? If you recall, I mentioned you needed to enable
> direct grants for the apiman-gateway-api client on newer KCs.
>
> We're going to be moving to a newer version of Keycloak fairly soon, but
> perhaps we can document that quirk in the meanwhile. However, I think we
> could add the direct grants to our sample realm definition, and it
> shouldn't break. I'll test it out now.
>
> On 05/01/2016 22:53, Paul Blair wrote:
>> Today I've been having a lot of trouble creating a gateway. When I put
>> in the gateway name, description, configuration endpoint and
>> configuration endpoint credentials, I kept getting "Authentication to
>> the gateway failed. Perhaps check that your credentials are correct."  I
>> was able to log in to Keycloak using the apimanager credentials, so I
>> know they are correct.
>>
>> In the Keycloak log I see:
>>
>>      WARN  [org.keycloak.events] type=LOGIN_ERROR, realmId=apiman,
>>      clientId=apiman-gateway-api, *userId=null*, ipAddress=[x.x.x.x],
>>      error=not_allowed, grant_type=password,
>>      auth_method=oauth_credentials, client_auth_method=client-secret
>>
>>
>> I couldn't figure out why the userId should be null. The apimanager user
>> has the apipublisher role, the apiman-gateway-api client has the proper
>> valid redirect URI and uses the openid-connect protocol with a
>> confidential access type, and the application configurations are using
>> the correct client secret.
>>
>> I was finally able to fix the issue by enabling direct access grants on
>> the apiman-gateway-api client.  Should this be part of the default
>> configuration for apiman-gateway-api in the apiman-realm.json, file, or
>> is there something I'm misssing?
>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>


From eric.wittmann at redhat.com  Thu Jan  7 08:08:19 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Thu, 7 Jan 2016 08:08:19 -0500
Subject: [Apiman-user] How to update backend implementation URL for
 published Service without changing the version
In-Reply-To: <CAG9c92LHPHFnSr0krXAB0UXM_DxzbftSSf+Vtr7fQSb+qLArwA@mail.gmail.com>
References: <CAG9c92J9MRSqQvUMK2ARiUmLRedt6SfVzuPZCGMG-JoqhTEeig@mail.gmail.com>
	<568A9D27.2070400@redhat.com>
	<CAG9c92LdKqinw_YjK3LutiUn2+7jKcQW7DkYTd6=YsCHvzNYSQ@mail.gmail.com>
	<568BBE9F.2000504@redhat.com>
	<CAG9c92J9x30cfw6dFW2qG7wD+E7NcDAwT0LZ=OJ++AnbmC0jJA@mail.gmail.com>
	<CAG9c92LHPHFnSr0krXAB0UXM_DxzbftSSf+Vtr7fQSb+qLArwA@mail.gmail.com>
Message-ID: <568E6343.4050502@redhat.com>

No nothing like that should be needed.  Doing that curl command is just 
like doing an UPDATE on a SQL db.  I even tried it locally (switching 
between URLs by updating that record in elastic) and didn't have any 
problems.

Did you restart apiman after the change?  Unfortunately (for this 
use-case) apiman will cache the information so that it doesn't have to 
do a lookup in ES for *every* request.

Also what happens how when you do the -XGET call?  Do you see the new data?

-Eric

On 1/7/2016 2:58 AM, Sanjay Melinamani wrote:
> Hi Eric,
> Even after the restart, gateway is still using the OLD service
> implementation URL. Do I have to rebuild the index, clear cache or do
> something else??
> When grepped for old URL, I can still see it in indices folder of
> elastic search. I tried to clear cache and used refresh commands but did
> not work!
>
> Appreciate if you can provide some more guidance here.
>
> Thanks
> Sanjay
>
>
> On Wed, Jan 6, 2016 at 12:57 PM, Sanjay Melinamani <mssanjay at gmail.com
> <mailto:mssanjay at gmail.com>> wrote:
>
>     Thanks  a ton! Worked like a charm :)
>
>     Sanjay
>
>
>     On Tue, Jan 5, 2016 at 8:01 AM, Eric Wittmann
>     <eric.wittmann at redhat.com <mailto:eric.wittmann at redhat.com>> wrote:
>
>         Drop the /_source from the PUT command. :)
>
>         -Eric
>
>         On 1/5/2016 1:45 AM, Sanjay Melinamani wrote:
>
>             Thanks Eric for your reply! makes sense...
>
>             I tried to use the two CURL commands.
>
>             GET worked and I was able to see the end point being used.
>             curl -XGET
>             http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
>             {"endpoint":"http://OLD_URL","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}
>
>
>
>             But the PUT failed as below..
>
>             curl -XPUT
>             http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
>             -d
>             '{"endpoint":"http://NEW_URL","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}'
>
>             No handler found for uri
>             [/apiman_gateway/service/prism:osa:1.0/_source]
>             and method [PUT]
>
>
>             Thanks again for your time
>
>             Sanjay
>
>
>             On Mon, Jan 4, 2016 at 11:26 AM, 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>>> wrote:
>
>                  Hi Sanjay, thanks for the questions.
>
>                  Currently there is no easy way to update the backend
>             implementation
>                  endpiont URL without creating a new version of the service.
>
>                  However, if this is a one-off sort of thing then you
>             may be able to
>                  get it done.  It depends mostly on what configuration
>             you are
>                  using.  But I'll explain based on the most recent 1.1.x
>             release
>                  (1.1.9.Final) with its default configuration.
>
>                  The Manager and Gateway are decoupled, resulting in the
>             duplication
>                  of *some* of the data (including the endpoint URL).  So
>             when you
>                  "publish" a service from the Manager, the Gateway is given
>                  information about the service.  This information is
>             stored in the
>                  Gateway's "registry".  By default the registry
>             implementation is
>                  elasticsearch.  So if you wanted to change the endpoint
>             URL for a
>                  service, you would need to update that information in
>             your Database
>                  (you did this) *and* in elasticsearch.
>
>                  It's actually not that difficult to update the
>             information in
>                  elasticsearch.  You'll need to find the correct record
>             and then
>                  update it.  If you're using the default installation,
>             then ES is
>                  running on port 19200.  If you want to change the
>             following service:
>
>                  Organization:  Example
>                  Service ID:    MyService
>                  Version:       1.0
>
>                  Then you might do something like this:
>
>                  curl -XGET
>             http://localhost:19200/apiman_gateway/service/Example:MyService:1.0/_source
>
>                  You could then take that JSON result, modify the bits
>             you want to
>                  change, and then update it like so (as an example -
>             please replace
>                  the JSON below with the JSON you get back from the GET
>             above):
>
>                  curl -XPUT
>             http://localhost:19200/apiman_gateway/service/Example:MyService:1.0
>             -d '
>                  {
>                     "endpoint" : "http://UPDATED-ENDPOINT-HERE",
>                     "endpointType" : "rest",
>                     "publicService" : true,
>                     "organizationId" : "Example",
>                     "serviceId": "MyService",
>                     "version" : "1.0",
>                     "endpointProperties": [],
>                     "policies":[]
>                  }
>                  '
>
>                  Once this is done you'll have to restart apiman so that
>             the Gateway
>                  picks up the changes.
>
>                  Note: we are making some changes in apiman 1.2.x that
>             will make all
>                  of this easier under some circumstances.  In
>             particular, as of
>                  apiman 1.2.0.Final you will be able to re-publish
>             "Public" services
>                  (now called APIs).  So if the API is public then you
>             can simply make
>                  changes and then republish those changes to the
>             Gateway.  If the API
>                  is *not* public then the current semantics are the
>             same:  you cannot
>                  make changes and republish because that may violate
>             contracts that
>                  consumers have made with your API.
>
>                  -Eric
>
>
>
>                  On 12/29/2015 12:19 PM, Sanjay Melinamani wrote:
>
>                      Hi All,
>                      I am using APIMAN 1.1.9 and for an existing API
>             that I have
>                      published to
>                      consumers, I like to change its backend
>             implementation end point URL
>                      without changing the API service version.
>                      I updated the backend implementation URL in
>             database table
>                      "service_versions". I can see the updated URL from
>             UI but still the
>                      gateway is using the old implementation URL specified.
>                      Does it cache the implementation URL once the
>             service is
>                      published ? Is
>                      there anyway I can update  the implementation URL
>             for an
>                      existing service?
>
>                      Appreciate your time and help.
>
>                      Thanks
>                      Sanjay
>
>
>
>
>                      _______________________________________________
>                      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
>
>
>
>

From pblair at clearme.com  Thu Jan  7 10:34:42 2016
From: pblair at clearme.com (Paul Blair)
Date: Thu, 7 Jan 2016 15:34:42 +0000
Subject: [Apiman-user] Flood of requests to Keycloak when accessing
 apiman UI
In-Reply-To: <568D1A51.6040206@redhat.com>
Message-ID: <D2B3EF30.11306%pblair@clearme.com>

Yes, we're deploying into Wildfly (8) in Dockers on AWS.

I tried enabling session affinity on Keycloak but we still get quite a
number of requests to Keycloak -- now they're just going to one of the
Keycloaks. I haven't enabled session affinity on the API manager yet. I'll
let you know how that turns out.

On 1/6/16, 8:44 AM, "Eric Wittmann" <eric.wittmann at redhat.com> wrote:

>Can you remind me what your configuration for the API Manager is?  I
>think you're deploying into Wildfly, correct?
>
>To be honest I'm not very familiar with how the keycloak adapters work,
>so I'm guessing here.  But based on the little bit of KC integration
>code we've written for apiman I'm betting that you need to have session
>affinity enabled for the manager UI.  Otherwise there's no way for a
>given request from the browser to be authenticated without redirecting
>to the login page.
>
>Note that I have created the following JIRA that would help with the
>flood of auth redirects:
>
>https://issues.jboss.org/browse/APIMAN-877
>
>But even so it likely wouldn't fix the underlying problem, which is that
>without session affinity it may take some luck for you to successfully
>log in and view the UI (since there are a few redirects happening as
>part of the login process).
>
>As for the Gateway - you shouldn't need session affinity enabled there,
>because there is currently no redirect based authentication happening
>(e.g. we're using BASIC Auth to authenticate into the Gateway API from
>the Manager).
>
>-Eric
>
>
>On 1/5/2016 4:05 PM, Paul Blair wrote:
>> We are testing setting up a configuration where the API gateway, the API
>> manager UI, and Keycloak are all behind their own load balancers on AWS.
>> Keycloak is clustered using JDBC_PING.
>>
>> When I try to access the apimanui URL after logging in via Keycloak,
>> sometimes the admin page is rendered; sometimes it isn't and I have to
>> refresh it a few times. I see a flood of requests coming into both of
>> the Keycloak instances.
>>
>>  From what I can see, after the POST to Keycloak happens, there is a
>> sequence of 302 redirects that eventually results in a successful GET to
>> index.html. After that, however, each request for a resource on the page
>> ? css, javascript, fonts, whatever ? also gets a 302 and is redirected
>> to Keycloak and redirected back before the request is successful. I'm
>> getting the impression from what I'm seeing that the bearer token is not
>> being received by the browser and/or submitted with requests.
>>
>> Below is an example from the browser request log. All the browser
>> requests are to various subdomains of us-west-2.elb.amazonaws.com (the
>> load balancers); the instances of apiman and Keycloak are all on
>> subdomains of us-west-2.compute.amazonaws.com. There is currently no
>> session affinity set up in the load balancers for Keycloak, the apiman
>> gateway, or the apiman management UI.
>>
>> Any ideas on what might be causing this?
>>
>> *** Part 1: Browser login via Keycloak and request for index.html ***
>>
>>     POST
>>     
>>https://[KEYCLOAK]/auth/realms/apiman/login-actions/authenticate?code=[CO
>>DE-01]&execution=[EXECUTION-01]
>>        Cookie:"KC_RESTART=[RESTART-01]"
>>     Response: 302
>>
>>     
>>Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/authenticat
>>e?code=[CODE-01]"
>>     GET
>>     
>>https://[KEYCLOAK]/auth/realms/apiman/login-actions/authenticate?code=[CO
>>DE-01]
>>        Cookie:"KC_RESTART=[RESTART-01]"
>>     Response: 302
>>
>>     
>>Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-ac
>>tion?code=[CODE-02]"
>>     GET
>>     
>>https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=
>>[CODE-02]
>>        Cookie:"KC_RESTART=[RESTART-01]"
>>     Response: 302
>>        
>>Location:"https://[API_MANAGER]/apimanui/index.html?state=[STATE-01]"
>>        Set-Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-01]; Version=1;
>>     Path=/auth/realms/apiman; HttpOnly
>>                    KEYCLOAK_SESSION=apiman/[KC_SESS-01]; Version=1;
>>     Expires=Wed, 06-Jan-2016 06:09:59 GMT; Max-Age=36000;
>>     Path=/auth/realms/apiman
>>                    KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970
>>     00:00:10 GMT; Max-Age=0; Path=/auth/realms/apiman; HttpOnly"
>>
>>     GET
>>     
>>https://[API_MANAGER]/apimanui/index.html?state=[STATE-01]&code=[CODE-03]
>>        Cookie:"OAuth_Token_Request_State=[STATE-01]"
>>     Response: 302
>>        Location:"https://[API_MANAGER]/apimanui/index.html"
>>        Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01];
>>path=/apimanui
>>                    OAuth_Token_Request_State=; Max-Age=0; Expires=Thu,
>>     01-Jan-1970 00:00:00 GMT"
>>
>>     GET https://[API_MANAGER]/apimanui/index.html
>>        Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01]"
>>     Response: 302
>>
>>     
>>Location:"https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/a
>>uth?response_type=code&client_id=apimanui&redirect_uri=https%3A%2F%2F[API
>>_MANAGER]%2Fapimanui%2Findex.html&state=[STATE-02]&login=true"
>>        Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02];
>>path=/apimanui
>>                    OAuth_Token_Request_State=[STATE-02]; secure"
>>
>>     GET
>>     
>>https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?respon
>>se_type=code&client_id=apimanui&redirect_uri=https://[API_MANAGER]/apiman
>>ui/index.html&state=[STATE-02]&login=true
>>        Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-01];
>>     KEYCLOAK_SESSION=apiman/[KC_SESS-01]"
>>     Response: 302
>>
>>     
>>Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-ac
>>tion?code=[CODE-04]"
>>        Set-Cookie:"KC_RESTART=[RESTART-02]; Version=1;
>>     Path=/auth/realms/apiman; HttpOnly"
>>
>>     GET
>>     
>>https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=
>>[CODE-04]
>>        Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-01];
>>     KEYCLOAK_SESSION=apiman/[KC_SESS-01]; KC_RESTART=[RESTART-02]"
>>     Response: 302
>>
>>     
>>Location:"https://[API_MANAGER]/apimanui/index.html?state=[STATE-02]&code
>>=[CODE-05]"
>>        Set-Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-02]; Version=1;
>>     Path=/auth/realms/apiman; HttpOnly
>>                    KEYCLOAK_SESSION=apiman/[KC_SESS-01]; Version=1;
>>     Expires=Wed, 06-Jan-2016 06:10:00 GMT; Max-Age=36000;
>>     Path=/auth/realms/apiman
>>                    KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970
>>     00:00:10 GMT; Max-Age=0; Path=/auth/realms/apiman; HttpOnly"
>>
>>     GET
>>     
>>https://[API_MANAGER]/apimanui/index.html?state=[STATE-02]&code=[CODE-05]
>>        Cookie:"OAuth_Token_Request_State=[STATE-02];
>>     JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02]"
>>     Response: 200
>>        Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01];
>>path=/apimanui"
>>
>>
>> *** Part 2: Subsequent requests for resources (here,
>> bootstrap-select.css) ***
>>
>>     GET
>>     
>>https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstrap-select.css
>>?cid=2015-10-23_16:50
>>        Cookie:"OAuth_Token_Request_State=[STATE-02];
>>     JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01]"
>>     Response: 302
>>
>>     
>>Location:"https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/a
>>uth?response_type=code&client_id=apimanui&redirect_uri=https%3A%2F%2F[API
>>_MANAGER]%2Fapimanui%2Flibs%2Fbootstrap-select%2Fbootstrap-select.css?cid
>>%3D2015-10-23_16%3A50&state=[STATE-03]&login=true"
>>        Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02];
>>path=/apimanui
>>                    OAuth_Token_Request_State=[STATE-03]; secure"
>>
>>     GET
>>     
>>https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?respon
>>se_type=code&client_id=apimanui&redirect_uri=https://[API_MANAGER]/apiman
>>ui/libs/bootstrap-select/bootstrap-select.css?cid=2015-10-23_16:50&state=
>>[STATE-03]&login=true
>>        Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-03];
>>     KEYCLOAK_SESSION=apiman/[KC_SESS-01]"
>>     Response: 302
>>
>>     
>>Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-ac
>>tion?code=[CODE-06]"
>>        Set-Cookie:"KC_RESTART=[RESTART-03]; Version=1;
>>     Path=/auth/realms/apiman; HttpOnly"
>>
>>     GET
>>     
>>https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=
>>[CODE-06]
>>        Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-03];
>>     KEYCLOAK_SESSION=apiman/[KC_SESS-01]; KC_RESTART=[RESTART-03]"
>>     Response: 302
>>
>>     
>>Location:"https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstrap-
>>select.css?cid=2015-10-23_16:50&state=[STATE-03]&code=[CODE-07]"
>>        Set-Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-04]; Version=1;
>>     Path=/auth/realms/apiman; HttpOnly
>>                    KEYCLOAK_SESSION=apiman/[KC_SESS-01]; Version=1;
>>     Expires=Wed, 06-Jan-2016 06:10:02 GMT; Max-Age=36000;
>>     Path=/auth/realms/apiman
>>                    KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970
>>     00:00:10 GMT; Max-Age=0; Path=/auth/realms/apiman; HttpOnly"
>>
>>     GET
>>     
>>https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstrap-select.css
>>?cid=2015-10-23_16:50&state=[STATE-03]&code=[CODE-07]
>>
>>     
>>Cookie:"OAuth_Token_Request_State=445/4a12cbb7-c16d-42a5-90c7-cf296616674
>>a;
>>     OAuth_Token_Request_State=[STATE-02];
>>     JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02]"
>>     Response: 400
>>        Set-Cookie:"OAuth_Token_Request_State=; Max-Age=0; Expires=Thu,
>>     01-Jan-1970 00:00:00 GMT"
>>
>>
>> *** Meanwhile, in Keycloak ? the logs have the following segment
>> repeatedly: ***
>>
>>     DEBUG [org.keycloak.protocol.oidc.utils.RedirectUtils] (default
>>     task-23) replacing relative valid redirect with:
>>     https://[API_MANAGER]/apimanui/*
>>     DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default
>>     task-23) AUTHENTICATE
>>     DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default
>>     task-23) authenticator: auth-cookie
>>     DEBUG [org.keycloak.services.managers.AuthenticationManager]
>>     (default task-23) token active - active: true, issued-at:
>>     1,452,019,157, not-before: 1,452,014,329
>>     DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default
>>     task-23) authenticator SUCCESS: auth-cookie
>>     DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default
>>     task-23) execution is processed
>>
>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>



From pblair at clearme.com  Thu Jan  7 10:38:19 2016
From: pblair at clearme.com (Paul Blair)
Date: Thu, 7 Jan 2016 15:38:19 +0000
Subject: [Apiman-user] Should the apiman-gateway-api client have direct
 access grants enabled?
In-Reply-To: <568E52D2.2050405@redhat.com>
Message-ID: <D2B3F020.1130C%pblair@clearme.com>

Thanks for that -- for various reasons I need to wait until Monday to try
it, but after I posted this I had made the change in our realm file and it
worked.

Sorry if I had asked the same question twice. I had looked at the docs but
forgotten that it had come up on the list.


On 1/7/16, 6:58 AM, "Marc Savy" <marc.savy at redhat.com> wrote:

>I've updated the realm definition. As previously indicated, it seems to
>work fine with the version of KC that ships with our quickstart set-ups,
>in addition to 'fixing' newer ones.
>
>Paul: if you could try it out that'd be great. It's a tiny change, but
>it's one of those areas that could have more impact that initially
>anticipated :-).
>
>Check out the PR here - https://github.com/apiman/apiman/pull/318
>
>On 06/01/2016 09:52, Marc Savy wrote:
>> I presume you're still using the newer version of Keycloak than our
>> quickstarts ship with? If you recall, I mentioned you needed to enable
>> direct grants for the apiman-gateway-api client on newer KCs.
>>
>> We're going to be moving to a newer version of Keycloak fairly soon, but
>> perhaps we can document that quirk in the meanwhile. However, I think we
>> could add the direct grants to our sample realm definition, and it
>> shouldn't break. I'll test it out now.
>>
>> On 05/01/2016 22:53, Paul Blair wrote:
>>> Today I've been having a lot of trouble creating a gateway. When I put
>>> in the gateway name, description, configuration endpoint and
>>> configuration endpoint credentials, I kept getting "Authentication to
>>> the gateway failed. Perhaps check that your credentials are correct."
>>>I
>>> was able to log in to Keycloak using the apimanager credentials, so I
>>> know they are correct.
>>>
>>> In the Keycloak log I see:
>>>
>>>      WARN  [org.keycloak.events] type=LOGIN_ERROR, realmId=apiman,
>>>      clientId=apiman-gateway-api, *userId=null*, ipAddress=[x.x.x.x],
>>>      error=not_allowed, grant_type=password,
>>>      auth_method=oauth_credentials, client_auth_method=client-secret
>>>
>>>
>>> I couldn't figure out why the userId should be null. The apimanager
>>>user
>>> has the apipublisher role, the apiman-gateway-api client has the proper
>>> valid redirect URI and uses the openid-connect protocol with a
>>> confidential access type, and the application configurations are using
>>> the correct client secret.
>>>
>>> I was finally able to fix the issue by enabling direct access grants on
>>> the apiman-gateway-api client.  Should this be part of the default
>>> configuration for apiman-gateway-api in the apiman-realm.json, file, or
>>> is there something I'm misssing?
>>>
>>>
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>



From eric.wittmann at redhat.com  Thu Jan  7 11:02:33 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Thu, 7 Jan 2016 11:02:33 -0500
Subject: [Apiman-user] Flood of requests to Keycloak when accessing
 apiman UI
In-Reply-To: <D2B3EF30.11306%pblair@clearme.com>
References: <D2B3EF30.11306%pblair@clearme.com>
Message-ID: <568E8C19.80402@redhat.com>

OK great, thanks.

I think session affinity on the API Manager side of things is required. 
  Without that, every request from the browser to the UI (for CSS, 
images, etc, as well as for refreshing the bearer token) will look to 
the server like a brand new unauthenticated request.

Looking forward to hearing how it goes.

-Eric

On 1/7/2016 10:34 AM, Paul Blair wrote:
> Yes, we're deploying into Wildfly (8) in Dockers on AWS.
>
> I tried enabling session affinity on Keycloak but we still get quite a
> number of requests to Keycloak -- now they're just going to one of the
> Keycloaks. I haven't enabled session affinity on the API manager yet. I'll
> let you know how that turns out.
>
> On 1/6/16, 8:44 AM, "Eric Wittmann" <eric.wittmann at redhat.com> wrote:
>
>> Can you remind me what your configuration for the API Manager is?  I
>> think you're deploying into Wildfly, correct?
>>
>> To be honest I'm not very familiar with how the keycloak adapters work,
>> so I'm guessing here.  But based on the little bit of KC integration
>> code we've written for apiman I'm betting that you need to have session
>> affinity enabled for the manager UI.  Otherwise there's no way for a
>> given request from the browser to be authenticated without redirecting
>> to the login page.
>>
>> Note that I have created the following JIRA that would help with the
>> flood of auth redirects:
>>
>> https://issues.jboss.org/browse/APIMAN-877
>>
>> But even so it likely wouldn't fix the underlying problem, which is that
>> without session affinity it may take some luck for you to successfully
>> log in and view the UI (since there are a few redirects happening as
>> part of the login process).
>>
>> As for the Gateway - you shouldn't need session affinity enabled there,
>> because there is currently no redirect based authentication happening
>> (e.g. we're using BASIC Auth to authenticate into the Gateway API from
>> the Manager).
>>
>> -Eric
>>
>>
>> On 1/5/2016 4:05 PM, Paul Blair wrote:
>>> We are testing setting up a configuration where the API gateway, the API
>>> manager UI, and Keycloak are all behind their own load balancers on AWS.
>>> Keycloak is clustered using JDBC_PING.
>>>
>>> When I try to access the apimanui URL after logging in via Keycloak,
>>> sometimes the admin page is rendered; sometimes it isn't and I have to
>>> refresh it a few times. I see a flood of requests coming into both of
>>> the Keycloak instances.
>>>
>>>   From what I can see, after the POST to Keycloak happens, there is a
>>> sequence of 302 redirects that eventually results in a successful GET to
>>> index.html. After that, however, each request for a resource on the page
>>> ? css, javascript, fonts, whatever ? also gets a 302 and is redirected
>>> to Keycloak and redirected back before the request is successful. I'm
>>> getting the impression from what I'm seeing that the bearer token is not
>>> being received by the browser and/or submitted with requests.
>>>
>>> Below is an example from the browser request log. All the browser
>>> requests are to various subdomains of us-west-2.elb.amazonaws.com (the
>>> load balancers); the instances of apiman and Keycloak are all on
>>> subdomains of us-west-2.compute.amazonaws.com. There is currently no
>>> session affinity set up in the load balancers for Keycloak, the apiman
>>> gateway, or the apiman management UI.
>>>
>>> Any ideas on what might be causing this?
>>>
>>> *** Part 1: Browser login via Keycloak and request for index.html ***
>>>
>>>      POST
>>>
>>> https://[KEYCLOAK]/auth/realms/apiman/login-actions/authenticate?code=[CO
>>> DE-01]&execution=[EXECUTION-01]
>>>         Cookie:"KC_RESTART=[RESTART-01]"
>>>      Response: 302
>>>
>>>
>>> Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/authenticat
>>> e?code=[CODE-01]"
>>>      GET
>>>
>>> https://[KEYCLOAK]/auth/realms/apiman/login-actions/authenticate?code=[CO
>>> DE-01]
>>>         Cookie:"KC_RESTART=[RESTART-01]"
>>>      Response: 302
>>>
>>>
>>> Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-ac
>>> tion?code=[CODE-02]"
>>>      GET
>>>
>>> https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=
>>> [CODE-02]
>>>         Cookie:"KC_RESTART=[RESTART-01]"
>>>      Response: 302
>>>
>>> Location:"https://[API_MANAGER]/apimanui/index.html?state=[STATE-01]"
>>>         Set-Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-01]; Version=1;
>>>      Path=/auth/realms/apiman; HttpOnly
>>>                     KEYCLOAK_SESSION=apiman/[KC_SESS-01]; Version=1;
>>>      Expires=Wed, 06-Jan-2016 06:09:59 GMT; Max-Age=36000;
>>>      Path=/auth/realms/apiman
>>>                     KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970
>>>      00:00:10 GMT; Max-Age=0; Path=/auth/realms/apiman; HttpOnly"
>>>
>>>      GET
>>>
>>> https://[API_MANAGER]/apimanui/index.html?state=[STATE-01]&code=[CODE-03]
>>>         Cookie:"OAuth_Token_Request_State=[STATE-01]"
>>>      Response: 302
>>>         Location:"https://[API_MANAGER]/apimanui/index.html"
>>>         Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01];
>>> path=/apimanui
>>>                     OAuth_Token_Request_State=; Max-Age=0; Expires=Thu,
>>>      01-Jan-1970 00:00:00 GMT"
>>>
>>>      GET https://[API_MANAGER]/apimanui/index.html
>>>         Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01]"
>>>      Response: 302
>>>
>>>
>>> Location:"https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/a
>>> uth?response_type=code&client_id=apimanui&redirect_uri=https%3A%2F%2F[API
>>> _MANAGER]%2Fapimanui%2Findex.html&state=[STATE-02]&login=true"
>>>         Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02];
>>> path=/apimanui
>>>                     OAuth_Token_Request_State=[STATE-02]; secure"
>>>
>>>      GET
>>>
>>> https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?respon
>>> se_type=code&client_id=apimanui&redirect_uri=https://[API_MANAGER]/apiman
>>> ui/index.html&state=[STATE-02]&login=true
>>>         Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-01];
>>>      KEYCLOAK_SESSION=apiman/[KC_SESS-01]"
>>>      Response: 302
>>>
>>>
>>> Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-ac
>>> tion?code=[CODE-04]"
>>>         Set-Cookie:"KC_RESTART=[RESTART-02]; Version=1;
>>>      Path=/auth/realms/apiman; HttpOnly"
>>>
>>>      GET
>>>
>>> https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=
>>> [CODE-04]
>>>         Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-01];
>>>      KEYCLOAK_SESSION=apiman/[KC_SESS-01]; KC_RESTART=[RESTART-02]"
>>>      Response: 302
>>>
>>>
>>> Location:"https://[API_MANAGER]/apimanui/index.html?state=[STATE-02]&code
>>> =[CODE-05]"
>>>         Set-Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-02]; Version=1;
>>>      Path=/auth/realms/apiman; HttpOnly
>>>                     KEYCLOAK_SESSION=apiman/[KC_SESS-01]; Version=1;
>>>      Expires=Wed, 06-Jan-2016 06:10:00 GMT; Max-Age=36000;
>>>      Path=/auth/realms/apiman
>>>                     KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970
>>>      00:00:10 GMT; Max-Age=0; Path=/auth/realms/apiman; HttpOnly"
>>>
>>>      GET
>>>
>>> https://[API_MANAGER]/apimanui/index.html?state=[STATE-02]&code=[CODE-05]
>>>         Cookie:"OAuth_Token_Request_State=[STATE-02];
>>>      JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02]"
>>>      Response: 200
>>>         Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01];
>>> path=/apimanui"
>>>
>>>
>>> *** Part 2: Subsequent requests for resources (here,
>>> bootstrap-select.css) ***
>>>
>>>      GET
>>>
>>> https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstrap-select.css
>>> ?cid=2015-10-23_16:50
>>>         Cookie:"OAuth_Token_Request_State=[STATE-02];
>>>      JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01]"
>>>      Response: 302
>>>
>>>
>>> Location:"https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/a
>>> uth?response_type=code&client_id=apimanui&redirect_uri=https%3A%2F%2F[API
>>> _MANAGER]%2Fapimanui%2Flibs%2Fbootstrap-select%2Fbootstrap-select.css?cid
>>> %3D2015-10-23_16%3A50&state=[STATE-03]&login=true"
>>>         Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02];
>>> path=/apimanui
>>>                     OAuth_Token_Request_State=[STATE-03]; secure"
>>>
>>>      GET
>>>
>>> https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?respon
>>> se_type=code&client_id=apimanui&redirect_uri=https://[API_MANAGER]/apiman
>>> ui/libs/bootstrap-select/bootstrap-select.css?cid=2015-10-23_16:50&state=
>>> [STATE-03]&login=true
>>>         Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-03];
>>>      KEYCLOAK_SESSION=apiman/[KC_SESS-01]"
>>>      Response: 302
>>>
>>>
>>> Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-ac
>>> tion?code=[CODE-06]"
>>>         Set-Cookie:"KC_RESTART=[RESTART-03]; Version=1;
>>>      Path=/auth/realms/apiman; HttpOnly"
>>>
>>>      GET
>>>
>>> https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=
>>> [CODE-06]
>>>         Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-03];
>>>      KEYCLOAK_SESSION=apiman/[KC_SESS-01]; KC_RESTART=[RESTART-03]"
>>>      Response: 302
>>>
>>>
>>> Location:"https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstrap-
>>> select.css?cid=2015-10-23_16:50&state=[STATE-03]&code=[CODE-07]"
>>>         Set-Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-04]; Version=1;
>>>      Path=/auth/realms/apiman; HttpOnly
>>>                     KEYCLOAK_SESSION=apiman/[KC_SESS-01]; Version=1;
>>>      Expires=Wed, 06-Jan-2016 06:10:02 GMT; Max-Age=36000;
>>>      Path=/auth/realms/apiman
>>>                     KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970
>>>      00:00:10 GMT; Max-Age=0; Path=/auth/realms/apiman; HttpOnly"
>>>
>>>      GET
>>>
>>> https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstrap-select.css
>>> ?cid=2015-10-23_16:50&state=[STATE-03]&code=[CODE-07]
>>>
>>>
>>> Cookie:"OAuth_Token_Request_State=445/4a12cbb7-c16d-42a5-90c7-cf296616674
>>> a;
>>>      OAuth_Token_Request_State=[STATE-02];
>>>      JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02]"
>>>      Response: 400
>>>         Set-Cookie:"OAuth_Token_Request_State=; Max-Age=0; Expires=Thu,
>>>      01-Jan-1970 00:00:00 GMT"
>>>
>>>
>>> *** Meanwhile, in Keycloak ? the logs have the following segment
>>> repeatedly: ***
>>>
>>>      DEBUG [org.keycloak.protocol.oidc.utils.RedirectUtils] (default
>>>      task-23) replacing relative valid redirect with:
>>>      https://[API_MANAGER]/apimanui/*
>>>      DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default
>>>      task-23) AUTHENTICATE
>>>      DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default
>>>      task-23) authenticator: auth-cookie
>>>      DEBUG [org.keycloak.services.managers.AuthenticationManager]
>>>      (default task-23) token active - active: true, issued-at:
>>>      1,452,019,157, not-before: 1,452,014,329
>>>      DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default
>>>      task-23) authenticator SUCCESS: auth-cookie
>>>      DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default
>>>      task-23) execution is processed
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>

From pblair at clearme.com  Mon Jan 11 10:51:23 2016
From: pblair at clearme.com (Paul Blair)
Date: Mon, 11 Jan 2016 15:51:23 +0000
Subject: [Apiman-user] Flood of requests to Keycloak when accessing
 apiman UI
In-Reply-To: <568E8C19.80402@redhat.com>
Message-ID: <D2B93941.11337%pblair@clearme.com>

When running just one instance of API manager I no longer get the flood of
requests. I think that?s the way we're going to go, and just be able to
bring up a new Docker image if that one fails for some reason -- we're not
anticipating load issues, and high-availability isn't a priority for the
admin console.

On 1/7/16, 11:02 AM, "Eric Wittmann" <eric.wittmann at redhat.com> wrote:

>OK great, thanks.
>
>I think session affinity on the API Manager side of things is required.
>  Without that, every request from the browser to the UI (for CSS,
>images, etc, as well as for refreshing the bearer token) will look to
>the server like a brand new unauthenticated request.
>
>Looking forward to hearing how it goes.
>
>-Eric
>
>On 1/7/2016 10:34 AM, Paul Blair wrote:
>> Yes, we're deploying into Wildfly (8) in Dockers on AWS.
>>
>> I tried enabling session affinity on Keycloak but we still get quite a
>> number of requests to Keycloak -- now they're just going to one of the
>> Keycloaks. I haven't enabled session affinity on the API manager yet.
>>I'll
>> let you know how that turns out.
>>
>> On 1/6/16, 8:44 AM, "Eric Wittmann" <eric.wittmann at redhat.com> wrote:
>>
>>> Can you remind me what your configuration for the API Manager is?  I
>>> think you're deploying into Wildfly, correct?
>>>
>>> To be honest I'm not very familiar with how the keycloak adapters work,
>>> so I'm guessing here.  But based on the little bit of KC integration
>>> code we've written for apiman I'm betting that you need to have session
>>> affinity enabled for the manager UI.  Otherwise there's no way for a
>>> given request from the browser to be authenticated without redirecting
>>> to the login page.
>>>
>>> Note that I have created the following JIRA that would help with the
>>> flood of auth redirects:
>>>
>>> https://issues.jboss.org/browse/APIMAN-877
>>>
>>> But even so it likely wouldn't fix the underlying problem, which is
>>>that
>>> without session affinity it may take some luck for you to successfully
>>> log in and view the UI (since there are a few redirects happening as
>>> part of the login process).
>>>
>>> As for the Gateway - you shouldn't need session affinity enabled there,
>>> because there is currently no redirect based authentication happening
>>> (e.g. we're using BASIC Auth to authenticate into the Gateway API from
>>> the Manager).
>>>
>>> -Eric
>>>
>>>
>>> On 1/5/2016 4:05 PM, Paul Blair wrote:
>>>> We are testing setting up a configuration where the API gateway, the
>>>>API
>>>> manager UI, and Keycloak are all behind their own load balancers on
>>>>AWS.
>>>> Keycloak is clustered using JDBC_PING.
>>>>
>>>> When I try to access the apimanui URL after logging in via Keycloak,
>>>> sometimes the admin page is rendered; sometimes it isn't and I have to
>>>> refresh it a few times. I see a flood of requests coming into both of
>>>> the Keycloak instances.
>>>>
>>>>   From what I can see, after the POST to Keycloak happens, there is a
>>>> sequence of 302 redirects that eventually results in a successful GET
>>>>to
>>>> index.html. After that, however, each request for a resource on the
>>>>page
>>>> ? css, javascript, fonts, whatever ? also gets a 302 and is redirected
>>>> to Keycloak and redirected back before the request is successful. I'm
>>>> getting the impression from what I'm seeing that the bearer token is
>>>>not
>>>> being received by the browser and/or submitted with requests.
>>>>
>>>> Below is an example from the browser request log. All the browser
>>>> requests are to various subdomains of us-west-2.elb.amazonaws.com (the
>>>> load balancers); the instances of apiman and Keycloak are all on
>>>> subdomains of us-west-2.compute.amazonaws.com. There is currently no
>>>> session affinity set up in the load balancers for Keycloak, the apiman
>>>> gateway, or the apiman management UI.
>>>>
>>>> Any ideas on what might be causing this?
>>>>
>>>> *** Part 1: Browser login via Keycloak and request for index.html ***
>>>>
>>>>      POST
>>>>
>>>> 
>>>>https://[KEYCLOAK]/auth/realms/apiman/login-actions/authenticate?code=[
>>>>CO
>>>> DE-01]&execution=[EXECUTION-01]
>>>>         Cookie:"KC_RESTART=[RESTART-01]"
>>>>      Response: 302
>>>>
>>>>
>>>> 
>>>>Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/authentic
>>>>at
>>>> e?code=[CODE-01]"
>>>>      GET
>>>>
>>>> 
>>>>https://[KEYCLOAK]/auth/realms/apiman/login-actions/authenticate?code=[
>>>>CO
>>>> DE-01]
>>>>         Cookie:"KC_RESTART=[RESTART-01]"
>>>>      Response: 302
>>>>
>>>>
>>>> 
>>>>Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-
>>>>ac
>>>> tion?code=[CODE-02]"
>>>>      GET
>>>>
>>>> 
>>>>https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?cod
>>>>e=
>>>> [CODE-02]
>>>>         Cookie:"KC_RESTART=[RESTART-01]"
>>>>      Response: 302
>>>>
>>>> Location:"https://[API_MANAGER]/apimanui/index.html?state=[STATE-01]"
>>>>         Set-Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-01]; Version=1;
>>>>      Path=/auth/realms/apiman; HttpOnly
>>>>                     KEYCLOAK_SESSION=apiman/[KC_SESS-01]; Version=1;
>>>>      Expires=Wed, 06-Jan-2016 06:09:59 GMT; Max-Age=36000;
>>>>      Path=/auth/realms/apiman
>>>>                     KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970
>>>>      00:00:10 GMT; Max-Age=0; Path=/auth/realms/apiman; HttpOnly"
>>>>
>>>>      GET
>>>>
>>>> 
>>>>https://[API_MANAGER]/apimanui/index.html?state=[STATE-01]&code=[CODE-0
>>>>3]
>>>>         Cookie:"OAuth_Token_Request_State=[STATE-01]"
>>>>      Response: 302
>>>>         Location:"https://[API_MANAGER]/apimanui/index.html"
>>>>         Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01];
>>>> path=/apimanui
>>>>                     OAuth_Token_Request_State=; Max-Age=0;
>>>>Expires=Thu,
>>>>      01-Jan-1970 00:00:00 GMT"
>>>>
>>>>      GET https://[API_MANAGER]/apimanui/index.html
>>>>         Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01]"
>>>>      Response: 302
>>>>
>>>>
>>>> 
>>>>Location:"https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect
>>>>/a
>>>> 
>>>>uth?response_type=code&client_id=apimanui&redirect_uri=https%3A%2F%2F[A
>>>>PI
>>>> _MANAGER]%2Fapimanui%2Findex.html&state=[STATE-02]&login=true"
>>>>         Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02];
>>>> path=/apimanui
>>>>                     OAuth_Token_Request_State=[STATE-02]; secure"
>>>>
>>>>      GET
>>>>
>>>> 
>>>>https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?resp
>>>>on
>>>> 
>>>>se_type=code&client_id=apimanui&redirect_uri=https://[API_MANAGER]/apim
>>>>an
>>>> ui/index.html&state=[STATE-02]&login=true
>>>>         Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-01];
>>>>      KEYCLOAK_SESSION=apiman/[KC_SESS-01]"
>>>>      Response: 302
>>>>
>>>>
>>>> 
>>>>Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-
>>>>ac
>>>> tion?code=[CODE-04]"
>>>>         Set-Cookie:"KC_RESTART=[RESTART-02]; Version=1;
>>>>      Path=/auth/realms/apiman; HttpOnly"
>>>>
>>>>      GET
>>>>
>>>> 
>>>>https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?cod
>>>>e=
>>>> [CODE-04]
>>>>         Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-01];
>>>>      KEYCLOAK_SESSION=apiman/[KC_SESS-01]; KC_RESTART=[RESTART-02]"
>>>>      Response: 302
>>>>
>>>>
>>>> 
>>>>Location:"https://[API_MANAGER]/apimanui/index.html?state=[STATE-02]&co
>>>>de
>>>> =[CODE-05]"
>>>>         Set-Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-02]; Version=1;
>>>>      Path=/auth/realms/apiman; HttpOnly
>>>>                     KEYCLOAK_SESSION=apiman/[KC_SESS-01]; Version=1;
>>>>      Expires=Wed, 06-Jan-2016 06:10:00 GMT; Max-Age=36000;
>>>>      Path=/auth/realms/apiman
>>>>                     KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970
>>>>      00:00:10 GMT; Max-Age=0; Path=/auth/realms/apiman; HttpOnly"
>>>>
>>>>      GET
>>>>
>>>> 
>>>>https://[API_MANAGER]/apimanui/index.html?state=[STATE-02]&code=[CODE-0
>>>>5]
>>>>         Cookie:"OAuth_Token_Request_State=[STATE-02];
>>>>      JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02]"
>>>>      Response: 200
>>>>         Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01];
>>>> path=/apimanui"
>>>>
>>>>
>>>> *** Part 2: Subsequent requests for resources (here,
>>>> bootstrap-select.css) ***
>>>>
>>>>      GET
>>>>
>>>> 
>>>>https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstrap-select.c
>>>>ss
>>>> ?cid=2015-10-23_16:50
>>>>         Cookie:"OAuth_Token_Request_State=[STATE-02];
>>>>      JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01]"
>>>>      Response: 302
>>>>
>>>>
>>>> 
>>>>Location:"https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect
>>>>/a
>>>> 
>>>>uth?response_type=code&client_id=apimanui&redirect_uri=https%3A%2F%2F[A
>>>>PI
>>>> 
>>>>_MANAGER]%2Fapimanui%2Flibs%2Fbootstrap-select%2Fbootstrap-select.css?c
>>>>id
>>>> %3D2015-10-23_16%3A50&state=[STATE-03]&login=true"
>>>>         Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02];
>>>> path=/apimanui
>>>>                     OAuth_Token_Request_State=[STATE-03]; secure"
>>>>
>>>>      GET
>>>>
>>>> 
>>>>https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?resp
>>>>on
>>>> 
>>>>se_type=code&client_id=apimanui&redirect_uri=https://[API_MANAGER]/apim
>>>>an
>>>> 
>>>>ui/libs/bootstrap-select/bootstrap-select.css?cid=2015-10-23_16:50&stat
>>>>e=
>>>> [STATE-03]&login=true
>>>>         Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-03];
>>>>      KEYCLOAK_SESSION=apiman/[KC_SESS-01]"
>>>>      Response: 302
>>>>
>>>>
>>>> 
>>>>Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-
>>>>ac
>>>> tion?code=[CODE-06]"
>>>>         Set-Cookie:"KC_RESTART=[RESTART-03]; Version=1;
>>>>      Path=/auth/realms/apiman; HttpOnly"
>>>>
>>>>      GET
>>>>
>>>> 
>>>>https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?cod
>>>>e=
>>>> [CODE-06]
>>>>         Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-03];
>>>>      KEYCLOAK_SESSION=apiman/[KC_SESS-01]; KC_RESTART=[RESTART-03]"
>>>>      Response: 302
>>>>
>>>>
>>>> 
>>>>Location:"https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstra
>>>>p-
>>>> select.css?cid=2015-10-23_16:50&state=[STATE-03]&code=[CODE-07]"
>>>>         Set-Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-04]; Version=1;
>>>>      Path=/auth/realms/apiman; HttpOnly
>>>>                     KEYCLOAK_SESSION=apiman/[KC_SESS-01]; Version=1;
>>>>      Expires=Wed, 06-Jan-2016 06:10:02 GMT; Max-Age=36000;
>>>>      Path=/auth/realms/apiman
>>>>                     KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970
>>>>      00:00:10 GMT; Max-Age=0; Path=/auth/realms/apiman; HttpOnly"
>>>>
>>>>      GET
>>>>
>>>> 
>>>>https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstrap-select.c
>>>>ss
>>>> ?cid=2015-10-23_16:50&state=[STATE-03]&code=[CODE-07]
>>>>
>>>>
>>>> 
>>>>Cookie:"OAuth_Token_Request_State=445/4a12cbb7-c16d-42a5-90c7-cf2966166
>>>>74
>>>> a;
>>>>      OAuth_Token_Request_State=[STATE-02];
>>>>      JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02]"
>>>>      Response: 400
>>>>         Set-Cookie:"OAuth_Token_Request_State=; Max-Age=0;
>>>>Expires=Thu,
>>>>      01-Jan-1970 00:00:00 GMT"
>>>>
>>>>
>>>> *** Meanwhile, in Keycloak ? the logs have the following segment
>>>> repeatedly: ***
>>>>
>>>>      DEBUG [org.keycloak.protocol.oidc.utils.RedirectUtils] (default
>>>>      task-23) replacing relative valid redirect with:
>>>>      https://[API_MANAGER]/apimanui/*
>>>>      DEBUG [org.keycloak.authentication.AuthenticationProcessor]
>>>>(default
>>>>      task-23) AUTHENTICATE
>>>>      DEBUG [org.keycloak.authentication.AuthenticationProcessor]
>>>>(default
>>>>      task-23) authenticator: auth-cookie
>>>>      DEBUG [org.keycloak.services.managers.AuthenticationManager]
>>>>      (default task-23) token active - active: true, issued-at:
>>>>      1,452,019,157, not-before: 1,452,014,329
>>>>      DEBUG [org.keycloak.authentication.AuthenticationProcessor]
>>>>(default
>>>>      task-23) authenticator SUCCESS: auth-cookie
>>>>      DEBUG [org.keycloak.authentication.AuthenticationProcessor]
>>>>(default
>>>>      task-23) execution is processed
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Apiman-user mailing list
>>>> Apiman-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>
>>



From pblair at clearme.com  Mon Jan 11 11:03:48 2016
From: pblair at clearme.com (Paul Blair)
Date: Mon, 11 Jan 2016 16:03:48 +0000
Subject: [Apiman-user] Status of 1.2.0?
Message-ID: <D2B93C91.11345%pblair@clearme.com>

I'm noticing in Github there is a 1.2.0.Final tag based on commit a commit with message "Prepared apiman for release: 1.2.0.Final". Is the release good to go if I build it from source?

(I'm getting an exception when publishing an API but unfortunately it's not giving me interesting information because of a NullPointerException in the GatewayClient's exception handler for PublishingException. I noticed that this exception handler is fixed in the 1.2 stream, so I'm eager to grab that release.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160111/3359c0d6/attachment.html 

From marc.savy at redhat.com  Mon Jan 11 11:19:16 2016
From: marc.savy at redhat.com (Marc Savy)
Date: Mon, 11 Jan 2016 16:19:16 +0000
Subject: [Apiman-user] Status of 1.2.0?
In-Reply-To: <D2B93C91.11345%pblair@clearme.com>
References: <D2B93C91.11345%pblair@clearme.com>
Message-ID: <5693D604.5060404@redhat.com>

Are you currently using 1.1.x or some other 1.2.x tag?

On 11/01/2016 16:03, Paul Blair wrote:
> I'm noticing in Github there is a 1.2.0.Final tag based on commit a
> commit with message "Prepared apiman for release: 1.2.0.Final". Is the
> release good to go if I build it from source?
>
> (I'm getting an exception when publishing an API but unfortunately it's
> not giving me interesting information because of a NullPointerException
> in the GatewayClient's exception handler for PublishingException. I
> noticed that this exception handler is fixed in the 1.2 stream, so I'm
> eager to grab that release.)
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>


From eric.wittmann at redhat.com  Mon Jan 11 11:22:08 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 11 Jan 2016 11:22:08 -0500
Subject: [Apiman-user] Flood of requests to Keycloak when accessing
 apiman UI
In-Reply-To: <D2B93941.11337%pblair@clearme.com>
References: <D2B93941.11337%pblair@clearme.com>
Message-ID: <5693D6B0.5010906@redhat.com>

OK that makes sense on multiple fronts.  I'm pretty confident now that 
the issue was session affinity.  But if you don't need multiple nodes, 
then obviously just having a single one accomplishes the same goal. :)

-Eric

On 1/11/2016 10:51 AM, Paul Blair wrote:
> When running just one instance of API manager I no longer get the flood of
> requests. I think that?s the way we're going to go, and just be able to
> bring up a new Docker image if that one fails for some reason -- we're not
> anticipating load issues, and high-availability isn't a priority for the
> admin console.
>
> On 1/7/16, 11:02 AM, "Eric Wittmann" <eric.wittmann at redhat.com> wrote:
>
>> OK great, thanks.
>>
>> I think session affinity on the API Manager side of things is required.
>>   Without that, every request from the browser to the UI (for CSS,
>> images, etc, as well as for refreshing the bearer token) will look to
>> the server like a brand new unauthenticated request.
>>
>> Looking forward to hearing how it goes.
>>
>> -Eric
>>
>> On 1/7/2016 10:34 AM, Paul Blair wrote:
>>> Yes, we're deploying into Wildfly (8) in Dockers on AWS.
>>>
>>> I tried enabling session affinity on Keycloak but we still get quite a
>>> number of requests to Keycloak -- now they're just going to one of the
>>> Keycloaks. I haven't enabled session affinity on the API manager yet.
>>> I'll
>>> let you know how that turns out.
>>>
>>> On 1/6/16, 8:44 AM, "Eric Wittmann" <eric.wittmann at redhat.com> wrote:
>>>
>>>> Can you remind me what your configuration for the API Manager is?  I
>>>> think you're deploying into Wildfly, correct?
>>>>
>>>> To be honest I'm not very familiar with how the keycloak adapters work,
>>>> so I'm guessing here.  But based on the little bit of KC integration
>>>> code we've written for apiman I'm betting that you need to have session
>>>> affinity enabled for the manager UI.  Otherwise there's no way for a
>>>> given request from the browser to be authenticated without redirecting
>>>> to the login page.
>>>>
>>>> Note that I have created the following JIRA that would help with the
>>>> flood of auth redirects:
>>>>
>>>> https://issues.jboss.org/browse/APIMAN-877
>>>>
>>>> But even so it likely wouldn't fix the underlying problem, which is
>>>> that
>>>> without session affinity it may take some luck for you to successfully
>>>> log in and view the UI (since there are a few redirects happening as
>>>> part of the login process).
>>>>
>>>> As for the Gateway - you shouldn't need session affinity enabled there,
>>>> because there is currently no redirect based authentication happening
>>>> (e.g. we're using BASIC Auth to authenticate into the Gateway API from
>>>> the Manager).
>>>>
>>>> -Eric
>>>>
>>>>
>>>> On 1/5/2016 4:05 PM, Paul Blair wrote:
>>>>> We are testing setting up a configuration where the API gateway, the
>>>>> API
>>>>> manager UI, and Keycloak are all behind their own load balancers on
>>>>> AWS.
>>>>> Keycloak is clustered using JDBC_PING.
>>>>>
>>>>> When I try to access the apimanui URL after logging in via Keycloak,
>>>>> sometimes the admin page is rendered; sometimes it isn't and I have to
>>>>> refresh it a few times. I see a flood of requests coming into both of
>>>>> the Keycloak instances.
>>>>>
>>>>>    From what I can see, after the POST to Keycloak happens, there is a
>>>>> sequence of 302 redirects that eventually results in a successful GET
>>>>> to
>>>>> index.html. After that, however, each request for a resource on the
>>>>> page
>>>>> ? css, javascript, fonts, whatever ? also gets a 302 and is redirected
>>>>> to Keycloak and redirected back before the request is successful. I'm
>>>>> getting the impression from what I'm seeing that the bearer token is
>>>>> not
>>>>> being received by the browser and/or submitted with requests.
>>>>>
>>>>> Below is an example from the browser request log. All the browser
>>>>> requests are to various subdomains of us-west-2.elb.amazonaws.com (the
>>>>> load balancers); the instances of apiman and Keycloak are all on
>>>>> subdomains of us-west-2.compute.amazonaws.com. There is currently no
>>>>> session affinity set up in the load balancers for Keycloak, the apiman
>>>>> gateway, or the apiman management UI.
>>>>>
>>>>> Any ideas on what might be causing this?
>>>>>
>>>>> *** Part 1: Browser login via Keycloak and request for index.html ***
>>>>>
>>>>>       POST
>>>>>
>>>>>
>>>>> https://[KEYCLOAK]/auth/realms/apiman/login-actions/authenticate?code=[
>>>>> CO
>>>>> DE-01]&execution=[EXECUTION-01]
>>>>>          Cookie:"KC_RESTART=[RESTART-01]"
>>>>>       Response: 302
>>>>>
>>>>>
>>>>>
>>>>> Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/authentic
>>>>> at
>>>>> e?code=[CODE-01]"
>>>>>       GET
>>>>>
>>>>>
>>>>> https://[KEYCLOAK]/auth/realms/apiman/login-actions/authenticate?code=[
>>>>> CO
>>>>> DE-01]
>>>>>          Cookie:"KC_RESTART=[RESTART-01]"
>>>>>       Response: 302
>>>>>
>>>>>
>>>>>
>>>>> Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-
>>>>> ac
>>>>> tion?code=[CODE-02]"
>>>>>       GET
>>>>>
>>>>>
>>>>> https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?cod
>>>>> e=
>>>>> [CODE-02]
>>>>>          Cookie:"KC_RESTART=[RESTART-01]"
>>>>>       Response: 302
>>>>>
>>>>> Location:"https://[API_MANAGER]/apimanui/index.html?state=[STATE-01]"
>>>>>          Set-Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-01]; Version=1;
>>>>>       Path=/auth/realms/apiman; HttpOnly
>>>>>                      KEYCLOAK_SESSION=apiman/[KC_SESS-01]; Version=1;
>>>>>       Expires=Wed, 06-Jan-2016 06:09:59 GMT; Max-Age=36000;
>>>>>       Path=/auth/realms/apiman
>>>>>                      KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970
>>>>>       00:00:10 GMT; Max-Age=0; Path=/auth/realms/apiman; HttpOnly"
>>>>>
>>>>>       GET
>>>>>
>>>>>
>>>>> https://[API_MANAGER]/apimanui/index.html?state=[STATE-01]&code=[CODE-0
>>>>> 3]
>>>>>          Cookie:"OAuth_Token_Request_State=[STATE-01]"
>>>>>       Response: 302
>>>>>          Location:"https://[API_MANAGER]/apimanui/index.html"
>>>>>          Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01];
>>>>> path=/apimanui
>>>>>                      OAuth_Token_Request_State=; Max-Age=0;
>>>>> Expires=Thu,
>>>>>       01-Jan-1970 00:00:00 GMT"
>>>>>
>>>>>       GET https://[API_MANAGER]/apimanui/index.html
>>>>>          Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01]"
>>>>>       Response: 302
>>>>>
>>>>>
>>>>>
>>>>> Location:"https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect
>>>>> /a
>>>>>
>>>>> uth?response_type=code&client_id=apimanui&redirect_uri=https%3A%2F%2F[A
>>>>> PI
>>>>> _MANAGER]%2Fapimanui%2Findex.html&state=[STATE-02]&login=true"
>>>>>          Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02];
>>>>> path=/apimanui
>>>>>                      OAuth_Token_Request_State=[STATE-02]; secure"
>>>>>
>>>>>       GET
>>>>>
>>>>>
>>>>> https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?resp
>>>>> on
>>>>>
>>>>> se_type=code&client_id=apimanui&redirect_uri=https://[API_MANAGER]/apim
>>>>> an
>>>>> ui/index.html&state=[STATE-02]&login=true
>>>>>          Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-01];
>>>>>       KEYCLOAK_SESSION=apiman/[KC_SESS-01]"
>>>>>       Response: 302
>>>>>
>>>>>
>>>>>
>>>>> Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-
>>>>> ac
>>>>> tion?code=[CODE-04]"
>>>>>          Set-Cookie:"KC_RESTART=[RESTART-02]; Version=1;
>>>>>       Path=/auth/realms/apiman; HttpOnly"
>>>>>
>>>>>       GET
>>>>>
>>>>>
>>>>> https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?cod
>>>>> e=
>>>>> [CODE-04]
>>>>>          Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-01];
>>>>>       KEYCLOAK_SESSION=apiman/[KC_SESS-01]; KC_RESTART=[RESTART-02]"
>>>>>       Response: 302
>>>>>
>>>>>
>>>>>
>>>>> Location:"https://[API_MANAGER]/apimanui/index.html?state=[STATE-02]&co
>>>>> de
>>>>> =[CODE-05]"
>>>>>          Set-Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-02]; Version=1;
>>>>>       Path=/auth/realms/apiman; HttpOnly
>>>>>                      KEYCLOAK_SESSION=apiman/[KC_SESS-01]; Version=1;
>>>>>       Expires=Wed, 06-Jan-2016 06:10:00 GMT; Max-Age=36000;
>>>>>       Path=/auth/realms/apiman
>>>>>                      KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970
>>>>>       00:00:10 GMT; Max-Age=0; Path=/auth/realms/apiman; HttpOnly"
>>>>>
>>>>>       GET
>>>>>
>>>>>
>>>>> https://[API_MANAGER]/apimanui/index.html?state=[STATE-02]&code=[CODE-0
>>>>> 5]
>>>>>          Cookie:"OAuth_Token_Request_State=[STATE-02];
>>>>>       JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02]"
>>>>>       Response: 200
>>>>>          Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01];
>>>>> path=/apimanui"
>>>>>
>>>>>
>>>>> *** Part 2: Subsequent requests for resources (here,
>>>>> bootstrap-select.css) ***
>>>>>
>>>>>       GET
>>>>>
>>>>>
>>>>> https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstrap-select.c
>>>>> ss
>>>>> ?cid=2015-10-23_16:50
>>>>>          Cookie:"OAuth_Token_Request_State=[STATE-02];
>>>>>       JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01]"
>>>>>       Response: 302
>>>>>
>>>>>
>>>>>
>>>>> Location:"https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect
>>>>> /a
>>>>>
>>>>> uth?response_type=code&client_id=apimanui&redirect_uri=https%3A%2F%2F[A
>>>>> PI
>>>>>
>>>>> _MANAGER]%2Fapimanui%2Flibs%2Fbootstrap-select%2Fbootstrap-select.css?c
>>>>> id
>>>>> %3D2015-10-23_16%3A50&state=[STATE-03]&login=true"
>>>>>          Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02];
>>>>> path=/apimanui
>>>>>                      OAuth_Token_Request_State=[STATE-03]; secure"
>>>>>
>>>>>       GET
>>>>>
>>>>>
>>>>> https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?resp
>>>>> on
>>>>>
>>>>> se_type=code&client_id=apimanui&redirect_uri=https://[API_MANAGER]/apim
>>>>> an
>>>>>
>>>>> ui/libs/bootstrap-select/bootstrap-select.css?cid=2015-10-23_16:50&stat
>>>>> e=
>>>>> [STATE-03]&login=true
>>>>>          Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-03];
>>>>>       KEYCLOAK_SESSION=apiman/[KC_SESS-01]"
>>>>>       Response: 302
>>>>>
>>>>>
>>>>>
>>>>> Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-
>>>>> ac
>>>>> tion?code=[CODE-06]"
>>>>>          Set-Cookie:"KC_RESTART=[RESTART-03]; Version=1;
>>>>>       Path=/auth/realms/apiman; HttpOnly"
>>>>>
>>>>>       GET
>>>>>
>>>>>
>>>>> https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?cod
>>>>> e=
>>>>> [CODE-06]
>>>>>          Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-03];
>>>>>       KEYCLOAK_SESSION=apiman/[KC_SESS-01]; KC_RESTART=[RESTART-03]"
>>>>>       Response: 302
>>>>>
>>>>>
>>>>>
>>>>> Location:"https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstra
>>>>> p-
>>>>> select.css?cid=2015-10-23_16:50&state=[STATE-03]&code=[CODE-07]"
>>>>>          Set-Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-04]; Version=1;
>>>>>       Path=/auth/realms/apiman; HttpOnly
>>>>>                      KEYCLOAK_SESSION=apiman/[KC_SESS-01]; Version=1;
>>>>>       Expires=Wed, 06-Jan-2016 06:10:02 GMT; Max-Age=36000;
>>>>>       Path=/auth/realms/apiman
>>>>>                      KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970
>>>>>       00:00:10 GMT; Max-Age=0; Path=/auth/realms/apiman; HttpOnly"
>>>>>
>>>>>       GET
>>>>>
>>>>>
>>>>> https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstrap-select.c
>>>>> ss
>>>>> ?cid=2015-10-23_16:50&state=[STATE-03]&code=[CODE-07]
>>>>>
>>>>>
>>>>>
>>>>> Cookie:"OAuth_Token_Request_State=445/4a12cbb7-c16d-42a5-90c7-cf2966166
>>>>> 74
>>>>> a;
>>>>>       OAuth_Token_Request_State=[STATE-02];
>>>>>       JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02]"
>>>>>       Response: 400
>>>>>          Set-Cookie:"OAuth_Token_Request_State=; Max-Age=0;
>>>>> Expires=Thu,
>>>>>       01-Jan-1970 00:00:00 GMT"
>>>>>
>>>>>
>>>>> *** Meanwhile, in Keycloak ? the logs have the following segment
>>>>> repeatedly: ***
>>>>>
>>>>>       DEBUG [org.keycloak.protocol.oidc.utils.RedirectUtils] (default
>>>>>       task-23) replacing relative valid redirect with:
>>>>>       https://[API_MANAGER]/apimanui/*
>>>>>       DEBUG [org.keycloak.authentication.AuthenticationProcessor]
>>>>> (default
>>>>>       task-23) AUTHENTICATE
>>>>>       DEBUG [org.keycloak.authentication.AuthenticationProcessor]
>>>>> (default
>>>>>       task-23) authenticator: auth-cookie
>>>>>       DEBUG [org.keycloak.services.managers.AuthenticationManager]
>>>>>       (default task-23) token active - active: true, issued-at:
>>>>>       1,452,019,157, not-before: 1,452,014,329
>>>>>       DEBUG [org.keycloak.authentication.AuthenticationProcessor]
>>>>> (default
>>>>>       task-23) authenticator SUCCESS: auth-cookie
>>>>>       DEBUG [org.keycloak.authentication.AuthenticationProcessor]
>>>>> (default
>>>>>       task-23) execution is processed
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Apiman-user mailing list
>>>>> Apiman-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>
>>>
>

From pblair at clearme.com  Mon Jan 11 11:23:28 2016
From: pblair at clearme.com (Paul Blair)
Date: Mon, 11 Jan 2016 16:23:28 +0000
Subject: [Apiman-user] Status of 1.2.0?
In-Reply-To: <5693D604.5060404@redhat.com>
Message-ID: <D2B9411E.1134A%pblair@clearme.com>

Currently using 1.1.9.Final.

On 1/11/16, 11:19 AM, "Marc Savy" <marc.savy at redhat.com> wrote:

>Are you currently using 1.1.x or some other 1.2.x tag?
>
>On 11/01/2016 16:03, Paul Blair wrote:
>> I'm noticing in Github there is a 1.2.0.Final tag based on commit a
>> commit with message "Prepared apiman for release: 1.2.0.Final". Is the
>> release good to go if I build it from source?
>>
>> (I'm getting an exception when publishing an API but unfortunately it's
>> not giving me interesting information because of a NullPointerException
>> in the GatewayClient's exception handler for PublishingException. I
>> noticed that this exception handler is fixed in the 1.2 stream, so I'm
>> eager to grab that release.)
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>



From eric.wittmann at redhat.com  Mon Jan 11 11:26:34 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 11 Jan 2016 11:26:34 -0500
Subject: [Apiman-user] Status of 1.2.0?
In-Reply-To: <D2B93C91.11345%pblair@clearme.com>
References: <D2B93C91.11345%pblair@clearme.com>
Message-ID: <5693D7BA.2060800@redhat.com>

Yes, apiman 1.2.0.Final is good to go - we're waiting on an official 
release until we have updated a few non-code related resources (project 
site, documentation, etc...).

Please note that 1.2.0.Final is a breaking change from 1.1.x.  In 
particular we have renamed a number of entities, resulting in changes to 
the storage layer *and* changes to the manager API endpoints.

If you are in production with 1.1.9.Final then you won't be able to 
easily upgrade (a procedure for doing upgrades was introduced in 1.2.x 
but only works going forward).

If you haven't gone to production yet, you can grab 1.2.0.Final but know 
that you'll basically have to start fresh until we can develop some sort 
of useful upgrade procedure specific to 1.1.9->1.2.0.

Note: you can build from source or download from here:

http://downloads.jboss.org/apiman/1.2.0.Final/apiman-distro-wildfly8-1.2.0.Final-overlay.zip

-Eric


On 1/11/2016 11:03 AM, Paul Blair wrote:
> I'm noticing in Github there is a 1.2.0.Final tag based on commit a
> commit with message "Prepared apiman for release: 1.2.0.Final". Is the
> release good to go if I build it from source?
>
> (I'm getting an exception when publishing an API but unfortunately it's
> not giving me interesting information because of a NullPointerException
> in the GatewayClient's exception handler for PublishingException. I
> noticed that this exception handler is fixed in the 1.2 stream, so I'm
> eager to grab that release.)
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From marc.savy at redhat.com  Mon Jan 11 11:27:02 2016
From: marc.savy at redhat.com (Marc Savy)
Date: Mon, 11 Jan 2016 16:27:02 +0000
Subject: [Apiman-user] Status of 1.2.0?
In-Reply-To: <D2B9411E.1134A%pblair@clearme.com>
References: <5693D604.5060404@redhat.com> <D2B9411E.1134A%pblair@clearme.com>
Message-ID: <5693D7D6.1040701@redhat.com>

The short answer is that 1.2.0.Final is good to go: We haven't released because we're updating the docs (well spotted!).

The longer answer is that Eric did some refactoring to change 'Service' => 'API' and 'Application' => 'Client App'. This changes various URIs, object names, etc, around apiman, which is likely to require some refactoring in your scripts.

Regards,
Marc

On 11/01/2016 16:23, Paul Blair wrote:
> Currently using 1.1.9.Final.
>
> On 1/11/16, 11:19 AM, "Marc Savy" <marc.savy at redhat.com> wrote:
>
> > Are you currently using 1.1.x or some other 1.2.x tag?
> >
> > On 11/01/2016 16:03, Paul Blair wrote:
> >> I'm noticing in Github there is a 1.2.0.Final tag based on commit a
> >> commit with message "Prepared apiman for release: 1.2.0.Final". Is the
> >> release good to go if I build it from source?
> >>
> >> (I'm getting an exception when publishing an API but unfortunately it's
> >> not giving me interesting information because of a NullPointerException
> >> in the GatewayClient's exception handler for PublishingException. I
> >> noticed that this exception handler is fixed in the 1.2 stream, so I'm
> >> eager to grab that release.)
> >>
> >>
> >> _______________________________________________
> >> Apiman-user mailing list
> >> Apiman-user at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/apiman-user
> >>
> >
>


From pblair at clearme.com  Mon Jan 11 17:13:13 2016
From: pblair at clearme.com (Paul Blair)
Date: Mon, 11 Jan 2016 22:13:13 +0000
Subject: [Apiman-user] apiman-gateway.public-endpoint property
Message-ID: <D2B99326.11360%pblair@clearme.com>

The Production Guide mentions that one should set the API Gateway public endpoint using the apiman-gateway.public-endpoint property. Since I see it in the Wildfly8Platform.java on 1.2.0.Final I'm assuming this is still operative for the new release.

Question: Is this property needed for the API Manager, or just for the API Gateway?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160111/23c29987/attachment.html 

From ton at finalist.nl  Tue Jan 12 05:07:34 2016
From: ton at finalist.nl (Ton Swieb)
Date: Tue, 12 Jan 2016 11:07:34 +0100
Subject: [Apiman-user] HTTP request/response logging from the Apiman gateway
	to back-end services
Message-ID: <CAJJ5CnQkGtyf2ayJ016SXG_5dT3ggqgJ=apqLkc2NLoggfJvHg@mail.gmail.com>

Hi,

I would like to see the HTTP request/response logging between the Apiman
gateway and the back-end services.

Is this possible in Apiman? If so, how can I activate it?

I already tried enabling the RequestDumpHandler in Undertow, but that only
logs the inbound HTTP request/response to the Apiman gateway. So the
communication between the API client and the API gateway, but I would like
to see the outbound HTTP request/response logging.

Regards,

Ton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160112/38035308/attachment.html 

From eric.wittmann at redhat.com  Tue Jan 12 08:55:04 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 12 Jan 2016 08:55:04 -0500
Subject: [Apiman-user] apiman-gateway.public-endpoint property
In-Reply-To: <D2B99326.11360%pblair@clearme.com>
References: <D2B99326.11360%pblair@clearme.com>
Message-ID: <569505B8.1010402@redhat.com>

That property should still apply in 1.2.x - it's needed because the 
Gateway is responsible for reporting its own base location.  This base 
location is used to figure out a "real" URL to use when invoking managed 
APIs.  Since often times the app server doesn't know what its external 
endpoint is (often due to a load balancer or firewall) it usually needs 
to be configured in the properties file.

Anyway, that property is only relevant for the Gateway.

-Eric

On 1/11/2016 5:13 PM, Paul Blair wrote:
> The Production Guide mentions that one should set the API Gateway public
> endpoint using the apiman-gateway.public-endpoint property. Since I see
> it in the Wildfly8Platform.java on 1.2.0.Final I'm assuming this is
> still operative for the new release.
>
> Question: Is this property needed for the API Manager, or just for the
> API Gateway?
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From jstrathern at gmail.com  Mon Jan 11 18:08:28 2016
From: jstrathern at gmail.com (Joe Strathern)
Date: Mon, 11 Jan 2016 16:08:28 -0700
Subject: [Apiman-user] Cannot publish Service with Basic Auth API Security
Message-ID: <CA+AnJVA+5MjWMt3+wofDwNpSWzA_JRthc_4jukcjA+vojB-ArQ@mail.gmail.com>

Hello APIMan Community,

I am trying to create and publish a service within APIMan that is secured
by basic authentication, however i am encountering errors whenever i set
the Implementation to Basic Auth and then try to publish.

I am currently using APIMan 1.1.9 within Wildfly 8.2.0.Final
The Service will publish without issues if i set the Implementation to
None, however as soon as i set it to BASIC (with the correct username/pass)
I get a Server Error 500 page with the following stack trace:

io.apiman.manager.api.rest.contract.exceptions.ActionException: Failed
to publish service.
	at io.apiman.manager.api.rest.impl.util.ExceptionFactory.actionException(ExceptionFactory.java:308)
	at io.apiman.manager.api.rest.impl.ActionResourceImpl.publishService(ActionResourceImpl.java:201)
	at io.apiman.manager.api.rest.impl.ActionResourceImpl.performAction(ActionResourceImpl.java:103)
	at io.apiman.manager.api.rest.impl.ActionResourceImpl$Proxy$_$$_WeldClientProxy.performAction(Unknown
Source)
	at sun.reflect.GeneratedMethodAccessor157.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
	at io.apiman.common.servlet.RootResourceFilter.doFilter(RootResourceFilter.java:59)
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
	at io.apiman.manager.api.war.TransactionWatchdogFilter.doFilter(TransactionWatchdogFilter.java:57)
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
	at io.apiman.manager.api.security.impl.DefaultSecurityContextFilter.doFilter(DefaultSecurityContextFilter.java:56)
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
	at io.apiman.common.servlet.DisableCachingFilter.doFilter(DisableCachingFilter.java:59)
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
	at io.apiman.common.servlet.ApimanCorsFilter.doFilter(ApimanCorsFilter.java:71)
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
	at io.apiman.common.servlet.LocaleFilter.doFilter(LocaleFilter.java:61)
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handleRequest(UndertowAuthenticatedActionsHandler.java:66)
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63)
	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261)
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: io.apiman.gateway.engine.beans.exceptions.PublishingException
	at io.apiman.manager.api.gateway.rest.GatewayClient.readPublishingException(GatewayClient.java:273)
	at io.apiman.manager.api.gateway.rest.GatewayClient.publish(GatewayClient.java:216)
	at io.apiman.manager.api.gateway.rest.RestGatewayLink.publishService(RestGatewayLink.java:162)
	at io.apiman.manager.api.rest.impl.ActionResourceImpl.publishService(ActionResourceImpl.java:189)
	... 66 more
Caused by: java.lang.NullPointerException
	at java.lang.Throwable.setStackTrace(Throwable.java:864)
	at io.apiman.manager.api.gateway.rest.GatewayClient.readPublishingException(GatewayClient.java:271)
	... 69 more


If anyone has seen this before and has a possible workaround/solution,
please let me know.

Thanks,
Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160111/4366f8a1/attachment-0001.html 

From eric.wittmann at redhat.com  Tue Jan 12 08:58:22 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 12 Jan 2016 08:58:22 -0500
Subject: [Apiman-user] HTTP request/response logging from the Apiman
 gateway to back-end services
In-Reply-To: <CAJJ5CnQkGtyf2ayJ016SXG_5dT3ggqgJ=apqLkc2NLoggfJvHg@mail.gmail.com>
References: <CAJJ5CnQkGtyf2ayJ016SXG_5dT3ggqgJ=apqLkc2NLoggfJvHg@mail.gmail.com>
Message-ID: <5695067E.9070904@redhat.com>

We don't currently have a feature to log the back-end request/response. 
  I'd love it if you would open a feature request ticket in JIRA for 
that (seems like a nice thing to have).

In the short term you could implement a custom policy that would Sys.out 
the ServiceRequest and ServiceResponse objects (note: in 1.2.x these are 
called ApiRequest and ApiResponse).  If you do this, make sure to put 
that policy *last* in the chain.

-Eric

On 1/12/2016 5:07 AM, Ton Swieb wrote:
> Hi,
>
> I would like to see the HTTP request/response logging between the Apiman
> gateway and the back-end services.
>
> Is this possible in Apiman? If so, how can I activate it?
>
> I already tried enabling the RequestDumpHandler in Undertow, but that
> only logs the inbound HTTP request/response to the Apiman gateway. So
> the communication between the API client and the API gateway, but I
> would like to see the outbound HTTP request/response logging.
>
> Regards,
>
> Ton
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From eric.wittmann at redhat.com  Tue Jan 12 09:04:01 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 12 Jan 2016 09:04:01 -0500
Subject: [Apiman-user] Cannot publish Service with Basic Auth API
	Security
In-Reply-To: <CA+AnJVA+5MjWMt3+wofDwNpSWzA_JRthc_4jukcjA+vojB-ArQ@mail.gmail.com>
References: <CA+AnJVA+5MjWMt3+wofDwNpSWzA_JRthc_4jukcjA+vojB-ArQ@mail.gmail.com>
Message-ID: <569507D1.1090302@redhat.com>

Hi Joe - I think you're running into a bug in 1.1.9.Final that is 
unfortunately masking the real publishing error. :(

We have a couple of options here:

1) Try to get a 1.1.10.Final released that fixes the problem (which 
would at least let us see why publishing was failing)
2) Try to debug the reason for the failure by attaching a java debugger 
to a running apiman
3) Download the latest version 1.2.0.Final which I believe fixes the NPE 
problem

Any of those options sound reasonable?  Note that if you install 
1.2.0.Final you'll need to reconfigure all your APIs again from scratch. 
  We don't yet have a migration/upgrade path from 1.1 to 1.2.

-Eric

On 1/11/2016 6:08 PM, Joe Strathern wrote:
> Hello APIMan Community,
>
> I am trying to create and publish a service within APIMan that is
> secured by basic authentication, however i am encountering errors
> whenever i set the Implementation to Basic Auth and then try to publish.
>
> I am currently using APIMan 1.1.9 within Wildfly 8.2.0.Final
> The Service will publish without issues if i set the Implementation to
> None, however as soon as i set it to BASIC (with the correct
> username/pass) I get a Server Error 500 page with the following stack trace:
>
> io.apiman.manager.api.rest.contract.exceptions.ActionException: Failed to publish service.
> 	at io.apiman.manager.api.rest.impl.util.ExceptionFactory.actionException(ExceptionFactory.java:308)
> 	at io.apiman.manager.api.rest.impl.ActionResourceImpl.publishService(ActionResourceImpl.java:201)
> 	at io.apiman.manager.api.rest.impl.ActionResourceImpl.performAction(ActionResourceImpl.java:103)
> 	at io.apiman.manager.api.rest.impl.ActionResourceImpl$Proxy$_$$_WeldClientProxy.performAction(Unknown Source)
> 	at sun.reflect.GeneratedMethodAccessor157.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296)
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237)
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
> 	at io.apiman.common.servlet.RootResourceFilter.doFilter(RootResourceFilter.java:59)
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> 	at io.apiman.manager.api.war.TransactionWatchdogFilter.doFilter(TransactionWatchdogFilter.java:57)
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> 	at io.apiman.manager.api.security.impl.DefaultSecurityContextFilter.doFilter(DefaultSecurityContextFilter.java:56)
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> 	at io.apiman.common.servlet.DisableCachingFilter.doFilter(DisableCachingFilter.java:59)
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> 	at io.apiman.common.servlet.ApimanCorsFilter.doFilter(ApimanCorsFilter.java:71)
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> 	at io.apiman.common.servlet.LocaleFilter.doFilter(LocaleFilter.java:61)
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handleRequest(UndertowAuthenticatedActionsHandler.java:66)
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: io.apiman.gateway.engine.beans.exceptions.PublishingException
> 	at io.apiman.manager.api.gateway.rest.GatewayClient.readPublishingException(GatewayClient.java:273)
> 	at io.apiman.manager.api.gateway.rest.GatewayClient.publish(GatewayClient.java:216)
> 	at io.apiman.manager.api.gateway.rest.RestGatewayLink.publishService(RestGatewayLink.java:162)
> 	at io.apiman.manager.api.rest.impl.ActionResourceImpl.publishService(ActionResourceImpl.java:189)
> 	... 66 more
> Caused by: java.lang.NullPointerException
> 	at java.lang.Throwable.setStackTrace(Throwable.java:864)
> 	at io.apiman.manager.api.gateway.rest.GatewayClient.readPublishingException(GatewayClient.java:271)
> 	... 69 more
>
>
> If anyone has seen this before and has a possible workaround/solution,
> please let me know.
>
> Thanks,
> Joe
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From pblair at clearme.com  Tue Jan 12 10:07:14 2016
From: pblair at clearme.com (Paul Blair)
Date: Tue, 12 Jan 2016 15:07:14 +0000
Subject: [Apiman-user] Cannot publish Service with Basic Auth API
	Security
In-Reply-To: <569507D1.1090302@redhat.com>
Message-ID: <D2BA7ECE.11374%pblair@clearme.com>

I was just dealing with the same problem, which is why I upgraded to 1.2.0.

After upgrading, I found that the exception was caused by the publisher
trying to publish to the wrong URI, because the gateway wasn't accessible
on the URI that is specified in the gateway setup. This doesn't sound like
the problem you're having, though, because you seem to be able to publish
ok before you change authentication.

With regard to upgrading to 1.2.0 -- the DDL changed, so I wound up
tearing down my apiman database and re-running the DDL; if you are in
production and need to upgrade this could be trickier because I believe
you'll need to create a diff script yourself. I also needed to bring in
the changes to apiman.properties and apiman-realm.json.


On 1/12/16, 9:04 AM, "Eric Wittmann" <eric.wittmann at redhat.com> wrote:

>Hi Joe - I think you're running into a bug in 1.1.9.Final that is
>unfortunately masking the real publishing error. :(
>
>We have a couple of options here:
>
>1) Try to get a 1.1.10.Final released that fixes the problem (which
>would at least let us see why publishing was failing)
>2) Try to debug the reason for the failure by attaching a java debugger
>to a running apiman
>3) Download the latest version 1.2.0.Final which I believe fixes the NPE
>problem
>
>Any of those options sound reasonable?  Note that if you install
>1.2.0.Final you'll need to reconfigure all your APIs again from scratch.
>  We don't yet have a migration/upgrade path from 1.1 to 1.2.
>
>-Eric
>
>On 1/11/2016 6:08 PM, Joe Strathern wrote:
>> Hello APIMan Community,
>>
>> I am trying to create and publish a service within APIMan that is
>> secured by basic authentication, however i am encountering errors
>> whenever i set the Implementation to Basic Auth and then try to publish.
>>
>> I am currently using APIMan 1.1.9 within Wildfly 8.2.0.Final
>> The Service will publish without issues if i set the Implementation to
>> None, however as soon as i set it to BASIC (with the correct
>> username/pass) I get a Server Error 500 page with the following stack
>>trace:
>>
>> io.apiman.manager.api.rest.contract.exceptions.ActionException: Failed
>>to publish service.
>>     at 
>>io.apiman.manager.api.rest.impl.util.ExceptionFactory.actionException(Exc
>>eptionFactory.java:308)
>>     at 
>>io.apiman.manager.api.rest.impl.ActionResourceImpl.publishService(ActionR
>>esourceImpl.java:201)
>>     at 
>>io.apiman.manager.api.rest.impl.ActionResourceImpl.performAction(ActionRe
>>sourceImpl.java:103)
>>     at 
>>io.apiman.manager.api.rest.impl.ActionResourceImpl$Proxy$_$$_WeldClientPr
>>oxy.performAction(Unknown Source)
>>     at sun.reflect.GeneratedMethodAccessor157.invoke(Unknown Source)
>>     at 
>>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI
>>mpl.java:43)
>>     at java.lang.reflect.Method.invoke(Method.java:497)
>>     at 
>>org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java
>>:137)
>>     at 
>>org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMeth
>>odInvoker.java:296)
>>     at 
>>org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoke
>>r.java:250)
>>     at 
>>org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoke
>>r.java:237)
>>     at 
>>org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatche
>>r.java:356)
>>     at 
>>org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatche
>>r.java:179)
>>     at 
>>org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.serv
>>ice(ServletContainerDispatcher.java:220)
>>     at 
>>org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(H
>>ttpServletDispatcher.java:56)
>>     at 
>>org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(H
>>ttpServletDispatcher.java:51)
>>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>     at 
>>io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.
>>java:85)
>>     at 
>>io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(Filte
>>rHandler.java:130)
>>     at 
>>io.apiman.common.servlet.RootResourceFilter.doFilter(RootResourceFilter.j
>>ava:59)
>>     at 
>>io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>     at 
>>io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(Filte
>>rHandler.java:132)
>>     at 
>>io.apiman.manager.api.war.TransactionWatchdogFilter.doFilter(TransactionW
>>atchdogFilter.java:57)
>>     at 
>>io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>     at 
>>io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(Filte
>>rHandler.java:132)
>>     at 
>>io.apiman.manager.api.security.impl.DefaultSecurityContextFilter.doFilter
>>(DefaultSecurityContextFilter.java:56)
>>     at 
>>io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>     at 
>>io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(Filte
>>rHandler.java:132)
>>     at 
>>io.apiman.common.servlet.DisableCachingFilter.doFilter(DisableCachingFilt
>>er.java:59)
>>     at 
>>io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>     at 
>>io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(Filte
>>rHandler.java:132)
>>     at 
>>io.apiman.common.servlet.ApimanCorsFilter.doFilter(ApimanCorsFilter.java:
>>71)
>>     at 
>>io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>     at 
>>io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(Filte
>>rHandler.java:132)
>>     at 
>>io.apiman.common.servlet.LocaleFilter.doFilter(LocaleFilter.java:61)
>>     at 
>>io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>     at 
>>io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(Filte
>>rHandler.java:132)
>>     at 
>>io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.ja
>>va:85)
>>     at 
>>io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRe
>>quest(ServletSecurityRoleHandler.java:61)
>>     at 
>>io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(Serv
>>letDispatchingHandler.java:36)
>>     at 
>>org.wildfly.extension.undertow.security.SecurityContextAssociationHandler
>>.handleRequest(SecurityContextAssociationHandler.java:78)
>>     at 
>>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl
>>er.java:43)
>>     at 
>>org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handle
>>Request(UndertowAuthenticatedActionsHandler.java:66)
>>     at 
>>io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.ha
>>ndleRequest(SSLInformationAssociationHandler.java:131)
>>     at 
>>io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.ha
>>ndleRequest(ServletAuthenticationCallHandler.java:56)
>>     at 
>>io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCach
>>eHandler.java:33)
>>     at 
>>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl
>>er.java:43)
>>     at 
>>io.undertow.security.handlers.AuthenticationConstraintHandler.handleReque
>>st(AuthenticationConstraintHandler.java:51)
>>     at 
>>io.undertow.security.handlers.AbstractConfidentialityHandler.handleReques
>>t(AbstractConfidentialityHandler.java:45)
>>     at 
>>io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHan
>>dler.handleRequest(ServletConfidentialityConstraintHandler.java:63)
>>     at 
>>io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.ha
>>ndleRequest(ServletSecurityConstraintHandler.java:56)
>>     at 
>>io.undertow.security.handlers.AuthenticationMechanismsHandler.handleReque
>>st(AuthenticationMechanismsHandler.java:58)
>>     at 
>>io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.h
>>andleRequest(CachedAuthenticatedSessionHandler.java:70)
>>     at 
>>io.undertow.security.handlers.SecurityInitialHandler.handleRequest(Securi
>>tyInitialHandler.java:76)
>>     at 
>>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl
>>er.java:43)
>>     at 
>>org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleR
>>equest(JACCContextIdHandler.java:61)
>>     at 
>>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl
>>er.java:43)
>>     at 
>>org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest
>>(ServletPreAuthActionsHandler.java:69)
>>     at 
>>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl
>>er.java:43)
>>     at 
>>io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(Ser
>>vletInitialHandler.java:261)
>>     at 
>>io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(Servle
>>tInitialHandler.java:247)
>>     at 
>>io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInit
>>ialHandler.java:76)
>>     at 
>>io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(Servle
>>tInitialHandler.java:166)
>>     at 
>>io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
>>     at 
>>io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
>>     at 
>>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java
>>:1142)
>>     at 
>>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.jav
>>a:617)
>>     at java.lang.Thread.run(Thread.java:745)
>> Caused by: io.apiman.gateway.engine.beans.exceptions.PublishingException
>>     at 
>>io.apiman.manager.api.gateway.rest.GatewayClient.readPublishingException(
>>GatewayClient.java:273)
>>     at 
>>io.apiman.manager.api.gateway.rest.GatewayClient.publish(GatewayClient.ja
>>va:216)
>>     at 
>>io.apiman.manager.api.gateway.rest.RestGatewayLink.publishService(RestGat
>>ewayLink.java:162)
>>     at 
>>io.apiman.manager.api.rest.impl.ActionResourceImpl.publishService(ActionR
>>esourceImpl.java:189)
>>     ... 66 more
>> Caused by: java.lang.NullPointerException
>>     at java.lang.Throwable.setStackTrace(Throwable.java:864)
>>     at 
>>io.apiman.manager.api.gateway.rest.GatewayClient.readPublishingException(
>>GatewayClient.java:271)
>>     ... 69 more
>>
>>
>> If anyone has seen this before and has a possible workaround/solution,
>> please let me know.
>>
>> Thanks,
>> Joe
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>_______________________________________________
>Apiman-user mailing list
>Apiman-user at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/apiman-user



From ton at finalist.nl  Tue Jan 12 10:31:29 2016
From: ton at finalist.nl (Ton Swieb)
Date: Tue, 12 Jan 2016 16:31:29 +0100
Subject: [Apiman-user] HTTP request/response logging from the Apiman
 gateway to back-end services
Message-ID: <CAJJ5CnQm8KUAAF6s4pCYePWf=70WDt7vMabSt9Rm+=-EdoV76w@mail.gmail.com>

Hi Eric,

Good to know. I logged: https://issues.jboss.org/browse/APIMAN-897

Regards, Ton

2016-01-12 14:58 GMT+01:00 Eric Wittmann <eric.wittmann at redhat.com>:

> We don't currently have a feature to log the back-end request/response.
> I'd love it if you would open a feature request ticket in JIRA for that
> (seems like a nice thing to have).
>
> In the short term you could implement a custom policy that would Sys.out
> the ServiceRequest and ServiceResponse objects (note: in 1.2.x these are
> called ApiRequest and ApiResponse).  If you do this, make sure to put that
> policy *last* in the chain.
>
> -Eric
>
> On 1/12/2016 5:07 AM, Ton Swieb wrote:
>
>> Hi,
>>
>> I would like to see the HTTP request/response logging between the Apiman
>> gateway and the back-end services.
>>
>> Is this possible in Apiman? If so, how can I activate it?
>>
>> I already tried enabling the RequestDumpHandler in Undertow, but that
>> only logs the inbound HTTP request/response to the Apiman gateway. So
>> the communication between the API client and the API gateway, but I
>> would like to see the outbound HTTP request/response logging.
>>
>> Regards,
>>
>> Ton
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> 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/20160112/4549f292/attachment-0001.html 

From eric.wittmann at redhat.com  Tue Jan 12 10:55:46 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 12 Jan 2016 10:55:46 -0500
Subject: [Apiman-user] HTTP request/response logging from the Apiman
 gateway to back-end services
In-Reply-To: <CAJJ5CnQm8KUAAF6s4pCYePWf=70WDt7vMabSt9Rm+=-EdoV76w@mail.gmail.com>
References: <CAJJ5CnQm8KUAAF6s4pCYePWf=70WDt7vMabSt9Rm+=-EdoV76w@mail.gmail.com>
Message-ID: <56952202.50106@redhat.com>

Excellent, thanks!

On 1/12/2016 10:31 AM, Ton Swieb wrote:
> Hi Eric,
>
> Good to know. I logged: https://issues.jboss.org/browse/APIMAN-897
>
> Regards, Ton
>
> 2016-01-12 14:58 GMT+01:00 Eric Wittmann <eric.wittmann at redhat.com
> <mailto:eric.wittmann at redhat.com>>:
>
>     We don't currently have a feature to log the back-end
>     request/response.  I'd love it if you would open a feature request
>     ticket in JIRA for that (seems like a nice thing to have).
>
>     In the short term you could implement a custom policy that would
>     Sys.out the ServiceRequest and ServiceResponse objects (note: in
>     1.2.x these are called ApiRequest and ApiResponse).  If you do this,
>     make sure to put that policy *last* in the chain.
>
>     -Eric
>
>     On 1/12/2016 5:07 AM, Ton Swieb wrote:
>
>         Hi,
>
>         I would like to see the HTTP request/response logging between
>         the Apiman
>         gateway and the back-end services.
>
>         Is this possible in Apiman? If so, how can I activate it?
>
>         I already tried enabling the RequestDumpHandler in Undertow, but
>         that
>         only logs the inbound HTTP request/response to the Apiman
>         gateway. So
>         the communication between the API client and the API gateway, but I
>         would like to see the outbound HTTP request/response logging.
>
>         Regards,
>
>         Ton
>
>
>         _______________________________________________
>         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
>
>

From eric.wittmann at redhat.com  Tue Jan 12 11:00:57 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 12 Jan 2016 11:00:57 -0500
Subject: [Apiman-user] Cannot publish Service with Basic Auth API
	Security
In-Reply-To: <D2BA7ECE.11374%pblair@clearme.com>
References: <D2BA7ECE.11374%pblair@clearme.com>
Message-ID: <56952339.8040103@redhat.com>

This is exactly right.  I do want to note, for the record, that as of 
1.2.0 we have a data export feature that is intended to make upgrades 
easier.  The procedure for upgrading apiman should be something like this:

1) export the apiman data (there is a UI screen to do this)
2) shut down apiman-oldversion
3) install apiman-newversion
4) run apiman-newversion
5) import the apiman data exported in step #1 (there is a UI screen to 
do this)

Further, steps #1 and #5 are supported in the API Manager REST API - so 
you could automate this if needed.

Finally, the export file in step #1 is a simple JSON output format, 
which can be tweaked/processed easily prior to importing it in step #5.

-Eric

On 1/12/2016 10:07 AM, Paul Blair wrote:
> I was just dealing with the same problem, which is why I upgraded to 1.2.0.
>
> After upgrading, I found that the exception was caused by the publisher
> trying to publish to the wrong URI, because the gateway wasn't accessible
> on the URI that is specified in the gateway setup. This doesn't sound like
> the problem you're having, though, because you seem to be able to publish
> ok before you change authentication.
>
> With regard to upgrading to 1.2.0 -- the DDL changed, so I wound up
> tearing down my apiman database and re-running the DDL; if you are in
> production and need to upgrade this could be trickier because I believe
> you'll need to create a diff script yourself. I also needed to bring in
> the changes to apiman.properties and apiman-realm.json.
>
>
> On 1/12/16, 9:04 AM, "Eric Wittmann" <eric.wittmann at redhat.com> wrote:
>
>> Hi Joe - I think you're running into a bug in 1.1.9.Final that is
>> unfortunately masking the real publishing error. :(
>>
>> We have a couple of options here:
>>
>> 1) Try to get a 1.1.10.Final released that fixes the problem (which
>> would at least let us see why publishing was failing)
>> 2) Try to debug the reason for the failure by attaching a java debugger
>> to a running apiman
>> 3) Download the latest version 1.2.0.Final which I believe fixes the NPE
>> problem
>>
>> Any of those options sound reasonable?  Note that if you install
>> 1.2.0.Final you'll need to reconfigure all your APIs again from scratch.
>>   We don't yet have a migration/upgrade path from 1.1 to 1.2.
>>
>> -Eric
>>
>> On 1/11/2016 6:08 PM, Joe Strathern wrote:
>>> Hello APIMan Community,
>>>
>>> I am trying to create and publish a service within APIMan that is
>>> secured by basic authentication, however i am encountering errors
>>> whenever i set the Implementation to Basic Auth and then try to publish.
>>>
>>> I am currently using APIMan 1.1.9 within Wildfly 8.2.0.Final
>>> The Service will publish without issues if i set the Implementation to
>>> None, however as soon as i set it to BASIC (with the correct
>>> username/pass) I get a Server Error 500 page with the following stack
>>> trace:
>>>
>>> io.apiman.manager.api.rest.contract.exceptions.ActionException: Failed
>>> to publish service.
>>>      at
>>> io.apiman.manager.api.rest.impl.util.ExceptionFactory.actionException(Exc
>>> eptionFactory.java:308)
>>>      at
>>> io.apiman.manager.api.rest.impl.ActionResourceImpl.publishService(ActionR
>>> esourceImpl.java:201)
>>>      at
>>> io.apiman.manager.api.rest.impl.ActionResourceImpl.performAction(ActionRe
>>> sourceImpl.java:103)
>>>      at
>>> io.apiman.manager.api.rest.impl.ActionResourceImpl$Proxy$_$$_WeldClientPr
>>> oxy.performAction(Unknown Source)
>>>      at sun.reflect.GeneratedMethodAccessor157.invoke(Unknown Source)
>>>      at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI
>>> mpl.java:43)
>>>      at java.lang.reflect.Method.invoke(Method.java:497)
>>>      at
>>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java
>>> :137)
>>>      at
>>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMeth
>>> odInvoker.java:296)
>>>      at
>>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoke
>>> r.java:250)
>>>      at
>>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoke
>>> r.java:237)
>>>      at
>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatche
>>> r.java:356)
>>>      at
>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatche
>>> r.java:179)
>>>      at
>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.serv
>>> ice(ServletContainerDispatcher.java:220)
>>>      at
>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(H
>>> ttpServletDispatcher.java:56)
>>>      at
>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(H
>>> ttpServletDispatcher.java:51)
>>>      at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>>      at
>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.
>>> java:85)
>>>      at
>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(Filte
>>> rHandler.java:130)
>>>      at
>>> io.apiman.common.servlet.RootResourceFilter.doFilter(RootResourceFilter.j
>>> ava:59)
>>>      at
>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>>      at
>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(Filte
>>> rHandler.java:132)
>>>      at
>>> io.apiman.manager.api.war.TransactionWatchdogFilter.doFilter(TransactionW
>>> atchdogFilter.java:57)
>>>      at
>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>>      at
>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(Filte
>>> rHandler.java:132)
>>>      at
>>> io.apiman.manager.api.security.impl.DefaultSecurityContextFilter.doFilter
>>> (DefaultSecurityContextFilter.java:56)
>>>      at
>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>>      at
>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(Filte
>>> rHandler.java:132)
>>>      at
>>> io.apiman.common.servlet.DisableCachingFilter.doFilter(DisableCachingFilt
>>> er.java:59)
>>>      at
>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>>      at
>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(Filte
>>> rHandler.java:132)
>>>      at
>>> io.apiman.common.servlet.ApimanCorsFilter.doFilter(ApimanCorsFilter.java:
>>> 71)
>>>      at
>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>>      at
>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(Filte
>>> rHandler.java:132)
>>>      at
>>> io.apiman.common.servlet.LocaleFilter.doFilter(LocaleFilter.java:61)
>>>      at
>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>>      at
>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(Filte
>>> rHandler.java:132)
>>>      at
>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.ja
>>> va:85)
>>>      at
>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRe
>>> quest(ServletSecurityRoleHandler.java:61)
>>>      at
>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(Serv
>>> letDispatchingHandler.java:36)
>>>      at
>>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler
>>> .handleRequest(SecurityContextAssociationHandler.java:78)
>>>      at
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl
>>> er.java:43)
>>>      at
>>> org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handle
>>> Request(UndertowAuthenticatedActionsHandler.java:66)
>>>      at
>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.ha
>>> ndleRequest(SSLInformationAssociationHandler.java:131)
>>>      at
>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.ha
>>> ndleRequest(ServletAuthenticationCallHandler.java:56)
>>>      at
>>> io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCach
>>> eHandler.java:33)
>>>      at
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl
>>> er.java:43)
>>>      at
>>> io.undertow.security.handlers.AuthenticationConstraintHandler.handleReque
>>> st(AuthenticationConstraintHandler.java:51)
>>>      at
>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleReques
>>> t(AbstractConfidentialityHandler.java:45)
>>>      at
>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHan
>>> dler.handleRequest(ServletConfidentialityConstraintHandler.java:63)
>>>      at
>>> io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.ha
>>> ndleRequest(ServletSecurityConstraintHandler.java:56)
>>>      at
>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleReque
>>> st(AuthenticationMechanismsHandler.java:58)
>>>      at
>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.h
>>> andleRequest(CachedAuthenticatedSessionHandler.java:70)
>>>      at
>>> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(Securi
>>> tyInitialHandler.java:76)
>>>      at
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl
>>> er.java:43)
>>>      at
>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleR
>>> equest(JACCContextIdHandler.java:61)
>>>      at
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl
>>> er.java:43)
>>>      at
>>> org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest
>>> (ServletPreAuthActionsHandler.java:69)
>>>      at
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl
>>> er.java:43)
>>>      at
>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(Ser
>>> vletInitialHandler.java:261)
>>>      at
>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(Servle
>>> tInitialHandler.java:247)
>>>      at
>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInit
>>> ialHandler.java:76)
>>>      at
>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(Servle
>>> tInitialHandler.java:166)
>>>      at
>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
>>>      at
>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
>>>      at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java
>>> :1142)
>>>      at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.jav
>>> a:617)
>>>      at java.lang.Thread.run(Thread.java:745)
>>> Caused by: io.apiman.gateway.engine.beans.exceptions.PublishingException
>>>      at
>>> io.apiman.manager.api.gateway.rest.GatewayClient.readPublishingException(
>>> GatewayClient.java:273)
>>>      at
>>> io.apiman.manager.api.gateway.rest.GatewayClient.publish(GatewayClient.ja
>>> va:216)
>>>      at
>>> io.apiman.manager.api.gateway.rest.RestGatewayLink.publishService(RestGat
>>> ewayLink.java:162)
>>>      at
>>> io.apiman.manager.api.rest.impl.ActionResourceImpl.publishService(ActionR
>>> esourceImpl.java:189)
>>>      ... 66 more
>>> Caused by: java.lang.NullPointerException
>>>      at java.lang.Throwable.setStackTrace(Throwable.java:864)
>>>      at
>>> io.apiman.manager.api.gateway.rest.GatewayClient.readPublishingException(
>>> GatewayClient.java:271)
>>>      ... 69 more
>>>
>>>
>>> If anyone has seen this before and has a possible workaround/solution,
>>> please let me know.
>>>
>>> Thanks,
>>> Joe
>>>
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From marc.savy at redhat.com  Wed Jan 13 10:39:26 2016
From: marc.savy at redhat.com (Marc Savy)
Date: Wed, 13 Jan 2016 15:39:26 +0000
Subject: [Apiman-user] Anyone interested in Prometheus metrics for apiman?
Message-ID: <56966FAE.5050206@redhat.com>

Hi All,

Is anyone interested in Prometheus metrics/monitoring for apiman?

There's currently a PoC implementation for the Vert.x 3 gateway (which
none of you are likely using!), however it's probably of limited
practical use in the wild.

The nature of Prometheus is rather different to any of the other engines
we've worked with, in that you must define which measures you're
interested in a priori, rather than spitting out raw data and analysing
it later.

Clearly, this requires substantial decisions to be made in advance as to
what kind of metrics are important to you, and indeed which ones you
don't want.

I think in many cases we'll just have to provide a base class which can
be extended so you can implement your own measures in a way that suits you.

However, it would be good to provide a default implementation which has
a useful set of measures which will cover a least a substantial portion
of usecases.

Therefore, my questions are:

- Should we provide a default implementation of Prometheus metrics. Or
are requirements too diverse to make it worthwhile?

- If yes, which measures should we provide by default?

- Would there be an argument for having engines like Prometheus to be
run concurrently with another one (e.g. elaticsearch metrics), because
it serves a different purpose. What's your use case?


Regards,
Marc

From michele.danieli at gmail.com  Wed Jan 13 15:05:13 2016
From: michele.danieli at gmail.com (michele danieli)
Date: Wed, 13 Jan 2016 20:05:13 +0000
Subject: [Apiman-user] OAuth with non public API
Message-ID: <CAH+8e1cgb7f4ik21oQN9xZXS5rM7t7WST=_sz=toPGp9GCLVyg@mail.gmail.com>

When considering non public API and applying a OAuth authentication policy,
the application identifier must be provided using the api_key as a header?

If so, does not it means that the user authorized client and the actual api
consumer application have no strict relationship?


Thanks
Michele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160113/56c37558/attachment.html 

From eric.wittmann at redhat.com  Thu Jan 14 08:34:22 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Thu, 14 Jan 2016 08:34:22 -0500
Subject: [Apiman-user] OAuth with non public API
In-Reply-To: <CAH+8e1cgb7f4ik21oQN9xZXS5rM7t7WST=_sz=toPGp9GCLVyg@mail.gmail.com>
References: <CAH+8e1cgb7f4ik21oQN9xZXS5rM7t7WST=_sz=toPGp9GCLVyg@mail.gmail.com>
Message-ID: <5697A3DE.20306@redhat.com>

Hi Michele.

That is correct.  Typically the end-user population is tied to the API 
being invoked rather than the Client (software) being used to connect. 
If that is not the case, then you could configure the OAuth policy on 
the Client Application rather than on the API (Service).  That way you 
could have a different user population for each connecting client.  If 
that's your use-case I'd love to hear more about it. :)

-Eric

On 1/13/2016 3:05 PM, michele danieli wrote:
> When considering non public API and applying a OAuth authentication
> policy, the application identifier must be provided using the api_key as
> a header?
>
> If so, does not it means that the user authorized client and the actual
> api consumer application have no strict relationship?
>
>
> Thanks
> Michele
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From michele.danieli at gmail.com  Thu Jan 14 13:16:21 2016
From: michele.danieli at gmail.com (michele danieli)
Date: Thu, 14 Jan 2016 18:16:21 +0000
Subject: [Apiman-user] OAuth with non public API
In-Reply-To: <5697A3DE.20306@redhat.com>
References: <CAH+8e1cgb7f4ik21oQN9xZXS5rM7t7WST=_sz=toPGp9GCLVyg@mail.gmail.com>
	<5697A3DE.20306@redhat.com>
Message-ID: <CAH+8e1fzC3oyBr-U01Y+6aGB5VfbHfoQk-1a5ogetOMEUYkSjA@mail.gmail.com>

Hello Eric,
my scenario is the following.

A set of API has been defined to expose core business functions, to clerks
and sales force automation. Some functions are specifically sensitive. All
access requires end user authentication. Some function are only accessible
to users when using trusted clients: for example access from browsers js
apps is not enabled to some functions, while native clients for mobile SFA
do.

For trusted application i have implemented OAUTH with signed JWT client
authentication (updated KC to latest) almost meeting security requirements
(added a ticket to KC for supports of nonces) but oauth client and
application are actually unrelated, so no way I can relate the client id to
application to enforce access to sensitive api to only users authenticated
with the trusted client.

Of course I can set the api_key header to the one I have associated to the
trusted client, but this are unrelated (security department not so happy).
I could probably use the api_key as client_id in KC and implement a custom
policy to verify the access token audience (i guess that is where the
client is mapped in the signed token) matches the apikey.

In general i was thinking if diffeent strategies for application
identification made sense (at api level) .

Bests
Mike

On Thu, 14 Jan 2016 at 14:34, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> Hi Michele.
>
> That is correct.  Typically the end-user population is tied to the API
> being invoked rather than the Client (software) being used to connect.
> If that is not the case, then you could configure the OAuth policy on
> the Client Application rather than on the API (Service).  That way you
> could have a different user population for each connecting client.  If
> that's your use-case I'd love to hear more about it. :)
>
> -Eric
>
> On 1/13/2016 3:05 PM, michele danieli wrote:
> > When considering non public API and applying a OAuth authentication
> > policy, the application identifier must be provided using the api_key as
> > a header?
> >
> > If so, does not it means that the user authorized client and the actual
> > api consumer application have no strict relationship?
> >
> >
> > Thanks
> > Michele
> >
> >
> > _______________________________________________
> > Apiman-user mailing list
> > 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/20160114/27c1992e/attachment-0001.html 

From cmoulliard at redhat.com  Fri Jan 15 11:07:49 2016
From: cmoulliard at redhat.com (Charles Moulliard)
Date: Fri, 15 Jan 2016 17:07:49 +0100
Subject: [Apiman-user] Apiman & Loadbalancer F5
Message-ID: <56991955.5010704@redhat.com>

Hi,

If I use a loadbalancer (= F5) exposing a physical IP address (= routed 
on internet) and calling one of our endpoints (REST, ...) running into 
different integration servers (Fuse + Camel), can we design such topology ?

We setup an Apiman Manager  (Front + ElasticSearch Database) to define 
the plans, services, roles, policies of all the endpoints which are 
running into different Fuse Servers. As the mapping between the incoming 
request and the endpoint is managed by the Apiman Gateway, I'm thinking 
to install one Apiman Gateway / Fuse Server.
Is it doable ?

Client --> 192.168.1.1 (IP Address of the Server replying to a REST 
Service) "Loadbalancer F5" --> NAT --> address of the gateway (= 
10.0.2.1) managing the mapping between the request and the physical 
endpoint --> Camel REST Endpoint (10.0.1.1). The Apiman Manager could 
run internally on this addess (10.0.2.100).

To support high availability or workload distribution, it will be 
required that at least each Camel REST / Web Service runs into multiple 
instances of Fuse Servers. That means that their IP address will be 
different (A REST service will be deployed on 10.0.1.1, 10.0.1.2, 
10.0.1.3, ...).

Question : As the GUI interface of the Apiman Manager to encode the 
address of the endpoint to map proposes one field (and no more if we 
would like to distribute the requests to different servers), is there a 
possibility to define a 1 to many relation into ApiMan Server (maybe if 
we develop such a feature) or do I have also to install an Apiman 
Manager / Gateway per Fuse Server and to encode the same info (plans, 
services, ...) excepted the IP address of the server which is different ?

Regards,

Charles

From uvax at informatica.com  Mon Jan 18 07:10:01 2016
From: uvax at informatica.com (Vax, Uri)
Date: Mon, 18 Jan 2016 12:10:01 +0000
Subject: [Apiman-user] Rate-limit policy does not work in APIMan cluster
Message-ID: <BN1PR0301MB076933C440348631FD07BA55C0C00@BN1PR0301MB0769.namprd03.prod.outlook.com>


Hi

I'm using APIMan 1.1.9.
It seems like Rate-limit policy does not work properly when there are several nodes (node1, node2).

The scenario:

*         Setup up an APIMan cluster with two nodes (node1 , node2).

*         Create a service with a rate-limit policy of 5 request per minute

*         Send requests to the service using postman (or any other http client):

o   Send requests to node1 until rate limit is exceeded

o   Send another request to node2 - APIMan will pass the request to the service end-point API instead of returning the "Rate limit exceeded" response



Thanks,
Uri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160118/dd3645ff/attachment.html 

From jcechace at gmail.com  Mon Jan 18 08:32:57 2016
From: jcechace at gmail.com (=?UTF-8?B?SmFrdWIgxIxlY2jDocSNZWs=?=)
Date: Mon, 18 Jan 2016 14:32:57 +0100
Subject: [Apiman-user] Rate-limit policy does not work in APIMan cluster
In-Reply-To: <BN1PR0301MB076933C440348631FD07BA55C0C00@BN1PR0301MB0769.namprd03.prod.outlook.com>
References: <BN1PR0301MB076933C440348631FD07BA55C0C00@BN1PR0301MB0769.namprd03.prod.outlook.com>
Message-ID: <CALvAxYvnH5yXUZdhZka7mUYaR0pUFoknCae_PqyH0e62Ft8=oA@mail.gmail.com>

Hello,

could you please describe the setup/topology of your "cluster"?  The HA
setup of apiman takes advantage of the fact that state is shared only
inside ES -- so you should be good as long as you share one ES cluster
among all gateways. Thus it is not really a cluster.


Jakub.

On Mon, Jan 18, 2016 at 1:10 PM, Vax, Uri <uvax at informatica.com> wrote:

>
>
> Hi
>
>
>
> I?m using APIMan 1.1.9.
>
> It seems like Rate-limit policy does not work properly when there are
> several nodes (node1, node2).
>
>
>
> *The scenario:*
>
> ?         Setup up an APIMan cluster with two nodes (node1 , node2).
>
> ?         Create a service with a rate-limit policy of 5 request per
> minute
>
> ?         Send requests to the service using postman (or any other http
> client):
>
> o   Send requests to node1 until rate limit is exceeded
>
> o   Send another request to node2 ? APIMan will pass the request to the
> service end-point API instead of returning the ?Rate limit exceeded?
> response
>
>
>
>
>
>
>
> Thanks,
>
> Uri
>
> _______________________________________________
> Apiman-user mailing list
> 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/20160118/d789f6b4/attachment.html 

From uvax at informatica.com  Mon Jan 18 09:03:33 2016
From: uvax at informatica.com (Vax, Uri)
Date: Mon, 18 Jan 2016 14:03:33 +0000
Subject: [Apiman-user] Rate-limit policy does not work in APIMan cluster
In-Reply-To: <CALvAxYvnH5yXUZdhZka7mUYaR0pUFoknCae_PqyH0e62Ft8=oA@mail.gmail.com>
References: <BN1PR0301MB076933C440348631FD07BA55C0C00@BN1PR0301MB0769.namprd03.prod.outlook.com>
	<CALvAxYvnH5yXUZdhZka7mUYaR0pUFoknCae_PqyH0e62Ft8=oA@mail.gmail.com>
Message-ID: <BN1PR0301MB0769C5476BD8B9991F192AC0C0C00@BN1PR0301MB0769.namprd03.prod.outlook.com>


The cluster:

Two Linux machines
Node1: Gateway + Manager + Elastic Search
Node2: Gateway

Node1 and Node2 share same Elastic Search.

Maybe I missing something?

By the way? not sure, but I noticed that the value of rateBucket has been initialized after the request to Node2
{
        "_index": "apiman_gateway",
        "_type": "rateBucket",
        "_id": "UFVCTElDfHx8fGxvY2FsfHxzfHwxLjA=",
        "_score": 1,
        "_source": {
          "count": 1,
          "last": 1453115651374
        }


From: Jakub ?ech??ek [mailto:jcechace at gmail.com]
Sent: Monday, January 18, 2016 3:33 PM
To: Vax, Uri
Cc: apiman-user at lists.jboss.org
Subject: Re: [Apiman-user] Rate-limit policy does not work in APIMan cluster

Hello,

could you please describe the setup/topology of your "cluster"?  The HA setup of apiman takes advantage of the fact that state is shared only inside ES -- so you should be good as long as you share one ES cluster among all gateways. Thus it is not really a cluster.


Jakub.

On Mon, Jan 18, 2016 at 1:10 PM, Vax, Uri <uvax at informatica.com<mailto:uvax at informatica.com>> wrote:

Hi

I?m using APIMan 1.1.9.
It seems like Rate-limit policy does not work properly when there are several nodes (node1, node2).

The scenario:

?         Setup up an APIMan cluster with two nodes (node1 , node2).

?         Create a service with a rate-limit policy of 5 request per minute

?         Send requests to the service using postman (or any other http client):

o   Send requests to node1 until rate limit is exceeded

o   Send another request to node2 ? APIMan will pass the request to the service end-point API instead of returning the ?Rate limit exceeded? response



Thanks,
Uri

_______________________________________________
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/20160118/5cf9fe6b/attachment-0001.html 

From ton at finalist.nl  Tue Jan 19 05:25:11 2016
From: ton at finalist.nl (Ton Swieb)
Date: Tue, 19 Jan 2016 11:25:11 +0100
Subject: [Apiman-user] Property placeholder within policy does not resolve
 in the gateway (v1.2.0.Final / APIMAN-831)
Message-ID: <CAJJ5CnQE=QKpSU8btGtWJ7x2Be7o2Lp+vb7r-4ekL60nZyZXPA@mail.gmail.com>

Hi,

I tried to take the property placeholder functionality for a test drive,
which should be available as of v1.2.0.Final. See JIRA:
https://issues.jboss.org/browse/APIMAN-831

But for some reason I do not get it to work. Did I configure something
wrong or am I running into a bug?

I use the property placeholder in the keycloak plugin which is
preconfigured in a Docker image.
I defined the realm property of the Keycloak plugin as
${external_url}/auth/realms/apiman

I started my Docker image with the -e external_url=
https://192.168.99.100:8443 parameter to set the environment variable
within the Docker container.

When I try to access the API I get a failure in Keycloak Plugin saying:

{
  "type": "Authentication",
  "failureCode": 11004,
  "responseCode": 401,
  "message": "Token audience doesn't match domain. Token issuer is
https://192.168.99.100:8443/auth/realms/apiman, but URL from
configuration is ${external_url}/auth/realms/apiman",
  "headers": {}
}

It looks like the property placeholder did not get resolved correctly.

When I have a look in the Docker image using docker exec -ti <name>
/binbash and do a list of the environment variables. The environment
variable is correctly defined:
MacBook-Pro-van-Ton:~ ton$ docker exec -ti tiny_wilson /bin/bash
[jboss at 43c099aae441 ~]$ export
declare -x APIMAN_VERSION="1.2.0.Final"
....
declare -x external_url="https://192.168.99.100:8443"

I also tried setting the property to ${external_url} without the
'/auth/realms/apiman' suffix. I figured that it might perhaps will do a
full String comparison, but that did not work either.

Any ideas?

Regards, Ton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160119/c893fa2d/attachment.html 

From cmoulliard at redhat.com  Tue Jan 19 05:30:08 2016
From: cmoulliard at redhat.com (Charles Moulliard)
Date: Tue, 19 Jan 2016 11:30:08 +0100
Subject: [Apiman-user] Apiman & Loadbalancer F5 !
Message-ID: <569E1030.9020608@redhat.com>

Hi,

If I use a loadbalancer (= F5) exposing a physical IP address (= routed 
on internet) and calling one of our endpoints (REST, ...) running into 
different integration servers (Fuse + Camel), can we design such topology ?

We setup an Apiman Manager  (Front + ElasticSearch Database) to define 
the plans, services, roles, policies of all the endpoints which are 
running into different Fuse Servers. As the mapping between the incoming 
request and the endpoint is managed by the Apiman Gateway, I'm thinking 
to install one Apiman Gateway / Fuse Server.
Is it doable ?

Client --> 192.168.1.1 (IP Address of the Server replying to a REST 
Service) "Loadbalancer F5" --> NAT --> address of the gateway (= 
10.0.2.1) managing the mapping between the request and the physical 
endpoint --> Camel REST Endpoint (10.0.1.1). The Apiman Manager could 
run internally on this addess (10.0.2.100).

To support high availability or workload distribution, it will be 
required that at least each Camel REST / Web Service runs into multiple 
instances of Fuse Servers. That means that their IP address will be 
different (A REST service will be deployed on 10.0.1.1, 10.0.1.2, 
10.0.1.3, ...).

Question : As the GUI interface of the Apiman Manager to encode the 
address of the endpoint to map proposes one field (and no more if we 
would like to distribute the requests to different servers), is there a 
possibility to define a 1 to many relation into ApiMan Server (maybe if 
we develop such a feature) or do I have also to install an Apiman 
Manager / Gateway per Fuse Server and to encode the same info (plans, 
services, ...) excepted the IP address of the server which is different ?

Regards,

Charles

From ton at finalist.nl  Tue Jan 19 05:44:03 2016
From: ton at finalist.nl (Ton Swieb)
Date: Tue, 19 Jan 2016 11:44:03 +0100
Subject: [Apiman-user] Property placeholder within policy does not
 resolve in the gateway (v1.2.0.Final / APIMAN-831)
In-Reply-To: <CAJJ5CnQE=QKpSU8btGtWJ7x2Be7o2Lp+vb7r-4ekL60nZyZXPA@mail.gmail.com>
References: <CAJJ5CnQE=QKpSU8btGtWJ7x2Be7o2Lp+vb7r-4ekL60nZyZXPA@mail.gmail.com>
Message-ID: <CAJJ5CnSigVVmVKqUdB0Oz3xc3MsaTFT8cGDN+WHV=Jf7X0B+gw@mail.gmail.com>

Hi,

I just tried it with a system property instead of a environment property.
With a system property it works, but they are a bit cumbersome to supply to
the apiman-wildfly docker image.
Are environment variables expected to work?

Regards, Ton



2016-01-19 11:25 GMT+01:00 Ton Swieb <ton at finalist.nl>:

> Hi,
>
> I tried to take the property placeholder functionality for a test drive,
> which should be available as of v1.2.0.Final. See JIRA:
> https://issues.jboss.org/browse/APIMAN-831
>
> But for some reason I do not get it to work. Did I configure something
> wrong or am I running into a bug?
>
> I use the property placeholder in the keycloak plugin which is
> preconfigured in a Docker image.
> I defined the realm property of the Keycloak plugin as
> ${external_url}/auth/realms/apiman
>
> I started my Docker image with the -e external_url=
> https://192.168.99.100:8443 parameter to set the environment variable
> within the Docker container.
>
> When I try to access the API I get a failure in Keycloak Plugin saying:
>
> {
>   "type": "Authentication",
>   "failureCode": 11004,
>   "responseCode": 401,
>   "message": "Token audience doesn't match domain. Token issuer is https://192.168.99.100:8443/auth/realms/apiman, but URL from configuration is ${external_url}/auth/realms/apiman",
>   "headers": {}
> }
>
> It looks like the property placeholder did not get resolved correctly.
>
> When I have a look in the Docker image using docker exec -ti <name>
> /binbash and do a list of the environment variables. The environment
> variable is correctly defined:
> MacBook-Pro-van-Ton:~ ton$ docker exec -ti tiny_wilson /bin/bash
> [jboss at 43c099aae441 ~]$ export
> declare -x APIMAN_VERSION="1.2.0.Final"
> ....
> declare -x external_url="https://192.168.99.100:8443"
>
> I also tried setting the property to ${external_url} without the
> '/auth/realms/apiman' suffix. I figured that it might perhaps will do a
> full String comparison, but that did not work either.
>
> Any ideas?
>
> Regards, Ton
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160119/3d493d96/attachment.html 

From eric.wittmann at redhat.com  Tue Jan 19 08:56:39 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 19 Jan 2016 08:56:39 -0500
Subject: [Apiman-user] Rate-limit policy does not work in APIMan cluster
In-Reply-To: <BN1PR0301MB0769C5476BD8B9991F192AC0C0C00@BN1PR0301MB0769.namprd03.prod.outlook.com>
References: <BN1PR0301MB076933C440348631FD07BA55C0C00@BN1PR0301MB0769.namprd03.prod.outlook.com>
	<CALvAxYvnH5yXUZdhZka7mUYaR0pUFoknCae_PqyH0e62Ft8=oA@mail.gmail.com>
	<BN1PR0301MB0769C5476BD8B9991F192AC0C0C00@BN1PR0301MB0769.namprd03.prod.outlook.com>
Message-ID: <569E4097.40502@redhat.com>

Are you 100% sure that the Gateway on Node1 and Node2 are sharing the 
same Elasticsearch instance?  From your description it sounds like 
perhaps they are not (e.g. the rateBucket being initialized after the 
request to Node2).

Perhaps you could send us the apiman.properties files from *each* of 
your two nodes?

Regards,

Eric

On 1/18/2016 9:03 AM, Vax, Uri wrote:
> The cluster:
>
> Two Linux machines
>
> *Node1*: Gateway + Manager + Elastic Search
>
> *Node2*: Gateway
>
> Node1 and Node2 share same Elastic Search.
>
> Maybe I missing something?
>
> By the way? not sure, but I noticed that the value of *rateBucket* has
> been initialized after the request to Node2
>
> {
>
>          "_index": "apiman_gateway",
>
>          "_type": "rateBucket",
>
>          "_id": "UFVCTElDfHx8fGxvY2FsfHxzfHwxLjA=",
>
>          "_score": 1,
>
>          "_source": {
>
>            "count": 1,
>
>            "last": 1453115651374
>
>          }
>
> *From:*Jakub ?ech??ek [mailto:jcechace at gmail.com]
> *Sent:* Monday, January 18, 2016 3:33 PM
> *To:* Vax, Uri
> *Cc:* apiman-user at lists.jboss.org
> *Subject:* Re: [Apiman-user] Rate-limit policy does not work in APIMan
> cluster
>
> Hello,
>
> could you please describe the setup/topology of your "cluster"?  The HA
> setup of apiman takes advantage of the fact that state is shared only
> inside ES -- so you should be good as long as you share one ES cluster
> among all gateways. Thus it is not really a cluster.
>
> Jakub.
>
> On Mon, Jan 18, 2016 at 1:10 PM, Vax, Uri <uvax at informatica.com
> <mailto:uvax at informatica.com>> wrote:
>
> Hi
>
> I?m using APIMan 1.1.9.
>
> It seems like Rate-limit policy does not work properly when there are
> several nodes (node1, node2).
>
> *_The scenario:_*
>
> ?Setup up an APIMan cluster with two nodes (node1 , node2).
>
> ?Create a service with a rate-limit policy of 5 request per minute
>
> ?Send requests to the service using postman (or any other http client):
>
> oSend requests to node1 until rate limit is exceeded
>
> oSend another request to node2 ? APIMan will pass the request to the
> service end-point API instead of returning the ?Rate limit exceeded?
> response
>
> Thanks,
>
> Uri
>
>
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From eric.wittmann at redhat.com  Tue Jan 19 09:28:59 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 19 Jan 2016 09:28:59 -0500
Subject: [Apiman-user] Property placeholder within policy does not
 resolve in the gateway (v1.2.0.Final / APIMAN-831)
In-Reply-To: <CAJJ5CnSigVVmVKqUdB0Oz3xc3MsaTFT8cGDN+WHV=Jf7X0B+gw@mail.gmail.com>
References: <CAJJ5CnQE=QKpSU8btGtWJ7x2Be7o2Lp+vb7r-4ekL60nZyZXPA@mail.gmail.com>
	<CAJJ5CnSigVVmVKqUdB0Oz3xc3MsaTFT8cGDN+WHV=Jf7X0B+gw@mail.gmail.com>
Message-ID: <569E482B.1000703@redhat.com>

Yes, environment variables are expected to work.  Let me write up a bug 
and I can look into the problem today.

Note that this is the code being used to resolve a single property by key:

https://github.com/apiman/apiman/blob/master/common/util/src/main/java/io/apiman/common/util/ApimanStrLookup.java

Here is a JIRA issue for tracking purposes:

https://issues.jboss.org/browse/APIMAN-904

-Eric

On 1/19/2016 5:44 AM, Ton Swieb wrote:
> Hi,
>
> I just tried it with a system property instead of a environment
> property. With a system property it works, but they are a bit cumbersome
> to supply to the apiman-wildfly docker image.
> Are environment variables expected to work?
>
> Regards, Ton
>
>
>
> 2016-01-19 11:25 GMT+01:00 Ton Swieb <ton at finalist.nl
> <mailto:ton at finalist.nl>>:
>
>     Hi,
>
>     I tried to take the property placeholder functionality for a test
>     drive, which should be available as of v1.2.0.Final. See JIRA:
>     https://issues.jboss.org/browse/APIMAN-831
>
>     But for some reason I do not get it to work. Did I configure
>     something wrong or am I running into a bug?
>
>     I use the property placeholder in the keycloak plugin which is
>     preconfigured in a Docker image.
>     I defined the realm property of the Keycloak plugin as
>     ${external_url}/auth/realms/apiman
>
>     I started my Docker image with the -e
>     external_url=https://192.168.99.100:8443 parameter to set the
>     environment variable within the Docker container.
>
>     When I try to access the API I get a failure in Keycloak Plugin saying:
>
>     {
>        "type": "Authentication",
>        "failureCode": 11004,
>        "responseCode": 401,
>        "message": "Token audience doesn't match domain. Token issuer ishttps://192.168.99.100:8443/auth/realms/apiman, but URL from configuration is ${external_url}/auth/realms/apiman",
>        "headers": {}
>     }
>
>     It looks like the property placeholder did not get resolved correctly.
>
>     When I have a look in the Docker image using docker exec -ti <name>
>     /binbash and do a list of the environment variables. The environment
>     variable is correctly defined:
>     MacBook-Pro-van-Ton:~ ton$ docker exec -ti tiny_wilson /bin/bash
>     [jboss at 43c099aae441 ~]$ export
>     declare -x APIMAN_VERSION="1.2.0.Final"
>     ....
>     declare -x external_url="https://192.168.99.100:8443"
>
>     I also tried setting the property to ${external_url} without the
>     '/auth/realms/apiman' suffix. I figured that it might perhaps will
>     do a full String comparison, but that did not work either.
>
>     Any ideas?
>
>     Regards, Ton
>
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From eric.wittmann at redhat.com  Tue Jan 19 09:47:45 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 19 Jan 2016 09:47:45 -0500
Subject: [Apiman-user] Apiman & Loadbalancer F5 !
In-Reply-To: <569E1030.9020608@redhat.com>
References: <569E1030.9020608@redhat.com>
Message-ID: <569E4C91.9090909@redhat.com>

Hi Charles.  I'm not 100% certain I understand all aspects of your 
question - perhaps a diagram would help me, in case my answer doesn't 
make sense (and if you have the time).  :)

You are right that there is no 1..N mapping of an apiman service/api to 
a back-end endpoint URL.  That is a feature we are contemplating for the 
future but it's certainly not available yet.

Here are some thoughts that might be useful/relevant to this use case. 
First is that you could of course implement a custom policy that changed 
the back-end endpoint URL based on whatever criteria you see fit.  The 
custom policy would simply have to change the value of the 
ApiRequest->Api:endpoint field.  Doing that should be considered unsafe 
and a temporary workaround, as the Api object is globally scoped, and 
really should be either cloned (if we want to suppor this use-case) or 
immutable (if we don't).

Another thing to note is that as of 1.2.0.Final we support system 
property and environment variable replacements in the API endpoint, 
endpoint properties, and all policy configurations.  This means that you 
could install *identical* gateways on all the per fuse server, 
configured using the same shared registry.  Then, when you configure the 
Service/API endpoint, you could set the value to something like:

${external_url}

Then you could set a system property, which could be different for each 
gateway node, like so:

(on gateway server 1)
-Dexternal_url=http://fuse_server_1:port/

(on gateway server 2)
-Dexternal_url=http://fuse_server_2:port/

That way your configuration is shared but certain aspects/properties of 
the configuration are *externalized*.

This feature was originally meant to support more easily migrating data 
between dev/test/prod environments, but it would work fine for this as well.

Did any of that help?

-Eric


On 1/19/2016 5:30 AM, Charles Moulliard wrote:
> Hi,
>
> If I use a loadbalancer (= F5) exposing a physical IP address (= routed
> on internet) and calling one of our endpoints (REST, ...) running into
> different integration servers (Fuse + Camel), can we design such topology ?
>
> We setup an Apiman Manager  (Front + ElasticSearch Database) to define
> the plans, services, roles, policies of all the endpoints which are
> running into different Fuse Servers. As the mapping between the incoming
> request and the endpoint is managed by the Apiman Gateway, I'm thinking
> to install one Apiman Gateway / Fuse Server.
> Is it doable ?
>
> Client --> 192.168.1.1 (IP Address of the Server replying to a REST
> Service) "Loadbalancer F5" --> NAT --> address of the gateway (=
> 10.0.2.1) managing the mapping between the request and the physical
> endpoint --> Camel REST Endpoint (10.0.1.1). The Apiman Manager could
> run internally on this addess (10.0.2.100).
>
> To support high availability or workload distribution, it will be
> required that at least each Camel REST / Web Service runs into multiple
> instances of Fuse Servers. That means that their IP address will be
> different (A REST service will be deployed on 10.0.1.1, 10.0.1.2,
> 10.0.1.3, ...).
>
> Question : As the GUI interface of the Apiman Manager to encode the
> address of the endpoint to map proposes one field (and no more if we
> would like to distribute the requests to different servers), is there a
> possibility to define a 1 to many relation into ApiMan Server (maybe if
> we develop such a feature) or do I have also to install an Apiman
> Manager / Gateway per Fuse Server and to encode the same info (plans,
> services, ...) excepted the IP address of the server which is different ?
>
> Regards,
>
> Charles
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From uvax at informatica.com  Tue Jan 19 09:55:51 2016
From: uvax at informatica.com (Vax, Uri)
Date: Tue, 19 Jan 2016 14:55:51 +0000
Subject: [Apiman-user] Rate-limit policy does not work in APIMan cluster
In-Reply-To: <569E4097.40502@redhat.com>
References: <BN1PR0301MB076933C440348631FD07BA55C0C00@BN1PR0301MB0769.namprd03.prod.outlook.com>
	<CALvAxYvnH5yXUZdhZka7mUYaR0pUFoknCae_PqyH0e62Ft8=oA@mail.gmail.com>
	<BN1PR0301MB0769C5476BD8B9991F192AC0C0C00@BN1PR0301MB0769.namprd03.prod.outlook.com>
	<569E4097.40502@redhat.com>
Message-ID: <BN1PR0301MB076956C8AB403A15B47942FFC0C10@BN1PR0301MB0769.namprd03.prod.outlook.com>

apiman.properties files attached .

Talinux3 = Node1
Talinux1 = Node2

-----Original Message-----
From: Eric Wittmann [mailto:eric.wittmann at redhat.com] 
Sent: Tuesday, January 19, 2016 3:57 PM
To: Vax, Uri; Jakub ?ech??ek
Cc: apiman-user at lists.jboss.org
Subject: Re: [Apiman-user] Rate-limit policy does not work in APIMan cluster

Are you 100% sure that the Gateway on Node1 and Node2 are sharing the same Elasticsearch instance?  From your description it sounds like perhaps they are not (e.g. the rateBucket being initialized after the request to Node2).

Perhaps you could send us the apiman.properties files from *each* of your two nodes?

Regards,

Eric

On 1/18/2016 9:03 AM, Vax, Uri wrote:
> The cluster:
>
> Two Linux machines
>
> *Node1*: Gateway + Manager + Elastic Search
>
> *Node2*: Gateway
>
> Node1 and Node2 share same Elastic Search.
>
> Maybe I missing something?
>
> By the way? not sure, but I noticed that the value of *rateBucket* has 
> been initialized after the request to Node2
>
> {
>
>          "_index": "apiman_gateway",
>
>          "_type": "rateBucket",
>
>          "_id": "UFVCTElDfHx8fGxvY2FsfHxzfHwxLjA=",
>
>          "_score": 1,
>
>          "_source": {
>
>            "count": 1,
>
>            "last": 1453115651374
>
>          }
>
> *From:*Jakub ?ech??ek [mailto:jcechace at gmail.com]
> *Sent:* Monday, January 18, 2016 3:33 PM
> *To:* Vax, Uri
> *Cc:* apiman-user at lists.jboss.org
> *Subject:* Re: [Apiman-user] Rate-limit policy does not work in APIMan 
> cluster
>
> Hello,
>
> could you please describe the setup/topology of your "cluster"?  The 
> HA setup of apiman takes advantage of the fact that state is shared 
> only inside ES -- so you should be good as long as you share one ES 
> cluster among all gateways. Thus it is not really a cluster.
>
> Jakub.
>
> On Mon, Jan 18, 2016 at 1:10 PM, Vax, Uri <uvax at informatica.com 
> <mailto:uvax at informatica.com>> wrote:
>
> Hi
>
> I?m using APIMan 1.1.9.
>
> It seems like Rate-limit policy does not work properly when there are 
> several nodes (node1, node2).
>
> *_The scenario:_*
>
> ?Setup up an APIMan cluster with two nodes (node1 , node2).
>
> ?Create a service with a rate-limit policy of 5 request per minute
>
> ?Send requests to the service using postman (or any other http client):
>
> oSend requests to node1 until rate limit is exceeded
>
> oSend another request to node2 ? APIMan will pass the request to the 
> service end-point API instead of returning the ?Rate limit exceeded?
> response
>
> Thanks,
>
> Uri
>
>
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apiman.properties.talinux1
Type: application/octet-stream
Size: 8352 bytes
Desc: apiman.properties.talinux1
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20160119/9fe69620/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apiman.properties.talinux3
Type: application/octet-stream
Size: 8352 bytes
Desc: apiman.properties.talinux3
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20160119/9fe69620/attachment-0003.obj 

From eric.wittmann at redhat.com  Tue Jan 19 10:57:31 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 19 Jan 2016 10:57:31 -0500
Subject: [Apiman-user] Rate-limit policy does not work in APIMan cluster
In-Reply-To: <BN1PR0301MB076956C8AB403A15B47942FFC0C10@BN1PR0301MB0769.namprd03.prod.outlook.com>
References: <BN1PR0301MB076933C440348631FD07BA55C0C00@BN1PR0301MB0769.namprd03.prod.outlook.com>
	<CALvAxYvnH5yXUZdhZka7mUYaR0pUFoknCae_PqyH0e62Ft8=oA@mail.gmail.com>
	<BN1PR0301MB0769C5476BD8B9991F192AC0C0C00@BN1PR0301MB0769.namprd03.prod.outlook.com>
	<569E4097.40502@redhat.com>
	<BN1PR0301MB076956C8AB403A15B47942FFC0C10@BN1PR0301MB0769.namprd03.prod.outlook.com>
Message-ID: <569E5CEB.2040808@redhat.com>

Thanks - those settings look fine to me.  I'll try to reproduce this 
today and see what I get.  I'll report back when I have some information.

-Eric

On 1/19/2016 9:55 AM, Vax, Uri wrote:
> apiman.properties files attached .
>
> Talinux3 = Node1
> Talinux1 = Node2
>
> -----Original Message-----
> From: Eric Wittmann [mailto:eric.wittmann at redhat.com]
> Sent: Tuesday, January 19, 2016 3:57 PM
> To: Vax, Uri; Jakub ?ech??ek
> Cc: apiman-user at lists.jboss.org
> Subject: Re: [Apiman-user] Rate-limit policy does not work in APIMan cluster
>
> Are you 100% sure that the Gateway on Node1 and Node2 are sharing the same Elasticsearch instance?  From your description it sounds like perhaps they are not (e.g. the rateBucket being initialized after the request to Node2).
>
> Perhaps you could send us the apiman.properties files from *each* of your two nodes?
>
> Regards,
>
> Eric
>
> On 1/18/2016 9:03 AM, Vax, Uri wrote:
>> The cluster:
>>
>> Two Linux machines
>>
>> *Node1*: Gateway + Manager + Elastic Search
>>
>> *Node2*: Gateway
>>
>> Node1 and Node2 share same Elastic Search.
>>
>> Maybe I missing something?
>>
>> By the way? not sure, but I noticed that the value of *rateBucket* has
>> been initialized after the request to Node2
>>
>> {
>>
>>           "_index": "apiman_gateway",
>>
>>           "_type": "rateBucket",
>>
>>           "_id": "UFVCTElDfHx8fGxvY2FsfHxzfHwxLjA=",
>>
>>           "_score": 1,
>>
>>           "_source": {
>>
>>             "count": 1,
>>
>>             "last": 1453115651374
>>
>>           }
>>
>> *From:*Jakub ?ech??ek [mailto:jcechace at gmail.com]
>> *Sent:* Monday, January 18, 2016 3:33 PM
>> *To:* Vax, Uri
>> *Cc:* apiman-user at lists.jboss.org
>> *Subject:* Re: [Apiman-user] Rate-limit policy does not work in APIMan
>> cluster
>>
>> Hello,
>>
>> could you please describe the setup/topology of your "cluster"?  The
>> HA setup of apiman takes advantage of the fact that state is shared
>> only inside ES -- so you should be good as long as you share one ES
>> cluster among all gateways. Thus it is not really a cluster.
>>
>> Jakub.
>>
>> On Mon, Jan 18, 2016 at 1:10 PM, Vax, Uri <uvax at informatica.com
>> <mailto:uvax at informatica.com>> wrote:
>>
>> Hi
>>
>> I?m using APIMan 1.1.9.
>>
>> It seems like Rate-limit policy does not work properly when there are
>> several nodes (node1, node2).
>>
>> *_The scenario:_*
>>
>> ?Setup up an APIMan cluster with two nodes (node1 , node2).
>>
>> ?Create a service with a rate-limit policy of 5 request per minute
>>
>> ?Send requests to the service using postman (or any other http client):
>>
>> oSend requests to node1 until rate limit is exceeded
>>
>> oSend another request to node2 ? APIMan will pass the request to the
>> service end-point API instead of returning the ?Rate limit exceeded?
>> response
>>
>> Thanks,
>>
>> Uri
>>
>>
>> _______________________________________________
>> 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
>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>

From eric.wittmann at redhat.com  Tue Jan 19 14:53:25 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 19 Jan 2016 14:53:25 -0500
Subject: [Apiman-user] Rate-limit policy does not work in APIMan cluster
In-Reply-To: <BN1PR0301MB076956C8AB403A15B47942FFC0C10@BN1PR0301MB0769.namprd03.prod.outlook.com>
References: <BN1PR0301MB076933C440348631FD07BA55C0C00@BN1PR0301MB0769.namprd03.prod.outlook.com>
	<CALvAxYvnH5yXUZdhZka7mUYaR0pUFoknCae_PqyH0e62Ft8=oA@mail.gmail.com>
	<BN1PR0301MB0769C5476BD8B9991F192AC0C0C00@BN1PR0301MB0769.namprd03.prod.outlook.com>
	<569E4097.40502@redhat.com>
	<BN1PR0301MB076956C8AB403A15B47942FFC0C10@BN1PR0301MB0769.namprd03.prod.outlook.com>
Message-ID: <569E9435.6020301@redhat.com>

Hi Uri.

I just did some testing on a couple of machines and everything worked as 
expected for me.

However, I wonder if perhaps you don't have your two servers 
time-sync'd?  If the times aren't the same on all the servers, then the 
time-window logic in the rate limiting code will be inconsistent at best.

I initially had some trouble with this, but once I installed ntp on both 
my machines then everything worked fine.

-Eric

On 1/19/2016 9:55 AM, Vax, Uri wrote:
> apiman.properties files attached .
>
> Talinux3 = Node1
> Talinux1 = Node2
>
> -----Original Message-----
> From: Eric Wittmann [mailto:eric.wittmann at redhat.com]
> Sent: Tuesday, January 19, 2016 3:57 PM
> To: Vax, Uri; Jakub ?ech??ek
> Cc: apiman-user at lists.jboss.org
> Subject: Re: [Apiman-user] Rate-limit policy does not work in APIMan cluster
>
> Are you 100% sure that the Gateway on Node1 and Node2 are sharing the same Elasticsearch instance?  From your description it sounds like perhaps they are not (e.g. the rateBucket being initialized after the request to Node2).
>
> Perhaps you could send us the apiman.properties files from *each* of your two nodes?
>
> Regards,
>
> Eric
>
> On 1/18/2016 9:03 AM, Vax, Uri wrote:
>> The cluster:
>>
>> Two Linux machines
>>
>> *Node1*: Gateway + Manager + Elastic Search
>>
>> *Node2*: Gateway
>>
>> Node1 and Node2 share same Elastic Search.
>>
>> Maybe I missing something?
>>
>> By the way? not sure, but I noticed that the value of *rateBucket* has
>> been initialized after the request to Node2
>>
>> {
>>
>>           "_index": "apiman_gateway",
>>
>>           "_type": "rateBucket",
>>
>>           "_id": "UFVCTElDfHx8fGxvY2FsfHxzfHwxLjA=",
>>
>>           "_score": 1,
>>
>>           "_source": {
>>
>>             "count": 1,
>>
>>             "last": 1453115651374
>>
>>           }
>>
>> *From:*Jakub ?ech??ek [mailto:jcechace at gmail.com]
>> *Sent:* Monday, January 18, 2016 3:33 PM
>> *To:* Vax, Uri
>> *Cc:* apiman-user at lists.jboss.org
>> *Subject:* Re: [Apiman-user] Rate-limit policy does not work in APIMan
>> cluster
>>
>> Hello,
>>
>> could you please describe the setup/topology of your "cluster"?  The
>> HA setup of apiman takes advantage of the fact that state is shared
>> only inside ES -- so you should be good as long as you share one ES
>> cluster among all gateways. Thus it is not really a cluster.
>>
>> Jakub.
>>
>> On Mon, Jan 18, 2016 at 1:10 PM, Vax, Uri <uvax at informatica.com
>> <mailto:uvax at informatica.com>> wrote:
>>
>> Hi
>>
>> I?m using APIMan 1.1.9.
>>
>> It seems like Rate-limit policy does not work properly when there are
>> several nodes (node1, node2).
>>
>> *_The scenario:_*
>>
>> ?Setup up an APIMan cluster with two nodes (node1 , node2).
>>
>> ?Create a service with a rate-limit policy of 5 request per minute
>>
>> ?Send requests to the service using postman (or any other http client):
>>
>> oSend requests to node1 until rate limit is exceeded
>>
>> oSend another request to node2 ? APIMan will pass the request to the
>> service end-point API instead of returning the ?Rate limit exceeded?
>> response
>>
>> Thanks,
>>
>> Uri
>>
>>
>> _______________________________________________
>> 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
>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>

From gwolfman at Informatica.com  Tue Jan 19 15:52:14 2016
From: gwolfman at Informatica.com (Wolfman, Gadi)
Date: Tue, 19 Jan 2016 20:52:14 +0000
Subject: [Apiman-user] Rate-limit policy does not work in APIMan cluster
In-Reply-To: <569E9435.6020301@redhat.com>
References: <BN1PR0301MB076933C440348631FD07BA55C0C00@BN1PR0301MB0769.namprd03.prod.outlook.com>
	<CALvAxYvnH5yXUZdhZka7mUYaR0pUFoknCae_PqyH0e62Ft8=oA@mail.gmail.com>
	<BN1PR0301MB0769C5476BD8B9991F192AC0C0C00@BN1PR0301MB0769.namprd03.prod.outlook.com>
	<569E4097.40502@redhat.com>
	<BN1PR0301MB076956C8AB403A15B47942FFC0C10@BN1PR0301MB0769.namprd03.prod.outlook.com>,
	<569E9435.6020301@redhat.com>
Message-ID: <5mnpqpyghcl6g8e1tnc372sl.1453236729348@email.android.com>

+Shay
See question regarding clock synchronization


Sent from my Samsung Galaxy smartphone.


-------- Original message --------
From: Eric Wittmann <eric.wittmann at redhat.com>
Date:19/01/2016 21:53 (GMT+02:00)
To: "Vax, Uri" <uvax at informatica.com>, Jakub ?ech??ek <jcechace at gmail.com>
Cc: apiman-user at lists.jboss.org
Subject: Re: [Apiman-user] Rate-limit policy does not work in APIMan cluster

Hi Uri.

I just did some testing on a couple of machines and everything worked as
expected for me.

However, I wonder if perhaps you don't have your two servers
time-sync'd?  If the times aren't the same on all the servers, then the
time-window logic in the rate limiting code will be inconsistent at best.

I initially had some trouble with this, but once I installed ntp on both
my machines then everything worked fine.

-Eric

On 1/19/2016 9:55 AM, Vax, Uri wrote:
> apiman.properties files attached .
>
> Talinux3 = Node1
> Talinux1 = Node2
>
> -----Original Message-----
> From: Eric Wittmann [mailto:eric.wittmann at redhat.com]
> Sent: Tuesday, January 19, 2016 3:57 PM
> To: Vax, Uri; Jakub ?ech??ek
> Cc: apiman-user at lists.jboss.org
> Subject: Re: [Apiman-user] Rate-limit policy does not work in APIMan cluster
>
> Are you 100% sure that the Gateway on Node1 and Node2 are sharing the same Elasticsearch instance?  From your description it sounds like perhaps they are not (e.g. the rateBucket being initialized after the request to Node2).
>
> Perhaps you could send us the apiman.properties files from *each* of your two nodes?
>
> Regards,
>
> Eric
>
> On 1/18/2016 9:03 AM, Vax, Uri wrote:
>> The cluster:
>>
>> Two Linux machines
>>
>> *Node1*: Gateway + Manager + Elastic Search
>>
>> *Node2*: Gateway
>>
>> Node1 and Node2 share same Elastic Search.
>>
>> Maybe I missing something?
>>
>> By the way? not sure, but I noticed that the value of *rateBucket* has
>> been initialized after the request to Node2
>>
>> {
>>
>>           "_index": "apiman_gateway",
>>
>>           "_type": "rateBucket",
>>
>>           "_id": "UFVCTElDfHx8fGxvY2FsfHxzfHwxLjA=",
>>
>>           "_score": 1,
>>
>>           "_source": {
>>
>>             "count": 1,
>>
>>             "last": 1453115651374
>>
>>           }
>>
>> *From:*Jakub ?ech??ek [mailto:jcechace at gmail.com]
>> *Sent:* Monday, January 18, 2016 3:33 PM
>> *To:* Vax, Uri
>> *Cc:* apiman-user at lists.jboss.org
>> *Subject:* Re: [Apiman-user] Rate-limit policy does not work in APIMan
>> cluster
>>
>> Hello,
>>
>> could you please describe the setup/topology of your "cluster"?  The
>> HA setup of apiman takes advantage of the fact that state is shared
>> only inside ES -- so you should be good as long as you share one ES
>> cluster among all gateways. Thus it is not really a cluster.
>>
>> Jakub.
>>
>> On Mon, Jan 18, 2016 at 1:10 PM, Vax, Uri <uvax at informatica.com
>> <mailto:uvax at informatica.com>> wrote:
>>
>> Hi
>>
>> I?m using APIMan 1.1.9.
>>
>> It seems like Rate-limit policy does not work properly when there are
>> several nodes (node1, node2).
>>
>> *_The scenario:_*
>>
>> ?Setup up an APIMan cluster with two nodes (node1 , node2).
>>
>> ?Create a service with a rate-limit policy of 5 request per minute
>>
>> ?Send requests to the service using postman (or any other http client):
>>
>> oSend requests to node1 until rate limit is exceeded
>>
>> oSend another request to node2 ? APIMan will pass the request to the
>> service end-point API instead of returning the ?Rate limit exceeded?
>> response
>>
>> Thanks,
>>
>> Uri
>>
>>
>> _______________________________________________
>> 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
>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
_______________________________________________
Apiman-user mailing list
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/20160119/939b1862/attachment.html 

From cmoulliard at redhat.com  Wed Jan 20 03:26:02 2016
From: cmoulliard at redhat.com (Charles Moulliard)
Date: Wed, 20 Jan 2016 09:26:02 +0100
Subject: [Apiman-user] Apiman & Loadbalancer F5 !
In-Reply-To: <569E4C91.9090909@redhat.com>
References: <569E1030.9020608@redhat.com> <569E4C91.9090909@redhat.com>
Message-ID: <569F449A.2060409@redhat.com>

Hi Eric,

Here is a diagram that I have created based on your response. I think 
that it should confirm what we have discussed - correct ?

Regards,

Charles
On 19/01/16 15:47, Eric Wittmann wrote:
> Hi Charles.  I'm not 100% certain I understand all aspects of your 
> question - perhaps a diagram would help me, in case my answer doesn't 
> make sense (and if you have the time).  :)
>
> You are right that there is no 1..N mapping of an apiman service/api 
> to a back-end endpoint URL.  That is a feature we are contemplating 
> for the future but it's certainly not available yet.
>
> Here are some thoughts that might be useful/relevant to this use case. 
> First is that you could of course implement a custom policy that 
> changed the back-end endpoint URL based on whatever criteria you see 
> fit.  The custom policy would simply have to change the value of the 
> ApiRequest->Api:endpoint field.  Doing that should be considered 
> unsafe and a temporary workaround, as the Api object is globally 
> scoped, and really should be either cloned (if we want to suppor this 
> use-case) or immutable (if we don't).
>
> Another thing to note is that as of 1.2.0.Final we support system 
> property and environment variable replacements in the API endpoint, 
> endpoint properties, and all policy configurations. This means that 
> you could install *identical* gateways on all the per fuse server, 
> configured using the same shared registry.  Then, when you configure 
> the Service/API endpoint, you could set the value to something like:
>
> ${external_url}
>
> Then you could set a system property, which could be different for 
> each gateway node, like so:
>
> (on gateway server 1)
> -Dexternal_url=http://fuse_server_1:port/
>
> (on gateway server 2)
> -Dexternal_url=http://fuse_server_2:port/
>
> That way your configuration is shared but certain aspects/properties 
> of the configuration are *externalized*.
>
> This feature was originally meant to support more easily migrating 
> data between dev/test/prod environments, but it would work fine for 
> this as well.
>
> Did any of that help?
>
> -Eric
>
>
> On 1/19/2016 5:30 AM, Charles Moulliard wrote:
>> Hi,
>>
>> If I use a loadbalancer (= F5) exposing a physical IP address (= routed
>> on internet) and calling one of our endpoints (REST, ...) running into
>> different integration servers (Fuse + Camel), can we design such 
>> topology ?
>>
>> We setup an Apiman Manager  (Front + ElasticSearch Database) to define
>> the plans, services, roles, policies of all the endpoints which are
>> running into different Fuse Servers. As the mapping between the incoming
>> request and the endpoint is managed by the Apiman Gateway, I'm thinking
>> to install one Apiman Gateway / Fuse Server.
>> Is it doable ?
>>
>> Client --> 192.168.1.1 (IP Address of the Server replying to a REST
>> Service) "Loadbalancer F5" --> NAT --> address of the gateway (=
>> 10.0.2.1) managing the mapping between the request and the physical
>> endpoint --> Camel REST Endpoint (10.0.1.1). The Apiman Manager could
>> run internally on this addess (10.0.2.100).
>>
>> To support high availability or workload distribution, it will be
>> required that at least each Camel REST / Web Service runs into multiple
>> instances of Fuse Servers. That means that their IP address will be
>> different (A REST service will be deployed on 10.0.1.1, 10.0.1.2,
>> 10.0.1.3, ...).
>>
>> Question : As the GUI interface of the Apiman Manager to encode the
>> address of the endpoint to map proposes one field (and no more if we
>> would like to distribute the requests to different servers), is there a
>> possibility to define a 1 to many relation into ApiMan Server (maybe if
>> we develop such a feature) or do I have also to install an Apiman
>> Manager / Gateway per Fuse Server and to encode the same info (plans,
>> services, ...) excepted the IP address of the server which is 
>> different ?
>>
>> Regards,
>>
>> Charles
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: loadbalancing-apiman.png
Type: image/png
Size: 157776 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20160120/277edd67/attachment-0001.png 

From ton at finalist.nl  Wed Jan 20 04:04:04 2016
From: ton at finalist.nl (Ton Swieb)
Date: Wed, 20 Jan 2016 10:04:04 +0100
Subject: [Apiman-user] Property placeholder within policy does not
 resolve in the gateway (v1.2.0.Final / APIMAN-831)
In-Reply-To: <569E482B.1000703@redhat.com>
References: <CAJJ5CnQE=QKpSU8btGtWJ7x2Be7o2Lp+vb7r-4ekL60nZyZXPA@mail.gmail.com>
	<CAJJ5CnSigVVmVKqUdB0Oz3xc3MsaTFT8cGDN+WHV=Jf7X0B+gw@mail.gmail.com>
	<569E482B.1000703@redhat.com>
Message-ID: <CAJJ5CnSWPpo9HBh8Yud6qadFtnhHUz1Rcis-Q6HRx6EQ0V3C=A@mail.gmail.com>

Hi Eric,

I see in JIRA that you found the bug. Good catch. Thanks for the quick
response.
Looking forward to Apiman v1.2.1.Final

Regards, Ton

2016-01-19 15:28 GMT+01:00 Eric Wittmann <eric.wittmann at redhat.com>:

> Yes, environment variables are expected to work.  Let me write up a bug
> and I can look into the problem today.
>
> Note that this is the code being used to resolve a single property by key:
>
>
> https://github.com/apiman/apiman/blob/master/common/util/src/main/java/io/apiman/common/util/ApimanStrLookup.java
>
> Here is a JIRA issue for tracking purposes:
>
> https://issues.jboss.org/browse/APIMAN-904
>
> -Eric
>
> On 1/19/2016 5:44 AM, Ton Swieb wrote:
>
>> Hi,
>>
>> I just tried it with a system property instead of a environment
>> property. With a system property it works, but they are a bit cumbersome
>> to supply to the apiman-wildfly docker image.
>> Are environment variables expected to work?
>>
>> Regards, Ton
>>
>>
>>
>> 2016-01-19 11:25 GMT+01:00 Ton Swieb <ton at finalist.nl
>> <mailto:ton at finalist.nl>>:
>>
>>     Hi,
>>
>>     I tried to take the property placeholder functionality for a test
>>     drive, which should be available as of v1.2.0.Final. See JIRA:
>>     https://issues.jboss.org/browse/APIMAN-831
>>
>>     But for some reason I do not get it to work. Did I configure
>>     something wrong or am I running into a bug?
>>
>>     I use the property placeholder in the keycloak plugin which is
>>     preconfigured in a Docker image.
>>     I defined the realm property of the Keycloak plugin as
>>     ${external_url}/auth/realms/apiman
>>
>>     I started my Docker image with the -e
>>     external_url=https://192.168.99.100:8443 parameter to set the
>>     environment variable within the Docker container.
>>
>>     When I try to access the API I get a failure in Keycloak Plugin
>> saying:
>>
>>     {
>>        "type": "Authentication",
>>        "failureCode": 11004,
>>        "responseCode": 401,
>>        "message": "Token audience doesn't match domain. Token issuer
>> ishttps://192.168.99.100:8443/auth/realms/apiman, but URL from
>> configuration is ${external_url}/auth/realms/apiman",
>>        "headers": {}
>>     }
>>
>>     It looks like the property placeholder did not get resolved correctly.
>>
>>     When I have a look in the Docker image using docker exec -ti <name>
>>     /binbash and do a list of the environment variables. The environment
>>     variable is correctly defined:
>>     MacBook-Pro-van-Ton:~ ton$ docker exec -ti tiny_wilson /bin/bash
>>     [jboss at 43c099aae441 ~]$ export
>>     declare -x APIMAN_VERSION="1.2.0.Final"
>>     ....
>>     declare -x external_url="https://192.168.99.100:8443"
>>
>>     I also tried setting the property to ${external_url} without the
>>     '/auth/realms/apiman' suffix. I figured that it might perhaps will
>>     do a full String comparison, but that did not work either.
>>
>>     Any ideas?
>>
>>     Regards, Ton
>>
>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> 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/20160120/eb6e4457/attachment.html 

From eric.wittmann at redhat.com  Wed Jan 20 05:25:46 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Wed, 20 Jan 2016 05:25:46 -0500
Subject: [Apiman-user] Apiman & Loadbalancer F5 !
In-Reply-To: <569F449A.2060409@redhat.com>
References: <569E1030.9020608@redhat.com> <569E4C91.9090909@redhat.com>
	<569F449A.2060409@redhat.com>
Message-ID: <569F60AA.7050802@redhat.com>

That looks correct.

-Eric

On 1/20/2016 3:26 AM, Charles Moulliard wrote:
> Hi Eric,
>
> Here is a diagram that I have created based on your response. I think
> that it should confirm what we have discussed - correct ?
>
> Regards,
>
> Charles
> On 19/01/16 15:47, Eric Wittmann wrote:
>> Hi Charles.  I'm not 100% certain I understand all aspects of your
>> question - perhaps a diagram would help me, in case my answer doesn't
>> make sense (and if you have the time).  :)
>>
>> You are right that there is no 1..N mapping of an apiman service/api
>> to a back-end endpoint URL.  That is a feature we are contemplating
>> for the future but it's certainly not available yet.
>>
>> Here are some thoughts that might be useful/relevant to this use case.
>> First is that you could of course implement a custom policy that
>> changed the back-end endpoint URL based on whatever criteria you see
>> fit.  The custom policy would simply have to change the value of the
>> ApiRequest->Api:endpoint field.  Doing that should be considered
>> unsafe and a temporary workaround, as the Api object is globally
>> scoped, and really should be either cloned (if we want to suppor this
>> use-case) or immutable (if we don't).
>>
>> Another thing to note is that as of 1.2.0.Final we support system
>> property and environment variable replacements in the API endpoint,
>> endpoint properties, and all policy configurations. This means that
>> you could install *identical* gateways on all the per fuse server,
>> configured using the same shared registry.  Then, when you configure
>> the Service/API endpoint, you could set the value to something like:
>>
>> ${external_url}
>>
>> Then you could set a system property, which could be different for
>> each gateway node, like so:
>>
>> (on gateway server 1)
>> -Dexternal_url=http://fuse_server_1:port/
>>
>> (on gateway server 2)
>> -Dexternal_url=http://fuse_server_2:port/
>>
>> That way your configuration is shared but certain aspects/properties
>> of the configuration are *externalized*.
>>
>> This feature was originally meant to support more easily migrating
>> data between dev/test/prod environments, but it would work fine for
>> this as well.
>>
>> Did any of that help?
>>
>> -Eric
>>
>>
>> On 1/19/2016 5:30 AM, Charles Moulliard wrote:
>>> Hi,
>>>
>>> If I use a loadbalancer (= F5) exposing a physical IP address (= routed
>>> on internet) and calling one of our endpoints (REST, ...) running into
>>> different integration servers (Fuse + Camel), can we design such
>>> topology ?
>>>
>>> We setup an Apiman Manager  (Front + ElasticSearch Database) to define
>>> the plans, services, roles, policies of all the endpoints which are
>>> running into different Fuse Servers. As the mapping between the incoming
>>> request and the endpoint is managed by the Apiman Gateway, I'm thinking
>>> to install one Apiman Gateway / Fuse Server.
>>> Is it doable ?
>>>
>>> Client --> 192.168.1.1 (IP Address of the Server replying to a REST
>>> Service) "Loadbalancer F5" --> NAT --> address of the gateway (=
>>> 10.0.2.1) managing the mapping between the request and the physical
>>> endpoint --> Camel REST Endpoint (10.0.1.1). The Apiman Manager could
>>> run internally on this addess (10.0.2.100).
>>>
>>> To support high availability or workload distribution, it will be
>>> required that at least each Camel REST / Web Service runs into multiple
>>> instances of Fuse Servers. That means that their IP address will be
>>> different (A REST service will be deployed on 10.0.1.1, 10.0.1.2,
>>> 10.0.1.3, ...).
>>>
>>> Question : As the GUI interface of the Apiman Manager to encode the
>>> address of the endpoint to map proposes one field (and no more if we
>>> would like to distribute the requests to different servers), is there a
>>> possibility to define a 1 to many relation into ApiMan Server (maybe if
>>> we develop such a feature) or do I have also to install an Apiman
>>> Manager / Gateway per Fuse Server and to encode the same info (plans,
>>> services, ...) excepted the IP address of the server which is
>>> different ?
>>>
>>> Regards,
>>>
>>> Charles
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>

From uvax at informatica.com  Wed Jan 20 05:34:27 2016
From: uvax at informatica.com (Vax, Uri)
Date: Wed, 20 Jan 2016 10:34:27 +0000
Subject: [Apiman-user] Rate-limit policy does not work in APIMan cluster
In-Reply-To: <569E9435.6020301@redhat.com>
References: <BN1PR0301MB076933C440348631FD07BA55C0C00@BN1PR0301MB0769.namprd03.prod.outlook.com>
	<CALvAxYvnH5yXUZdhZka7mUYaR0pUFoknCae_PqyH0e62Ft8=oA@mail.gmail.com>
	<BN1PR0301MB0769C5476BD8B9991F192AC0C0C00@BN1PR0301MB0769.namprd03.prod.outlook.com>
	<569E4097.40502@redhat.com>
	<BN1PR0301MB076956C8AB403A15B47942FFC0C10@BN1PR0301MB0769.namprd03.prod.outlook.com>
	<569E9435.6020301@redhat.com>
Message-ID: <BN1PR0301MB076913CFCE0890C37CF07768C0C20@BN1PR0301MB0769.namprd03.prod.outlook.com>

Hi Eric, 
It was indeed the sync issue. 
Now the servers are time-sync'd and the rate limit works properly. 

Thanks,
Uri



-----Original Message-----
From: Eric Wittmann [mailto:eric.wittmann at redhat.com] 
Sent: Tuesday, January 19, 2016 9:53 PM
To: Vax, Uri; Jakub ?ech??ek
Cc: apiman-user at lists.jboss.org
Subject: Re: [Apiman-user] Rate-limit policy does not work in APIMan cluster

Hi Uri.

I just did some testing on a couple of machines and everything worked as expected for me.

However, I wonder if perhaps you don't have your two servers time-sync'd?  If the times aren't the same on all the servers, then the time-window logic in the rate limiting code will be inconsistent at best.

I initially had some trouble with this, but once I installed ntp on both my machines then everything worked fine.

-Eric

On 1/19/2016 9:55 AM, Vax, Uri wrote:
> apiman.properties files attached .
>
> Talinux3 = Node1
> Talinux1 = Node2
>
> -----Original Message-----
> From: Eric Wittmann [mailto:eric.wittmann at redhat.com]
> Sent: Tuesday, January 19, 2016 3:57 PM
> To: Vax, Uri; Jakub ?ech??ek
> Cc: apiman-user at lists.jboss.org
> Subject: Re: [Apiman-user] Rate-limit policy does not work in APIMan 
> cluster
>
> Are you 100% sure that the Gateway on Node1 and Node2 are sharing the same Elasticsearch instance?  From your description it sounds like perhaps they are not (e.g. the rateBucket being initialized after the request to Node2).
>
> Perhaps you could send us the apiman.properties files from *each* of your two nodes?
>
> Regards,
>
> Eric
>
> On 1/18/2016 9:03 AM, Vax, Uri wrote:
>> The cluster:
>>
>> Two Linux machines
>>
>> *Node1*: Gateway + Manager + Elastic Search
>>
>> *Node2*: Gateway
>>
>> Node1 and Node2 share same Elastic Search.
>>
>> Maybe I missing something?
>>
>> By the way? not sure, but I noticed that the value of *rateBucket* 
>> has been initialized after the request to Node2
>>
>> {
>>
>>           "_index": "apiman_gateway",
>>
>>           "_type": "rateBucket",
>>
>>           "_id": "UFVCTElDfHx8fGxvY2FsfHxzfHwxLjA=",
>>
>>           "_score": 1,
>>
>>           "_source": {
>>
>>             "count": 1,
>>
>>             "last": 1453115651374
>>
>>           }
>>
>> *From:*Jakub ?ech??ek [mailto:jcechace at gmail.com]
>> *Sent:* Monday, January 18, 2016 3:33 PM
>> *To:* Vax, Uri
>> *Cc:* apiman-user at lists.jboss.org
>> *Subject:* Re: [Apiman-user] Rate-limit policy does not work in 
>> APIMan cluster
>>
>> Hello,
>>
>> could you please describe the setup/topology of your "cluster"?  The 
>> HA setup of apiman takes advantage of the fact that state is shared 
>> only inside ES -- so you should be good as long as you share one ES 
>> cluster among all gateways. Thus it is not really a cluster.
>>
>> Jakub.
>>
>> On Mon, Jan 18, 2016 at 1:10 PM, Vax, Uri <uvax at informatica.com 
>> <mailto:uvax at informatica.com>> wrote:
>>
>> Hi
>>
>> I?m using APIMan 1.1.9.
>>
>> It seems like Rate-limit policy does not work properly when there are 
>> several nodes (node1, node2).
>>
>> *_The scenario:_*
>>
>> ?Setup up an APIMan cluster with two nodes (node1 , node2).
>>
>> ?Create a service with a rate-limit policy of 5 request per minute
>>
>> ?Send requests to the service using postman (or any other http client):
>>
>> oSend requests to node1 until rate limit is exceeded
>>
>> oSend another request to node2 ? APIMan will pass the request to the 
>> service end-point API instead of returning the ?Rate limit exceeded?
>> response
>>
>> Thanks,
>>
>> Uri
>>
>>
>> _______________________________________________
>> 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
>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>


From eric.wittmann at redhat.com  Wed Jan 20 05:56:42 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Wed, 20 Jan 2016 05:56:42 -0500
Subject: [Apiman-user] Rate-limit policy does not work in APIMan cluster
In-Reply-To: <BN1PR0301MB076913CFCE0890C37CF07768C0C20@BN1PR0301MB0769.namprd03.prod.outlook.com>
References: <BN1PR0301MB076933C440348631FD07BA55C0C00@BN1PR0301MB0769.namprd03.prod.outlook.com>
	<CALvAxYvnH5yXUZdhZka7mUYaR0pUFoknCae_PqyH0e62Ft8=oA@mail.gmail.com>
	<BN1PR0301MB0769C5476BD8B9991F192AC0C0C00@BN1PR0301MB0769.namprd03.prod.outlook.com>
	<569E4097.40502@redhat.com>
	<BN1PR0301MB076956C8AB403A15B47942FFC0C10@BN1PR0301MB0769.namprd03.prod.outlook.com>
	<569E9435.6020301@redhat.com>
	<BN1PR0301MB076913CFCE0890C37CF07768C0C20@BN1PR0301MB0769.namprd03.prod.outlook.com>
Message-ID: <569F67EA.9090602@redhat.com>

Glad to hear it!

On 1/20/2016 5:34 AM, Vax, Uri wrote:
> Hi Eric,
> It was indeed the sync issue.
> Now the servers are time-sync'd and the rate limit works properly.
>
> Thanks,
> Uri
>
>
>
> -----Original Message-----
> From: Eric Wittmann [mailto:eric.wittmann at redhat.com]
> Sent: Tuesday, January 19, 2016 9:53 PM
> To: Vax, Uri; Jakub ?ech??ek
> Cc: apiman-user at lists.jboss.org
> Subject: Re: [Apiman-user] Rate-limit policy does not work in APIMan cluster
>
> Hi Uri.
>
> I just did some testing on a couple of machines and everything worked as expected for me.
>
> However, I wonder if perhaps you don't have your two servers time-sync'd?  If the times aren't the same on all the servers, then the time-window logic in the rate limiting code will be inconsistent at best.
>
> I initially had some trouble with this, but once I installed ntp on both my machines then everything worked fine.
>
> -Eric
>
> On 1/19/2016 9:55 AM, Vax, Uri wrote:
>> apiman.properties files attached .
>>
>> Talinux3 = Node1
>> Talinux1 = Node2
>>
>> -----Original Message-----
>> From: Eric Wittmann [mailto:eric.wittmann at redhat.com]
>> Sent: Tuesday, January 19, 2016 3:57 PM
>> To: Vax, Uri; Jakub ?ech??ek
>> Cc: apiman-user at lists.jboss.org
>> Subject: Re: [Apiman-user] Rate-limit policy does not work in APIMan
>> cluster
>>
>> Are you 100% sure that the Gateway on Node1 and Node2 are sharing the same Elasticsearch instance?  From your description it sounds like perhaps they are not (e.g. the rateBucket being initialized after the request to Node2).
>>
>> Perhaps you could send us the apiman.properties files from *each* of your two nodes?
>>
>> Regards,
>>
>> Eric
>>
>> On 1/18/2016 9:03 AM, Vax, Uri wrote:
>>> The cluster:
>>>
>>> Two Linux machines
>>>
>>> *Node1*: Gateway + Manager + Elastic Search
>>>
>>> *Node2*: Gateway
>>>
>>> Node1 and Node2 share same Elastic Search.
>>>
>>> Maybe I missing something?
>>>
>>> By the way? not sure, but I noticed that the value of *rateBucket*
>>> has been initialized after the request to Node2
>>>
>>> {
>>>
>>>            "_index": "apiman_gateway",
>>>
>>>            "_type": "rateBucket",
>>>
>>>            "_id": "UFVCTElDfHx8fGxvY2FsfHxzfHwxLjA=",
>>>
>>>            "_score": 1,
>>>
>>>            "_source": {
>>>
>>>              "count": 1,
>>>
>>>              "last": 1453115651374
>>>
>>>            }
>>>
>>> *From:*Jakub ?ech??ek [mailto:jcechace at gmail.com]
>>> *Sent:* Monday, January 18, 2016 3:33 PM
>>> *To:* Vax, Uri
>>> *Cc:* apiman-user at lists.jboss.org
>>> *Subject:* Re: [Apiman-user] Rate-limit policy does not work in
>>> APIMan cluster
>>>
>>> Hello,
>>>
>>> could you please describe the setup/topology of your "cluster"?  The
>>> HA setup of apiman takes advantage of the fact that state is shared
>>> only inside ES -- so you should be good as long as you share one ES
>>> cluster among all gateways. Thus it is not really a cluster.
>>>
>>> Jakub.
>>>
>>> On Mon, Jan 18, 2016 at 1:10 PM, Vax, Uri <uvax at informatica.com
>>> <mailto:uvax at informatica.com>> wrote:
>>>
>>> Hi
>>>
>>> I?m using APIMan 1.1.9.
>>>
>>> It seems like Rate-limit policy does not work properly when there are
>>> several nodes (node1, node2).
>>>
>>> *_The scenario:_*
>>>
>>> ?Setup up an APIMan cluster with two nodes (node1 , node2).
>>>
>>> ?Create a service with a rate-limit policy of 5 request per minute
>>>
>>> ?Send requests to the service using postman (or any other http client):
>>>
>>> oSend requests to node1 until rate limit is exceeded
>>>
>>> oSend another request to node2 ? APIMan will pass the request to the
>>> service end-point API instead of returning the ?Rate limit exceeded?
>>> response
>>>
>>> Thanks,
>>>
>>> Uri
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>

From cmoullia at redhat.com  Wed Jan 20 06:24:27 2016
From: cmoullia at redhat.com (Charles Moulliard)
Date: Wed, 20 Jan 2016 06:24:27 -0500 (EST)
Subject: [Apiman-user] Apiman & Loadbalancer F5 !
In-Reply-To: <569F60AA.7050802@redhat.com>
References: <569E1030.9020608@redhat.com> <569E4C91.9090909@redhat.com>
	<569F449A.2060409@redhat.com> <569F60AA.7050802@redhat.com>
Message-ID: <F9C223E2-8871-4F82-9EB5-2CFA2CD6F520@redhat.com>

I missed something on the diagram - the apiman server that admin will use to encode the plans, services, endpoints & policies 

Sent from my iPhone

> On 20 janv. 2016, at 11:25, Eric Wittmann <eric.wittmann at redhat.com> wrote:
> 
> That looks correct.
> 
> -Eric
> 
>> On 1/20/2016 3:26 AM, Charles Moulliard wrote:
>> Hi Eric,
>> 
>> Here is a diagram that I have created based on your response. I think
>> that it should confirm what we have discussed - correct ?
>> 
>> Regards,
>> 
>> Charles
>>> On 19/01/16 15:47, Eric Wittmann wrote:
>>> Hi Charles.  I'm not 100% certain I understand all aspects of your
>>> question - perhaps a diagram would help me, in case my answer doesn't
>>> make sense (and if you have the time).  :)
>>> 
>>> You are right that there is no 1..N mapping of an apiman service/api
>>> to a back-end endpoint URL.  That is a feature we are contemplating
>>> for the future but it's certainly not available yet.
>>> 
>>> Here are some thoughts that might be useful/relevant to this use case.
>>> First is that you could of course implement a custom policy that
>>> changed the back-end endpoint URL based on whatever criteria you see
>>> fit.  The custom policy would simply have to change the value of the
>>> ApiRequest->Api:endpoint field.  Doing that should be considered
>>> unsafe and a temporary workaround, as the Api object is globally
>>> scoped, and really should be either cloned (if we want to suppor this
>>> use-case) or immutable (if we don't).
>>> 
>>> Another thing to note is that as of 1.2.0.Final we support system
>>> property and environment variable replacements in the API endpoint,
>>> endpoint properties, and all policy configurations. This means that
>>> you could install *identical* gateways on all the per fuse server,
>>> configured using the same shared registry.  Then, when you configure
>>> the Service/API endpoint, you could set the value to something like:
>>> 
>>> ${external_url}
>>> 
>>> Then you could set a system property, which could be different for
>>> each gateway node, like so:
>>> 
>>> (on gateway server 1)
>>> -Dexternal_url=http://fuse_server_1:port/
>>> 
>>> (on gateway server 2)
>>> -Dexternal_url=http://fuse_server_2:port/
>>> 
>>> That way your configuration is shared but certain aspects/properties
>>> of the configuration are *externalized*.
>>> 
>>> This feature was originally meant to support more easily migrating
>>> data between dev/test/prod environments, but it would work fine for
>>> this as well.
>>> 
>>> Did any of that help?
>>> 
>>> -Eric
>>> 
>>> 
>>>> On 1/19/2016 5:30 AM, Charles Moulliard wrote:
>>>> Hi,
>>>> 
>>>> If I use a loadbalancer (= F5) exposing a physical IP address (= routed
>>>> on internet) and calling one of our endpoints (REST, ...) running into
>>>> different integration servers (Fuse + Camel), can we design such
>>>> topology ?
>>>> 
>>>> We setup an Apiman Manager  (Front + ElasticSearch Database) to define
>>>> the plans, services, roles, policies of all the endpoints which are
>>>> running into different Fuse Servers. As the mapping between the incoming
>>>> request and the endpoint is managed by the Apiman Gateway, I'm thinking
>>>> to install one Apiman Gateway / Fuse Server.
>>>> Is it doable ?
>>>> 
>>>> Client --> 192.168.1.1 (IP Address of the Server replying to a REST
>>>> Service) "Loadbalancer F5" --> NAT --> address of the gateway (=
>>>> 10.0.2.1) managing the mapping between the request and the physical
>>>> endpoint --> Camel REST Endpoint (10.0.1.1). The Apiman Manager could
>>>> run internally on this addess (10.0.2.100).
>>>> 
>>>> To support high availability or workload distribution, it will be
>>>> required that at least each Camel REST / Web Service runs into multiple
>>>> instances of Fuse Servers. That means that their IP address will be
>>>> different (A REST service will be deployed on 10.0.1.1, 10.0.1.2,
>>>> 10.0.1.3, ...).
>>>> 
>>>> Question : As the GUI interface of the Apiman Manager to encode the
>>>> address of the endpoint to map proposes one field (and no more if we
>>>> would like to distribute the requests to different servers), is there a
>>>> possibility to define a 1 to many relation into ApiMan Server (maybe if
>>>> we develop such a feature) or do I have also to install an Apiman
>>>> Manager / Gateway per Fuse Server and to encode the same info (plans,
>>>> services, ...) excepted the IP address of the server which is
>>>> different ?
>>>> 
>>>> Regards,
>>>> 
>>>> Charles
>>>> _______________________________________________
>>>> Apiman-user mailing list
>>>> Apiman-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>> 


From michele.danieli at gmail.com  Wed Jan 20 09:13:35 2016
From: michele.danieli at gmail.com (michele danieli)
Date: Wed, 20 Jan 2016 15:13:35 +0100
Subject: [Apiman-user] OAuth with non public API
In-Reply-To: <CAH+8e1fzC3oyBr-U01Y+6aGB5VfbHfoQk-1a5ogetOMEUYkSjA@mail.gmail.com>
References: <CAH+8e1cgb7f4ik21oQN9xZXS5rM7t7WST=_sz=toPGp9GCLVyg@mail.gmail.com>
	<5697A3DE.20306@redhat.com>
	<CAH+8e1fzC3oyBr-U01Y+6aGB5VfbHfoQk-1a5ogetOMEUYkSjA@mail.gmail.com>
Message-ID: <CAH+8e1dxxEOGYPhF7+RveWV27UBNEUWgtAnkDuWHa0ZwBs-1iw@mail.gmail.com>

Hello Eric,
still related to the point above, I think a key element is that there is no
actual correlation between the application in APIMAN and the client in KC.
You createan application, but the application has only an key for
associating itself to the API via a contract, while from an OAuth
perspective you need  a client and eventually a secret, which you only
configure in KC.  This means configuration of an application and enablement
of OAuth requires users to interact separately with KC and APIMAN, which is
odd.  Of course I understand that complexities lay behind, for example in
which realm a client would be defined?

On Thu, Jan 14, 2016 at 7:16 PM, michele danieli <michele.danieli at gmail.com>
wrote:

> Hello Eric,
> my scenario is the following.
>
> A set of API has been defined to expose core business functions, to clerks
> and sales force automation. Some functions are specifically sensitive. All
> access requires end user authentication. Some function are only accessible
> to users when using trusted clients: for example access from browsers js
> apps is not enabled to some functions, while native clients for mobile SFA
> do.
>
> For trusted application i have implemented OAUTH with signed JWT client
> authentication (updated KC to latest) almost meeting security requirements
> (added a ticket to KC for supports of nonces) but oauth client and
> application are actually unrelated, so no way I can relate the client id to
> application to enforce access to sensitive api to only users authenticated
> with the trusted client.
>
> Of course I can set the api_key header to the one I have associated to the
> trusted client, but this are unrelated (security department not so happy).
> I could probably use the api_key as client_id in KC and implement a custom
> policy to verify the access token audience (i guess that is where the
> client is mapped in the signed token) matches the apikey.
>
> In general i was thinking if diffeent strategies for application
> identification made sense (at api level) .
>
> Bests
> Mike
>
>
> On Thu, 14 Jan 2016 at 14:34, Eric Wittmann <eric.wittmann at redhat.com>
> wrote:
>
>> Hi Michele.
>>
>> That is correct.  Typically the end-user population is tied to the API
>> being invoked rather than the Client (software) being used to connect.
>> If that is not the case, then you could configure the OAuth policy on
>> the Client Application rather than on the API (Service).  That way you
>> could have a different user population for each connecting client.  If
>> that's your use-case I'd love to hear more about it. :)
>>
>> -Eric
>>
>> On 1/13/2016 3:05 PM, michele danieli wrote:
>> > When considering non public API and applying a OAuth authentication
>> > policy, the application identifier must be provided using the api_key as
>> > a header?
>> >
>> > If so, does not it means that the user authorized client and the actual
>> > api consumer application have no strict relationship?
>> >
>> >
>> > Thanks
>> > Michele
>> >
>> >
>> > _______________________________________________
>> > Apiman-user mailing list
>> > 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/20160120/7c9d60ed/attachment.html 

From eric.wittmann at redhat.com  Wed Jan 20 09:22:08 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Wed, 20 Jan 2016 09:22:08 -0500
Subject: [Apiman-user] OAuth with non public API
In-Reply-To: <CAH+8e1dxxEOGYPhF7+RveWV27UBNEUWgtAnkDuWHa0ZwBs-1iw@mail.gmail.com>
References: <CAH+8e1cgb7f4ik21oQN9xZXS5rM7t7WST=_sz=toPGp9GCLVyg@mail.gmail.com>
	<5697A3DE.20306@redhat.com>
	<CAH+8e1fzC3oyBr-U01Y+6aGB5VfbHfoQk-1a5ogetOMEUYkSjA@mail.gmail.com>
	<CAH+8e1dxxEOGYPhF7+RveWV27UBNEUWgtAnkDuWHa0ZwBs-1iw@mail.gmail.com>
Message-ID: <569F9810.6060902@redhat.com>

You are 100% right about that.  Ultimately the issue is that we do *not* 
currently support OAuth as a mechanism to identify the client app being 
used to invoke the API.

I do agree that we need tighter integration with KC in a number of 
places to make everything easier to consume.  I think that perhaps we 
are too decoupled from KC at the moment.

Do you have any thoughts on how you'd like to see it work?  Just your 
impressions - I won't hold you to them. ;)

We're always looking for ways to improve, and one of the best things for 
us is when users describe what they would like to see!

-Eric

On 1/20/2016 9:13 AM, michele danieli wrote:
> Hello Eric,
> still related to the point above, I think a key element is that there is
> no actual correlation between the application in APIMAN and the client
> in KC.  You createan application, but the application has only an key
> for associating itself to the API via a contract, while from an OAuth
> perspective you need  a client and eventually a secret, which you only
> configure in KC.  This means configuration of an application and
> enablement of OAuth requires users to interact separately with KC and
> APIMAN, which is odd.  Of course I understand that complexities lay
> behind, for example in which realm a client would be defined?
>
> On Thu, Jan 14, 2016 at 7:16 PM, michele danieli
> <michele.danieli at gmail.com <mailto:michele.danieli at gmail.com>> wrote:
>
>     Hello Eric,
>     my scenario is the following.
>
>     A set of API has been defined to expose core business functions, to
>     clerks and sales force automation. Some functions are specifically
>     sensitive. All access requires end user authentication. Some
>     function are only accessible to users when using trusted clients:
>     for example access from browsers js apps is not enabled to some
>     functions, while native clients for mobile SFA do.
>
>     For trusted application i have implemented OAUTH with signed JWT
>     client authentication (updated KC to latest) almost meeting security
>     requirements (added a ticket to KC for supports of nonces) but oauth
>     client and application are actually unrelated, so no way I can
>     relate the client id to application to enforce access to sensitive
>     api to only users authenticated with the trusted client.
>
>     Of course I can set the api_key header to the one I have associated
>     to the trusted client, but this are unrelated (security department
>     not so happy). I could probably use the api_key as client_id in KC
>     and implement a custom policy to verify the access token audience (i
>     guess that is where the client is mapped in the signed token)
>     matches the apikey.
>
>     In general i was thinking if diffeent strategies for application
>     identification made sense (at api level) .
>
>     Bests
>     Mike
>
>
>     On Thu, 14 Jan 2016 at 14:34, Eric Wittmann
>     <eric.wittmann at redhat.com <mailto:eric.wittmann at redhat.com>> wrote:
>
>         Hi Michele.
>
>         That is correct.  Typically the end-user population is tied to
>         the API
>         being invoked rather than the Client (software) being used to
>         connect.
>         If that is not the case, then you could configure the OAuth
>         policy on
>         the Client Application rather than on the API (Service).  That
>         way you
>         could have a different user population for each connecting
>         client.  If
>         that's your use-case I'd love to hear more about it. :)
>
>         -Eric
>
>         On 1/13/2016 3:05 PM, michele danieli wrote:
>          > When considering non public API and applying a OAuth
>         authentication
>          > policy, the application identifier must be provided using the
>         api_key as
>          > a header?
>          >
>          > If so, does not it means that the user authorized client and
>         the actual
>          > api consumer application have no strict relationship?
>          >
>          >
>          > Thanks
>          > Michele
>          >
>          >
>          > _______________________________________________
>          > 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
>          >
>
>

From michele.danieli at gmail.com  Fri Jan 22 01:30:47 2016
From: michele.danieli at gmail.com (michele danieli)
Date: Fri, 22 Jan 2016 06:30:47 +0000
Subject: [Apiman-user] OAuth with non public API
In-Reply-To: <569F9810.6060902@redhat.com>
References: <CAH+8e1cgb7f4ik21oQN9xZXS5rM7t7WST=_sz=toPGp9GCLVyg@mail.gmail.com>
	<5697A3DE.20306@redhat.com>
	<CAH+8e1fzC3oyBr-U01Y+6aGB5VfbHfoQk-1a5ogetOMEUYkSjA@mail.gmail.com>
	<CAH+8e1dxxEOGYPhF7+RveWV27UBNEUWgtAnkDuWHa0ZwBs-1iw@mail.gmail.com>
	<569F9810.6060902@redhat.com>
Message-ID: <CAH+8e1fmhR6Ezo8vmw-Mng5mrfC04Dnq2UFRQBrXFDRPoCu9_A@mail.gmail.com>

Hello Eric,
the key problem i guess (which is not actually a problem itself from KC
perspective) comes from the fact that in KC clients are associated to
realms and a you don't know which realm a user will be authenticated
against.

I would expect an application to have an application ID and secret, which
are generated at application creation time, and those id and credentials
would match a KC client in OAuth (dually application cancellation or
credential revocation or change would reflect into KC).

This means a consistent Integration with the developer portal. If not using
a developer portal I can provision my application in KC and actually keep
API "public".

I understand this has architectural impact for you, but on architects
considering an api management product in several api management scenarios.
(b2b and b2c, mobile, published API and internal API).

Beats
Mike

On Wed, 20 Jan 2016 at 15:22, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> You are 100% right about that.  Ultimately the issue is that we do *not*
> currently support OAuth as a mechanism to identify the client app being
> used to invoke the API.
>
> I do agree that we need tighter integration with KC in a number of
> places to make everything easier to consume.  I think that perhaps we
> are too decoupled from KC at the moment.
>
> Do you have any thoughts on how you'd like to see it work?  Just your
> impressions - I won't hold you to them. ;)
>
> We're always looking for ways to improve, and one of the best things for
> us is when users describe what they would like to see!
>
> -Eric
>
> On 1/20/2016 9:13 AM, michele danieli wrote:
> > Hello Eric,
> > still related to the point above, I think a key element is that there is
> > no actual correlation between the application in APIMAN and the client
> > in KC.  You createan application, but the application has only an key
> > for associating itself to the API via a contract, while from an OAuth
> > perspective you need  a client and eventually a secret, which you only
> > configure in KC.  This means configuration of an application and
> > enablement of OAuth requires users to interact separately with KC and
> > APIMAN, which is odd.  Of course I understand that complexities lay
> > behind, for example in which realm a client would be defined?
> >
> > On Thu, Jan 14, 2016 at 7:16 PM, michele danieli
> > <michele.danieli at gmail.com <mailto:michele.danieli at gmail.com>> wrote:
> >
> >     Hello Eric,
> >     my scenario is the following.
> >
> >     A set of API has been defined to expose core business functions, to
> >     clerks and sales force automation. Some functions are specifically
> >     sensitive. All access requires end user authentication. Some
> >     function are only accessible to users when using trusted clients:
> >     for example access from browsers js apps is not enabled to some
> >     functions, while native clients for mobile SFA do.
> >
> >     For trusted application i have implemented OAUTH with signed JWT
> >     client authentication (updated KC to latest) almost meeting security
> >     requirements (added a ticket to KC for supports of nonces) but oauth
> >     client and application are actually unrelated, so no way I can
> >     relate the client id to application to enforce access to sensitive
> >     api to only users authenticated with the trusted client.
> >
> >     Of course I can set the api_key header to the one I have associated
> >     to the trusted client, but this are unrelated (security department
> >     not so happy). I could probably use the api_key as client_id in KC
> >     and implement a custom policy to verify the access token audience (i
> >     guess that is where the client is mapped in the signed token)
> >     matches the apikey.
> >
> >     In general i was thinking if diffeent strategies for application
> >     identification made sense (at api level) .
> >
> >     Bests
> >     Mike
> >
> >
> >     On Thu, 14 Jan 2016 at 14:34, Eric Wittmann
> >     <eric.wittmann at redhat.com <mailto:eric.wittmann at redhat.com>> wrote:
> >
> >         Hi Michele.
> >
> >         That is correct.  Typically the end-user population is tied to
> >         the API
> >         being invoked rather than the Client (software) being used to
> >         connect.
> >         If that is not the case, then you could configure the OAuth
> >         policy on
> >         the Client Application rather than on the API (Service).  That
> >         way you
> >         could have a different user population for each connecting
> >         client.  If
> >         that's your use-case I'd love to hear more about it. :)
> >
> >         -Eric
> >
> >         On 1/13/2016 3:05 PM, michele danieli wrote:
> >          > When considering non public API and applying a OAuth
> >         authentication
> >          > policy, the application identifier must be provided using the
> >         api_key as
> >          > a header?
> >          >
> >          > If so, does not it means that the user authorized client and
> >         the actual
> >          > api consumer application have no strict relationship?
> >          >
> >          >
> >          > Thanks
> >          > Michele
> >          >
> >          >
> >          > _______________________________________________
> >          > 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/20160122/0fd40dab/attachment-0001.html 

From eric.wittmann at redhat.com  Fri Jan 22 14:27:44 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Fri, 22 Jan 2016 14:27:44 -0500
Subject: [Apiman-user] Announcement: apiman 1.2.x released!
Message-ID: <56A282B0.4030804@redhat.com>

Greetings, earthlings!

At long last we are happy to announce the release of apiman version 
1.2.1.Final.  You can read more about this most excellent release here:

http://www.apiman.io/blog/apiman/2016/01/22/release-1.2.html

Thank you very much to everyone in the community for your interest and 
support.  Hopefully 1.2 provides a bunch of functionality that folks 
have been asking for.

Now that the first version of 1.2.x is out the door, expect us to be 
going back to our more frequent release schedule!

-Eric


From amit.joshi at markit.com  Mon Jan 25 15:18:51 2016
From: amit.joshi at markit.com (Amit Joshi)
Date: Mon, 25 Jan 2016 20:18:51 +0000
Subject: [Apiman-user] Replacing Keycloak
Message-ID: <9e20ee912967468d9ef348091088c39b@NJ4PDMSGDAG01.markit.partners>

Hello,

I have the following setup:

Ping server -> external https url  (something like https://pingfederate.mydomain.com) - through an apache reverse proxy. Real server is pingfederate001.internal.com.
APIman  -> external https url (something like https://apiman.mydomain.com) through ab apache reverse proxy. Real server is apiman001.internal.com.

I am trying to replace keycloak with ping federate in APIMan.  I have

-          Disabled the integrated Keycloak.

-          Changed the <kc:auth-server-url>https://pingfederate.mydomain.com/as/token.oauth2</kc:auth-server-url<https://pingfederate.mydomain.com/as/token.oauth2%3c/kc:auth-server-url>>

However, when I access I see the following as the redirect - which is clearly wrong:

https://pingfederate.mydomain.com/as/token.oauth2/relams/apiman/protocol/openid_connect/auth?
with the following parameters:
response_type=code
client_id=apimanui
redirect_uri=http://apiman001.internal.com

I looked the code for the keycloak plugin but can't seem to see where the redirect is generated or set. I assume it is some additional properties or settings that I have to do or change code for so I can generate a Ping friendly redirect url etc.

Appreciate any help or any pointers.

Regards,

Amit Joshi

________________________________

This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page

Please visit http://www.markit.com/en/about/contact/contact-us.page for contact information on our offices worldwide.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160125/31bba735/attachment.html 

From eric.wittmann at redhat.com  Mon Jan 25 15:36:33 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 25 Jan 2016 15:36:33 -0500
Subject: [Apiman-user] Replacing Keycloak
In-Reply-To: <9e20ee912967468d9ef348091088c39b@NJ4PDMSGDAG01.markit.partners>
References: <9e20ee912967468d9ef348091088c39b@NJ4PDMSGDAG01.markit.partners>
Message-ID: <56A68751.2070904@redhat.com>

Hi Amit.

To be clear, you are trying to replace Keycloak as the authentication 
mechanism for logging into the apiman UI, correct?

I can't say I know how to configure a web application to use 
pingfederate for authenticaiton (never done that before).  But I can 
tell you that it's likely that you will not be able to use the settings 
in standalone-apiman.xml because those are configuration settings for 
the keycloak auth client adapter.  The client adapter is the keycloak 
specific client that handles authentication redirects to the auth 
server.  I *assume* this adapter is keycloak-specific.

In order to get pingfederate working I must assume that they 
(pingfederate) have some documentation for how to configure a java web 
application for authentication.  Sadly their documentation server seems 
to be broken at the moment.

I'll warn you that, while I'm sure using pingfederate is *possible*, it 
is probably not trivial.  You may need to contribute some code to apiman 
in order to enable support in the UI, for example.  If hacking some code 
is not a daunting prospect then I'd be happy to help point you in the 
direction of all the authentication touch points...

-Eric


On 1/25/2016 3:18 PM, Amit Joshi wrote:
> Hello,
>
> I have the following setup:
>
> Ping server -> external https url  (something like
> https://pingfederate.mydomain.com) ? through an apache reverse proxy.
> Real server is pingfederate001.internal.com.
>
> APIman  -> external https url (something like
> https://apiman.mydomain.com) through ab apache reverse proxy. Real
> server is apiman001.internal.com.
>
> I am trying to replace keycloak with ping federate in APIMan.  I have
>
> -Disabled the integrated Keycloak.
>
> -Changed the
> <kc:auth-server-url>https://pingfederate.mydomain.com/as/token.oauth2</kc:auth-server-url
> <https://pingfederate.mydomain.com/as/token.oauth2%3c/kc:auth-server-url>>
>
> However, when I access I see the following as the redirect ? which is
> clearly wrong:
>
> https://pingfederate.mydomain.com/as/token.oauth2/relams/apiman/protocol/openid_connect/auth?
>
> with the following parameters:
>
> response_type=code
>
> client_id=apimanui
>
> redirect_uri=http://apiman001.internal.com
>
> I looked the code for the keycloak plugin but can?t seem to see where
> the redirect is generated or set. I assume it is some additional
> properties or settings that I have to do or change code for so I can
> generate a Ping friendly redirect url etc.
>
> Appreciate any help or any pointers.
>
> Regards,
>
> Amit Joshi
>
>
> ------------------------------------------------------------------------
>
> This e-mail, including accompanying communications and attachments, is
> strictly confidential and only for the intended recipient. Any
> retention, use or disclosure not expressly authorised by Markit is
> prohibited. This email is subject to all waivers and other terms at the
> following link: http://www.markit.com/en/about/legal/email-disclaimer.page
>
> Please visit http://www.markit.com/en/about/contact/contact-us.page for
> contact information on our offices worldwide.
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From amit.joshi at markit.com  Mon Jan 25 15:47:38 2016
From: amit.joshi at markit.com (Amit Joshi)
Date: Mon, 25 Jan 2016 20:47:38 +0000
Subject: [Apiman-user] Replacing Keycloak
In-Reply-To: <56A68751.2070904@redhat.com>
References: <9e20ee912967468d9ef348091088c39b@NJ4PDMSGDAG01.markit.partners>
	<56A68751.2070904@redhat.com>
Message-ID: <1411b3529e074cb1ae5860a14fbcb62a@NJ4PDMSGDAG01.markit.partners>

Hello,

I am trying to use Ping Federate for both login and for the API restrictions.

I understand that integrating into Ping Federate might not be trivial and might require some hacking into the APIMan code. I have created a sample java app that does the SP initiated login for ping federate that works. However with APIMan I am lost as to where to start ... I tried to look at the apiman-plugin-keycloak-oauth-policy to see but I suspect that it will take me some time to trace through it and figured that people working on the product might be able to get me started quicker.

In short, happy to help hack on the code but will need the touch points.  I assume there is some code somewhere that checks if the token already exists and if not then generates the auth request, gets the access code, validates the code and generates the token?

Regards,

Amit Joshi

-----Original Message-----
From: Eric Wittmann [mailto:eric.wittmann at redhat.com]
Sent: Monday, January 25, 2016 3:37 PM
To: Amit Joshi; apiman-user at lists.jboss.org
Subject: Re: [Apiman-user] Replacing Keycloak

Hi Amit.

To be clear, you are trying to replace Keycloak as the authentication mechanism for logging into the apiman UI, correct?

I can't say I know how to configure a web application to use pingfederate for authenticaiton (never done that before).  But I can tell you that it's likely that you will not be able to use the settings in standalone-apiman.xml because those are configuration settings for the keycloak auth client adapter.  The client adapter is the keycloak specific client that handles authentication redirects to the auth server.  I *assume* this adapter is keycloak-specific.

In order to get pingfederate working I must assume that they
(pingfederate) have some documentation for how to configure a java web application for authentication.  Sadly their documentation server seems to be broken at the moment.

I'll warn you that, while I'm sure using pingfederate is *possible*, it is probably not trivial.  You may need to contribute some code to apiman in order to enable support in the UI, for example.  If hacking some code is not a daunting prospect then I'd be happy to help point you in the direction of all the authentication touch points...

-Eric


On 1/25/2016 3:18 PM, Amit Joshi wrote:
> Hello,
>
> I have the following setup:
>
> Ping server -> external https url  (something like
> https://pingfederate.mydomain.com) - through an apache reverse proxy.
> Real server is pingfederate001.internal.com.
>
> APIman  -> external https url (something like
> https://apiman.mydomain.com) through ab apache reverse proxy. Real
> server is apiman001.internal.com.
>
> I am trying to replace keycloak with ping federate in APIMan.  I have
>
> -Disabled the integrated Keycloak.
>
> -Changed the
> <kc:auth-server-url>https://pingfederate.mydomain.com/as/token.oauth2<
> /kc:auth-server-url
> <https://pingfederate.mydomain.com/as/token.oauth2%3c/kc:auth-server-u
> rl>>
>
> However, when I access I see the following as the redirect - which is
> clearly wrong:
>
> https://pingfederate.mydomain.com/as/token.oauth2/relams/apiman/protocol/openid_connect/auth?
>
> with the following parameters:
>
> response_type=code
>
> client_id=apimanui
>
> redirect_uri=http://apiman001.internal.com
>
> I looked the code for the keycloak plugin but can't seem to see where
> the redirect is generated or set. I assume it is some additional
> properties or settings that I have to do or change code for so I can
> generate a Ping friendly redirect url etc.
>
> Appreciate any help or any pointers.
>
> Regards,
>
> Amit Joshi
>
>
> ----------------------------------------------------------------------
> --
>
> This e-mail, including accompanying communications and attachments, is
> strictly confidential and only for the intended recipient. Any
> retention, use or disclosure not expressly authorised by Markit is
> prohibited. This email is subject to all waivers and other terms at
> the following link:
> http://www.markit.com/en/about/legal/email-disclaimer.page
>
> Please visit http://www.markit.com/en/about/contact/contact-us.page
> for contact information on our offices worldwide.
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

________________________________

This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page

Please visit http://www.markit.com/en/about/contact/contact-us.page for contact information on our offices worldwide.


From pblair at clearme.com  Mon Jan 25 15:50:42 2016
From: pblair at clearme.com (Paul Blair)
Date: Mon, 25 Jan 2016 20:50:42 +0000
Subject: [Apiman-user] 1.2.1.Final / Wildfly 9 conflict with production
 deployment instructions
Message-ID: <D2CBF4D0.11575%pblair@clearme.com>

The production guide gives the following guidance about disabling the bundled Keycloak components:

Because you will be using an external/standalone Keycloak server, it is useful to disable the Keycloak components that are bundled with the apiman quickstart. To do that, make the following modification to the standalone-apiman.xml file:

<subsystem xmlns="urn:jboss:domain:keycloak:1.0">
  <auth-server name="main-auth-server">
    <enabled>false</enabled>
    <web-context>auth</web-context>
  </auth-server>
</subsystem>

When I start the server after upgrading from 1.2.0.Final, and comparing the standalone-apiman.xml config file with the old one, I get:

20:46:49,393 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-1.0.2.Final.jar:1.0.2.Final]
...
Caused by: javax.xml.stream.XMLStreamException: Unknown keycloak-server subsystem tag: auth-server

Any idea what this configuration should look like now?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160125/735c475d/attachment-0001.html 

From eric.wittmann at redhat.com  Mon Jan 25 16:08:04 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 25 Jan 2016 16:08:04 -0500
Subject: [Apiman-user] Replacing Keycloak
In-Reply-To: <1411b3529e074cb1ae5860a14fbcb62a@NJ4PDMSGDAG01.markit.partners>
References: <9e20ee912967468d9ef348091088c39b@NJ4PDMSGDAG01.markit.partners>
	<56A68751.2070904@redhat.com>
	<1411b3529e074cb1ae5860a14fbcb62a@NJ4PDMSGDAG01.markit.partners>
Message-ID: <56A68EB4.3050702@redhat.com>

OK great - we're on the same page then.  Happy to help (and then reap 
the benefits of your work in apiman!).  :)

We need to split the problem up into two.  The first (and probably 
harder) problem is supporting PF as an authentication mechanism for 
apiman.  The second problem is protecting managed APIs with PF.

#1 Apiman Auth via PF
---------------------
* Can you share your PF sample java app?
* There are three WARs that will need to be protected:
    - apiman.war
    - apiman-gateway-api.war
    - apimanui.war
* !!!!!!  Let's focus first on "apimanui.war", which is a standard java 
web application.  !!!!!!!!
* We will need to secure the WAR with PF *and* provide a PF-specific 
impl of ISecurityContext.  There are two impls thus far, 
DefaultSecurityContext and KeycloakSecurityContext.  If the PF 
authentication code puts the auth principal and roles into the servlet 
request, then you can use DefaultSecurityContext.  If not, a custom impl 
may be required (see the KC impl for more info).

	http://bit.ly/1ZZAmwW

* The security context is configured here:

	http://bit.ly/1KAvu51

* After the user logs into the UI, the UI will then use the oauth bearer 
token to make authenticated calls directly from the UI to the API 
Manager REST layer.  This bearer token is periodically refreshed by 
making a call to the /apimanui/ context to get a new token.  This is 
what is called:  ITokenGenerator
* Assuming PF uses bearer tokens, we'll need a PF implementation of the 
above interface.  See KeyCloakBearerTokenGenerator for more information.

* Note: the keycloak plugin you are looking at is *not* the code that is 
called when logging into apiman.  For that, you'd have to look at the 
keycloak adapter code:

	https://github.com/keycloak/keycloak/tree/master/adapters


#2 Protected Managed APIs with PF
---------------------------------
* Our OAuth support is a keycloak-specific apiman policy that I think 
you've already discovered:

https://github.com/apiman/apiman-plugins/tree/master/keycloak-oauth-policy

* Adding PF authentication support will require a *new* plugin specific 
to PF.

-------------------

OK that's a lot, I know.  Let's start with your PF enabled java app and 
try to apply those principals to the API Manager UI.

-Eric


On 1/25/2016 3:47 PM, Amit Joshi wrote:
> Hello,
>
> I am trying to use Ping Federate for both login and for the API restrictions.
>
> I understand that integrating into Ping Federate might not be trivial and might require some hacking into the APIMan code. I have created a sample java app that does the SP initiated login for ping federate that works. However with APIMan I am lost as to where to start ... I tried to look at the apiman-plugin-keycloak-oauth-policy to see but I suspect that it will take me some time to trace through it and figured that people working on the product might be able to get me started quicker.
>
> In short, happy to help hack on the code but will need the touch points.  I assume there is some code somewhere that checks if the token already exists and if not then generates the auth request, gets the access code, validates the code and generates the token?
>
> Regards,
>
> Amit Joshi
>
> -----Original Message-----
> From: Eric Wittmann [mailto:eric.wittmann at redhat.com]
> Sent: Monday, January 25, 2016 3:37 PM
> To: Amit Joshi; apiman-user at lists.jboss.org
> Subject: Re: [Apiman-user] Replacing Keycloak
>
> Hi Amit.
>
> To be clear, you are trying to replace Keycloak as the authentication mechanism for logging into the apiman UI, correct?
>
> I can't say I know how to configure a web application to use pingfederate for authenticaiton (never done that before).  But I can tell you that it's likely that you will not be able to use the settings in standalone-apiman.xml because those are configuration settings for the keycloak auth client adapter.  The client adapter is the keycloak specific client that handles authentication redirects to the auth server.  I *assume* this adapter is keycloak-specific.
>
> In order to get pingfederate working I must assume that they
> (pingfederate) have some documentation for how to configure a java web application for authentication.  Sadly their documentation server seems to be broken at the moment.
>
> I'll warn you that, while I'm sure using pingfederate is *possible*, it is probably not trivial.  You may need to contribute some code to apiman in order to enable support in the UI, for example.  If hacking some code is not a daunting prospect then I'd be happy to help point you in the direction of all the authentication touch points...
>
> -Eric
>
>
> On 1/25/2016 3:18 PM, Amit Joshi wrote:
>> Hello,
>>
>> I have the following setup:
>>
>> Ping server -> external https url  (something like
>> https://pingfederate.mydomain.com) - through an apache reverse proxy.
>> Real server is pingfederate001.internal.com.
>>
>> APIman  -> external https url (something like
>> https://apiman.mydomain.com) through ab apache reverse proxy. Real
>> server is apiman001.internal.com.
>>
>> I am trying to replace keycloak with ping federate in APIMan.  I have
>>
>> -Disabled the integrated Keycloak.
>>
>> -Changed the
>> <kc:auth-server-url>https://pingfederate.mydomain.com/as/token.oauth2<
>> /kc:auth-server-url
>> <https://pingfederate.mydomain.com/as/token.oauth2%3c/kc:auth-server-u
>> rl>>
>>
>> However, when I access I see the following as the redirect - which is
>> clearly wrong:
>>
>> https://pingfederate.mydomain.com/as/token.oauth2/relams/apiman/protocol/openid_connect/auth?
>>
>> with the following parameters:
>>
>> response_type=code
>>
>> client_id=apimanui
>>
>> redirect_uri=http://apiman001.internal.com
>>
>> I looked the code for the keycloak plugin but can't seem to see where
>> the redirect is generated or set. I assume it is some additional
>> properties or settings that I have to do or change code for so I can
>> generate a Ping friendly redirect url etc.
>>
>> Appreciate any help or any pointers.
>>
>> Regards,
>>
>> Amit Joshi
>>
>>
>> ----------------------------------------------------------------------
>> --
>>
>> This e-mail, including accompanying communications and attachments, is
>> strictly confidential and only for the intended recipient. Any
>> retention, use or disclosure not expressly authorised by Markit is
>> prohibited. This email is subject to all waivers and other terms at
>> the following link:
>> http://www.markit.com/en/about/legal/email-disclaimer.page
>>
>> Please visit http://www.markit.com/en/about/contact/contact-us.page
>> for contact information on our offices worldwide.
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>
> ________________________________
>
> This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page
>
> Please visit http://www.markit.com/en/about/contact/contact-us.page for contact information on our offices worldwide.
>

From eric.wittmann at redhat.com  Mon Jan 25 16:19:26 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 25 Jan 2016 16:19:26 -0500
Subject: [Apiman-user] 1.2.1.Final / Wildfly 9 conflict with production
 deployment instructions
In-Reply-To: <D2CBF4D0.11575%pblair@clearme.com>
References: <D2CBF4D0.11575%pblair@clearme.com>
Message-ID: <56A6915E.101@redhat.com>

Oh poop.

You're right - they changed how KC is configured.  Since we upgraded to 
the latest keycloak, the production guide needs to change.

Here's the new configuration format:

https://github.com/apiman/apiman/blob/master/distro/wildfly9/src/main/resources/overlay/standalone/configuration/standalone-apiman.xml#L411-L442

I'll update the production guide and thanks for the notice.

-Eric

On 1/25/2016 3:50 PM, Paul Blair wrote:
> The production guide gives the following guidance about disabling the
> bundled Keycloak components:
>
>     Because you will be using an external/standalone Keycloak server, it
>     is useful to disable the Keycloak components that are bundled with
>     the apiman quickstart. To do that, make the following modification
>     to the *standalone-apiman.xml* file:
>
>     <subsystemxmlns="urn:jboss:domain:keycloak:1.0">
>     <auth-servername="main-auth-server">
>     <enabled>false</enabled>
>     <web-context>auth</web-context>
>     </auth-server>
>     </subsystem>
>
> When I start the server after upgrading from 1.2.0.Final, and comparing
> the standalone-apiman.xml config file with the old one, I get:
>
>     20:46:49,393 ERROR [org.jboss.as.server] (Controller Boot Thread)
>     WFLYSRV0055: Caught exception during boot:
>     org.jboss.as.controller.persistence.ConfigurationPersistenceException:
>     WFLYCTL0085: Failed to parse configuration
>     at
>     org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
>     [wildfly-controller-1.0.2.Final.jar:1.0.2.Final]
>     ?
>     Caused by: javax.xml.stream.XMLStreamException: Unknown
>     keycloak-server subsystem tag: auth-server
>
>
> Any idea what this configuration should look like now?
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From eric.wittmann at redhat.com  Mon Jan 25 16:21:19 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 25 Jan 2016 16:21:19 -0500
Subject: [Apiman-user] 1.2.1.Final / Wildfly 9 conflict with production
 deployment instructions
In-Reply-To: <D2CBF4D0.11575%pblair@clearme.com>
References: <D2CBF4D0.11575%pblair@clearme.com>
Message-ID: <56A691CF.7050905@redhat.com>

Sorry, I meant this is the new configuration:

https://github.com/apiman/apiman/blob/master/distro/wildfly9/src/main/resources/overlay/standalone/configuration/standalone-apiman.xml#L408-L410

They split the keycloak config into two separate subsystems.

-Eric

On 1/25/2016 3:50 PM, Paul Blair wrote:
> The production guide gives the following guidance about disabling the
> bundled Keycloak components:
>
>     Because you will be using an external/standalone Keycloak server, it
>     is useful to disable the Keycloak components that are bundled with
>     the apiman quickstart. To do that, make the following modification
>     to the *standalone-apiman.xml* file:
>
>     <subsystemxmlns="urn:jboss:domain:keycloak:1.0">
>     <auth-servername="main-auth-server">
>     <enabled>false</enabled>
>     <web-context>auth</web-context>
>     </auth-server>
>     </subsystem>
>
> When I start the server after upgrading from 1.2.0.Final, and comparing
> the standalone-apiman.xml config file with the old one, I get:
>
>     20:46:49,393 ERROR [org.jboss.as.server] (Controller Boot Thread)
>     WFLYSRV0055: Caught exception during boot:
>     org.jboss.as.controller.persistence.ConfigurationPersistenceException:
>     WFLYCTL0085: Failed to parse configuration
>     at
>     org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
>     [wildfly-controller-1.0.2.Final.jar:1.0.2.Final]
>     ?
>     Caused by: javax.xml.stream.XMLStreamException: Unknown
>     keycloak-server subsystem tag: auth-server
>
>
> Any idea what this configuration should look like now?
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From pblair at clearme.com  Mon Jan 25 16:32:04 2016
From: pblair at clearme.com (Paul Blair)
Date: Mon, 25 Jan 2016 21:32:04 +0000
Subject: [Apiman-user] 1.2.1.Final / Wildfly 9 conflict with production
 deployment instructions
In-Reply-To: <56A691CF.7050905@redhat.com>
References: <D2CBF4D0.11575%pblair@clearme.com> <56A691CF.7050905@redhat.com>
Message-ID: <D2CBFD1D.1157B%pblair@clearme.com>

What's not clear to me at this point is how to disable the local Keycloak.
In the section you highlighted, I had used

<subsystem xmlns="urn:jboss:domain:keycloak-server:1.1">
   <auth-server name="main-auth-server">
      <enabled>false</enabled>
      <web-context>auth</web-context>
   </auth-server>
</subsystem>


But this is what gives the "Unknown keycloak-server subsystem tag:
auth-server" error.

I'm not sure where to look up the documentation of this subsystem; it's
not in the documentation of the JBoss adapter for Keycloak. Do I just
remove the subsystem completely from the xml file in order to disable the
server?


On 1/25/16, 4:21 PM, "Eric Wittmann" <eric.wittmann at redhat.com> wrote:

>Sorry, I meant this is the new configuration:
>
>https://github.com/apiman/apiman/blob/master/distro/wildfly9/src/main/reso
>urces/overlay/standalone/configuration/standalone-apiman.xml#L408-L410
>
>They split the keycloak config into two separate subsystems.
>
>-Eric
>
>On 1/25/2016 3:50 PM, Paul Blair wrote:
>> The production guide gives the following guidance about disabling the
>> bundled Keycloak components:
>>
>>     Because you will be using an external/standalone Keycloak server, it
>>     is useful to disable the Keycloak components that are bundled with
>>     the apiman quickstart. To do that, make the following modification
>>     to the *standalone-apiman.xml* file:
>>
>>     <subsystemxmlns="urn:jboss:domain:keycloak:1.0">
>>     <auth-servername="main-auth-server">
>>     <enabled>false</enabled>
>>     <web-context>auth</web-context>
>>     </auth-server>
>>     </subsystem>
>>
>> When I start the server after upgrading from 1.2.0.Final, and comparing
>> the standalone-apiman.xml config file with the old one, I get:
>>
>>     20:46:49,393 ERROR [org.jboss.as.server] (Controller Boot Thread)
>>     WFLYSRV0055: Caught exception during boot:
>>     
>>org.jboss.as.controller.persistence.ConfigurationPersistenceException:
>>     WFLYCTL0085: Failed to parse configuration
>>     at
>>     
>>org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlCon
>>figurationPersister.java:131)
>>     [wildfly-controller-1.0.2.Final.jar:1.0.2.Final]
>>     ?
>>     Caused by: javax.xml.stream.XMLStreamException: Unknown
>>     keycloak-server subsystem tag: auth-server
>>
>>
>> Any idea what this configuration should look like now?
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>



From cmoullia at redhat.com  Tue Jan 26 01:07:31 2016
From: cmoullia at redhat.com (Charles Moulliard)
Date: Tue, 26 Jan 2016 01:07:31 -0500 (EST)
Subject: [Apiman-user] Authorization policy with Web Service
In-Reply-To: <102920649.14104363.1453788267323.JavaMail.zimbra@redhat.com>
Message-ID: <2120861066.14105591.1453788451831.JavaMail.zimbra@redhat.com>

Hi,

Could it be possible to use the existing authorization policy to handle WebService where according to the SOAPAction we have to authorize the call to a method or do we have to create a new authorization policy ?

As a WebService is not managed as RESTfull service where the HTTP Operation (= verb) can be used to determine if we will create, read or update something and restrict access for a user based on a role (writer, reader or admin), I try to figure out how we could achieve that authorization (= role based) based on the SOAPAction for webservice without creating a different WebService with only one operation/method to handle the actions to create/delete/read/update ...

Regards,

Charles

From mssanjay at gmail.com  Tue Jan 26 02:08:34 2016
From: mssanjay at gmail.com (Sanjay Melinamani)
Date: Tue, 26 Jan 2016 02:08:34 -0500
Subject: [Apiman-user] How to update backend implementation URL for
 published Service without changing the version
In-Reply-To: <568E6343.4050502@redhat.com>
References: <CAG9c92J9MRSqQvUMK2ARiUmLRedt6SfVzuPZCGMG-JoqhTEeig@mail.gmail.com>
	<568A9D27.2070400@redhat.com>
	<CAG9c92LdKqinw_YjK3LutiUn2+7jKcQW7DkYTd6=YsCHvzNYSQ@mail.gmail.com>
	<568BBE9F.2000504@redhat.com>
	<CAG9c92J9x30cfw6dFW2qG7wD+E7NcDAwT0LZ=OJ++AnbmC0jJA@mail.gmail.com>
	<CAG9c92LHPHFnSr0krXAB0UXM_DxzbftSSf+Vtr7fQSb+qLArwA@mail.gmail.com>
	<568E6343.4050502@redhat.com>
Message-ID: <CAG9c92L2RZYH6svR5WYF254P8z1DSo0X+aeRUTQzJWN_7kTwrQ@mail.gmail.com>

Hi Eric,
Congratulations on the new Release! I can't wait to migrate to 1.2.1 !!

Meanwhile I am still having hard time replacing the implementation URL used
in a published API.. Here is what I see..
When I execute GET, I see the new implementation URL used (
http://internal-XXXX.elb.amazonaws.com:8080/hra-web/services/engine/OSA/cf)
but when I do a grep on my old URL "10.0.0.241", I see the matches in index
files. How can I rebuild the indices?


[ec2-user at Prism-ST-GWY wildfly-8.2.0.Final]$ curl -XGET
http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
{"endpoint":"
http://internal-XXXX.elb.amazonaws.com:8080/hra-web/services/engine/OSA/cf
","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}


[ec2-user at Prism-ST-GWY wildfly-8.2.0.Final]$ grep -rnw . -e "10.0.0.241"
Binary file
./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/3/index/_0.cfs
matches
Binary file
./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/3/index/_1y.cfs
matches
Binary file
./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/3/index/_1z.cfs
matches
Binary file
./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/2/index/_2.cfs
matches
Binary file
./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/2/index/_3.cfs
matches
Binary file
./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/2/index/_4.cfs
matches
Binary file
./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/4/index/_0.cfs
matches
Binary file
./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/4/index/_1.cfs
matches

Thanks
Sanjay



On Thu, Jan 7, 2016 at 8:08 AM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> No nothing like that should be needed.  Doing that curl command is just
> like doing an UPDATE on a SQL db.  I even tried it locally (switching
> between URLs by updating that record in elastic) and didn't have any
> problems.
>
> Did you restart apiman after the change?  Unfortunately (for this
> use-case) apiman will cache the information so that it doesn't have to do a
> lookup in ES for *every* request.
>
> Also what happens how when you do the -XGET call?  Do you see the new data?
>
> -Eric
>
> On 1/7/2016 2:58 AM, Sanjay Melinamani wrote:
>
>> Hi Eric,
>> Even after the restart, gateway is still using the OLD service
>> implementation URL. Do I have to rebuild the index, clear cache or do
>> something else??
>> When grepped for old URL, I can still see it in indices folder of
>> elastic search. I tried to clear cache and used refresh commands but did
>> not work!
>>
>> Appreciate if you can provide some more guidance here.
>>
>> Thanks
>> Sanjay
>>
>>
>> On Wed, Jan 6, 2016 at 12:57 PM, Sanjay Melinamani <mssanjay at gmail.com
>> <mailto:mssanjay at gmail.com>> wrote:
>>
>>     Thanks  a ton! Worked like a charm :)
>>
>>     Sanjay
>>
>>
>>     On Tue, Jan 5, 2016 at 8:01 AM, Eric Wittmann
>>     <eric.wittmann at redhat.com <mailto:eric.wittmann at redhat.com>> wrote:
>>
>>         Drop the /_source from the PUT command. :)
>>
>>         -Eric
>>
>>         On 1/5/2016 1:45 AM, Sanjay Melinamani wrote:
>>
>>             Thanks Eric for your reply! makes sense...
>>
>>             I tried to use the two CURL commands.
>>
>>             GET worked and I was able to see the end point being used.
>>             curl -XGET
>>
>> http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
>>             {"endpoint":"http://OLD_URL
>> ","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}
>>
>>
>>
>>             But the PUT failed as below..
>>
>>             curl -XPUT
>>
>> http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
>>             -d
>>             '{"endpoint":"http://NEW_URL
>> ","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}'
>>
>>             No handler found for uri
>>             [/apiman_gateway/service/prism:osa:1.0/_source]
>>             and method [PUT]
>>
>>
>>             Thanks again for your time
>>
>>             Sanjay
>>
>>
>>             On Mon, Jan 4, 2016 at 11:26 AM, 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>>> wrote:
>>
>>                  Hi Sanjay, thanks for the questions.
>>
>>                  Currently there is no easy way to update the backend
>>             implementation
>>                  endpiont URL without creating a new version of the
>> service.
>>
>>                  However, if this is a one-off sort of thing then you
>>             may be able to
>>                  get it done.  It depends mostly on what configuration
>>             you are
>>                  using.  But I'll explain based on the most recent 1.1.x
>>             release
>>                  (1.1.9.Final) with its default configuration.
>>
>>                  The Manager and Gateway are decoupled, resulting in the
>>             duplication
>>                  of *some* of the data (including the endpoint URL).  So
>>             when you
>>                  "publish" a service from the Manager, the Gateway is
>> given
>>                  information about the service.  This information is
>>             stored in the
>>                  Gateway's "registry".  By default the registry
>>             implementation is
>>                  elasticsearch.  So if you wanted to change the endpoint
>>             URL for a
>>                  service, you would need to update that information in
>>             your Database
>>                  (you did this) *and* in elasticsearch.
>>
>>                  It's actually not that difficult to update the
>>             information in
>>                  elasticsearch.  You'll need to find the correct record
>>             and then
>>                  update it.  If you're using the default installation,
>>             then ES is
>>                  running on port 19200.  If you want to change the
>>             following service:
>>
>>                  Organization:  Example
>>                  Service ID:    MyService
>>                  Version:       1.0
>>
>>                  Then you might do something like this:
>>
>>                  curl -XGET
>>
>> http://localhost:19200/apiman_gateway/service/Example:MyService:1.0/_source
>>
>>                  You could then take that JSON result, modify the bits
>>             you want to
>>                  change, and then update it like so (as an example -
>>             please replace
>>                  the JSON below with the JSON you get back from the GET
>>             above):
>>
>>                  curl -XPUT
>>
>> http://localhost:19200/apiman_gateway/service/Example:MyService:1.0
>>             -d '
>>                  {
>>                     "endpoint" : "http://UPDATED-ENDPOINT-HERE",
>>                     "endpointType" : "rest",
>>                     "publicService" : true,
>>                     "organizationId" : "Example",
>>                     "serviceId": "MyService",
>>                     "version" : "1.0",
>>                     "endpointProperties": [],
>>                     "policies":[]
>>                  }
>>                  '
>>
>>                  Once this is done you'll have to restart apiman so that
>>             the Gateway
>>                  picks up the changes.
>>
>>                  Note: we are making some changes in apiman 1.2.x that
>>             will make all
>>                  of this easier under some circumstances.  In
>>             particular, as of
>>                  apiman 1.2.0.Final you will be able to re-publish
>>             "Public" services
>>                  (now called APIs).  So if the API is public then you
>>             can simply make
>>                  changes and then republish those changes to the
>>             Gateway.  If the API
>>                  is *not* public then the current semantics are the
>>             same:  you cannot
>>                  make changes and republish because that may violate
>>             contracts that
>>                  consumers have made with your API.
>>
>>                  -Eric
>>
>>
>>
>>                  On 12/29/2015 12:19 PM, Sanjay Melinamani wrote:
>>
>>                      Hi All,
>>                      I am using APIMAN 1.1.9 and for an existing API
>>             that I have
>>                      published to
>>                      consumers, I like to change its backend
>>             implementation end point URL
>>                      without changing the API service version.
>>                      I updated the backend implementation URL in
>>             database table
>>                      "service_versions". I can see the updated URL from
>>             UI but still the
>>                      gateway is using the old implementation URL
>> specified.
>>                      Does it cache the implementation URL once the
>>             service is
>>                      published ? Is
>>                      there anyway I can update  the implementation URL
>>             for an
>>                      existing service?
>>
>>                      Appreciate your time and help.
>>
>>                      Thanks
>>                      Sanjay
>>
>>
>>
>>
>>                      _______________________________________________
>>                      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
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160126/eb125b22/attachment-0001.html 

From eric.wittmann at redhat.com  Tue Jan 26 07:57:05 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 26 Jan 2016 07:57:05 -0500
Subject: [Apiman-user] 1.2.1.Final / Wildfly 9 conflict with production
 deployment instructions
In-Reply-To: <D2CBFD1D.1157B%pblair@clearme.com>
References: <D2CBF4D0.11575%pblair@clearme.com> <56A691CF.7050905@redhat.com>
	<D2CBFD1D.1157B%pblair@clearme.com>
Message-ID: <56A76D21.2000102@redhat.com>

Ah yes - that's right.  Remove the subsystem.  They no longer have an 
"enabled" option.

-Eric

On 1/25/2016 4:32 PM, Paul Blair wrote:
> What's not clear to me at this point is how to disable the local Keycloak.
> In the section you highlighted, I had used
>
> <subsystem xmlns="urn:jboss:domain:keycloak-server:1.1">
>     <auth-server name="main-auth-server">
>        <enabled>false</enabled>
>        <web-context>auth</web-context>
>     </auth-server>
> </subsystem>
>
>
> But this is what gives the "Unknown keycloak-server subsystem tag:
> auth-server" error.
>
> I'm not sure where to look up the documentation of this subsystem; it's
> not in the documentation of the JBoss adapter for Keycloak. Do I just
> remove the subsystem completely from the xml file in order to disable the
> server?
>
>
> On 1/25/16, 4:21 PM, "Eric Wittmann" <eric.wittmann at redhat.com> wrote:
>
>> Sorry, I meant this is the new configuration:
>>
>> https://github.com/apiman/apiman/blob/master/distro/wildfly9/src/main/reso
>> urces/overlay/standalone/configuration/standalone-apiman.xml#L408-L410
>>
>> They split the keycloak config into two separate subsystems.
>>
>> -Eric
>>
>> On 1/25/2016 3:50 PM, Paul Blair wrote:
>>> The production guide gives the following guidance about disabling the
>>> bundled Keycloak components:
>>>
>>>      Because you will be using an external/standalone Keycloak server, it
>>>      is useful to disable the Keycloak components that are bundled with
>>>      the apiman quickstart. To do that, make the following modification
>>>      to the *standalone-apiman.xml* file:
>>>
>>>      <subsystemxmlns="urn:jboss:domain:keycloak:1.0">
>>>      <auth-servername="main-auth-server">
>>>      <enabled>false</enabled>
>>>      <web-context>auth</web-context>
>>>      </auth-server>
>>>      </subsystem>
>>>
>>> When I start the server after upgrading from 1.2.0.Final, and comparing
>>> the standalone-apiman.xml config file with the old one, I get:
>>>
>>>      20:46:49,393 ERROR [org.jboss.as.server] (Controller Boot Thread)
>>>      WFLYSRV0055: Caught exception during boot:
>>>
>>> org.jboss.as.controller.persistence.ConfigurationPersistenceException:
>>>      WFLYCTL0085: Failed to parse configuration
>>>      at
>>>
>>> org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlCon
>>> figurationPersister.java:131)
>>>      [wildfly-controller-1.0.2.Final.jar:1.0.2.Final]
>>>      ?
>>>      Caused by: javax.xml.stream.XMLStreamException: Unknown
>>>      keycloak-server subsystem tag: auth-server
>>>
>>>
>>> Any idea what this configuration should look like now?
>>>
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>

From eric.wittmann at redhat.com  Tue Jan 26 08:06:49 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 26 Jan 2016 08:06:49 -0500
Subject: [Apiman-user] How to update backend implementation URL for
 published Service without changing the version
In-Reply-To: <CAG9c92L2RZYH6svR5WYF254P8z1DSo0X+aeRUTQzJWN_7kTwrQ@mail.gmail.com>
References: <CAG9c92J9MRSqQvUMK2ARiUmLRedt6SfVzuPZCGMG-JoqhTEeig@mail.gmail.com>
	<568A9D27.2070400@redhat.com>
	<CAG9c92LdKqinw_YjK3LutiUn2+7jKcQW7DkYTd6=YsCHvzNYSQ@mail.gmail.com>
	<568BBE9F.2000504@redhat.com>
	<CAG9c92J9x30cfw6dFW2qG7wD+E7NcDAwT0LZ=OJ++AnbmC0jJA@mail.gmail.com>
	<CAG9c92LHPHFnSr0krXAB0UXM_DxzbftSSf+Vtr7fQSb+qLArwA@mail.gmail.com>
	<568E6343.4050502@redhat.com>
	<CAG9c92L2RZYH6svR5WYF254P8z1DSo0X+aeRUTQzJWN_7kTwrQ@mail.gmail.com>
Message-ID: <56A76F69.7030807@redhat.com>

Thanks. :)

As for the index files - I think the bigger question is what do you see 
when you do a search in elastic?

curl -XGET http://localhost:19200/apiman_gateway/service/_search

What are the results of doing the above?

I don't have any idea what might be stored in the elasticsearch index 
files - so I can't tell you what to expect from a grep.

I *can* tell you that there is no re-index operation.  When you update 
the document (via the PUT http request) it should store the new data in 
ES *and* update its indices.  That's EXACTLY what apiman does internally 
when updating/adding/publishing a service.

After restarting apiman, is your gateway still using the wrong (old) 
endpoint?

One last thing - if you are planning on using this in production, we 
really recommend that you install a standalone instance of elasticsearch 
rather than using the one included in the apiman quickstart.  There's 
more information in the production guide:

http://www.apiman.io/latest/production-guide.html

-Eric

On 1/26/2016 2:08 AM, Sanjay Melinamani wrote:
> Hi Eric,
> Congratulations on the new Release! I can't wait to migrate to 1.2.1 !!
>
> Meanwhile I am still having hard time replacing the implementation URL
> used in a published API.. Here is what I see..
> When I execute GET, I see the new implementation URL used
> (http://internal-XXXX.elb.amazonaws.com:8080/hra-web/services/engine/OSA/cf)
> but when I do a grep on my old URL "10.0.0.241", I see the matches in
> index files. How can I rebuild the indices?
>
>
> [ec2-user at Prism-ST-GWY wildfly-8.2.0.Final]$ curl -XGET
> http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
> {"endpoint":"http://internal-XXXX.elb.amazonaws.com:8080/hra-web/services/engine/OSA/cf","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}
>
>
> [ec2-user at Prism-ST-GWY wildfly-8.2.0.Final]$ grep -rnw . -e "10.0.0.241"
> Binary file
> ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/3/index/_0.cfs
> matches
> Binary file
> ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/3/index/_1y.cfs
> matches
> Binary file
> ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/3/index/_1z.cfs
> matches
> Binary file
> ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/2/index/_2.cfs
> matches
> Binary file
> ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/2/index/_3.cfs
> matches
> Binary file
> ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/2/index/_4.cfs
> matches
> Binary file
> ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/4/index/_0.cfs
> matches
> Binary file
> ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/4/index/_1.cfs
> matches
>
> Thanks
> Sanjay
>
>
>
> On Thu, Jan 7, 2016 at 8:08 AM, Eric Wittmann <eric.wittmann at redhat.com
> <mailto:eric.wittmann at redhat.com>> wrote:
>
>     No nothing like that should be needed.  Doing that curl command is
>     just like doing an UPDATE on a SQL db.  I even tried it locally
>     (switching between URLs by updating that record in elastic) and
>     didn't have any problems.
>
>     Did you restart apiman after the change?  Unfortunately (for this
>     use-case) apiman will cache the information so that it doesn't have
>     to do a lookup in ES for *every* request.
>
>     Also what happens how when you do the -XGET call?  Do you see the
>     new data?
>
>     -Eric
>
>     On 1/7/2016 2:58 AM, Sanjay Melinamani wrote:
>
>         Hi Eric,
>         Even after the restart, gateway is still using the OLD service
>         implementation URL. Do I have to rebuild the index, clear cache
>         or do
>         something else??
>         When grepped for old URL, I can still see it in indices folder of
>         elastic search. I tried to clear cache and used refresh commands
>         but did
>         not work!
>
>         Appreciate if you can provide some more guidance here.
>
>         Thanks
>         Sanjay
>
>
>         On Wed, Jan 6, 2016 at 12:57 PM, Sanjay Melinamani
>         <mssanjay at gmail.com <mailto:mssanjay at gmail.com>
>         <mailto:mssanjay at gmail.com <mailto:mssanjay at gmail.com>>> wrote:
>
>              Thanks  a ton! Worked like a charm :)
>
>              Sanjay
>
>
>              On Tue, Jan 5, 2016 at 8:01 AM, 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>>> wrote:
>
>                  Drop the /_source from the PUT command. :)
>
>                  -Eric
>
>                  On 1/5/2016 1:45 AM, Sanjay Melinamani wrote:
>
>                      Thanks Eric for your reply! makes sense...
>
>                      I tried to use the two CURL commands.
>
>                      GET worked and I was able to see the end point
>         being used.
>                      curl -XGET
>         http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
>
>         {"endpoint":"http://OLD_URL","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}
>
>
>
>                      But the PUT failed as below..
>
>                      curl -XPUT
>         http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
>                      -d
>
>         '{"endpoint":"http://NEW_URL","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}'
>
>                      No handler found for uri
>                      [/apiman_gateway/service/prism:osa:1.0/_source]
>                      and method [PUT]
>
>
>                      Thanks again for your time
>
>                      Sanjay
>
>
>                      On Mon, Jan 4, 2016 at 11:26 AM, 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>>
>                      <mailto:eric.wittmann at redhat.com
>         <mailto:eric.wittmann at redhat.com>
>
>                      <mailto:eric.wittmann at redhat.com
>         <mailto:eric.wittmann at redhat.com>>>> wrote:
>
>                           Hi Sanjay, thanks for the questions.
>
>                           Currently there is no easy way to update the
>         backend
>                      implementation
>                           endpiont URL without creating a new version of
>         the service.
>
>                           However, if this is a one-off sort of thing
>         then you
>                      may be able to
>                           get it done.  It depends mostly on what
>         configuration
>                      you are
>                           using.  But I'll explain based on the most
>         recent 1.1.x
>                      release
>                           (1.1.9.Final) with its default configuration.
>
>                           The Manager and Gateway are decoupled,
>         resulting in the
>                      duplication
>                           of *some* of the data (including the endpoint
>         URL).  So
>                      when you
>                           "publish" a service from the Manager, the
>         Gateway is given
>                           information about the service.  This
>         information is
>                      stored in the
>                           Gateway's "registry".  By default the registry
>                      implementation is
>                           elasticsearch.  So if you wanted to change the
>         endpoint
>                      URL for a
>                           service, you would need to update that
>         information in
>                      your Database
>                           (you did this) *and* in elasticsearch.
>
>                           It's actually not that difficult to update the
>                      information in
>                           elasticsearch.  You'll need to find the
>         correct record
>                      and then
>                           update it.  If you're using the default
>         installation,
>                      then ES is
>                           running on port 19200.  If you want to change the
>                      following service:
>
>                           Organization:  Example
>                           Service ID:    MyService
>                           Version:       1.0
>
>                           Then you might do something like this:
>
>                           curl -XGET
>         http://localhost:19200/apiman_gateway/service/Example:MyService:1.0/_source
>
>                           You could then take that JSON result, modify
>         the bits
>                      you want to
>                           change, and then update it like so (as an
>         example -
>                      please replace
>                           the JSON below with the JSON you get back from
>         the GET
>                      above):
>
>                           curl -XPUT
>         http://localhost:19200/apiman_gateway/service/Example:MyService:1.0
>                      -d '
>                           {
>                              "endpoint" : "http://UPDATED-ENDPOINT-HERE",
>                              "endpointType" : "rest",
>                              "publicService" : true,
>                              "organizationId" : "Example",
>                              "serviceId": "MyService",
>                              "version" : "1.0",
>                              "endpointProperties": [],
>                              "policies":[]
>                           }
>                           '
>
>                           Once this is done you'll have to restart
>         apiman so that
>                      the Gateway
>                           picks up the changes.
>
>                           Note: we are making some changes in apiman
>         1.2.x that
>                      will make all
>                           of this easier under some circumstances.  In
>                      particular, as of
>                           apiman 1.2.0.Final you will be able to re-publish
>                      "Public" services
>                           (now called APIs).  So if the API is public
>         then you
>                      can simply make
>                           changes and then republish those changes to the
>                      Gateway.  If the API
>                           is *not* public then the current semantics are the
>                      same:  you cannot
>                           make changes and republish because that may
>         violate
>                      contracts that
>                           consumers have made with your API.
>
>                           -Eric
>
>
>
>                           On 12/29/2015 12:19 PM, Sanjay Melinamani wrote:
>
>                               Hi All,
>                               I am using APIMAN 1.1.9 and for an
>         existing API
>                      that I have
>                               published to
>                               consumers, I like to change its backend
>                      implementation end point URL
>                               without changing the API service version.
>                               I updated the backend implementation URL in
>                      database table
>                               "service_versions". I can see the updated
>         URL from
>                      UI but still the
>                               gateway is using the old implementation
>         URL specified.
>                               Does it cache the implementation URL once the
>                      service is
>                               published ? Is
>                               there anyway I can update  the
>         implementation URL
>                      for an
>                               existing service?
>
>                               Appreciate your time and help.
>
>                               Thanks
>                               Sanjay
>
>
>
>
>
>           _______________________________________________
>                               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
>
>
>
>
>

From amit.joshi at markit.com  Tue Jan 26 08:08:00 2016
From: amit.joshi at markit.com (Amit Joshi)
Date: Tue, 26 Jan 2016 13:08:00 +0000
Subject: [Apiman-user] Replacing Keycloak
In-Reply-To: <56A68EB4.3050702@redhat.com>
References: <9e20ee912967468d9ef348091088c39b@NJ4PDMSGDAG01.markit.partners>
	<56A68751.2070904@redhat.com>
	<1411b3529e074cb1ae5860a14fbcb62a@NJ4PDMSGDAG01.markit.partners>
	<56A68EB4.3050702@redhat.com>
Message-ID: <5b9979dca4a442b5bba7a42ba67dd02d@NJ4PDMSGDAG01.markit.partners>

Hello,



Thanks for the help. I am checking with the internal folks to check that I can share out the PF code (I don't anticipate any issues but need to make sure).



I read through the code a little bit and it appears that the best approach would be to have a Openidc adapter (since Ping Federate supports that directly). I am looking at the Keycloak adapter to see if I can use that code or whether there is some other library that will provide Openidc support directly into JEE - I am more familiar with Spring where Oauth2 support for external Oauth2 servers is part of Spring Security. I was thinking of looking at pac4j (http://www.pac4j.org/) that is Apache 2 licensed and claims to have full security token support (Oauth, Openid Connect, ...) for JEE. The approach I was thinking of:



1.       Use the library to get a  login security filter, replacing the KeyCloakLoginModule.

2.       Save the token similar to Keycloak

3.       Reuse the token for the API authentication.

4.       If that works then it should be able to authenticate against pretty much any other implementation (I would suspect even against Keycloak) directly.



Let me know what you think of the approach.



Regards,



Amit Joshi



-----Original Message-----
From: Eric Wittmann [mailto:eric.wittmann at redhat.com]
Sent: Monday, January 25, 2016 4:08 PM
To: Amit Joshi; apiman-user at lists.jboss.org
Subject: Re: [Apiman-user] Replacing Keycloak



OK great - we're on the same page then.  Happy to help (and then reap the benefits of your work in apiman!).  :)



We need to split the problem up into two.  The first (and probably

harder) problem is supporting PF as an authentication mechanism for apiman.  The second problem is protecting managed APIs with PF.



#1 Apiman Auth via PF

---------------------

* Can you share your PF sample java app?

* There are three WARs that will need to be protected:

    - apiman.war

    - apiman-gateway-api.war

    - apimanui.war

* !!!!!!  Let's focus first on "apimanui.war", which is a standard java web application.  !!!!!!!!

* We will need to secure the WAR with PF *and* provide a PF-specific impl of ISecurityContext.  There are two impls thus far, DefaultSecurityContext and KeycloakSecurityContext.  If the PF authentication code puts the auth principal and roles into the servlet request, then you can use DefaultSecurityContext.  If not, a custom impl may be required (see the KC impl for more info).



                http://bit.ly/1ZZAmwW



* The security context is configured here:



                http://bit.ly/1KAvu51



* After the user logs into the UI, the UI will then use the oauth bearer token to make authenticated calls directly from the UI to the API Manager REST layer.  This bearer token is periodically refreshed by making a call to the /apimanui/ context to get a new token.  This is what is called:  ITokenGenerator

* Assuming PF uses bearer tokens, we'll need a PF implementation of the above interface.  See KeyCloakBearerTokenGenerator for more information.



* Note: the keycloak plugin you are looking at is *not* the code that is called when logging into apiman.  For that, you'd have to look at the keycloak adapter code:



                https://github.com/keycloak/keycloak/tree/master/adapters





#2 Protected Managed APIs with PF

---------------------------------

* Our OAuth support is a keycloak-specific apiman policy that I think you've already discovered:



https://github.com/apiman/apiman-plugins/tree/master/keycloak-oauth-policy



* Adding PF authentication support will require a *new* plugin specific to PF.



-------------------



OK that's a lot, I know.  Let's start with your PF enabled java app and try to apply those principals to the API Manager UI.



-Eric





On 1/25/2016 3:47 PM, Amit Joshi wrote:

> Hello,

>

> I am trying to use Ping Federate for both login and for the API restrictions.

>

> I understand that integrating into Ping Federate might not be trivial and might require some hacking into the APIMan code. I have created a sample java app that does the SP initiated login for ping federate that works. However with APIMan I am lost as to where to start ... I tried to look at the apiman-plugin-keycloak-oauth-policy to see but I suspect that it will take me some time to trace through it and figured that people working on the product might be able to get me started quicker.

>

> In short, happy to help hack on the code but will need the touch points.  I assume there is some code somewhere that checks if the token already exists and if not then generates the auth request, gets the access code, validates the code and generates the token?

>

> Regards,

>

> Amit Joshi

>

> -----Original Message-----

> From: Eric Wittmann [mailto:eric.wittmann at redhat.com]

> Sent: Monday, January 25, 2016 3:37 PM

> To: Amit Joshi; apiman-user at lists.jboss.org<mailto:apiman-user at lists.jboss.org>

> Subject: Re: [Apiman-user] Replacing Keycloak

>

> Hi Amit.

>

> To be clear, you are trying to replace Keycloak as the authentication mechanism for logging into the apiman UI, correct?

>

> I can't say I know how to configure a web application to use pingfederate for authenticaiton (never done that before).  But I can tell you that it's likely that you will not be able to use the settings in standalone-apiman.xml because those are configuration settings for the keycloak auth client adapter.  The client adapter is the keycloak specific client that handles authentication redirects to the auth server.  I *assume* this adapter is keycloak-specific.

>

> In order to get pingfederate working I must assume that they

> (pingfederate) have some documentation for how to configure a java web application for authentication.  Sadly their documentation server seems to be broken at the moment.

>

> I'll warn you that, while I'm sure using pingfederate is *possible*, it is probably not trivial.  You may need to contribute some code to apiman in order to enable support in the UI, for example.  If hacking some code is not a daunting prospect then I'd be happy to help point you in the direction of all the authentication touch points...

>

> -Eric

>

>

> On 1/25/2016 3:18 PM, Amit Joshi wrote:

>> Hello,

>>

>> I have the following setup:

>>

>> Ping server -> external https url  (something like

>> https://pingfederate.mydomain.com) - through an apache reverse proxy.

>> Real server is pingfederate001.internal.com.

>>

>> APIman  -> external https url (something like

>> https://apiman.mydomain.com) through ab apache reverse proxy. Real

>> server is apiman001.internal.com.

>>

>> I am trying to replace keycloak with ping federate in APIMan.  I have

>>

>> -Disabled the integrated Keycloak.

>>

>> -Changed the

>> <kc:auth-server-url>https://pingfederate.mydomain.com/as/token.oauth2

>> <

>> /kc:auth-server-url

>> <https://pingfederate.mydomain.com/as/token.oauth2%3c/kc:auth-server-

>> u

>> rl>>

>>

>> However, when I access I see the following as the redirect - which is

>> clearly wrong:

>>

>> https://pingfederate.mydomain.com/as/token.oauth2/relams/apiman/protocol/openid_connect/auth?

>>

>> with the following parameters:

>>

>> response_type=code

>>

>> client_id=apimanui

>>

>> redirect_uri=http://apiman001.internal.com

>>

>> I looked the code for the keycloak plugin but can't seem to see where

>> the redirect is generated or set. I assume it is some additional

>> properties or settings that I have to do or change code for so I can

>> generate a Ping friendly redirect url etc.

>>

>> Appreciate any help or any pointers.

>>

>> Regards,

>>

>> Amit Joshi

>>

>>

>> ---------------------------------------------------------------------

>> -

>> --

>>

>> This e-mail, including accompanying communications and attachments,

>> is strictly confidential and only for the intended recipient. Any

>> retention, use or disclosure not expressly authorised by Markit is

>> prohibited. This email is subject to all waivers and other terms at

>> the following link:

>> http://www.markit.com/en/about/legal/email-disclaimer.page

>>

>> Please visit http://www.markit.com/en/about/contact/contact-us.page

>> for contact information on our offices worldwide.

>>

>>

>> _______________________________________________

>> 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

>>

>

> ________________________________

>

> This e-mail, including accompanying communications and attachments, is

> strictly confidential and only for the intended recipient. Any

> retention, use or disclosure not expressly authorised by Markit is

> prohibited. This email is subject to all waivers and other terms at

> the following link:

> http://www.markit.com/en/about/legal/email-disclaimer.page

>

> Please visit http://www.markit.com/en/about/contact/contact-us.page for contact information on our offices worldwide.

>

________________________________

This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page

Please visit http://www.markit.com/en/about/contact/contact-us.page for contact information on our offices worldwide.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160126/d9a7d8a2/attachment-0001.html 

From eric.wittmann at redhat.com  Tue Jan 26 08:11:13 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 26 Jan 2016 08:11:13 -0500
Subject: [Apiman-user] Authorization policy with Web Service
In-Reply-To: <2120861066.14105591.1453788451831.JavaMail.zimbra@redhat.com>
References: <2120861066.14105591.1453788451831.JavaMail.zimbra@redhat.com>
Message-ID: <56A77071.8050600@redhat.com>

The Authorization policy is specific to RESTful APIs - it uses the HTTP 
verb (as you noted) when determining if a request is allowed.  In fact, 
we've recently updated the UI to provide a drop-down for the Verb rather 
than having people type it in.

To perform Authorization using the SOAPAction HTTP header, I think we 
need a new policy.

If you're up for doing that yourself, fantastic.  If not then please add 
a JIRA feature request and we'll get something built when we can.  It 
shouldn't be very difficult.

-Eric

On 1/26/2016 1:07 AM, Charles Moulliard wrote:
> Hi,
>
> Could it be possible to use the existing authorization policy to handle WebService where according to the SOAPAction we have to authorize the call to a method or do we have to create a new authorization policy ?
>
> As a WebService is not managed as RESTfull service where the HTTP Operation (= verb) can be used to determine if we will create, read or update something and restrict access for a user based on a role (writer, reader or admin), I try to figure out how we could achieve that authorization (= role based) based on the SOAPAction for webservice without creating a different WebService with only one operation/method to handle the actions to create/delete/read/update ...
>
> Regards,
>
> Charles
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From mssanjay at gmail.com  Wed Jan 27 00:17:20 2016
From: mssanjay at gmail.com (Sanjay Melinamani)
Date: Wed, 27 Jan 2016 00:17:20 -0500
Subject: [Apiman-user] How to update backend implementation URL for
 published Service without changing the version
In-Reply-To: <56A76F69.7030807@redhat.com>
References: <CAG9c92J9MRSqQvUMK2ARiUmLRedt6SfVzuPZCGMG-JoqhTEeig@mail.gmail.com>
	<568A9D27.2070400@redhat.com>
	<CAG9c92LdKqinw_YjK3LutiUn2+7jKcQW7DkYTd6=YsCHvzNYSQ@mail.gmail.com>
	<568BBE9F.2000504@redhat.com>
	<CAG9c92J9x30cfw6dFW2qG7wD+E7NcDAwT0LZ=OJ++AnbmC0jJA@mail.gmail.com>
	<CAG9c92LHPHFnSr0krXAB0UXM_DxzbftSSf+Vtr7fQSb+qLArwA@mail.gmail.com>
	<568E6343.4050502@redhat.com>
	<CAG9c92L2RZYH6svR5WYF254P8z1DSo0X+aeRUTQzJWN_7kTwrQ@mail.gmail.com>
	<56A76F69.7030807@redhat.com>
Message-ID: <CAG9c92JRzqPc40NS3TE9dc19upnyLy4m3BTmFSAOVcYp=vYoXA@mail.gmail.com>

Hi Eric,
When I run curl -XGET http://localhost:19200/apiman_gateway/service/_search ,
I do see Old implementation URLs.
I have restarted apiman many times. Still the old url is being used.

Thanks
Sanjay


On Tue, Jan 26, 2016 at 8:06 AM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> Thanks. :)
>
> As for the index files - I think the bigger question is what do you see
> when you do a search in elastic?
>
> curl -XGET http://localhost:19200/apiman_gateway/service/_search
>
> What are the results of doing the above?
>
> I don't have any idea what might be stored in the elasticsearch index
> files - so I can't tell you what to expect from a grep.
>
> I *can* tell you that there is no re-index operation.  When you update the
> document (via the PUT http request) it should store the new data in ES
> *and* update its indices.  That's EXACTLY what apiman does internally when
> updating/adding/publishing a service.
>
> After restarting apiman, is your gateway still using the wrong (old)
> endpoint?
>
> One last thing - if you are planning on using this in production, we
> really recommend that you install a standalone instance of elasticsearch
> rather than using the one included in the apiman quickstart.  There's more
> information in the production guide:
>
> http://www.apiman.io/latest/production-guide.html
>
> -Eric
>
> On 1/26/2016 2:08 AM, Sanjay Melinamani wrote:
>
>> Hi Eric,
>>
>> Congratulations on the new Release! I can't wait to migrate to 1.2.1 !!
>>
>> Meanwhile I am still having hard time replacing the implementation URL
>> used in a published API.. Here is what I see..
>> When I execute GET, I see the new implementation URL used
>> (
>> http://internal-XXXX.elb.amazonaws.com:8080/hra-web/services/engine/OSA/cf
>> )
>> but when I do a grep on my old URL "10.0.0.241", I see the matches in
>> index files. How can I rebuild the indices?
>>
>>
>> [ec2-user at Prism-ST-GWY wildfly-8.2.0.Final]$ curl -XGET
>> http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
>> {"endpoint":"
>> http://internal-XXXX.elb.amazonaws.com:8080/hra-web/services/engine/OSA/cf
>> ","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}
>>
>>
>> [ec2-user at Prism-ST-GWY wildfly-8.2.0.Final]$ grep -rnw . -e "10.0.0.241"
>> Binary file
>>
>> ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/3/index/_0.cfs
>> matches
>> Binary file
>>
>> ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/3/index/_1y.cfs
>> matches
>> Binary file
>>
>> ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/3/index/_1z.cfs
>> matches
>> Binary file
>>
>> ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/2/index/_2.cfs
>> matches
>> Binary file
>>
>> ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/2/index/_3.cfs
>> matches
>> Binary file
>>
>> ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/2/index/_4.cfs
>> matches
>> Binary file
>>
>> ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/4/index/_0.cfs
>> matches
>> Binary file
>>
>> ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/4/index/_1.cfs
>> matches
>>
>> Thanks
>> Sanjay
>>
>>
>>
>> On Thu, Jan 7, 2016 at 8:08 AM, Eric Wittmann <eric.wittmann at redhat.com
>> <mailto:eric.wittmann at redhat.com>> wrote:
>>
>>     No nothing like that should be needed.  Doing that curl command is
>>     just like doing an UPDATE on a SQL db.  I even tried it locally
>>     (switching between URLs by updating that record in elastic) and
>>     didn't have any problems.
>>
>>     Did you restart apiman after the change?  Unfortunately (for this
>>     use-case) apiman will cache the information so that it doesn't have
>>     to do a lookup in ES for *every* request.
>>
>>     Also what happens how when you do the -XGET call?  Do you see the
>>     new data?
>>
>>     -Eric
>>
>>     On 1/7/2016 2:58 AM, Sanjay Melinamani wrote:
>>
>>         Hi Eric,
>>         Even after the restart, gateway is still using the OLD service
>>         implementation URL. Do I have to rebuild the index, clear cache
>>         or do
>>         something else??
>>         When grepped for old URL, I can still see it in indices folder of
>>         elastic search. I tried to clear cache and used refresh commands
>>         but did
>>         not work!
>>
>>         Appreciate if you can provide some more guidance here.
>>
>>         Thanks
>>         Sanjay
>>
>>
>>         On Wed, Jan 6, 2016 at 12:57 PM, Sanjay Melinamani
>>         <mssanjay at gmail.com <mailto:mssanjay at gmail.com>
>>         <mailto:mssanjay at gmail.com <mailto:mssanjay at gmail.com>>> wrote:
>>
>>              Thanks  a ton! Worked like a charm :)
>>
>>              Sanjay
>>
>>
>>              On Tue, Jan 5, 2016 at 8:01 AM, 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>>> wrote:
>>
>>                  Drop the /_source from the PUT command. :)
>>
>>                  -Eric
>>
>>                  On 1/5/2016 1:45 AM, Sanjay Melinamani wrote:
>>
>>                      Thanks Eric for your reply! makes sense...
>>
>>                      I tried to use the two CURL commands.
>>
>>                      GET worked and I was able to see the end point
>>         being used.
>>                      curl -XGET
>>
>> http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
>>
>>         {"endpoint":"http://OLD_URL
>> ","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}
>>
>>
>>
>>                      But the PUT failed as below..
>>
>>                      curl -XPUT
>>
>> http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
>>                      -d
>>
>>         '{"endpoint":"http://NEW_URL
>> ","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}'
>>
>>                      No handler found for uri
>>                      [/apiman_gateway/service/prism:osa:1.0/_source]
>>                      and method [PUT]
>>
>>
>>                      Thanks again for your time
>>
>>                      Sanjay
>>
>>
>>                      On Mon, Jan 4, 2016 at 11:26 AM, 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
>> >>
>>                      <mailto:eric.wittmann at redhat.com
>>         <mailto:eric.wittmann at redhat.com>
>>
>>                      <mailto:eric.wittmann at redhat.com
>>         <mailto:eric.wittmann at redhat.com>>>> wrote:
>>
>>                           Hi Sanjay, thanks for the questions.
>>
>>                           Currently there is no easy way to update the
>>         backend
>>                      implementation
>>                           endpiont URL without creating a new version of
>>         the service.
>>
>>                           However, if this is a one-off sort of thing
>>         then you
>>                      may be able to
>>                           get it done.  It depends mostly on what
>>         configuration
>>                      you are
>>                           using.  But I'll explain based on the most
>>         recent 1.1.x
>>                      release
>>                           (1.1.9.Final) with its default configuration.
>>
>>                           The Manager and Gateway are decoupled,
>>         resulting in the
>>                      duplication
>>                           of *some* of the data (including the endpoint
>>         URL).  So
>>                      when you
>>                           "publish" a service from the Manager, the
>>         Gateway is given
>>                           information about the service.  This
>>         information is
>>                      stored in the
>>                           Gateway's "registry".  By default the registry
>>                      implementation is
>>                           elasticsearch.  So if you wanted to change the
>>         endpoint
>>                      URL for a
>>                           service, you would need to update that
>>         information in
>>                      your Database
>>                           (you did this) *and* in elasticsearch.
>>
>>                           It's actually not that difficult to update the
>>                      information in
>>                           elasticsearch.  You'll need to find the
>>         correct record
>>                      and then
>>                           update it.  If you're using the default
>>         installation,
>>                      then ES is
>>                           running on port 19200.  If you want to change
>> the
>>                      following service:
>>
>>                           Organization:  Example
>>                           Service ID:    MyService
>>                           Version:       1.0
>>
>>                           Then you might do something like this:
>>
>>                           curl -XGET
>>
>> http://localhost:19200/apiman_gateway/service/Example:MyService:1.0/_source
>>
>>                           You could then take that JSON result, modify
>>         the bits
>>                      you want to
>>                           change, and then update it like so (as an
>>         example -
>>                      please replace
>>                           the JSON below with the JSON you get back from
>>         the GET
>>                      above):
>>
>>                           curl -XPUT
>>
>> http://localhost:19200/apiman_gateway/service/Example:MyService:1.0
>>                      -d '
>>                           {
>>                              "endpoint" : "http://UPDATED-ENDPOINT-HERE",
>>                              "endpointType" : "rest",
>>                              "publicService" : true,
>>                              "organizationId" : "Example",
>>                              "serviceId": "MyService",
>>                              "version" : "1.0",
>>                              "endpointProperties": [],
>>                              "policies":[]
>>                           }
>>                           '
>>
>>                           Once this is done you'll have to restart
>>         apiman so that
>>                      the Gateway
>>                           picks up the changes.
>>
>>                           Note: we are making some changes in apiman
>>         1.2.x that
>>                      will make all
>>                           of this easier under some circumstances.  In
>>                      particular, as of
>>                           apiman 1.2.0.Final you will be able to
>> re-publish
>>                      "Public" services
>>                           (now called APIs).  So if the API is public
>>         then you
>>                      can simply make
>>                           changes and then republish those changes to the
>>                      Gateway.  If the API
>>                           is *not* public then the current semantics are
>> the
>>                      same:  you cannot
>>                           make changes and republish because that may
>>         violate
>>                      contracts that
>>                           consumers have made with your API.
>>
>>                           -Eric
>>
>>
>>
>>                           On 12/29/2015 12:19 PM, Sanjay Melinamani wrote:
>>
>>                               Hi All,
>>                               I am using APIMAN 1.1.9 and for an
>>         existing API
>>                      that I have
>>                               published to
>>                               consumers, I like to change its backend
>>                      implementation end point URL
>>                               without changing the API service version.
>>                               I updated the backend implementation URL in
>>                      database table
>>                               "service_versions". I can see the updated
>>         URL from
>>                      UI but still the
>>                               gateway is using the old implementation
>>         URL specified.
>>                               Does it cache the implementation URL once
>> the
>>                      service is
>>                               published ? Is
>>                               there anyway I can update  the
>>         implementation URL
>>                      for an
>>                               existing service?
>>
>>                               Appreciate your time and help.
>>
>>                               Thanks
>>                               Sanjay
>>
>>
>>
>>
>>
>>           _______________________________________________
>>                               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
>>
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160127/d8d9589e/attachment-0001.html 

From lists at comiti.name  Wed Jan 27 05:32:46 2016
From: lists at comiti.name (enrico)
Date: Wed, 27 Jan 2016 11:32:46 +0100
Subject: [Apiman-user] external Keycloak server
Message-ID: <CAMJ0bZUd0fKRDFx5=UWT1Roaxqh6BpAJPZnBSwSac+wqcoLj+A@mail.gmail.com>

Hi all and thanks for this awesome project,

I'm trying to setup an Apiman instance pointing to external Keycloak server
(and Elastic search, I don't know if it could be related)
but I'm not able to log in.

The Apiman version is 1.2.1.Final and Keycloak 1.8.0.CR3.

In standalone-apiman.xml I have removed the lines:

https://github.com/apiman/apiman/blob/master/distro/wildfly9/src/main/resources/overlay/standalone/configuration/standalone-apiman.xml#L31

and

https://github.com/apiman/apiman/blob/master/distro/wildfly9/src/main/resources/overlay/standalone/configuration/standalone-apiman.xml#L408-L410

and set the auth server in

https://github.com/apiman/apiman/blob/master/distro/wildfly9/src/main/resources/overlay/standalone/configuration/standalone-apiman.xml#L414

The apiman-realm is taken from
https://raw.githubusercontent.com/apiman/apiman/master/distro/data/src/main/resources/data/apiman-realm.json

and I have substituted the "secret" fields with the values from
standalone-apiman.xml.

Relevant ERROR logs from Apiman
org.keycloak.adapters.OAuthRequestAuthenticator are:

failed to turn code into token
status from server: 400
{"error_description":"Client secret not provided in
request","error":"unauthorized_client"}

Any hint?

Cheers, Enrico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160127/52bcd71f/attachment.html 

From eric.wittmann at redhat.com  Wed Jan 27 09:04:28 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Wed, 27 Jan 2016 09:04:28 -0500
Subject: [Apiman-user] How to update backend implementation URL for
 published Service without changing the version
In-Reply-To: <CAG9c92JRzqPc40NS3TE9dc19upnyLy4m3BTmFSAOVcYp=vYoXA@mail.gmail.com>
References: <CAG9c92J9MRSqQvUMK2ARiUmLRedt6SfVzuPZCGMG-JoqhTEeig@mail.gmail.com>
	<568A9D27.2070400@redhat.com>
	<CAG9c92LdKqinw_YjK3LutiUn2+7jKcQW7DkYTd6=YsCHvzNYSQ@mail.gmail.com>
	<568BBE9F.2000504@redhat.com>
	<CAG9c92J9x30cfw6dFW2qG7wD+E7NcDAwT0LZ=OJ++AnbmC0jJA@mail.gmail.com>
	<CAG9c92LHPHFnSr0krXAB0UXM_DxzbftSSf+Vtr7fQSb+qLArwA@mail.gmail.com>
	<568E6343.4050502@redhat.com>
	<CAG9c92L2RZYH6svR5WYF254P8z1DSo0X+aeRUTQzJWN_7kTwrQ@mail.gmail.com>
	<56A76F69.7030807@redhat.com>
	<CAG9c92JRzqPc40NS3TE9dc19upnyLy4m3BTmFSAOVcYp=vYoXA@mail.gmail.com>
Message-ID: <56A8CE6C.8060306@redhat.com>

Sanjay - I will do some testing again to see if I can reproduce this 
behavior.  I'll respond back with *exact* steps and we'll see how it goes.

I honestly can't explain how you could be experiencing this - but then 
again I'm not really an expert on Elastic.  Based on what I know, I 
didn't think it was possible to run up against what you're seeing.

We'll see how my testing goes....

-Eric

On 1/27/2016 12:17 AM, Sanjay Melinamani wrote:
> Hi Eric,
> When I run curl -XGET
> http://localhost:19200/apiman_gateway/service/_search , I do see Old
> implementation URLs.
> I have restarted apiman many times. Still the old url is being used.
>
> Thanks
> Sanjay
>
>
> On Tue, Jan 26, 2016 at 8:06 AM, Eric Wittmann <eric.wittmann at redhat.com
> <mailto:eric.wittmann at redhat.com>> wrote:
>
>     Thanks. :)
>
>     As for the index files - I think the bigger question is what do you
>     see when you do a search in elastic?
>
>     curl -XGET http://localhost:19200/apiman_gateway/service/_search
>
>     What are the results of doing the above?
>
>     I don't have any idea what might be stored in the elasticsearch
>     index files - so I can't tell you what to expect from a grep.
>
>     I *can* tell you that there is no re-index operation.  When you
>     update the document (via the PUT http request) it should store the
>     new data in ES *and* update its indices.  That's EXACTLY what apiman
>     does internally when updating/adding/publishing a service.
>
>     After restarting apiman, is your gateway still using the wrong (old)
>     endpoint?
>
>     One last thing - if you are planning on using this in production, we
>     really recommend that you install a standalone instance of
>     elasticsearch rather than using the one included in the apiman
>     quickstart.  There's more information in the production guide:
>
>     http://www.apiman.io/latest/production-guide.html
>
>     -Eric
>
>     On 1/26/2016 2:08 AM, Sanjay Melinamani wrote:
>
>         Hi Eric,
>
>         Congratulations on the new Release! I can't wait to migrate to
>         1.2.1 !!
>
>         Meanwhile I am still having hard time replacing the
>         implementation URL
>         used in a published API.. Here is what I see..
>         When I execute GET, I see the new implementation URL used
>         (http://internal-XXXX.elb.amazonaws.com:8080/hra-web/services/engine/OSA/cf)
>         but when I do a grep on my old URL "10.0.0.241", I see the
>         matches in
>         index files. How can I rebuild the indices?
>
>
>         [ec2-user at Prism-ST-GWY wildfly-8.2.0.Final]$ curl -XGET
>         http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
>         {"endpoint":"http://internal-XXXX.elb.amazonaws.com:8080/hra-web/services/engine/OSA/cf","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}
>
>
>         [ec2-user at Prism-ST-GWY wildfly-8.2.0.Final]$ grep -rnw . -e
>         "10.0.0.241"
>         Binary file
>         ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/3/index/_0.cfs
>         matches
>         Binary file
>         ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/3/index/_1y.cfs
>         matches
>         Binary file
>         ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/3/index/_1z.cfs
>         matches
>         Binary file
>         ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/2/index/_2.cfs
>         matches
>         Binary file
>         ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/2/index/_3.cfs
>         matches
>         Binary file
>         ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/2/index/_4.cfs
>         matches
>         Binary file
>         ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/4/index/_0.cfs
>         matches
>         Binary file
>         ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/4/index/_1.cfs
>         matches
>
>         Thanks
>         Sanjay
>
>
>
>         On Thu, Jan 7, 2016 at 8:08 AM, 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>>> wrote:
>
>              No nothing like that should be needed.  Doing that curl
>         command is
>              just like doing an UPDATE on a SQL db.  I even tried it locally
>              (switching between URLs by updating that record in elastic) and
>              didn't have any problems.
>
>              Did you restart apiman after the change?  Unfortunately
>         (for this
>              use-case) apiman will cache the information so that it
>         doesn't have
>              to do a lookup in ES for *every* request.
>
>              Also what happens how when you do the -XGET call?  Do you
>         see the
>              new data?
>
>              -Eric
>
>              On 1/7/2016 2:58 AM, Sanjay Melinamani wrote:
>
>                  Hi Eric,
>                  Even after the restart, gateway is still using the OLD
>         service
>                  implementation URL. Do I have to rebuild the index,
>         clear cache
>                  or do
>                  something else??
>                  When grepped for old URL, I can still see it in indices
>         folder of
>                  elastic search. I tried to clear cache and used refresh
>         commands
>                  but did
>                  not work!
>
>                  Appreciate if you can provide some more guidance here.
>
>                  Thanks
>                  Sanjay
>
>
>                  On Wed, Jan 6, 2016 at 12:57 PM, Sanjay Melinamani
>                  <mssanjay at gmail.com <mailto:mssanjay at gmail.com>
>         <mailto:mssanjay at gmail.com <mailto:mssanjay at gmail.com>>
>                  <mailto:mssanjay at gmail.com <mailto:mssanjay at gmail.com>
>         <mailto:mssanjay at gmail.com <mailto:mssanjay at gmail.com>>>> wrote:
>
>                       Thanks  a ton! Worked like a charm :)
>
>                       Sanjay
>
>
>                       On Tue, Jan 5, 2016 at 8:01 AM, 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>>
>                  <mailto:eric.wittmann at redhat.com
>         <mailto:eric.wittmann at redhat.com>
>                  <mailto:eric.wittmann at redhat.com
>         <mailto:eric.wittmann at redhat.com>>>> wrote:
>
>                           Drop the /_source from the PUT command. :)
>
>                           -Eric
>
>                           On 1/5/2016 1:45 AM, Sanjay Melinamani wrote:
>
>                               Thanks Eric for your reply! makes sense...
>
>                               I tried to use the two CURL commands.
>
>                               GET worked and I was able to see the end point
>                  being used.
>                               curl -XGET
>         http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
>
>
>         {"endpoint":"http://OLD_URL","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}
>
>
>
>                               But the PUT failed as below..
>
>                               curl -XPUT
>         http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
>                               -d
>
>
>         '{"endpoint":"http://NEW_URL","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}'
>
>                               No handler found for uri
>
>           [/apiman_gateway/service/prism:osa:1.0/_source]
>                               and method [PUT]
>
>
>                               Thanks again for your time
>
>                               Sanjay
>
>
>                               On Mon, Jan 4, 2016 at 11:26 AM, 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>>
>                  <mailto:eric.wittmann at redhat.com
>         <mailto:eric.wittmann at redhat.com>
>         <mailto:eric.wittmann at redhat.com <mailto:eric.wittmann at redhat.com>>>
>                               <mailto:eric.wittmann at redhat.com
>         <mailto:eric.wittmann at redhat.com>
>                  <mailto:eric.wittmann at redhat.com
>         <mailto:eric.wittmann at redhat.com>>
>
>                               <mailto:eric.wittmann at redhat.com
>         <mailto:eric.wittmann at redhat.com>
>                  <mailto:eric.wittmann at redhat.com
>         <mailto:eric.wittmann at redhat.com>>>>> wrote:
>
>                                    Hi Sanjay, thanks for the questions.
>
>                                    Currently there is no easy way to
>         update the
>                  backend
>                               implementation
>                                    endpiont URL without creating a new
>         version of
>                  the service.
>
>                                    However, if this is a one-off sort of
>         thing
>                  then you
>                               may be able to
>                                    get it done.  It depends mostly on what
>                  configuration
>                               you are
>                                    using.  But I'll explain based on the
>         most
>                  recent 1.1.x
>                               release
>                                    (1.1.9.Final) with its default
>         configuration.
>
>                                    The Manager and Gateway are decoupled,
>                  resulting in the
>                               duplication
>                                    of *some* of the data (including the
>         endpoint
>                  URL).  So
>                               when you
>                                    "publish" a service from the Manager, the
>                  Gateway is given
>                                    information about the service.  This
>                  information is
>                               stored in the
>                                    Gateway's "registry".  By default the
>         registry
>                               implementation is
>                                    elasticsearch.  So if you wanted to
>         change the
>                  endpoint
>                               URL for a
>                                    service, you would need to update that
>                  information in
>                               your Database
>                                    (you did this) *and* in elasticsearch.
>
>                                    It's actually not that difficult to
>         update the
>                               information in
>                                    elasticsearch.  You'll need to find the
>                  correct record
>                               and then
>                                    update it.  If you're using the default
>                  installation,
>                               then ES is
>                                    running on port 19200.  If you want
>         to change the
>                               following service:
>
>                                    Organization:  Example
>                                    Service ID:    MyService
>                                    Version:       1.0
>
>                                    Then you might do something like this:
>
>                                    curl -XGET
>         http://localhost:19200/apiman_gateway/service/Example:MyService:1.0/_source
>
>                                    You could then take that JSON result,
>         modify
>                  the bits
>                               you want to
>                                    change, and then update it like so (as an
>                  example -
>                               please replace
>                                    the JSON below with the JSON you get
>         back from
>                  the GET
>                               above):
>
>                                    curl -XPUT
>         http://localhost:19200/apiman_gateway/service/Example:MyService:1.0
>                               -d '
>                                    {
>                                       "endpoint" :
>         "http://UPDATED-ENDPOINT-HERE",
>                                       "endpointType" : "rest",
>                                       "publicService" : true,
>                                       "organizationId" : "Example",
>                                       "serviceId": "MyService",
>                                       "version" : "1.0",
>                                       "endpointProperties": [],
>                                       "policies":[]
>                                    }
>                                    '
>
>                                    Once this is done you'll have to restart
>                  apiman so that
>                               the Gateway
>                                    picks up the changes.
>
>                                    Note: we are making some changes in
>         apiman
>                  1.2.x that
>                               will make all
>                                    of this easier under some
>         circumstances.  In
>                               particular, as of
>                                    apiman 1.2.0.Final you will be able
>         to re-publish
>                               "Public" services
>                                    (now called APIs).  So if the API is
>         public
>                  then you
>                               can simply make
>                                    changes and then republish those
>         changes to the
>                               Gateway.  If the API
>                                    is *not* public then the current
>         semantics are the
>                               same:  you cannot
>                                    make changes and republish because
>         that may
>                  violate
>                               contracts that
>                                    consumers have made with your API.
>
>                                    -Eric
>
>
>
>                                    On 12/29/2015 12:19 PM, Sanjay
>         Melinamani wrote:
>
>                                        Hi All,
>                                        I am using APIMAN 1.1.9 and for an
>                  existing API
>                               that I have
>                                        published to
>                                        consumers, I like to change its
>         backend
>                               implementation end point URL
>                                        without changing the API service
>         version.
>                                        I updated the backend
>         implementation URL in
>                               database table
>                                        "service_versions". I can see the
>         updated
>                  URL from
>                               UI but still the
>                                        gateway is using the old
>         implementation
>                  URL specified.
>                                        Does it cache the implementation
>         URL once the
>                               service is
>                                        published ? Is
>                                        there anyway I can update  the
>                  implementation URL
>                               for an
>                                        existing service?
>
>                                        Appreciate your time and help.
>
>                                        Thanks
>                                        Sanjay
>
>
>
>
>
>                    _______________________________________________
>                                        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>>>
>                               <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
>         <mailto:Apiman-user at lists.jboss.org>>>>
>         https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
>
>
>
>

From eric.wittmann at redhat.com  Wed Jan 27 11:34:48 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Wed, 27 Jan 2016 11:34:48 -0500
Subject: [Apiman-user] external Keycloak server
In-Reply-To: <CAMJ0bZUd0fKRDFx5=UWT1Roaxqh6BpAJPZnBSwSac+wqcoLj+A@mail.gmail.com>
References: <CAMJ0bZUd0fKRDFx5=UWT1Roaxqh6BpAJPZnBSwSac+wqcoLj+A@mail.gmail.com>
Message-ID: <56A8F1A8.4090405@redhat.com>

Hi Enrico.

Sorry about that - I think the production guide is a little out of date 
now that we released apiman against WildFly 9 and Keycloak 1.7.0.  I 
tried updating the guide, but apparently my instructions are incorrect 
or incomplete.  That's what I get for doing it too quickly.

We'll have a look at the guide asap and fix it up.  @msavy is going to 
have a swing at it later (hopefully) today or tomorrow.

What I can tell you right off the bat is that the realm file is probably 
not quite right (I think I forgot to update it for KC 1.7.0).

You could try manually configuring your KC realm, or just wait for us to 
update some stuff (the guide and the realm file).  :)

-Eric

On 1/27/2016 5:32 AM, enrico wrote:
> Hi all and thanks for this awesome project,
>
> I'm trying to setup an Apiman instance pointing to external Keycloak
> server (and Elastic search, I don't know if it could be related)
> but I'm not able to log in.
>
> The Apiman version is 1.2.1.Final and Keycloak 1.8.0.CR3.
>
> In standalone-apiman.xml I have removed the lines:
>
> https://github.com/apiman/apiman/blob/master/distro/wildfly9/src/main/resources/overlay/standalone/configuration/standalone-apiman.xml#L31
>
> and
>
> https://github.com/apiman/apiman/blob/master/distro/wildfly9/src/main/resources/overlay/standalone/configuration/standalone-apiman.xml#L408-L410
>
> and set the auth server in
>
> https://github.com/apiman/apiman/blob/master/distro/wildfly9/src/main/resources/overlay/standalone/configuration/standalone-apiman.xml#L414
>
> The apiman-realm is taken from
> https://raw.githubusercontent.com/apiman/apiman/master/distro/data/src/main/resources/data/apiman-realm.json
>
> and I have substituted the "secret" fields with the values from
> standalone-apiman.xml.
>
> Relevant ERROR logs from Apiman
> org.keycloak.adapters.OAuthRequestAuthenticator are:
>
> failed to turn code into token
> status from server: 400
> {"error_description":"Client secret not provided in
> request","error":"unauthorized_client"}
>
> Any hint?
>
> Cheers, Enrico
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From marc.savy at redhat.com  Wed Jan 27 11:49:55 2016
From: marc.savy at redhat.com (Marc Savy)
Date: Wed, 27 Jan 2016 16:49:55 +0000
Subject: [Apiman-user] external Keycloak server
In-Reply-To: <CAMJ0bZUd0fKRDFx5=UWT1Roaxqh6BpAJPZnBSwSac+wqcoLj+A@mail.gmail.com>
References: <CAMJ0bZUd0fKRDFx5=UWT1Roaxqh6BpAJPZnBSwSac+wqcoLj+A@mail.gmail.com>
Message-ID: <56A8F533.4050100@redhat.com>

Hi Enrico,

We haven't tested with Keycloak 1.8, as this is only a candidate release
at the moment (CR == RC).

I can give it a try, though and will report back.

Regards,
Marc

On 27/01/2016 10:32, enrico wrote:
> Hi all and thanks for this awesome project,
>
> I'm trying to setup an Apiman instance pointing to external Keycloak
> server (and Elastic search, I don't know if it could be related)
> but I'm not able to log in.
>
> The Apiman version is 1.2.1.Final and Keycloak 1.8.0.CR3.
>
> In standalone-apiman.xml I have removed the lines:
>
> https://github.com/apiman/apiman/blob/master/distro/wildfly9/src/main/resources/overlay/standalone/configuration/standalone-apiman.xml#L31
>
> and
>
> https://github.com/apiman/apiman/blob/master/distro/wildfly9/src/main/resources/overlay/standalone/configuration/standalone-apiman.xml#L408-L410
>
> and set the auth server in
>
> https://github.com/apiman/apiman/blob/master/distro/wildfly9/src/main/resources/overlay/standalone/configuration/standalone-apiman.xml#L414
>
> The apiman-realm is taken from
> https://raw.githubusercontent.com/apiman/apiman/master/distro/data/src/main/resources/data/apiman-realm.json
>
> and I have substituted the "secret" fields with the values from
> standalone-apiman.xml.
>
> Relevant ERROR logs from Apiman
> org.keycloak.adapters.OAuthRequestAuthenticator are:
>
> failed to turn code into token
> status from server: 400
> {"error_description":"Client secret not provided in
> request","error":"unauthorized_client"}
>
> Any hint?
>
> Cheers, Enrico
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>


From eric.wittmann at redhat.com  Wed Jan 27 12:11:57 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Wed, 27 Jan 2016 12:11:57 -0500
Subject: [Apiman-user] Replacing Keycloak
In-Reply-To: <5b9979dca4a442b5bba7a42ba67dd02d@NJ4PDMSGDAG01.markit.partners>
References: <9e20ee912967468d9ef348091088c39b@NJ4PDMSGDAG01.markit.partners>
	<56A68751.2070904@redhat.com>
	<1411b3529e074cb1ae5860a14fbcb62a@NJ4PDMSGDAG01.markit.partners>
	<56A68EB4.3050702@redhat.com>
	<5b9979dca4a442b5bba7a42ba67dd02d@NJ4PDMSGDAG01.markit.partners>
Message-ID: <56A8FA5D.5090408@redhat.com>

I hadn't seen pac4j before (not sure how I've missed it) but it looks 
like an interesting approach.

Definitely the first step is using it to secure the apiman web 
application(s).  As you say - that means replacing the Keycloak adapter 
layer.

The hardest part (I'm guessing) will be getting access to the bearer 
token so that the UI can make direct, authenticated calls to /apiman 
using it.

We can get this done iteratively I think - with step #1 definitely being 
to secure /apimanui (replacing the keycloak adapter authentication we 
currently use).

-Eric

On 1/26/2016 8:08 AM, Amit Joshi wrote:
> Hello,
>
> Thanks for the help. I am checking with the internal folks to check that
> I can share out the PF code (I don?t anticipate any issues but need to
> make sure).
>
> I read through the code a little bit and it appears that the best
> approach would be to have a Openidc adapter (since Ping Federate
> supports that directly). I am looking at the Keycloak adapter to see if
> I can use that code or whether there is some other library that will
> provide Openidc support directly into JEE - I am more familiar with
> Spring where Oauth2 support for external Oauth2 servers is part of
> Spring Security. I was thinking of looking at pac4j
> (http://www.pac4j.org/) that is Apache 2 licensed and claims to have
> full security token support (Oauth, Openid Connect, ...) for JEE. The
> approach I was thinking of:
>
> 1.Use the library to get a  login security filter, replacing the
> KeyCloakLoginModule.
>
> 2.Save the token similar to Keycloak
>
> 3.Reuse the token for the API authentication.
>
> 4.If that works then it should be able to authenticate against pretty
> much any other implementation (I would suspect even against Keycloak)
> directly.
>
> Let me know what you think of the approach.
>
> Regards,
>
> Amit Joshi
>
> -----Original Message-----
> From: Eric Wittmann [mailto:eric.wittmann at redhat.com]
> Sent: Monday, January 25, 2016 4:08 PM
> To: Amit Joshi; apiman-user at lists.jboss.org
> Subject: Re: [Apiman-user] Replacing Keycloak
>
> OK great - we're on the same page then.  Happy to help (and then reap
> the benefits of your work in apiman!).  :)
>
> We need to split the problem up into two.  The first (and probably
>
> harder) problem is supporting PF as an authentication mechanism for
> apiman.  The second problem is protecting managed APIs with PF.
>
> #1 Apiman Auth via PF
>
> ---------------------
>
> * Can you share your PF sample java app?
>
> * There are three WARs that will need to be protected:
>
>      - apiman.war
>
>      - apiman-gateway-api.war
>
>      - apimanui.war
>
> * !!!!!!  Let's focus first on "apimanui.war", which is a standard java
> web application.  !!!!!!!!
>
> * We will need to secure the WAR with PF *and* provide a PF-specific
> impl of ISecurityContext.  There are two impls thus far,
> DefaultSecurityContext and KeycloakSecurityContext.  If the PF
> authentication code puts the auth principal and roles into the servlet
> request, then you can use DefaultSecurityContext.  If not, a custom impl
> may be required (see the KC impl for more info).
>
> http://bit.ly/1ZZAmwW
>
> * The security context is configured here:
>
> http://bit.ly/1KAvu51
>
> * After the user logs into the UI, the UI will then use the oauth bearer
> token to make authenticated calls directly from the UI to the API
> Manager REST layer.  This bearer token is periodically refreshed by
> making a call to the /apimanui/ context to get a new token.  This is
> what is called:  ITokenGenerator
>
> * Assuming PF uses bearer tokens, we'll need a PF implementation of the
> above interface.  See KeyCloakBearerTokenGenerator for more information.
>
> * Note: the keycloak plugin you are looking at is *not* the code that is
> called when logging into apiman.  For that, you'd have to look at the
> keycloak adapter code:
>
> https://github.com/keycloak/keycloak/tree/master/adapters
>
> #2 Protected Managed APIs with PF
>
> ---------------------------------
>
> * Our OAuth support is a keycloak-specific apiman policy that I think
> you've already discovered:
>
> https://github.com/apiman/apiman-plugins/tree/master/keycloak-oauth-policy
>
> * Adding PF authentication support will require a *new* plugin specific
> to PF.
>
> -------------------
>
> OK that's a lot, I know.  Let's start with your PF enabled java app and
> try to apply those principals to the API Manager UI.
>
> -Eric
>
> On 1/25/2016 3:47 PM, Amit Joshi wrote:
>
>  > Hello,
>
>  >
>
>  > I am trying to use Ping Federate for both login and for the API
> restrictions.
>
>  >
>
>  > I understand that integrating into Ping Federate might not be trivial
> and might require some hacking into the APIMan code. I have created a
> sample java app that does the SP initiated login for ping federate that
> works. However with APIMan I am lost as to where to start ... I tried to
> look at the apiman-plugin-keycloak-oauth-policy to see but I suspect
> that it will take me some time to trace through it and figured that
> people working on the product might be able to get me started quicker.
>
>  >
>
>  > In short, happy to help hack on the code but will need the touch
> points.  I assume there is some code somewhere that checks if the token
> already exists and if not then generates the auth request, gets the
> access code, validates the code and generates the token?
>
>  >
>
>  > Regards,
>
>  >
>
>  > Amit Joshi
>
>  >
>
>  > -----Original Message-----
>
>  > From: Eric Wittmann [mailto:eric.wittmann at redhat.com]
>
>  > Sent: Monday, January 25, 2016 3:37 PM
>
>  > To: Amit Joshi; apiman-user at lists.jboss.org
> <mailto:apiman-user at lists.jboss.org>
>
>  > Subject: Re: [Apiman-user] Replacing Keycloak
>
>  >
>
>  > Hi Amit.
>
>  >
>
>  > To be clear, you are trying to replace Keycloak as the authentication
> mechanism for logging into the apiman UI, correct?
>
>  >
>
>  > I can't say I know how to configure a web application to use
> pingfederate for authenticaiton (never done that before).  But I can
> tell you that it's likely that you will not be able to use the settings
> in standalone-apiman.xml because those are configuration settings for
> the keycloak auth client adapter.  The client adapter is the keycloak
> specific client that handles authentication redirects to the auth
> server.  I *assume* this adapter is keycloak-specific.
>
>  >
>
>  > In order to get pingfederate working I must assume that they
>
>  > (pingfederate) have some documentation for how to configure a java
> web application for authentication.  Sadly their documentation server
> seems to be broken at the moment.
>
>  >
>
>  > I'll warn you that, while I'm sure using pingfederate is *possible*,
> it is probably not trivial.  You may need to contribute some code to
> apiman in order to enable support in the UI, for example.  If hacking
> some code is not a daunting prospect then I'd be happy to help point you
> in the direction of all the authentication touch points...
>
>  >
>
>  > -Eric
>
>  >
>
>  >
>
>  > On 1/25/2016 3:18 PM, Amit Joshi wrote:
>
>  >> Hello,
>
>  >>
>
>  >> I have the following setup:
>
>  >>
>
>  >> Ping server -> external https url  (something like
>
>  >> https://pingfederate.mydomain.com) - through an apache reverse proxy.
>
>  >> Real server is pingfederate001.internal.com.
>
>  >>
>
>  >> APIman  -> external https url (something like
>
>  >> https://apiman.mydomain.com) through ab apache reverse proxy. Real
>
>  >> server is apiman001.internal.com.
>
>  >>
>
>  >> I am trying to replace keycloak with ping federate in APIMan.  I have
>
>  >>
>
>  >> -Disabled the integrated Keycloak.
>
>  >>
>
>  >> -Changed the
>
>  >> <kc:auth-server-url>https://pingfederate.mydomain.com/as/token.oauth2
>
>  >> <
>
>  >> /kc:auth-server-url
>
>  >> <https://pingfederate.mydomain.com/as/token.oauth2%3c/kc:auth-server-
>
>  >> u
>
>  >> rl>>
>
>  >>
>
>  >> However, when I access I see the following as the redirect - which is
>
>  >> clearly wrong:
>
>  >>
>
>  >>
> https://pingfederate.mydomain.com/as/token.oauth2/relams/apiman/protocol/openid_connect/auth?
>
>  >>
>
>  >> with the following parameters:
>
>  >>
>
>  >> response_type=code
>
>  >>
>
>  >> client_id=apimanui
>
>  >>
>
>  >> redirect_uri=http://apiman001.internal.com
>
>  >>
>
>  >> I looked the code for the keycloak plugin but can't seem to see where
>
>  >> the redirect is generated or set. I assume it is some additional
>
>  >> properties or settings that I have to do or change code for so I can
>
>  >> generate a Ping friendly redirect url etc.
>
>  >>
>
>  >> Appreciate any help or any pointers.
>
>  >>
>
>  >> Regards,
>
>  >>
>
>  >> Amit Joshi
>
>  >>
>
>  >>
>
>  >> ---------------------------------------------------------------------
>
>  >> -
>
>  >> --
>
>  >>
>
>  >> This e-mail, including accompanying communications and attachments,
>
>  >> is strictly confidential and only for the intended recipient. Any
>
>  >> retention, use or disclosure not expressly authorised by Markit is
>
>  >> prohibited. This email is subject to all waivers and other terms at
>
>  >> the following link:
>
>  >> http://www.markit.com/en/about/legal/email-disclaimer.page
>
>  >>
>
>  >> Please visit http://www.markit.com/en/about/contact/contact-us.page
>
>  >> for contact information on our offices worldwide.
>
>  >>
>
>  >>
>
>  >> _______________________________________________
>
>  >> 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
>
>  >>
>
>  >
>
>  > ________________________________
>
>  >
>
>  > This e-mail, including accompanying communications and attachments, is
>
>  > strictly confidential and only for the intended recipient. Any
>
>  > retention, use or disclosure not expressly authorised by Markit is
>
>  > prohibited. This email is subject to all waivers and other terms at
>
>  > the following link:
>
>  > http://www.markit.com/en/about/legal/email-disclaimer.page
>
>  >
>
>  > Please visit http://www.markit.com/en/about/contact/contact-us.page
> for contact information on our offices worldwide.
>
>  >
>
>
> ------------------------------------------------------------------------
>
> This e-mail, including accompanying communications and attachments, is
> strictly confidential and only for the intended recipient. Any
> retention, use or disclosure not expressly authorised by Markit is
> prohibited. This email is subject to all waivers and other terms at the
> following link: http://www.markit.com/en/about/legal/email-disclaimer.page
>
> Please visit http://www.markit.com/en/about/contact/contact-us.page for
> contact information on our offices worldwide.

From eric.wittmann at redhat.com  Wed Jan 27 12:27:20 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Wed, 27 Jan 2016 12:27:20 -0500
Subject: [Apiman-user] How to update backend implementation URL for
 published Service without changing the version
In-Reply-To: <CAG9c92JRzqPc40NS3TE9dc19upnyLy4m3BTmFSAOVcYp=vYoXA@mail.gmail.com>
References: <CAG9c92J9MRSqQvUMK2ARiUmLRedt6SfVzuPZCGMG-JoqhTEeig@mail.gmail.com>
	<568A9D27.2070400@redhat.com>
	<CAG9c92LdKqinw_YjK3LutiUn2+7jKcQW7DkYTd6=YsCHvzNYSQ@mail.gmail.com>
	<568BBE9F.2000504@redhat.com>
	<CAG9c92J9x30cfw6dFW2qG7wD+E7NcDAwT0LZ=OJ++AnbmC0jJA@mail.gmail.com>
	<CAG9c92LHPHFnSr0krXAB0UXM_DxzbftSSf+Vtr7fQSb+qLArwA@mail.gmail.com>
	<568E6343.4050502@redhat.com>
	<CAG9c92L2RZYH6svR5WYF254P8z1DSo0X+aeRUTQzJWN_7kTwrQ@mail.gmail.com>
	<56A76F69.7030807@redhat.com>
	<CAG9c92JRzqPc40NS3TE9dc19upnyLy4m3BTmFSAOVcYp=vYoXA@mail.gmail.com>
Message-ID: <56A8FDF8.1090905@redhat.com>

OK Sanjay - I did a pretty thorough test of this with a fresh 
installation of apiman 1.1.9.Final.  You can see the test commands with 
output here:

https://gist.github.com/EricWittmann/90c454433954b0cea867

You'll notice that the information was updated successfully in 
elasticsearch and that apiman used the new endpoint URL (after a restart 
of apiman).

You can run the test yourself, if you like.  Here is the script:

https://gist.github.com/EricWittmann/d28239b5ac2922674c3e

I'd be interested to know if you get different results.

-Eric

On 1/27/2016 12:17 AM, Sanjay Melinamani wrote:
> Hi Eric,
> When I run curl -XGET
> http://localhost:19200/apiman_gateway/service/_search , I do see Old
> implementation URLs.
> I have restarted apiman many times. Still the old url is being used.
>
> Thanks
> Sanjay
>
>
> On Tue, Jan 26, 2016 at 8:06 AM, Eric Wittmann <eric.wittmann at redhat.com
> <mailto:eric.wittmann at redhat.com>> wrote:
>
>     Thanks. :)
>
>     As for the index files - I think the bigger question is what do you
>     see when you do a search in elastic?
>
>     curl -XGET http://localhost:19200/apiman_gateway/service/_search
>
>     What are the results of doing the above?
>
>     I don't have any idea what might be stored in the elasticsearch
>     index files - so I can't tell you what to expect from a grep.
>
>     I *can* tell you that there is no re-index operation.  When you
>     update the document (via the PUT http request) it should store the
>     new data in ES *and* update its indices.  That's EXACTLY what apiman
>     does internally when updating/adding/publishing a service.
>
>     After restarting apiman, is your gateway still using the wrong (old)
>     endpoint?
>
>     One last thing - if you are planning on using this in production, we
>     really recommend that you install a standalone instance of
>     elasticsearch rather than using the one included in the apiman
>     quickstart.  There's more information in the production guide:
>
>     http://www.apiman.io/latest/production-guide.html
>
>     -Eric
>
>     On 1/26/2016 2:08 AM, Sanjay Melinamani wrote:
>
>         Hi Eric,
>
>         Congratulations on the new Release! I can't wait to migrate to
>         1.2.1 !!
>
>         Meanwhile I am still having hard time replacing the
>         implementation URL
>         used in a published API.. Here is what I see..
>         When I execute GET, I see the new implementation URL used
>         (http://internal-XXXX.elb.amazonaws.com:8080/hra-web/services/engine/OSA/cf)
>         but when I do a grep on my old URL "10.0.0.241", I see the
>         matches in
>         index files. How can I rebuild the indices?
>
>
>         [ec2-user at Prism-ST-GWY wildfly-8.2.0.Final]$ curl -XGET
>         http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
>         {"endpoint":"http://internal-XXXX.elb.amazonaws.com:8080/hra-web/services/engine/OSA/cf","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}
>
>
>         [ec2-user at Prism-ST-GWY wildfly-8.2.0.Final]$ grep -rnw . -e
>         "10.0.0.241"
>         Binary file
>         ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/3/index/_0.cfs
>         matches
>         Binary file
>         ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/3/index/_1y.cfs
>         matches
>         Binary file
>         ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/3/index/_1z.cfs
>         matches
>         Binary file
>         ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/2/index/_2.cfs
>         matches
>         Binary file
>         ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/2/index/_3.cfs
>         matches
>         Binary file
>         ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/2/index/_4.cfs
>         matches
>         Binary file
>         ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/4/index/_0.cfs
>         matches
>         Binary file
>         ./standalone/data/es/data/apiman/nodes/0/indices/apiman_gateway/4/index/_1.cfs
>         matches
>
>         Thanks
>         Sanjay
>
>
>
>         On Thu, Jan 7, 2016 at 8:08 AM, 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>>> wrote:
>
>              No nothing like that should be needed.  Doing that curl
>         command is
>              just like doing an UPDATE on a SQL db.  I even tried it locally
>              (switching between URLs by updating that record in elastic) and
>              didn't have any problems.
>
>              Did you restart apiman after the change?  Unfortunately
>         (for this
>              use-case) apiman will cache the information so that it
>         doesn't have
>              to do a lookup in ES for *every* request.
>
>              Also what happens how when you do the -XGET call?  Do you
>         see the
>              new data?
>
>              -Eric
>
>              On 1/7/2016 2:58 AM, Sanjay Melinamani wrote:
>
>                  Hi Eric,
>                  Even after the restart, gateway is still using the OLD
>         service
>                  implementation URL. Do I have to rebuild the index,
>         clear cache
>                  or do
>                  something else??
>                  When grepped for old URL, I can still see it in indices
>         folder of
>                  elastic search. I tried to clear cache and used refresh
>         commands
>                  but did
>                  not work!
>
>                  Appreciate if you can provide some more guidance here.
>
>                  Thanks
>                  Sanjay
>
>
>                  On Wed, Jan 6, 2016 at 12:57 PM, Sanjay Melinamani
>                  <mssanjay at gmail.com <mailto:mssanjay at gmail.com>
>         <mailto:mssanjay at gmail.com <mailto:mssanjay at gmail.com>>
>                  <mailto:mssanjay at gmail.com <mailto:mssanjay at gmail.com>
>         <mailto:mssanjay at gmail.com <mailto:mssanjay at gmail.com>>>> wrote:
>
>                       Thanks  a ton! Worked like a charm :)
>
>                       Sanjay
>
>
>                       On Tue, Jan 5, 2016 at 8:01 AM, 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>>
>                  <mailto:eric.wittmann at redhat.com
>         <mailto:eric.wittmann at redhat.com>
>                  <mailto:eric.wittmann at redhat.com
>         <mailto:eric.wittmann at redhat.com>>>> wrote:
>
>                           Drop the /_source from the PUT command. :)
>
>                           -Eric
>
>                           On 1/5/2016 1:45 AM, Sanjay Melinamani wrote:
>
>                               Thanks Eric for your reply! makes sense...
>
>                               I tried to use the two CURL commands.
>
>                               GET worked and I was able to see the end point
>                  being used.
>                               curl -XGET
>         http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
>
>
>         {"endpoint":"http://OLD_URL","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}
>
>
>
>                               But the PUT failed as below..
>
>                               curl -XPUT
>         http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
>                               -d
>
>
>         '{"endpoint":"http://NEW_URL","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}'
>
>                               No handler found for uri
>
>           [/apiman_gateway/service/prism:osa:1.0/_source]
>                               and method [PUT]
>
>
>                               Thanks again for your time
>
>                               Sanjay
>
>
>                               On Mon, Jan 4, 2016 at 11:26 AM, 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>>
>                  <mailto:eric.wittmann at redhat.com
>         <mailto:eric.wittmann at redhat.com>
>         <mailto:eric.wittmann at redhat.com <mailto:eric.wittmann at redhat.com>>>
>                               <mailto:eric.wittmann at redhat.com
>         <mailto:eric.wittmann at redhat.com>
>                  <mailto:eric.wittmann at redhat.com
>         <mailto:eric.wittmann at redhat.com>>
>
>                               <mailto:eric.wittmann at redhat.com
>         <mailto:eric.wittmann at redhat.com>
>                  <mailto:eric.wittmann at redhat.com
>         <mailto:eric.wittmann at redhat.com>>>>> wrote:
>
>                                    Hi Sanjay, thanks for the questions.
>
>                                    Currently there is no easy way to
>         update the
>                  backend
>                               implementation
>                                    endpiont URL without creating a new
>         version of
>                  the service.
>
>                                    However, if this is a one-off sort of
>         thing
>                  then you
>                               may be able to
>                                    get it done.  It depends mostly on what
>                  configuration
>                               you are
>                                    using.  But I'll explain based on the
>         most
>                  recent 1.1.x
>                               release
>                                    (1.1.9.Final) with its default
>         configuration.
>
>                                    The Manager and Gateway are decoupled,
>                  resulting in the
>                               duplication
>                                    of *some* of the data (including the
>         endpoint
>                  URL).  So
>                               when you
>                                    "publish" a service from the Manager, the
>                  Gateway is given
>                                    information about the service.  This
>                  information is
>                               stored in the
>                                    Gateway's "registry".  By default the
>         registry
>                               implementation is
>                                    elasticsearch.  So if you wanted to
>         change the
>                  endpoint
>                               URL for a
>                                    service, you would need to update that
>                  information in
>                               your Database
>                                    (you did this) *and* in elasticsearch.
>
>                                    It's actually not that difficult to
>         update the
>                               information in
>                                    elasticsearch.  You'll need to find the
>                  correct record
>                               and then
>                                    update it.  If you're using the default
>                  installation,
>                               then ES is
>                                    running on port 19200.  If you want
>         to change the
>                               following service:
>
>                                    Organization:  Example
>                                    Service ID:    MyService
>                                    Version:       1.0
>
>                                    Then you might do something like this:
>
>                                    curl -XGET
>         http://localhost:19200/apiman_gateway/service/Example:MyService:1.0/_source
>
>                                    You could then take that JSON result,
>         modify
>                  the bits
>                               you want to
>                                    change, and then update it like so (as an
>                  example -
>                               please replace
>                                    the JSON below with the JSON you get
>         back from
>                  the GET
>                               above):
>
>                                    curl -XPUT
>         http://localhost:19200/apiman_gateway/service/Example:MyService:1.0
>                               -d '
>                                    {
>                                       "endpoint" :
>         "http://UPDATED-ENDPOINT-HERE",
>                                       "endpointType" : "rest",
>                                       "publicService" : true,
>                                       "organizationId" : "Example",
>                                       "serviceId": "MyService",
>                                       "version" : "1.0",
>                                       "endpointProperties": [],
>                                       "policies":[]
>                                    }
>                                    '
>
>                                    Once this is done you'll have to restart
>                  apiman so that
>                               the Gateway
>                                    picks up the changes.
>
>                                    Note: we are making some changes in
>         apiman
>                  1.2.x that
>                               will make all
>                                    of this easier under some
>         circumstances.  In
>                               particular, as of
>                                    apiman 1.2.0.Final you will be able
>         to re-publish
>                               "Public" services
>                                    (now called APIs).  So if the API is
>         public
>                  then you
>                               can simply make
>                                    changes and then republish those
>         changes to the
>                               Gateway.  If the API
>                                    is *not* public then the current
>         semantics are the
>                               same:  you cannot
>                                    make changes and republish because
>         that may
>                  violate
>                               contracts that
>                                    consumers have made with your API.
>
>                                    -Eric
>
>
>
>                                    On 12/29/2015 12:19 PM, Sanjay
>         Melinamani wrote:
>
>                                        Hi All,
>                                        I am using APIMAN 1.1.9 and for an
>                  existing API
>                               that I have
>                                        published to
>                                        consumers, I like to change its
>         backend
>                               implementation end point URL
>                                        without changing the API service
>         version.
>                                        I updated the backend
>         implementation URL in
>                               database table
>                                        "service_versions". I can see the
>         updated
>                  URL from
>                               UI but still the
>                                        gateway is using the old
>         implementation
>                  URL specified.
>                                        Does it cache the implementation
>         URL once the
>                               service is
>                                        published ? Is
>                                        there anyway I can update  the
>                  implementation URL
>                               for an
>                                        existing service?
>
>                                        Appreciate your time and help.
>
>                                        Thanks
>                                        Sanjay
>
>
>
>
>
>                    _______________________________________________
>                                        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>>>
>                               <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
>         <mailto:Apiman-user at lists.jboss.org>>>>
>         https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
>
>
>
>

From ah at tradeworks.io  Wed Jan 27 13:02:04 2016
From: ah at tradeworks.io (Anton Hughes)
Date: Wed, 27 Jan 2016 19:02:04 +0100
Subject: [Apiman-user] ApiMan and ActiveMQ
Message-ID: <CAMOUzMD1me0G0qU5QzsEoiaz2vhSpRXvPGimo-b9zQsoejkoPQ@mail.gmail.com>

Hello

I have seen that Apiman is provided as part of Fabric8, Very nice!

I am wondering, does apiman currently, or is it planned to, provide the
same features that it currently does to web services? So, policies could
also be applied to activemq queues and topics?

Thanks



-- 
Anton Hughes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160127/e5214cea/attachment.html 

From eric.wittmann at redhat.com  Wed Jan 27 14:47:58 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Wed, 27 Jan 2016 14:47:58 -0500
Subject: [Apiman-user] ApiMan and ActiveMQ
In-Reply-To: <CAMOUzMD1me0G0qU5QzsEoiaz2vhSpRXvPGimo-b9zQsoejkoPQ@mail.gmail.com>
References: <CAMOUzMD1me0G0qU5QzsEoiaz2vhSpRXvPGimo-b9zQsoejkoPQ@mail.gmail.com>
Message-ID: <56A91EEE.80006@redhat.com>

Hi Anton.

Support for protocols other than http/s is on the roadmap, although it's 
not coming *soon*.  The gateway is absolutely designed to support other 
protocols.  The input/output beans for the gateway attempt to be 
protocol agnostic, so hopefully we are reasonably well positioned to 
implement support for something like activemq.

I don't have much experience with JMS or activemq, so I don't know 
offhand how we can insert the gateway in between the client and the API. 
  But I'm sure there must be a way!

If you have ideas or want to contribute in this area - we'd be thrilled 
to provide guidance.  Otherwise you'll have to wait until the feature 
reaches critical priority. :)

-Eric

On 1/27/2016 1:02 PM, Anton Hughes wrote:
> Hello
>
> I have seen that Apiman is provided as part of Fabric8, Very nice!
>
> I am wondering, does apiman currently, or is it planned to, provide the
> same features that it currently does to web services? So, policies could
> also be applied to activemq queues and topics?
>
> Thanks
>
>
>
> --
> Anton Hughes
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From lists at comiti.name  Thu Jan 28 03:08:20 2016
From: lists at comiti.name (enrico)
Date: Thu, 28 Jan 2016 09:08:20 +0100
Subject: [Apiman-user] external Keycloak server
Message-ID: <CAMJ0bZUco5p3J9nBCc9h0aOD1Oz=CRuBZLbLLL9g_+FvY+H=DA@mail.gmail.com>

Hi all,
thanks for the responses.

@Mark: yes, I know that is a release candidate but looks like the
final version is near and, being on a new project, I wanted start with
the very last versions :)

A part from this, I have tried with 1.7.0.Final too, but I have the
same problem:

User gets a "Forbidden" page and Keycloak server logs say:

WARN  [org.keycloak.events]:
type=CODE_TO_TOKEN_ERROR,
realmId=352d562a-f3e5-4b7a-99ad-4331cdfdf085, clientId=apimanui,
userId=null, ipAddress=127.0.0.1, error=invalid_client_credentials,
grant_type=authorization_code

Thanks a lot for the help, best regards,
Enrico


On Wed, Jan 27, 2016 at 5:49 PM, Marc Savy <marc.savy at redhat.com> wrote:
> Hi Enrico,
>
> We haven't tested with Keycloak 1.8, as this is only a candidate release
> at the moment (CR == RC).
>
> I can give it a try, though and will report back.
>
> Regards,
> Marc
>



-- 
Enrico Comiti

From cmoullia at redhat.com  Thu Jan 28 03:14:47 2016
From: cmoullia at redhat.com (Charles Moulliard)
Date: Thu, 28 Jan 2016 03:14:47 -0500 (EST)
Subject: [Apiman-user] ApiMan and ActiveMQ
In-Reply-To: <56A91EEE.80006@redhat.com>
References: <CAMOUzMD1me0G0qU5QzsEoiaz2vhSpRXvPGimo-b9zQsoejkoPQ@mail.gmail.com>
	<56A91EEE.80006@redhat.com>
Message-ID: <33392768.15326997.1453968887229.JavaMail.zimbra@redhat.com>

As there is a HTTP/HTTPS ActiveMQ Transport protocol, you can already use the APiMan Gateway ;-) 
Nevertheless, I'm not sure that Apiman could offer real added value for such architecture design as Authentication (Basic, LDAP, JDBC) & Authorization is already designed into ActiveMQ (JAASAuthenticationPlugin & JAASAuthorization plugin) and I don't think that the cache, quota or rate policy are meaningful for JMS-HTTP transfer ...

----- Mail original -----
De: "Eric Wittmann" <eric.wittmann at redhat.com>
?: "Anton Hughes" <ah at tradeworks.io>, "apiman-user" <apiman-user at lists.jboss.org>
Envoy?: Mercredi 27 Janvier 2016 20:47:58
Objet: Re: [Apiman-user] ApiMan and ActiveMQ


Hi Anton.

Support for protocols other than http/s is on the roadmap, although it's 
not coming *soon*.  The gateway is absolutely designed to support other 
protocols.  The input/output beans for the gateway attempt to be 
protocol agnostic, so hopefully we are reasonably well positioned to 
implement support for something like activemq.

I don't have much experience with JMS or activemq, so I don't know 
offhand how we can insert the gateway in between the client and the API. 
  But I'm sure there must be a way!

If you have ideas or want to contribute in this area - we'd be thrilled 
to provide guidance.  Otherwise you'll have to wait until the feature 
reaches critical priority. :)

-Eric

On 1/27/2016 1:02 PM, Anton Hughes wrote:
> Hello
>
> I have seen that Apiman is provided as part of Fabric8, Very nice!
>
> I am wondering, does apiman currently, or is it planned to, provide the
> same features that it currently does to web services? So, policies could
> also be applied to activemq queues and topics?
>
> Thanks
>
>
>
> --
> Anton Hughes
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
_______________________________________________
Apiman-user mailing list
Apiman-user at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/apiman-user


From guydavis.ca at gmail.com  Thu Jan 28 16:02:57 2016
From: guydavis.ca at gmail.com (Guy Davis)
Date: Thu, 28 Jan 2016 14:02:57 -0700
Subject: [Apiman-user] external Keycloak server
In-Reply-To: <CAMJ0bZUco5p3J9nBCc9h0aOD1Oz=CRuBZLbLLL9g_+FvY+H=DA@mail.gmail.com>
References: <CAMJ0bZUco5p3J9nBCc9h0aOD1Oz=CRuBZLbLLL9g_+FvY+H=DA@mail.gmail.com>
Message-ID: <CAAgmn1rcCQN-W89PhG6XDFeEJAjC9uhQfKunD80WuSvtOzk=FA@mail.gmail.com>

Hi Enrico,

I just made the move to Apiman 1.2.1 (running on port 8081) and Keycloak
1.7.0 (running on port 8080), both behind an HAProxy instance.  I've
attached the section of my standalone-apiman.xml that worked for me.

Note, I'm *not* using the default 'apiman' realm as I am securing a number
of other web apps with Keycloak.  So I have 'MyRealm' with Keycloak client
of 'apiman', which is set for:

   - Client-protocol: openid-connect
   - Access Type: confidential
   - Direct Access Grants Enabled: ON
   - Valid redirect URIs:
      - /apimanui/*
      - /apiman-gateway-api/*
      - /apiman-es/*
      - /apiman/*

In that KC client, I have 3 realm roles for this:

   - apipublisher
   - apiadmin
   - apiuser

I had tried to keep these roles to just the KC client 'apiman', but it
wouldn't allow me to login to /apimanui unless the roles were realm-wide.
I'm going to try client-specific roles again now that apiman is 1.2.1.  I'm
using Postgres and ElasticSearch for storage, on other VMs.

This was enough to let me login and view /apimanui when I had those roles
for my Keycloak user.

Hope this helps,
Guy

On Thu, Jan 28, 2016 at 1:08 AM, enrico <lists at comiti.name> wrote:

> Hi all,
> thanks for the responses.
>
> @Mark: yes, I know that is a release candidate but looks like the
> final version is near and, being on a new project, I wanted start with
> the very last versions :)
>
> A part from this, I have tried with 1.7.0.Final too, but I have the
> same problem:
>
> User gets a "Forbidden" page and Keycloak server logs say:
>
> WARN  [org.keycloak.events]:
> type=CODE_TO_TOKEN_ERROR,
> realmId=352d562a-f3e5-4b7a-99ad-4331cdfdf085, clientId=apimanui,
> userId=null, ipAddress=127.0.0.1, error=invalid_client_credentials,
> grant_type=authorization_code
>
> Thanks a lot for the help, best regards,
> Enrico
>
>
> On Wed, Jan 27, 2016 at 5:49 PM, Marc Savy <marc.savy at redhat.com> wrote:
> > Hi Enrico,
> >
> > We haven't tested with Keycloak 1.8, as this is only a candidate release
> > at the moment (CR == RC).
> >
> > I can give it a try, though and will report back.
> >
> > Regards,
> > Marc
> >
>
>
>
> --
> Enrico Comiti
> _______________________________________________
> Apiman-user mailing list
> 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/20160128/59ca5c82/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: standalone-apiman-keycloak.xml
Type: text/xml
Size: 2342 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20160128/59ca5c82/attachment.xml 

From guydavis.ca at gmail.com  Thu Jan 28 23:45:27 2016
From: guydavis.ca at gmail.com (Guy Davis)
Date: Thu, 28 Jan 2016 21:45:27 -0700
Subject: [Apiman-user] Plugins page stack trace - APIMan 1.2.1 on PostgreSQL
	9.5
Message-ID: <CAAgmn1qHdEZB_=+rFui0FD_onv84WHYcO8tiHvQW5C-6hsG7-Q@mail.gmail.com>

Good day,

I was hoping to follow the recently published steps
<http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/1.2.x/2016/01/22/keycloak-oauth2-redux.html>
for using Keycloak to OAuth protect an API with APIMan.  I already have the
backend API (war file) protected by Keycloak directly.

When I click on the 'Manage Plugins' link:
[image: Inline image 1]

I receive the error shown (full trace attached):
[image: Inline image 2]

Any tips on which Postgres table/column is the problem?

At a higher level, I'm not sure I understand the blog post however.  I've
already protecting the various apiman *war files and their endpoints with
Keycloak's authentication behavior (default is OpenID Connect).  So if the
APIMan endpoints are protected already, what does the OAuth policy provide
further?  Any clarification on the integration points between Keycloak and
APIMan would be appreciated.

Thanks much,
Guy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160128/b3fcd100/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 141540 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20160128/b3fcd100/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 30913 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20160128/b3fcd100/attachment-0003.png 
-------------- next part --------------
io.apiman.manager.api.rest.contract.exceptions.SystemErrorException: io.apiman.manager.api.core.exceptions.StorageException: javax.persistence.PersistenceException: org.hibernate.exception.SQLGrammarException: could not extract ResultSet
	at io.apiman.manager.api.rest.impl.PluginResourceImpl.list(PluginResourceImpl.java:105)
	at io.apiman.manager.api.rest.impl.PluginResourceImpl$Proxy$_$$_WeldClientProxy.list(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
	at io.apiman.common.servlet.RootResourceFilter.doFilter(RootResourceFilter.java:59)
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
	at io.apiman.manager.api.war.TransactionWatchdogFilter.doFilter(TransactionWatchdogFilter.java:57)
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
	at io.apiman.manager.api.security.impl.DefaultSecurityContextFilter.doFilter(DefaultSecurityContextFilter.java:56)
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
	at io.apiman.common.servlet.DisableCachingFilter.doFilter(DisableCachingFilter.java:59)
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
	at io.apiman.common.servlet.ApimanCorsFilter.doFilter(ApimanCorsFilter.java:71)
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
	at io.apiman.common.servlet.LocaleFilter.doFilter(LocaleFilter.java:61)
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handleRequest(UndertowAuthenticatedActionsHandler.java:66)
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: io.apiman.manager.api.core.exceptions.StorageException: javax.persistence.PersistenceException: org.hibernate.exception.SQLGrammarException: could not extract ResultSet
	at io.apiman.manager.api.jpa.JpaStorage.listPlugins(JpaStorage.java:884)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:38)
	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
	at org.jboss.weld.proxies.IStorageQuery$816713464$Proxy$_$$_WeldClientProxy.listPlugins(Unknown Source)
	at io.apiman.manager.api.rest.impl.PluginResourceImpl.list(PluginResourceImpl.java:103)
	... 67 more
Caused by: javax.persistence.PersistenceException: org.hibernate.exception.SQLGrammarException: could not extract ResultSet
	at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763)
	at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677)
	at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:458)
	at io.apiman.manager.api.jpa.JpaStorage.listPlugins(JpaStorage.java:865)
	... 75 more
Caused by: org.hibernate.exception.SQLGrammarException: could not extract ResultSet
	at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:123)
	at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49)
	at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126)
	at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:112)
	at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:91)
	at org.hibernate.loader.Loader.getResultSet(Loader.java:2066)
	at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1863)
	at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1839)
	at org.hibernate.loader.Loader.doQuery(Loader.java:910)
	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:355)
	at org.hibernate.loader.Loader.doList(Loader.java:2554)
	at org.hibernate.loader.Loader.doList(Loader.java:2540)
	at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2370)
	at org.hibernate.loader.Loader.list(Loader.java:2365)
	at org.hibernate.loader.custom.CustomLoader.list(CustomLoader.java:353)
	at org.hibernate.internal.SessionImpl.listCustomQuery(SessionImpl.java:1909)
	at org.hibernate.internal.AbstractSessionImpl.list(AbstractSessionImpl.java:311)
	at org.hibernate.internal.SQLQueryImpl.list(SQLQueryImpl.java:141)
	at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:573)
	at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:449)
	... 76 more
Caused by: org.postgresql.util.PSQLException: ERROR: operator does not exist: boolean = integer
  Hint: No operator matches the given name and argument type(s). You might need to add explicit type casts.
  Position: 177
	at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2182)
	at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1911)
	at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:173)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:645)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:495)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:380)
	at org.jboss.jca.adapters.jdbc.CachedPreparedStatement.executeQuery(CachedPreparedStatement.java:116)
	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:504)
	at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:82)
	... 91 more

From lists at comiti.name  Fri Jan 29 04:11:04 2016
From: lists at comiti.name (enrico)
Date: Fri, 29 Jan 2016 10:11:04 +0100
Subject: [Apiman-user] external Keycloak server
In-Reply-To: <CAAgmn1rcCQN-W89PhG6XDFeEJAjC9uhQfKunD80WuSvtOzk=FA@mail.gmail.com>
References: <CAMJ0bZUco5p3J9nBCc9h0aOD1Oz=CRuBZLbLLL9g_+FvY+H=DA@mail.gmail.com>
	<CAAgmn1rcCQN-W89PhG6XDFeEJAjC9uhQfKunD80WuSvtOzk=FA@mail.gmail.com>
Message-ID: <CAMJ0bZXqiD-1vMtcBR8-hp998djPxLYiX_=jfms7zg9Ez-_nwA@mail.gmail.com>

Hi Guy,
thank you very much, it works!

For anyone with the same problem, this is my realm.json client definition:

    "applications" : [
        {
            "name" : "apiman",
            "enabled" : true,
            "directGrantsOnly" : true,
            "standardFlowEnabled": true,
            "baseUrl" : "http://apigateway:8080/",
            "redirectUris" : [
                "http://apigateway:8080/apimanui/*",
                "http://apigateway:8080/apiman-gateway-api/*",
                "http://apigateway:8080/apiman-es/*",
                "http://apigateway:8080/apiman/*"
            ],
            "secret" : "password"
        }
    ]

Thanks a lot again.

Cheers,
Enrico

On Thu, Jan 28, 2016 at 10:02 PM, Guy Davis <guydavis.ca at gmail.com> wrote:
> Hi Enrico,
>
> I just made the move to Apiman 1.2.1 (running on port 8081) and Keycloak
> 1.7.0 (running on port 8080), both behind an HAProxy instance.  I've
> attached the section of my standalone-apiman.xml that worked for me.
>
> Note, I'm not using the default 'apiman' realm as I am securing a number of
> other web apps with Keycloak.  So I have 'MyRealm' with Keycloak client of
> 'apiman', which is set for:
>
> Client-protocol: openid-connect
> Access Type: confidential
> Direct Access Grants Enabled: ON
> Valid redirect URIs:
>
> /apimanui/*
> /apiman-gateway-api/*
> /apiman-es/*
> /apiman/*
>
> In that KC client, I have 3 realm roles for this:
>
> apipublisher
> apiadmin
> apiuser
>
> I had tried to keep these roles to just the KC client 'apiman', but it
> wouldn't allow me to login to /apimanui unless the roles were realm-wide.
> I'm going to try client-specific roles again now that apiman is 1.2.1.  I'm
> using Postgres and ElasticSearch for storage, on other VMs.
>
> This was enough to let me login and view /apimanui when I had those roles
> for my Keycloak user.
>
> Hope this helps,
> Guy
>
> On Thu, Jan 28, 2016 at 1:08 AM, enrico <lists at comiti.name> wrote:
>>
>> Hi all,
>> thanks for the responses.
>>
>> @Mark: yes, I know that is a release candidate but looks like the
>> final version is near and, being on a new project, I wanted start with
>> the very last versions :)
>>
>> A part from this, I have tried with 1.7.0.Final too, but I have the
>> same problem:
>>
>> User gets a "Forbidden" page and Keycloak server logs say:
>>
>> WARN  [org.keycloak.events]:
>> type=CODE_TO_TOKEN_ERROR,
>> realmId=352d562a-f3e5-4b7a-99ad-4331cdfdf085, clientId=apimanui,
>> userId=null, ipAddress=127.0.0.1, error=invalid_client_credentials,
>> grant_type=authorization_code
>>
>> Thanks a lot for the help, best regards,
>> Enrico
>>
>>
>> On Wed, Jan 27, 2016 at 5:49 PM, Marc Savy <marc.savy at redhat.com> wrote:
>> > Hi Enrico,
>> >
>> > We haven't tested with Keycloak 1.8, as this is only a candidate release
>> > at the moment (CR == RC).
>> >
>> > I can give it a try, though and will report back.
>> >
>> > Regards,
>> > Marc
>> >
>>
>>
>>
>> --
>> Enrico Comiti
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>
>

From eric.wittmann at redhat.com  Fri Jan 29 08:14:57 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Fri, 29 Jan 2016 08:14:57 -0500
Subject: [Apiman-user] Plugins page stack trace - APIMan 1.2.1 on
 PostgreSQL 9.5
In-Reply-To: <CAAgmn1qHdEZB_=+rFui0FD_onv84WHYcO8tiHvQW5C-6hsG7-Q@mail.gmail.com>
References: <CAAgmn1qHdEZB_=+rFui0FD_onv84WHYcO8tiHvQW5C-6hsG7-Q@mail.gmail.com>
Message-ID: <56AB65D1.6020108@redhat.com>

Thanks for the full stack trace - I'll have a look at this asap.

What version of postgres are you using?

Regarding security, we use KeyCloak in two different ways.  The first is 
to secure apiman itself (e.g. so you can log into the UI).  The second 
as the OAuth provider when protecting managed APIs.  In order to enable 
OAuth for an API managed by apiman, you need to add the Keycloak OAuth 
policy to it.

Note that we could, for example, switch to using something *else* for 
securing apiman, such as JAAS or CAS.  Even if we did that, we would 
still support using KeyCloak to secure managed endpoints via OAuth.

I hope that makes sense.

-Eric


On 1/28/2016 11:45 PM, Guy Davis wrote:
> Good day,
>
> I was hoping to follow the recently published steps
> <http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/1.2.x/2016/01/22/keycloak-oauth2-redux.html>
> for using Keycloak to OAuth protect an API with APIMan.  I already have
> the backend API (war file) protected by Keycloak directly.
>
> When I click on the 'Manage Plugins' link:
> Inline image 1
>
> I receive the error shown (full trace attached):
> Inline image 2
>
> Any tips on which Postgres table/column is the problem?
>
> At a higher level, I'm not sure I understand the blog post however.
> I've already protecting the various apiman *war files and their
> endpoints with Keycloak's authentication behavior (default is OpenID
> Connect).  So if the APIMan endpoints are protected already, what does
> the OAuth policy provide further?  Any clarification on the integration
> points between Keycloak and APIMan would be appreciated.
>
> Thanks much,
> Guy
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From eric.wittmann at redhat.com  Fri Jan 29 08:16:30 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Fri, 29 Jan 2016 08:16:30 -0500
Subject: [Apiman-user] external Keycloak server
In-Reply-To: <CAMJ0bZXqiD-1vMtcBR8-hp998djPxLYiX_=jfms7zg9Ez-_nwA@mail.gmail.com>
References: <CAMJ0bZUco5p3J9nBCc9h0aOD1Oz=CRuBZLbLLL9g_+FvY+H=DA@mail.gmail.com>
	<CAAgmn1rcCQN-W89PhG6XDFeEJAjC9uhQfKunD80WuSvtOzk=FA@mail.gmail.com>
	<CAMJ0bZXqiD-1vMtcBR8-hp998djPxLYiX_=jfms7zg9Ez-_nwA@mail.gmail.com>
Message-ID: <56AB662E.7030006@redhat.com>

Any chance you can share your full realm file?  Perhaps with any secrets 
redacted.  :)

-Eric

On 1/29/2016 4:11 AM, enrico wrote:
> Hi Guy,
> thank you very much, it works!
>
> For anyone with the same problem, this is my realm.json client definition:
>
>      "applications" : [
>          {
>              "name" : "apiman",
>              "enabled" : true,
>              "directGrantsOnly" : true,
>              "standardFlowEnabled": true,
>              "baseUrl" : "http://apigateway:8080/",
>              "redirectUris" : [
>                  "http://apigateway:8080/apimanui/*",
>                  "http://apigateway:8080/apiman-gateway-api/*",
>                  "http://apigateway:8080/apiman-es/*",
>                  "http://apigateway:8080/apiman/*"
>              ],
>              "secret" : "password"
>          }
>      ]
>
> Thanks a lot again.
>
> Cheers,
> Enrico
>
> On Thu, Jan 28, 2016 at 10:02 PM, Guy Davis <guydavis.ca at gmail.com> wrote:
>> Hi Enrico,
>>
>> I just made the move to Apiman 1.2.1 (running on port 8081) and Keycloak
>> 1.7.0 (running on port 8080), both behind an HAProxy instance.  I've
>> attached the section of my standalone-apiman.xml that worked for me.
>>
>> Note, I'm not using the default 'apiman' realm as I am securing a number of
>> other web apps with Keycloak.  So I have 'MyRealm' with Keycloak client of
>> 'apiman', which is set for:
>>
>> Client-protocol: openid-connect
>> Access Type: confidential
>> Direct Access Grants Enabled: ON
>> Valid redirect URIs:
>>
>> /apimanui/*
>> /apiman-gateway-api/*
>> /apiman-es/*
>> /apiman/*
>>
>> In that KC client, I have 3 realm roles for this:
>>
>> apipublisher
>> apiadmin
>> apiuser
>>
>> I had tried to keep these roles to just the KC client 'apiman', but it
>> wouldn't allow me to login to /apimanui unless the roles were realm-wide.
>> I'm going to try client-specific roles again now that apiman is 1.2.1.  I'm
>> using Postgres and ElasticSearch for storage, on other VMs.
>>
>> This was enough to let me login and view /apimanui when I had those roles
>> for my Keycloak user.
>>
>> Hope this helps,
>> Guy
>>
>> On Thu, Jan 28, 2016 at 1:08 AM, enrico <lists at comiti.name> wrote:
>>>
>>> Hi all,
>>> thanks for the responses.
>>>
>>> @Mark: yes, I know that is a release candidate but looks like the
>>> final version is near and, being on a new project, I wanted start with
>>> the very last versions :)
>>>
>>> A part from this, I have tried with 1.7.0.Final too, but I have the
>>> same problem:
>>>
>>> User gets a "Forbidden" page and Keycloak server logs say:
>>>
>>> WARN  [org.keycloak.events]:
>>> type=CODE_TO_TOKEN_ERROR,
>>> realmId=352d562a-f3e5-4b7a-99ad-4331cdfdf085, clientId=apimanui,
>>> userId=null, ipAddress=127.0.0.1, error=invalid_client_credentials,
>>> grant_type=authorization_code
>>>
>>> Thanks a lot for the help, best regards,
>>> Enrico
>>>
>>>
>>> On Wed, Jan 27, 2016 at 5:49 PM, Marc Savy <marc.savy at redhat.com> wrote:
>>>> Hi Enrico,
>>>>
>>>> We haven't tested with Keycloak 1.8, as this is only a candidate release
>>>> at the moment (CR == RC).
>>>>
>>>> I can give it a try, though and will report back.
>>>>
>>>> Regards,
>>>> Marc
>>>>
>>>
>>>
>>>
>>> --
>>> Enrico Comiti
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From lists at comiti.name  Fri Jan 29 08:31:22 2016
From: lists at comiti.name (enrico)
Date: Fri, 29 Jan 2016 14:31:22 +0100
Subject: [Apiman-user] external Keycloak server
In-Reply-To: <56AB662E.7030006@redhat.com>
References: <CAMJ0bZUco5p3J9nBCc9h0aOD1Oz=CRuBZLbLLL9g_+FvY+H=DA@mail.gmail.com>
	<CAAgmn1rcCQN-W89PhG6XDFeEJAjC9uhQfKunD80WuSvtOzk=FA@mail.gmail.com>
	<CAMJ0bZXqiD-1vMtcBR8-hp998djPxLYiX_=jfms7zg9Ez-_nwA@mail.gmail.com>
	<56AB662E.7030006@redhat.com>
Message-ID: <CAMJ0bZU_Qrk=xnv-NrO2Q85g-SerVrK6G8rRr=5f3dDjU2pOcg@mail.gmail.com>

Hi, no problem at all...
It is only for a local test environment.

The Apiman and the Keycloak instances are separated but in the same
host "apigateway".
Apiman runs on port 8080, Keycloak on 32000.

Hope this helps.

Enrico


On Fri, Jan 29, 2016 at 2:16 PM, Eric Wittmann <eric.wittmann at redhat.com> wrote:
> Any chance you can share your full realm file?  Perhaps with any secrets
> redacted.  :)
>
> -Eric
>
>
> On 1/29/2016 4:11 AM, enrico wrote:
>>
>> Hi Guy,
>> thank you very much, it works!
>>
>> For anyone with the same problem, this is my realm.json client definition:
>>
>>      "applications" : [
>>          {
>>              "name" : "apiman",
>>              "enabled" : true,
>>              "directGrantsOnly" : true,
>>              "standardFlowEnabled": true,
>>              "baseUrl" : "http://apigateway:8080/",
>>              "redirectUris" : [
>>                  "http://apigateway:8080/apimanui/*",
>>                  "http://apigateway:8080/apiman-gateway-api/*",
>>                  "http://apigateway:8080/apiman-es/*",
>>                  "http://apigateway:8080/apiman/*"
>>              ],
>>              "secret" : "password"
>>          }
>>      ]
>>
>> Thanks a lot again.
>>
>> Cheers,
>> Enrico
>>
>> On Thu, Jan 28, 2016 at 10:02 PM, Guy Davis <guydavis.ca at gmail.com> wrote:
>>>
>>> Hi Enrico,
>>>
>>> I just made the move to Apiman 1.2.1 (running on port 8081) and Keycloak
>>> 1.7.0 (running on port 8080), both behind an HAProxy instance.  I've
>>> attached the section of my standalone-apiman.xml that worked for me.
>>>
>>> Note, I'm not using the default 'apiman' realm as I am securing a number
>>> of
>>> other web apps with Keycloak.  So I have 'MyRealm' with Keycloak client
>>> of
>>> 'apiman', which is set for:
>>>
>>> Client-protocol: openid-connect
>>> Access Type: confidential
>>> Direct Access Grants Enabled: ON
>>> Valid redirect URIs:
>>>
>>> /apimanui/*
>>> /apiman-gateway-api/*
>>> /apiman-es/*
>>> /apiman/*
>>>
>>> In that KC client, I have 3 realm roles for this:
>>>
>>> apipublisher
>>> apiadmin
>>> apiuser
>>>
>>> I had tried to keep these roles to just the KC client 'apiman', but it
>>> wouldn't allow me to login to /apimanui unless the roles were realm-wide.
>>> I'm going to try client-specific roles again now that apiman is 1.2.1.
>>> I'm
>>> using Postgres and ElasticSearch for storage, on other VMs.
>>>
>>> This was enough to let me login and view /apimanui when I had those roles
>>> for my Keycloak user.
>>>
>>> Hope this helps,
>>> Guy
>>>
>>> On Thu, Jan 28, 2016 at 1:08 AM, enrico <lists at comiti.name> wrote:
>>>>
>>>>
>>>> Hi all,
>>>> thanks for the responses.
>>>>
>>>> @Mark: yes, I know that is a release candidate but looks like the
>>>> final version is near and, being on a new project, I wanted start with
>>>> the very last versions :)
>>>>
>>>> A part from this, I have tried with 1.7.0.Final too, but I have the
>>>> same problem:
>>>>
>>>> User gets a "Forbidden" page and Keycloak server logs say:
>>>>
>>>> WARN  [org.keycloak.events]:
>>>> type=CODE_TO_TOKEN_ERROR,
>>>> realmId=352d562a-f3e5-4b7a-99ad-4331cdfdf085, clientId=apimanui,
>>>> userId=null, ipAddress=127.0.0.1, error=invalid_client_credentials,
>>>> grant_type=authorization_code
>>>>
>>>> Thanks a lot for the help, best regards,
>>>> Enrico
>>>>
>>>>
>>>> On Wed, Jan 27, 2016 at 5:49 PM, Marc Savy <marc.savy at redhat.com> wrote:
>>>>>
>>>>> Hi Enrico,
>>>>>
>>>>> We haven't tested with Keycloak 1.8, as this is only a candidate
>>>>> release
>>>>> at the moment (CR == RC).
>>>>>
>>>>> I can give it a try, though and will report back.
>>>>>
>>>>> Regards,
>>>>> Marc
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Enrico Comiti
>>>> _______________________________________________
>>>> Apiman-user mailing list
>>>> Apiman-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>>>
>>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apiman-realm.json
Type: application/json
Size: 3596 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20160129/1957e982/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apiman-keycloak-subsystem.xml
Type: text/xml
Size: 2952 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20160129/1957e982/attachment-0001.xml 

From eric.wittmann at redhat.com  Fri Jan 29 08:35:20 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Fri, 29 Jan 2016 08:35:20 -0500
Subject: [Apiman-user] external Keycloak server
In-Reply-To: <CAMJ0bZU_Qrk=xnv-NrO2Q85g-SerVrK6G8rRr=5f3dDjU2pOcg@mail.gmail.com>
References: <CAMJ0bZUco5p3J9nBCc9h0aOD1Oz=CRuBZLbLLL9g_+FvY+H=DA@mail.gmail.com>
	<CAAgmn1rcCQN-W89PhG6XDFeEJAjC9uhQfKunD80WuSvtOzk=FA@mail.gmail.com>
	<CAMJ0bZXqiD-1vMtcBR8-hp998djPxLYiX_=jfms7zg9Ez-_nwA@mail.gmail.com>
	<56AB662E.7030006@redhat.com>
	<CAMJ0bZU_Qrk=xnv-NrO2Q85g-SerVrK6G8rRr=5f3dDjU2pOcg@mail.gmail.com>
Message-ID: <56AB6A98.5010203@redhat.com>

Excellent, thanks very much.

On 1/29/2016 8:31 AM, enrico wrote:
> Hi, no problem at all...
> It is only for a local test environment.
>
> The Apiman and the Keycloak instances are separated but in the same
> host "apigateway".
> Apiman runs on port 8080, Keycloak on 32000.
>
> Hope this helps.
>
> Enrico
>
>
> On Fri, Jan 29, 2016 at 2:16 PM, Eric Wittmann <eric.wittmann at redhat.com> wrote:
>> Any chance you can share your full realm file?  Perhaps with any secrets
>> redacted.  :)
>>
>> -Eric
>>
>>
>> On 1/29/2016 4:11 AM, enrico wrote:
>>>
>>> Hi Guy,
>>> thank you very much, it works!
>>>
>>> For anyone with the same problem, this is my realm.json client definition:
>>>
>>>       "applications" : [
>>>           {
>>>               "name" : "apiman",
>>>               "enabled" : true,
>>>               "directGrantsOnly" : true,
>>>               "standardFlowEnabled": true,
>>>               "baseUrl" : "http://apigateway:8080/",
>>>               "redirectUris" : [
>>>                   "http://apigateway:8080/apimanui/*",
>>>                   "http://apigateway:8080/apiman-gateway-api/*",
>>>                   "http://apigateway:8080/apiman-es/*",
>>>                   "http://apigateway:8080/apiman/*"
>>>               ],
>>>               "secret" : "password"
>>>           }
>>>       ]
>>>
>>> Thanks a lot again.
>>>
>>> Cheers,
>>> Enrico
>>>
>>> On Thu, Jan 28, 2016 at 10:02 PM, Guy Davis <guydavis.ca at gmail.com> wrote:
>>>>
>>>> Hi Enrico,
>>>>
>>>> I just made the move to Apiman 1.2.1 (running on port 8081) and Keycloak
>>>> 1.7.0 (running on port 8080), both behind an HAProxy instance.  I've
>>>> attached the section of my standalone-apiman.xml that worked for me.
>>>>
>>>> Note, I'm not using the default 'apiman' realm as I am securing a number
>>>> of
>>>> other web apps with Keycloak.  So I have 'MyRealm' with Keycloak client
>>>> of
>>>> 'apiman', which is set for:
>>>>
>>>> Client-protocol: openid-connect
>>>> Access Type: confidential
>>>> Direct Access Grants Enabled: ON
>>>> Valid redirect URIs:
>>>>
>>>> /apimanui/*
>>>> /apiman-gateway-api/*
>>>> /apiman-es/*
>>>> /apiman/*
>>>>
>>>> In that KC client, I have 3 realm roles for this:
>>>>
>>>> apipublisher
>>>> apiadmin
>>>> apiuser
>>>>
>>>> I had tried to keep these roles to just the KC client 'apiman', but it
>>>> wouldn't allow me to login to /apimanui unless the roles were realm-wide.
>>>> I'm going to try client-specific roles again now that apiman is 1.2.1.
>>>> I'm
>>>> using Postgres and ElasticSearch for storage, on other VMs.
>>>>
>>>> This was enough to let me login and view /apimanui when I had those roles
>>>> for my Keycloak user.
>>>>
>>>> Hope this helps,
>>>> Guy
>>>>
>>>> On Thu, Jan 28, 2016 at 1:08 AM, enrico <lists at comiti.name> wrote:
>>>>>
>>>>>
>>>>> Hi all,
>>>>> thanks for the responses.
>>>>>
>>>>> @Mark: yes, I know that is a release candidate but looks like the
>>>>> final version is near and, being on a new project, I wanted start with
>>>>> the very last versions :)
>>>>>
>>>>> A part from this, I have tried with 1.7.0.Final too, but I have the
>>>>> same problem:
>>>>>
>>>>> User gets a "Forbidden" page and Keycloak server logs say:
>>>>>
>>>>> WARN  [org.keycloak.events]:
>>>>> type=CODE_TO_TOKEN_ERROR,
>>>>> realmId=352d562a-f3e5-4b7a-99ad-4331cdfdf085, clientId=apimanui,
>>>>> userId=null, ipAddress=127.0.0.1, error=invalid_client_credentials,
>>>>> grant_type=authorization_code
>>>>>
>>>>> Thanks a lot for the help, best regards,
>>>>> Enrico
>>>>>
>>>>>
>>>>> On Wed, Jan 27, 2016 at 5:49 PM, Marc Savy <marc.savy at redhat.com> wrote:
>>>>>>
>>>>>> Hi Enrico,
>>>>>>
>>>>>> We haven't tested with Keycloak 1.8, as this is only a candidate
>>>>>> release
>>>>>> at the moment (CR == RC).
>>>>>>
>>>>>> I can give it a try, though and will report back.
>>>>>>
>>>>>> Regards,
>>>>>> Marc
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Enrico Comiti
>>>>> _______________________________________________
>>>>> Apiman-user mailing list
>>>>> Apiman-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user