From ton at finalist.nl Tue Dec 1 02:46:45 2015 From: ton at finalist.nl (Ton Swieb) Date: Tue, 1 Dec 2015 08:46:45 +0100 Subject: [Apiman-user] Docker image for Apiman 1.1.9.Final In-Reply-To: <565A3C69.10406@redhat.com> References: <565A3C69.10406@redhat.com> Message-ID: Yes. I did. I am no specifying 1.1.9.Final directly instead of latest. 2015-11-29 0:44 GMT+01:00 Eric Wittmann : > OK thanks for letting me know. I'm not sure how 'latest' gets aliased to > some specific version. I'll have to poke around. :) > > I assume you resolved it by pulling the specific version? > > On 11/27/2015 9:16 AM, Ton Swieb wrote: > >> Hi Eric, >> >> Thanks for kicking of the docker build. >> I did find the 1.1.9.Final Docker image, but it looks like "latest" is >> still pointing at 1.1.8.Final. >> When doing a "docker pull jboss/apiman-wildfly" I end up with the >> 1.1.8.Final version instead of the 1.1.9.Final. >> >> Regards, >> >> Ton >> >> 2015-11-17 16:53 GMT+01:00 Eric Wittmann > >: >> >> Alas we do not control the tagging of that docker image and >> sometimes forget to check to see if it was done. This time it was >> overlooked by the /r/jboss guys. :) >> >> I should be building now. Keep an eye on it and if you don't see a >> 1.1.9.Final docker image sometime soon let me know. >> >> Looks like there might be some docker hub issues ATM that may delay >> things. >> >> -Eric >> >> On 11/17/2015 7:26 AM, Ton Swieb wrote: >> >> Hi, >> >> Is there a docker image available for the 1.1.9.Final release? >> I would expect it to find it here: >> https://hub.docker.com/r/jboss/apiman-wildfly/ >> But 1.1.8.Final is the latest I can find there. >> >> 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/20151201/b7f87a53/attachment.html From ton at finalist.nl Tue Dec 1 03:03:15 2015 From: ton at finalist.nl (Ton Swieb) Date: Tue, 1 Dec 2015 09:03:15 +0100 Subject: [Apiman-user] Forwarding HTTP requests to service implementations secured by OAuth Message-ID: Hi Eric, Marc, Thanks for getting back to me. Good point about the security implications of using the custom header policy. I am assuming that the credentials configured for the endpoint like basic auth en mutal SSL are better secured then the configuration of a policy. What role does someone need to read the custom header policy configuration? I am aware that refreshing the token will not be possible with the current setup. This should not be a problem for now. The tokens will have a long time to live. Regards, Ton 2015-11-30 15:25 GMT+01:00 Eric Wittmann : > Fair point. Although BASIC Auth probably isn't recommended either. :) > > On 11/30/2015 8:37 AM, Marc Savy wrote: > >> I'll take any further stuff to the ticket - but, my understanding is >> that Server-To-Server OAuth2 isn't particularly recommended (Mutual TLS >> or similar is preferred). >> >> That being said, I think you could argue we're just acting as a client >> by proxy, so perhaps it's okay. >> >> On 30/11/2015 13:33, Eric Wittmann wrote: >> >>> Right - at this point a custom policy is probably the only reasonable >>> approach. >>> >>> I've added OAuth support between the Gateway and back-end API as a >>> feature request here: >>> >>> https://issues.jboss.org/browse/APIMAN-811 >>> >>> -Eric >>> >>> On 11/30/2015 6:31 AM, Marc Savy wrote: >>> > Hi Ton, >>> > >>> > Sorry, I forgot to reply to this. >>> > >>> > In essence, you are correct. There's no in-built mechanism to achieve >>> > what you want (i.e. gateway acting as an OAuth2 *client*). >>> > >>> > You could indeed use the simple header policy to store a long-lived >>> > token, but this should not be considered a particularly secure approach >>> > (particularly if there's a chance that the token could be exposed >>> > somehow - e.g. by a user looking at the policy config in the UI). >>> > >>> > The second issue, which you are undoubtedly aware of, is that there is >>> > no mechanism to auto-refresh those token(s) once expired. >>> > >>> > Another option which you could explore is to create a custom policy >>> > which does the periodic refreshing of tokens for you. >>> > >>> > Regards, >>> > Marc >>> > >>> > On 18/11/2015 15:11, Ton Swieb wrote: >>> >> Hi Marc, >>> >> >>> >> That is correct. >>> >> >>> >> Regards, >>> >> >>> >> Ton >>> >> >>> >> 2015-11-18 16:02 GMT+01:00 Marc Savy >> >> >: >>> >> >>> >> Hi Ton, >>> >> >>> >> Just to clarify. From what I understand, you're trying to secure >>> >> communications between the apiman gateway and back-end service >>> >> using >>> >> OAuth2/OpenID Connect? >>> >> >>> >> I.e. You are *not* OAuth2 simply between the client to the apiman >>> >> gateway. >>> >> >>> >> Regards, >>> >> Marc >>> >> >>> >> On 18/11/2015 14:34, Ton Swieb wrote: >>> >> >>> >> Hi, >>> >> >>> >> I am using Apiman 1.1.8.Final and I want to use a backend >>> >> service in >>> >> Apiman which is secured by OAuth. >>> >> So instead of securing the Apiman side of the service, using >>> >> the >>> >> Keycloak OAuth plugin, Apiman needs forward calls to a >>> service >>> >> implementation that is secured by OAuth. I have got an OAuth >>> >> token with >>> >> a very long time to live (days/weeks/months) which I can use. >>> >> >>> >> Currently I only see the option to configure BASIC >>> >> Authentication or >>> >> MTLS/Two-Way-SSL on the service implementation. >>> >> Would it be possible to add the HTTP Simple Header policy to >>> >> the >>> >> service >>> >> and set the Authorization header with "Bearer........." or >>> will >>> >> that be >>> >> stripped off by Apiman when forwarding the call to the >>> backend >>> >> service? >>> >> >>> >> Kind regards, >>> >> >>> >> Ton >>> >> >>> >> >>> >> _______________________________________________ >>> >> Apiman-user mailing list >>> >> Apiman-user at lists.jboss.org >>> >> >>> >> 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/20151201/f07c8df9/attachment-0001.html From ton at finalist.nl Tue Dec 1 04:01:25 2015 From: ton at finalist.nl (Ton Swieb) Date: Tue, 1 Dec 2015 10:01:25 +0100 Subject: [Apiman-user] Policy for adding query parameters to service implementation URL Message-ID: Hi, Is there a policy for adding query parameters the service implementation URL? Similair to the simple header policy, but then for url query parameters? Regards, Ton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151201/0da34b68/attachment.html From eric.wittmann at redhat.com Tue Dec 1 07:55:34 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 1 Dec 2015 07:55:34 -0500 Subject: [Apiman-user] Forwarding HTTP requests to service implementations secured by OAuth In-Reply-To: References: Message-ID: <565D98C6.5050802@redhat.com> Both the endpoint security configuration information *and* all policy configuration information is encrypted prior to storing it in the API Manager database. I believe that any user with the "Service Read" permission can view that information. So any user who is an Organization Owner or a Service Provider member of the organization that owns the service. Of course, you can define your own roles in apiman, so other roles *may* exist which grant that permission. -Eric On 12/1/2015 3:03 AM, Ton Swieb wrote: > Hi Eric, Marc, > > Thanks for getting back to me. > > Good point about the security implications of using the custom header > policy. I am assuming that the credentials configured for the endpoint > like basic auth en mutal SSL are better secured then the configuration > of a policy. > > What role does someone need to read the custom header policy configuration? > > I am aware that refreshing the token will not be possible with the > current setup. This should not be a problem for now. The tokens will > have a long time to live. > > Regards, > > Ton > > 2015-11-30 15:25 GMT+01:00 Eric Wittmann >: > > Fair point. Although BASIC Auth probably isn't recommended either. :) > > On 11/30/2015 8:37 AM, Marc Savy wrote: > > I'll take any further stuff to the ticket - but, my understanding is > that Server-To-Server OAuth2 isn't particularly recommended > (Mutual TLS > or similar is preferred). > > That being said, I think you could argue we're just acting as a > client > by proxy, so perhaps it's okay. > > On 30/11/2015 13:33, Eric Wittmann wrote: > > Right - at this point a custom policy is probably the only > reasonable > approach. > > I've added OAuth support between the Gateway and back-end > API as a > feature request here: > > https://issues.jboss.org/browse/APIMAN-811 > > -Eric > > On 11/30/2015 6:31 AM, Marc Savy wrote: > > Hi Ton, > > > > Sorry, I forgot to reply to this. > > > > In essence, you are correct. There's no in-built > mechanism to achieve > > what you want (i.e. gateway acting as an OAuth2 *client*). > > > > You could indeed use the simple header policy to store a > long-lived > > token, but this should not be considered a particularly > secure approach > > (particularly if there's a chance that the token could be > exposed > > somehow - e.g. by a user looking at the policy config in > the UI). > > > > The second issue, which you are undoubtedly aware of, is > that there is > > no mechanism to auto-refresh those token(s) once expired. > > > > Another option which you could explore is to create a > custom policy > > which does the periodic refreshing of tokens for you. > > > > Regards, > > Marc > > > > On 18/11/2015 15:11, Ton Swieb wrote: > >> Hi Marc, > >> > >> That is correct. > >> > >> Regards, > >> > >> Ton > >> > >> 2015-11-18 16:02 GMT+01:00 Marc Savy > > >> >>: > >> > >> Hi Ton, > >> > >> Just to clarify. From what I understand, you're > trying to secure > >> communications between the apiman gateway and > back-end service > >> using > >> OAuth2/OpenID Connect? > >> > >> I.e. You are *not* OAuth2 simply between the client > to the apiman > >> gateway. > >> > >> Regards, > >> Marc > >> > >> On 18/11/2015 14:34, Ton Swieb wrote: > >> > >> Hi, > >> > >> I am using Apiman 1.1.8.Final and I want to use > a backend > >> service in > >> Apiman which is secured by OAuth. > >> So instead of securing the Apiman side of the > service, using > >> the > >> Keycloak OAuth plugin, Apiman needs forward > calls to a > service > >> implementation that is secured by OAuth. I have > got an OAuth > >> token with > >> a very long time to live (days/weeks/months) > which I can use. > >> > >> Currently I only see the option to configure BASIC > >> Authentication or > >> MTLS/Two-Way-SSL on the service implementation. > >> Would it be possible to add the HTTP Simple > Header policy to > >> the > >> service > >> and set the Authorization header with > "Bearer........." or > will > >> that be > >> stripped off by Apiman when forwarding the call > to the > backend > >> service? > >> > >> Kind regards, > >> > >> Ton > >> > >> > >> _______________________________________________ > >> Apiman-user mailing list > >> Apiman-user at lists.jboss.org > > >> > > >> 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 Dec 1 07:57:33 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 1 Dec 2015 07:57:33 -0500 Subject: [Apiman-user] Policy for adding query parameters to service implementation URL In-Reply-To: References: Message-ID: <565D993D.7090706@redhat.com> Not at present, no. That would be a very simple policy to implement, however. If you do not have the desire to implement your own custom policy for that, please do not hesitate to add a JIRA feature request: https://issues.jboss.org/browse/APIMAN -Eric On 12/1/2015 4:01 AM, Ton Swieb wrote: > Hi, > > Is there a policy for adding query parameters the service implementation > URL? Similair to the simple header policy, but then for url query > parameters? > > Regards, > > Ton > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From ton at finalist.nl Tue Dec 1 09:12:24 2015 From: ton at finalist.nl (Ton Swieb) Date: Tue, 1 Dec 2015 15:12:24 +0100 Subject: [Apiman-user] Policy for adding query parameters to service implementation URL In-Reply-To: <565D993D.7090706@redhat.com> References: <565D993D.7090706@redhat.com> Message-ID: Hi Eric, Ok. Good to know. I don't really need it right now, but I was wondering if it was already possible out of the box. Regards, Ton 2015-12-01 13:57 GMT+01:00 Eric Wittmann : > Not at present, no. That would be a very simple policy to implement, > however. If you do not have the desire to implement your own custom policy > for that, please do not hesitate to add a JIRA feature request: > > https://issues.jboss.org/browse/APIMAN > > -Eric > > On 12/1/2015 4:01 AM, Ton Swieb wrote: > >> Hi, >> >> Is there a policy for adding query parameters the service implementation >> URL? Similair to the simple header policy, but then for url query >> parameters? >> >> 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/20151201/3e44d62a/attachment.html From ton at finalist.nl Tue Dec 1 09:16:59 2015 From: ton at finalist.nl (Ton Swieb) Date: Tue, 1 Dec 2015 15:16:59 +0100 Subject: [Apiman-user] Forwarding HTTP requests to service implementations secured by OAuth In-Reply-To: <565D98C6.5050802@redhat.com> References: <565D98C6.5050802@redhat.com> Message-ID: Hi Eric, So if I understand you correctly it does not matter if my security sensitive information is configured directly on the endpoint or via a policy. Is this related to https://issues.jboss.org/browse/APIMAN-460? 2015-12-01 13:55 GMT+01:00 Eric Wittmann : > Both the endpoint security configuration information *and* all policy > configuration information is encrypted prior to storing it in the API > Manager database. I believe that any user with the "Service Read" > permission can view that information. So any user who is an Organization > Owner or a Service Provider member of the organization that owns the > service. Of course, you can define your own roles in apiman, so other > roles *may* exist which grant that permission. > > -Eric > > On 12/1/2015 3:03 AM, Ton Swieb wrote: > >> Hi Eric, Marc, >> >> Thanks for getting back to me. >> >> Good point about the security implications of using the custom header >> policy. I am assuming that the credentials configured for the endpoint >> like basic auth en mutal SSL are better secured then the configuration >> of a policy. >> >> What role does someone need to read the custom header policy >> configuration? >> >> I am aware that refreshing the token will not be possible with the >> current setup. This should not be a problem for now. The tokens will >> have a long time to live. >> >> Regards, >> >> Ton >> >> 2015-11-30 15:25 GMT+01:00 Eric Wittmann > >: >> >> Fair point. Although BASIC Auth probably isn't recommended either. :) >> >> On 11/30/2015 8:37 AM, Marc Savy wrote: >> >> I'll take any further stuff to the ticket - but, my understanding >> is >> that Server-To-Server OAuth2 isn't particularly recommended >> (Mutual TLS >> or similar is preferred). >> >> That being said, I think you could argue we're just acting as a >> client >> by proxy, so perhaps it's okay. >> >> On 30/11/2015 13:33, Eric Wittmann wrote: >> >> Right - at this point a custom policy is probably the only >> reasonable >> approach. >> >> I've added OAuth support between the Gateway and back-end >> API as a >> feature request here: >> >> https://issues.jboss.org/browse/APIMAN-811 >> >> -Eric >> >> On 11/30/2015 6:31 AM, Marc Savy wrote: >> > Hi Ton, >> > >> > Sorry, I forgot to reply to this. >> > >> > In essence, you are correct. There's no in-built >> mechanism to achieve >> > what you want (i.e. gateway acting as an OAuth2 *client*). >> > >> > You could indeed use the simple header policy to store a >> long-lived >> > token, but this should not be considered a particularly >> secure approach >> > (particularly if there's a chance that the token could be >> exposed >> > somehow - e.g. by a user looking at the policy config in >> the UI). >> > >> > The second issue, which you are undoubtedly aware of, is >> that there is >> > no mechanism to auto-refresh those token(s) once expired. >> > >> > Another option which you could explore is to create a >> custom policy >> > which does the periodic refreshing of tokens for you. >> > >> > Regards, >> > Marc >> > >> > On 18/11/2015 15:11, Ton Swieb wrote: >> >> Hi Marc, >> >> >> >> That is correct. >> >> >> >> Regards, >> >> >> >> Ton >> >> >> >> 2015-11-18 16:02 GMT+01:00 Marc Savy >> >> >> > >>: >> >> >> >> Hi Ton, >> >> >> >> Just to clarify. From what I understand, you're >> trying to secure >> >> communications between the apiman gateway and >> back-end service >> >> using >> >> OAuth2/OpenID Connect? >> >> >> >> I.e. You are *not* OAuth2 simply between the client >> to the apiman >> >> gateway. >> >> >> >> Regards, >> >> Marc >> >> >> >> On 18/11/2015 14:34, Ton Swieb wrote: >> >> >> >> Hi, >> >> >> >> I am using Apiman 1.1.8.Final and I want to use >> a backend >> >> service in >> >> Apiman which is secured by OAuth. >> >> So instead of securing the Apiman side of the >> service, using >> >> the >> >> Keycloak OAuth plugin, Apiman needs forward >> calls to a >> service >> >> implementation that is secured by OAuth. I have >> got an OAuth >> >> token with >> >> a very long time to live (days/weeks/months) >> which I can use. >> >> >> >> Currently I only see the option to configure >> BASIC >> >> Authentication or >> >> MTLS/Two-Way-SSL on the service implementation. >> >> Would it be possible to add the HTTP Simple >> Header policy to >> >> the >> >> service >> >> and set the Authorization header with >> "Bearer........." or >> will >> >> that be >> >> stripped off by Apiman when forwarding the call >> to the >> backend >> >> service? >> >> >> >> Kind regards, >> >> >> >> Ton >> >> >> >> >> >> _______________________________________________ >> >> Apiman-user mailing list >> >> Apiman-user at lists.jboss.org >> >> >> > > >> >> 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/20151201/1064b322/attachment-0001.html From eric.wittmann at redhat.com Tue Dec 1 10:43:48 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 1 Dec 2015 10:43:48 -0500 Subject: [Apiman-user] Forwarding HTTP requests to service implementations secured by OAuth In-Reply-To: References: <565D98C6.5050802@redhat.com> Message-ID: <565DC034.1080402@redhat.com> You are correct - from a security standpoint I don't think it matters. I do think 460 is related - we should ensure that potentially security sensitive information is not returned unless the requesting user has the appropriate permission. On 12/1/2015 9:16 AM, Ton Swieb wrote: > Hi Eric, > > So if I understand you correctly it does not matter if my security > sensitive information is configured directly on the endpoint or via a > policy. > Is this related to https://issues.jboss.org/browse/APIMAN-460? > > 2015-12-01 13:55 GMT+01:00 Eric Wittmann >: > > Both the endpoint security configuration information *and* all > policy configuration information is encrypted prior to storing it in > the API Manager database. I believe that any user with the "Service > Read" permission can view that information. So any user who is an > Organization Owner or a Service Provider member of the organization > that owns the service. Of course, you can define your own roles in > apiman, so other roles *may* exist which grant that permission. > > -Eric > > On 12/1/2015 3:03 AM, Ton Swieb wrote: > > Hi Eric, Marc, > > Thanks for getting back to me. > > Good point about the security implications of using the custom > header > policy. I am assuming that the credentials configured for the > endpoint > like basic auth en mutal SSL are better secured then the > configuration > of a policy. > > What role does someone need to read the custom header policy > configuration? > > I am aware that refreshing the token will not be possible with the > current setup. This should not be a problem for now. The tokens will > have a long time to live. > > Regards, > > Ton > > 2015-11-30 15:25 GMT+01:00 Eric Wittmann > > >>: > > Fair point. Although BASIC Auth probably isn't recommended > either. :) > > On 11/30/2015 8:37 AM, Marc Savy wrote: > > I'll take any further stuff to the ticket - but, my > understanding is > that Server-To-Server OAuth2 isn't particularly recommended > (Mutual TLS > or similar is preferred). > > That being said, I think you could argue we're just > acting as a > client > by proxy, so perhaps it's okay. > > On 30/11/2015 13:33, Eric Wittmann wrote: > > Right - at this point a custom policy is probably > the only > reasonable > approach. > > I've added OAuth support between the Gateway and > back-end > API as a > feature request here: > > https://issues.jboss.org/browse/APIMAN-811 > > -Eric > > On 11/30/2015 6:31 AM, Marc Savy wrote: > > Hi Ton, > > > > Sorry, I forgot to reply to this. > > > > In essence, you are correct. There's no in-built > mechanism to achieve > > what you want (i.e. gateway acting as an OAuth2 > *client*). > > > > You could indeed use the simple header policy to > store a > long-lived > > token, but this should not be considered a > particularly > secure approach > > (particularly if there's a chance that the token > could be > exposed > > somehow - e.g. by a user looking at the policy > config in > the UI). > > > > The second issue, which you are undoubtedly > aware of, is > that there is > > no mechanism to auto-refresh those token(s) once > expired. > > > > Another option which you could explore is to > create a > custom policy > > which does the periodic refreshing of tokens for > you. > > > > Regards, > > Marc > > > > On 18/11/2015 15:11, Ton Swieb wrote: > >> Hi Marc, > >> > >> That is correct. > >> > >> Regards, > >> > >> Ton > >> > >> 2015-11-18 16:02 GMT+01:00 Marc Savy > > > > >> > >>>: > >> > >> Hi Ton, > >> > >> Just to clarify. From what I understand, > you're > trying to secure > >> communications between the apiman gateway and > back-end service > >> using > >> OAuth2/OpenID Connect? > >> > >> I.e. You are *not* OAuth2 simply between > the client > to the apiman > >> gateway. > >> > >> Regards, > >> Marc > >> > >> On 18/11/2015 14:34, Ton Swieb wrote: > >> > >> Hi, > >> > >> I am using Apiman 1.1.8.Final and I > want to use > a backend > >> service in > >> Apiman which is secured by OAuth. > >> So instead of securing the Apiman side > of the > service, using > >> the > >> Keycloak OAuth plugin, Apiman needs > forward > calls to a > service > >> implementation that is secured by > OAuth. I have > got an OAuth > >> token with > >> a very long time to live > (days/weeks/months) > which I can use. > >> > >> Currently I only see the option to > configure BASIC > >> Authentication or > >> MTLS/Two-Way-SSL on the service > implementation. > >> Would it be possible to add the HTTP > Simple > Header policy to > >> the > >> service > >> and set the Authorization header with > "Bearer........." or > will > >> that be > >> stripped off by Apiman when forwarding > the call > to the > backend > >> service? > >> > >> Kind regards, > >> > >> Ton > >> > >> > >> > _______________________________________________ > >> Apiman-user mailing list > >> Apiman-user at lists.jboss.org > > > > >> > >> > >> > 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 Dec 1 10:44:43 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 1 Dec 2015 10:44:43 -0500 Subject: [Apiman-user] Policy for adding query parameters to service implementation URL In-Reply-To: References: <565D993D.7090706@redhat.com> Message-ID: <565DC06B.40006@redhat.com> That makes sense. I do think a JIRA feature request would be great. I can add it myself, of course, but if you wouldn't mind taking a couple minutes to create it I would prefer that (for tracking purposes). If not, that's fine too just let me know. :) On 12/1/2015 9:12 AM, Ton Swieb wrote: > Hi Eric, > > Ok. Good to know. > I don't really need it right now, but I was wondering if it was already > possible out of the box. > > Regards, > > Ton > > 2015-12-01 13:57 GMT+01:00 Eric Wittmann >: > > Not at present, no. That would be a very simple policy to > implement, however. If you do not have the desire to implement your > own custom policy for that, please do not hesitate to add a JIRA > feature request: > > https://issues.jboss.org/browse/APIMAN > > -Eric > > On 12/1/2015 4:01 AM, Ton Swieb wrote: > > Hi, > > Is there a policy for adding query parameters the service > implementation > URL? Similair to the simple header policy, but then for url query > parameters? > > Regards, > > Ton > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > > From ton at finalist.nl Tue Dec 1 11:01:21 2015 From: ton at finalist.nl (Ton Swieb) Date: Tue, 1 Dec 2015 17:01:21 +0100 Subject: [Apiman-user] Policy for adding query parameters to service implementation URL In-Reply-To: <565DC06B.40006@redhat.com> References: <565D993D.7090706@redhat.com> <565DC06B.40006@redhat.com> Message-ID: Hi Eric, Sure. No problem. I created: https://issues.jboss.org/browse/APIMAN-813 Regards, Ton 2015-12-01 16:44 GMT+01:00 Eric Wittmann : > That makes sense. I do think a JIRA feature request would be great. I > can add it myself, of course, but if you wouldn't mind taking a couple > minutes to create it I would prefer that (for tracking purposes). > > If not, that's fine too just let me know. :) > > On 12/1/2015 9:12 AM, Ton Swieb wrote: > >> Hi Eric, >> >> Ok. Good to know. >> I don't really need it right now, but I was wondering if it was already >> possible out of the box. >> >> Regards, >> >> Ton >> >> 2015-12-01 13:57 GMT+01:00 Eric Wittmann > >: >> >> Not at present, no. That would be a very simple policy to >> implement, however. If you do not have the desire to implement your >> own custom policy for that, please do not hesitate to add a JIRA >> feature request: >> >> https://issues.jboss.org/browse/APIMAN >> >> -Eric >> >> On 12/1/2015 4:01 AM, Ton Swieb wrote: >> >> Hi, >> >> Is there a policy for adding query parameters the service >> implementation >> URL? Similair to the simple header policy, but then for url query >> parameters? >> >> 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/20151201/e8b760d5/attachment.html From pblair at clearme.com Mon Dec 7 17:47:06 2015 From: pblair at clearme.com (Paul Blair) Date: Mon, 7 Dec 2015 22:47:06 +0000 Subject: [Apiman-user] Production deployment questions Message-ID: Hi - I'm working through the production deployment guide and have a few questions concerning the standalone-apiman.xml file. In the file, I see several entries like this (one each for apiman.war, apimanui.war, and apiman-gateway-api.war). apiman apiman password 1. Is "password" supposed to be replaced by some credential? This isn't mentioned in the instructions; my guess is that this credential is used only for applications that request REST Direct Access Grants, and that apiman doesn't. Is that correct? 2. If I'm configuring the gateway as a separate service, can I remove the apimanui.war secure-deployment entry? Correspondingly, when I configure the standalone API manager, do I remove the apiman-gateway-api.war entry? 3. Is it possible to set properties that appear in apiman.properties by way of Java system properties or in a configuration in the standalone-apiman.xml file? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151207/36a62b94/attachment.html From eric.wittmann at redhat.com Mon Dec 7 20:35:20 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Mon, 7 Dec 2015 20:35:20 -0500 Subject: [Apiman-user] Production deployment questions In-Reply-To: References: Message-ID: <566633D8.2010804@redhat.com> Hi Paul - answers inline below. > 1. Is "password" supposed to be replaced by some credential? This isn't > mentioned in the instructions; my guess is that this credential is used > only for applications that request REST Direct Access Grants, and that > apiman doesn't. Is that correct? Embarrassingly I'm not 100% sure what that setting is all about. Here is the documentation from keycloak: ---- credentials Specify the credentials of the application. This is an object notation where the key is the credential type and the value is the value of the credential type. Currently only 'password' is supported. This is REQUIRED. ---- It would be a good question to ask on the keycloak mailing list. @msavy - any idea? > 2. If I'm configuring the gateway as a separate service, can I remove > the apimanui.war secure-deployment entry? Correspondingly, when I > configure the standalone API manager, do I remove the > apiman-gateway-api.war entry? Yep! It's not *required* to remove them, but you can certainly remove them without ill effect. > 3. Is it possible to set properties that appear in apiman.properties by > way of Java system properties or in a configuration > in the standalone-apiman.xml file? Yes it is! :) Either of those approaches should work. You can also use environment variables and eap/wildfly vaulted values if you like. It's also possible to encrypt values (using our AesEncrypter class) and put the encrypted value in the config. Not really secure but it's better than having a password in clear text. -Eric From ton at finalist.nl Tue Dec 8 10:28:18 2015 From: ton at finalist.nl (Ton Swieb) Date: Tue, 8 Dec 2015 16:28:18 +0100 Subject: [Apiman-user] Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password Message-ID: Hi, I would like to secure my api's using the Keycloak OAuth2 policy. Similair to what is described in the blog post of Marc Savy: http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html Only with the difference that Keycloak delegates the login to a third party IdP. After logging in at this third party IdP I end up with an active session in the Apiman UI (the apiman realm of Keycloak). Now I am wondering how to get the bearer token, because I do not have a username/password combination I can use to make a call like: curl -X POST http://127.0.0.1:8080/auth/realms/stottie/protocol/openid-connect/token -H "Content-Type: application/x-www-form-urlencoded" -d "username=rincewind" -d 'password=apiman' -d 'grant_type=password' -d 'client_id=apiman' Because the username/password combination is linked to the third party IdP and not to Keycloak itself. Is there another way to obtain the bearer token? Perhaps this is aquestion which I should address at the keycloak mailinglist. I will try to ask the question there as well. Regards, Ton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151208/59471eab/attachment.html From pblair at clearme.com Tue Dec 8 11:19:39 2015 From: pblair at clearme.com (Paul Blair) Date: Tue, 8 Dec 2015 16:19:39 +0000 Subject: [Apiman-user] Having trouble connecting to Amazon Elasticsearch service Message-ID: Not quite sure what to make of this: I'm getting org.apache.http.NoHttpResponseException: [endpoint_URI]:443 failed to respond But if I do: curl https://[endpont_URI]:443 I get a response from Elasticsearch-this is because I have the Amazon Elasticsearch instance permissioned to accept any connections from the IP address where apiman is running. The apiman configurations look like this: apiman.es.protocol=http apiman.es.host=[endpoint_URI] apiman.es.port=443 apiman.es.username= apiman.es.password= Changing protocol from http to https doesn't appear to help, nor does removing the username and password properties entirely. Any suggestions? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151208/2b4fcfff/attachment.html From eric.wittmann at redhat.com Tue Dec 8 11:48:34 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 8 Dec 2015 11:48:34 -0500 Subject: [Apiman-user] Having trouble connecting to Amazon Elasticsearch service In-Reply-To: References: Message-ID: <566709E2.3020800@redhat.com> You definitely need to set the protocol to 'https', for the record. Beyond that I'm not quite sure. Do you have a full stack trace or just that part of it? On 12/8/2015 11:19 AM, Paul Blair wrote: > Not quite sure what to make of this: I'm getting > > org.apache.http.NoHttpResponseException: [endpoint_URI]:443 failed > to respond > > But if I do: > > curl https://[endpont_URI]:443 > > I get a response from Elasticsearch?this is because I have the Amazon > Elasticsearch instance permissioned to accept any connections from the > IP address where apiman is running. > > The apiman configurations look like this: > > apiman.es.protocol=http > apiman.es.host=[endpoint_URI] > apiman.es.port=443 > apiman.es.username= > apiman.es.password= > > Changing protocol from http to https doesn't appear to help, nor does > removing the username and password properties entirely. Any suggestions? > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From marc.savy at redhat.com Tue Dec 8 11:53:36 2015 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 8 Dec 2015 16:53:36 +0000 Subject: [Apiman-user] Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password In-Reply-To: References: Message-ID: <56670B10.7040003@redhat.com> Hi Ton, I'm not quite sure what you mean, but I think what you're asking for is brokerage/delegation in the form: 1. Client <-> Keycloak <-> Other IdP. 2. Client <-> apiman gateway Regards, Marc On 08/12/2015 15:28, Ton Swieb wrote: > Hi, > > I would like to secure my api's using the Keycloak OAuth2 policy. > Similair to what is described in the blog post of Marc Savy: > http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html > > Only with the difference that Keycloak delegates the login to a third > party IdP. After logging in at this third party IdP I end up with an > active session in the Apiman UI (the apiman realm of Keycloak). > > Now I am wondering how to get the bearer token, because I do not have a > username/password combination I can use to make a call like: > > |curl -X POST > http://127.0.0.1:8080/auth/realms/stottie/protocol/openid-connect/token > -H "Content-Type: application/x-www-form-urlencoded" -d > "username=rincewind" -d 'password=apiman' -d 'grant_type=password' -d > 'client_id=apiman'| > > Because the username/password combination is linked to the third party > IdP and not to Keycloak itself. > > Is there another way to obtain the bearer token? > > Perhaps this is aquestion which I should address at the keycloak > mailinglist. I will try to ask the question there as well. > > Regards, > > Ton > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From marc.savy at redhat.com Tue Dec 8 11:58:26 2015 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 8 Dec 2015 16:58:26 +0000 Subject: [Apiman-user] Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password In-Reply-To: <56670B10.7040003@redhat.com> References: <56670B10.7040003@redhat.com> Message-ID: <56670C32.3060000@redhat.com> To expand on that - depending on exactly what type of IdP (and specifically which technology) you were delegating to, it may be possible to do what you're asking - or you may need to write something custom. Can you provide more detail? Also, if you have very specific Keycloak questions you might be best served on the keycloak-user mailing list, which is extremely active (https://lists.jboss.org/mailman/listinfo/keycloak-user). On 08/12/2015 16:53, Marc Savy wrote: > Hi Ton, > > I'm not quite sure what you mean, but I think what you're asking for is > brokerage/delegation in the form: > > 1. Client <-> Keycloak <-> Other IdP. > 2. Client <-> apiman gateway > > Regards, > Marc > > On 08/12/2015 15:28, Ton Swieb wrote: > > Hi, > > > > I would like to secure my api's using the Keycloak OAuth2 policy. > > Similair to what is described in the blog post of Marc Savy: > > http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html > > > > > > Only with the difference that Keycloak delegates the login to a third > > party IdP. After logging in at this third party IdP I end up with an > > active session in the Apiman UI (the apiman realm of Keycloak). > > > > Now I am wondering how to get the bearer token, because I do not have a > > username/password combination I can use to make a call like: > > > > |curl -X POST > > http://127.0.0.1:8080/auth/realms/stottie/protocol/openid-connect/token > > -H "Content-Type: application/x-www-form-urlencoded" -d > > "username=rincewind" -d 'password=apiman' -d 'grant_type=password' -d > > 'client_id=apiman'| > > > > Because the username/password combination is linked to the third party > > IdP and not to Keycloak itself. > > > > Is there another way to obtain the bearer token? > > > > Perhaps this is aquestion which I should address at the keycloak > > mailinglist. I will try to ask the question there as well. > > > > Regards, > > > > Ton > > > > > > _______________________________________________ > > Apiman-user mailing list > > Apiman-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/apiman-user > > > From pblair at clearme.com Tue Dec 8 12:12:20 2015 From: pblair at clearme.com (Paul Blair) Date: Tue, 8 Dec 2015 17:12:20 +0000 Subject: [Apiman-user] Having trouble connecting to Amazon Elasticsearch service In-Reply-To: <566709E2.3020800@redhat.com> Message-ID: The stack trace is below. Note that the instance seems to start fine; it's only when I make a request to the Gateway that I get this error. Thanks! 16:18:04,746 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /apiman-gateway/test_api/1.7: java.lang.RuntimeException: org.apache.http.NoHttpResponseException: search-testapi-....us-west-2.es.amazonaws.com:443 failed to respond at io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClientFactor y.java:200) [apiman-gateway-engine-es-1.1.9.Final.jar:] at io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClientFactor y.java:140) [apiman-gateway-engine-es-1.1.9.Final.jar:] at io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClientFactor y.java:101) [apiman-gateway-engine-es-1.1.9.Final.jar:] at io.apiman.gateway.engine.es.ESClientFactory.createClient(ESClientFactory.ja va:66) [apiman-gateway-engine-es-1.1.9.Final.jar:] at io.apiman.gateway.engine.es.AbstractESComponent.getClient(AbstractESCompone nt.java:45) [apiman-gateway-engine-es-1.1.9.Final.jar:] at io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:315) [apiman-gateway-engine-es-1.1.9.Final.jar:] at io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:304) [apiman-gateway-engine-es-1.1.9.Final.jar:] at io.apiman.gateway.engine.es.CachingESRegistry.getService(CachingESRegistry. java:189) [apiman-gateway-engine-es-1.1.9.Final.jar:] at io.apiman.gateway.engine.impl.SecureRegistryWrapper.getService(SecureRegist ryWrapper.java:97) [apiman-gateway-engine-core-1.1.9.Final.jar:] at io.apiman.gateway.engine.impl.ServiceRequestExecutorImpl.execute(ServiceReq uestExecutorImpl.java:252) [apiman-gateway-engine-core-1.1.9.Final.jar:] at io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet. java:236) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] at io.apiman.gateway.platforms.servlet.GatewayServlet.doGet(GatewayServlet.jav a:82) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.ja va:86) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequ est(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(Servle tDispatchingHandler.java:36) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.h andleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.hand leRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.hand leRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest( AbstractConfidentialityHandler.java:46) [undertow-core-1.1.8.Final.jar:1.1.8.Final] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandl er.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest (AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.8.Final.jar:1.1.8.Final] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.han dleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(Security InitialHandler.java:76) [undertow-core-1.1.8.Final.jar:1.1.8.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleReq uest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(Servl etInitialHandler.java:261) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletI nitialHandler.java:248) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitia lHandler.java:77) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletI nitialHandler.java:167) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) [undertow-core-1.1.8.Final.jar:1.1.8.Final] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:761) [undertow-core-1.1.8.Final.jar:1.1.8.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1 142) [rt.jar:1.8.0_25] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java: 617) [rt.jar:1.8.0_25] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25] Caused by: org.apache.http.NoHttpResponseException: search-testapi-....us-west-2.es.amazonaws.com:443 failed to respond at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpRe sponseParser.java:143) [httpclient-4.5.jar:4.5] at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpRe sponseParser.java:57) [httpclient-4.5.jar:4.5] at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.j ava:261) [httpcore-4.4.1.jar:4.4.1] at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(Def aultBHttpClientConnection.java:165) [httpcore-4.4.1.jar:4.4.1] at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java: 167) [httpclient-4.5.jar:4.5] at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestE xecutor.java:272) [httpcore-4.4.1.jar:4.4.1] at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.ja va:124) [httpcore-4.4.1.jar:4.4.1] at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:2 71) [httpclient-4.5.jar:4.5] at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184) [httpclient-4.5.jar:4.5] at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) [httpclient-4.5.jar:4.5] at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) [httpclient-4.5.jar:4.5] at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient .java:184) [httpclient-4.5.jar:4.5] at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient .java:82) [httpclient-4.5.jar:4.5] at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient .java:107) [httpclient-4.5.jar:4.5] at io.searchbox.client.http.JestHttpClient.execute(JestHttpClient.java:50) [jest-0.1.6.jar:] at io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClientFactor y.java:193) [apiman-gateway-engine-es-1.1.9.Final.jar:] ... 39 more On 12/8/15, 11:48 AM, "Eric Wittmann" wrote: >You definitely need to set the protocol to 'https', for the record. >Beyond that I'm not quite sure. Do you have a full stack trace or just >that part of it? > >On 12/8/2015 11:19 AM, Paul Blair wrote: >> Not quite sure what to make of this: I'm getting >> >> org.apache.http.NoHttpResponseException: [endpoint_URI]:443 failed >> to respond >> >> But if I do: >> >> curl https://[endpont_URI]:443 >> >> I get a response from Elasticsearch?this is because I have the Amazon >> Elasticsearch instance permissioned to accept any connections from the >> IP address where apiman is running. >> >> The apiman configurations look like this: >> >> apiman.es.protocol=http >> apiman.es.host=[endpoint_URI] >> apiman.es.port=443 >> apiman.es.username= >> apiman.es.password= >> >> Changing protocol from http to https doesn't appear to help, nor does >> removing the username and password properties entirely. Any suggestions? >> >> >> _______________________________________________ >> 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 Dec 8 12:21:31 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 8 Dec 2015 12:21:31 -0500 Subject: [Apiman-user] Having trouble connecting to Amazon Elasticsearch service In-Reply-To: References: Message-ID: <5667119B.8080706@redhat.com> What version of elasticsearch are you using? On 12/8/2015 12:12 PM, Paul Blair wrote: > The stack trace is below. Note that the instance seems to start fine; it's > only when I make a request to the Gateway that I get this error. > > Thanks! > > 16:18:04,746 ERROR [io.undertow.request] (default task-1) UT005023: > Exception handling request to /apiman-gateway/test_api/1.7: > java.lang.RuntimeException: org.apache.http.NoHttpResponseException: > search-testapi-....us-west-2.es.amazonaws.com:443 failed to respond > at > io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClientFactor > y.java:200) [apiman-gateway-engine-es-1.1.9.Final.jar:] > at > io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClientFactor > y.java:140) [apiman-gateway-engine-es-1.1.9.Final.jar:] > at > io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClientFactor > y.java:101) [apiman-gateway-engine-es-1.1.9.Final.jar:] > at > io.apiman.gateway.engine.es.ESClientFactory.createClient(ESClientFactory.ja > va:66) [apiman-gateway-engine-es-1.1.9.Final.jar:] > at > io.apiman.gateway.engine.es.AbstractESComponent.getClient(AbstractESCompone > nt.java:45) [apiman-gateway-engine-es-1.1.9.Final.jar:] > at io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:315) > [apiman-gateway-engine-es-1.1.9.Final.jar:] > at io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:304) > [apiman-gateway-engine-es-1.1.9.Final.jar:] > at > io.apiman.gateway.engine.es.CachingESRegistry.getService(CachingESRegistry. > java:189) [apiman-gateway-engine-es-1.1.9.Final.jar:] > at > io.apiman.gateway.engine.impl.SecureRegistryWrapper.getService(SecureRegist > ryWrapper.java:97) [apiman-gateway-engine-core-1.1.9.Final.jar:] > at > io.apiman.gateway.engine.impl.ServiceRequestExecutorImpl.execute(ServiceReq > uestExecutorImpl.java:252) [apiman-gateway-engine-core-1.1.9.Final.jar:] > at > io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet. > java:236) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] > at > io.apiman.gateway.platforms.servlet.GatewayServlet.doGet(GatewayServlet.jav > a:82) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.ja > va:86) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] > at > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequ > est(ServletSecurityRoleHandler.java:62) > [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] > at > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(Servle > tDispatchingHandler.java:36) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] > at > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.h > andleRequest(SecurityContextAssociationHandler.java:78) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler > .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] > at > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.hand > leRequest(SSLInformationAssociationHandler.java:131) > [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] > at > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.hand > leRequest(ServletAuthenticationCallHandler.java:57) > [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler > .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] > at > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest( > AbstractConfidentialityHandler.java:46) > [undertow-core-1.1.8.Final.jar:1.1.8.Final] > at > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandl > er.handleRequest(ServletConfidentialityConstraintHandler.java:64) > [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] > at > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest > (AuthenticationMechanismsHandler.java:58) > [undertow-core-1.1.8.Final.jar:1.1.8.Final] > at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.han > dleRequest(CachedAuthenticatedSessionHandler.java:70) > [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] > at > io.undertow.security.handlers.SecurityInitialHandler.handleRequest(Security > InitialHandler.java:76) [undertow-core-1.1.8.Final.jar:1.1.8.Final] > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler > .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] > at > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleReq > uest(JACCContextIdHandler.java:61) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler > .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler > .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(Servl > etInitialHandler.java:261) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletI > nitialHandler.java:248) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitia > lHandler.java:77) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletI > nitialHandler.java:167) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) > [undertow-core-1.1.8.Final.jar:1.1.8.Final] > at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:761) > [undertow-core-1.1.8.Final.jar:1.1.8.Final] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1 > 142) [rt.jar:1.8.0_25] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java: > 617) [rt.jar:1.8.0_25] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25] > Caused by: org.apache.http.NoHttpResponseException: > search-testapi-....us-west-2.es.amazonaws.com:443 failed to respond > at > org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpRe > sponseParser.java:143) [httpclient-4.5.jar:4.5] > at > org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpRe > sponseParser.java:57) [httpclient-4.5.jar:4.5] > at > org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.j > ava:261) [httpcore-4.4.1.jar:4.4.1] > at > org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(Def > aultBHttpClientConnection.java:165) [httpcore-4.4.1.jar:4.4.1] > at > org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java: > 167) [httpclient-4.5.jar:4.5] > at > org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestE > xecutor.java:272) [httpcore-4.4.1.jar:4.4.1] > at > org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.ja > va:124) [httpcore-4.4.1.jar:4.4.1] > at > org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:2 > 71) [httpclient-4.5.jar:4.5] > at > org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184) > [httpclient-4.5.jar:4.5] > at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) > [httpclient-4.5.jar:4.5] > at > org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) > [httpclient-4.5.jar:4.5] > at > org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient > .java:184) [httpclient-4.5.jar:4.5] > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient > .java:82) [httpclient-4.5.jar:4.5] > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient > .java:107) [httpclient-4.5.jar:4.5] > at > io.searchbox.client.http.JestHttpClient.execute(JestHttpClient.java:50) > [jest-0.1.6.jar:] > at > io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClientFactor > y.java:193) [apiman-gateway-engine-es-1.1.9.Final.jar:] > ... 39 more > > > > > > On 12/8/15, 11:48 AM, "Eric Wittmann" wrote: > >> You definitely need to set the protocol to 'https', for the record. >> Beyond that I'm not quite sure. Do you have a full stack trace or just >> that part of it? >> >> On 12/8/2015 11:19 AM, Paul Blair wrote: >>> Not quite sure what to make of this: I'm getting >>> >>> org.apache.http.NoHttpResponseException: [endpoint_URI]:443 failed >>> to respond >>> >>> But if I do: >>> >>> curl https://[endpont_URI]:443 >>> >>> I get a response from Elasticsearch?this is because I have the Amazon >>> Elasticsearch instance permissioned to accept any connections from the >>> IP address where apiman is running. >>> >>> The apiman configurations look like this: >>> >>> apiman.es.protocol=http >>> apiman.es.host=[endpoint_URI] >>> apiman.es.port=443 >>> apiman.es.username= >>> apiman.es.password= >>> >>> Changing protocol from http to https doesn't appear to help, nor does >>> removing the username and password properties entirely. Any suggestions? >>> >>> >>> _______________________________________________ >>> Apiman-user mailing list >>> Apiman-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/apiman-user >>> > From pblair at clearme.com Tue Dec 8 12:28:14 2015 From: pblair at clearme.com (Paul Blair) Date: Tue, 8 Dec 2015 17:28:14 +0000 Subject: [Apiman-user] Having trouble connecting to Amazon Elasticsearch service In-Reply-To: <5667119B.8080706@redhat.com> Message-ID: Amazon says their current version is 1.5.2. Does apiman require version 2.x? On 12/8/15, 12:21 PM, "Eric Wittmann" wrote: >What version of elasticsearch are you using? > >On 12/8/2015 12:12 PM, Paul Blair wrote: >> The stack trace is below. Note that the instance seems to start fine; >>it's >> only when I make a request to the Gateway that I get this error. >> >> Thanks! >> >> 16:18:04,746 ERROR [io.undertow.request] (default task-1) UT005023: >> Exception handling request to /apiman-gateway/test_api/1.7: >> java.lang.RuntimeException: org.apache.http.NoHttpResponseException: >> search-testapi-....us-west-2.es.amazonaws.com:443 failed to respond >> at >> >>io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClientFact >>or >> y.java:200) [apiman-gateway-engine-es-1.1.9.Final.jar:] >> at >> >>io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClientFact >>or >> y.java:140) [apiman-gateway-engine-es-1.1.9.Final.jar:] >> at >> >>io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClientFact >>or >> y.java:101) [apiman-gateway-engine-es-1.1.9.Final.jar:] >> at >> >>io.apiman.gateway.engine.es.ESClientFactory.createClient(ESClientFactory. >>ja >> va:66) [apiman-gateway-engine-es-1.1.9.Final.jar:] >> at >> >>io.apiman.gateway.engine.es.AbstractESComponent.getClient(AbstractESCompo >>ne >> nt.java:45) [apiman-gateway-engine-es-1.1.9.Final.jar:] >> at >>io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:315) >> [apiman-gateway-engine-es-1.1.9.Final.jar:] >> at >>io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:304) >> [apiman-gateway-engine-es-1.1.9.Final.jar:] >> at >> >>io.apiman.gateway.engine.es.CachingESRegistry.getService(CachingESRegistr >>y. >> java:189) [apiman-gateway-engine-es-1.1.9.Final.jar:] >> at >> >>io.apiman.gateway.engine.impl.SecureRegistryWrapper.getService(SecureRegi >>st >> ryWrapper.java:97) [apiman-gateway-engine-core-1.1.9.Final.jar:] >> at >> >>io.apiman.gateway.engine.impl.ServiceRequestExecutorImpl.execute(ServiceR >>eq >> uestExecutorImpl.java:252) [apiman-gateway-engine-core-1.1.9.Final.jar:] >> at >> >>io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServle >>t. >> java:236) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >> at >> >>io.apiman.gateway.platforms.servlet.GatewayServlet.doGet(GatewayServlet.j >>av >> a:82) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) >> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >> at >> >>io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler. >>ja >> va:86) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >> at >> >>io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRe >>qu >> est(ServletSecurityRoleHandler.java:62) >> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >> at >> >>io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(Serv >>le >> tDispatchingHandler.java:36) >>[undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >> at >> >>org.wildfly.extension.undertow.security.SecurityContextAssociationHandler >>.h >> andleRequest(SecurityContextAssociationHandler.java:78) >> at >> >>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl >>er >> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >> at >> >>io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.ha >>nd >> leRequest(SSLInformationAssociationHandler.java:131) >> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >> at >> >>io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.ha >>nd >> leRequest(ServletAuthenticationCallHandler.java:57) >> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >> at >> >>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl >>er >> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >> at >> >>io.undertow.security.handlers.AbstractConfidentialityHandler.handleReques >>t( >> AbstractConfidentialityHandler.java:46) >> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >> at >> >>io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHan >>dl >> er.handleRequest(ServletConfidentialityConstraintHandler.java:64) >> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >> at >> >>io.undertow.security.handlers.AuthenticationMechanismsHandler.handleReque >>st >> (AuthenticationMechanismsHandler.java:58) >> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >> at >> >>io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.h >>an >> dleRequest(CachedAuthenticatedSessionHandler.java:70) >> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >> at >> >>io.undertow.security.handlers.SecurityInitialHandler.handleRequest(Securi >>ty >> InitialHandler.java:76) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >> at >> >>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl >>er >> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >> at >> >>org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleR >>eq >> uest(JACCContextIdHandler.java:61) >> at >> >>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl >>er >> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >> at >> >>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl >>er >> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >> at >> >>io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(Ser >>vl >> etInitialHandler.java:261) >>[undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >> at >> >>io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(Servle >>tI >> nitialHandler.java:248) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >> at >> >>io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInit >>ia >> lHandler.java:77) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >> at >> >>io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(Servle >>tI >> nitialHandler.java:167) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >> at >>io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) >> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >> at >> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:761) >> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >> at >> >>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java >>:1 >> 142) [rt.jar:1.8.0_25] >> at >> >>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.jav >>a: >> 617) [rt.jar:1.8.0_25] >> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25] >> Caused by: org.apache.http.NoHttpResponseException: >> search-testapi-....us-west-2.es.amazonaws.com:443 failed to respond >> at >> >>org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttp >>Re >> sponseParser.java:143) [httpclient-4.5.jar:4.5] >> at >> >>org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttp >>Re >> sponseParser.java:57) [httpclient-4.5.jar:4.5] >> at >> >>org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser >>.j >> ava:261) [httpcore-4.4.1.jar:4.4.1] >> at >> >>org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(D >>ef >> aultBHttpClientConnection.java:165) [httpcore-4.4.1.jar:4.4.1] >> at >> >>org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.jav >>a: >> 167) [httpclient-4.5.jar:4.5] >> at >> >>org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpReques >>tE >> xecutor.java:272) [httpcore-4.4.1.jar:4.4.1] >> at >> >>org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor. >>ja >> va:124) [httpcore-4.4.1.jar:4.4.1] >> at >> >>org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java >>:2 >> 71) [httpclient-4.5.jar:4.5] >> at >> >>org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184 >>) >> [httpclient-4.5.jar:4.5] >> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) >> [httpclient-4.5.jar:4.5] >> at >> >>org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110 >>) >> [httpclient-4.5.jar:4.5] >> at >> >>org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClie >>nt >> .java:184) [httpclient-4.5.jar:4.5] >> at >> >>org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClie >>nt >> .java:82) [httpclient-4.5.jar:4.5] >> at >> >>org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClie >>nt >> .java:107) [httpclient-4.5.jar:4.5] >> at >> io.searchbox.client.http.JestHttpClient.execute(JestHttpClient.java:50) >> [jest-0.1.6.jar:] >> at >> >>io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClientFact >>or >> y.java:193) [apiman-gateway-engine-es-1.1.9.Final.jar:] >> ... 39 more >> >> >> >> >> >> On 12/8/15, 11:48 AM, "Eric Wittmann" wrote: >> >>> You definitely need to set the protocol to 'https', for the record. >>> Beyond that I'm not quite sure. Do you have a full stack trace or just >>> that part of it? >>> >>> On 12/8/2015 11:19 AM, Paul Blair wrote: >>>> Not quite sure what to make of this: I'm getting >>>> >>>> org.apache.http.NoHttpResponseException: [endpoint_URI]:443 >>>>failed >>>> to respond >>>> >>>> But if I do: >>>> >>>> curl https://[endpont_URI]:443 >>>> >>>> I get a response from Elasticsearch?this is because I have the Amazon >>>> Elasticsearch instance permissioned to accept any connections from the >>>> IP address where apiman is running. >>>> >>>> The apiman configurations look like this: >>>> >>>> apiman.es.protocol=http >>>> apiman.es.host=[endpoint_URI] >>>> apiman.es.port=443 >>>> apiman.es.username= >>>> apiman.es.password= >>>> >>>> Changing protocol from http to https doesn't appear to help, nor does >>>> removing the username and password properties entirely. Any >>>>suggestions? >>>> >>>> >>>> _______________________________________________ >>>> 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 Dec 8 12:30:11 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 8 Dec 2015 12:30:11 -0500 Subject: [Apiman-user] Having trouble connecting to Amazon Elasticsearch service In-Reply-To: References: Message-ID: <566713A3.9040009@redhat.com> Nope - I was worried that you were using 2.x, which we do not currently support. Do you happen to have any instructions handy for setting up an AMZ elasticsearch instance so I can try to reproduce this error? On 12/8/2015 12:28 PM, Paul Blair wrote: > Amazon says their current version is 1.5.2. Does apiman require version > 2.x? > > On 12/8/15, 12:21 PM, "Eric Wittmann" wrote: > >> What version of elasticsearch are you using? >> >> On 12/8/2015 12:12 PM, Paul Blair wrote: >>> The stack trace is below. Note that the instance seems to start fine; >>> it's >>> only when I make a request to the Gateway that I get this error. >>> >>> Thanks! >>> >>> 16:18:04,746 ERROR [io.undertow.request] (default task-1) UT005023: >>> Exception handling request to /apiman-gateway/test_api/1.7: >>> java.lang.RuntimeException: org.apache.http.NoHttpResponseException: >>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to respond >>> at >>> >>> io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClientFact >>> or >>> y.java:200) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>> at >>> >>> io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClientFact >>> or >>> y.java:140) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>> at >>> >>> io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClientFact >>> or >>> y.java:101) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>> at >>> >>> io.apiman.gateway.engine.es.ESClientFactory.createClient(ESClientFactory. >>> ja >>> va:66) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>> at >>> >>> io.apiman.gateway.engine.es.AbstractESComponent.getClient(AbstractESCompo >>> ne >>> nt.java:45) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>> at >>> io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:315) >>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>> at >>> io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:304) >>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>> at >>> >>> io.apiman.gateway.engine.es.CachingESRegistry.getService(CachingESRegistr >>> y. >>> java:189) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>> at >>> >>> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getService(SecureRegi >>> st >>> ryWrapper.java:97) [apiman-gateway-engine-core-1.1.9.Final.jar:] >>> at >>> >>> io.apiman.gateway.engine.impl.ServiceRequestExecutorImpl.execute(ServiceR >>> eq >>> uestExecutorImpl.java:252) [apiman-gateway-engine-core-1.1.9.Final.jar:] >>> at >>> >>> io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServle >>> t. >>> java:236) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>> at >>> >>> io.apiman.gateway.platforms.servlet.GatewayServlet.doGet(GatewayServlet.j >>> av >>> a:82) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) >>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>> at >>> >>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler. >>> ja >>> va:86) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>> at >>> >>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRe >>> qu >>> est(ServletSecurityRoleHandler.java:62) >>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>> at >>> >>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(Serv >>> le >>> tDispatchingHandler.java:36) >>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>> at >>> >>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler >>> .h >>> andleRequest(SecurityContextAssociationHandler.java:78) >>> at >>> >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl >>> er >>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>> at >>> >>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.ha >>> nd >>> leRequest(SSLInformationAssociationHandler.java:131) >>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>> at >>> >>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.ha >>> nd >>> leRequest(ServletAuthenticationCallHandler.java:57) >>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>> at >>> >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl >>> er >>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>> at >>> >>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleReques >>> t( >>> AbstractConfidentialityHandler.java:46) >>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>> at >>> >>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHan >>> dl >>> er.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>> at >>> >>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleReque >>> st >>> (AuthenticationMechanismsHandler.java:58) >>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>> at >>> >>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.h >>> an >>> dleRequest(CachedAuthenticatedSessionHandler.java:70) >>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>> at >>> >>> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(Securi >>> ty >>> InitialHandler.java:76) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>> at >>> >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl >>> er >>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>> at >>> >>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleR >>> eq >>> uest(JACCContextIdHandler.java:61) >>> at >>> >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl >>> er >>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>> at >>> >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl >>> er >>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>> at >>> >>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(Ser >>> vl >>> etInitialHandler.java:261) >>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>> at >>> >>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(Servle >>> tI >>> nitialHandler.java:248) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>> at >>> >>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInit >>> ia >>> lHandler.java:77) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>> at >>> >>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(Servle >>> tI >>> nitialHandler.java:167) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>> at >>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) >>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>> at >>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:761) >>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>> at >>> >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java >>> :1 >>> 142) [rt.jar:1.8.0_25] >>> at >>> >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.jav >>> a: >>> 617) [rt.jar:1.8.0_25] >>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25] >>> Caused by: org.apache.http.NoHttpResponseException: >>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to respond >>> at >>> >>> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttp >>> Re >>> sponseParser.java:143) [httpclient-4.5.jar:4.5] >>> at >>> >>> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttp >>> Re >>> sponseParser.java:57) [httpclient-4.5.jar:4.5] >>> at >>> >>> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser >>> .j >>> ava:261) [httpcore-4.4.1.jar:4.4.1] >>> at >>> >>> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(D >>> ef >>> aultBHttpClientConnection.java:165) [httpcore-4.4.1.jar:4.4.1] >>> at >>> >>> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.jav >>> a: >>> 167) [httpclient-4.5.jar:4.5] >>> at >>> >>> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpReques >>> tE >>> xecutor.java:272) [httpcore-4.4.1.jar:4.4.1] >>> at >>> >>> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor. >>> ja >>> va:124) [httpcore-4.4.1.jar:4.4.1] >>> at >>> >>> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java >>> :2 >>> 71) [httpclient-4.5.jar:4.5] >>> at >>> >>> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184 >>> ) >>> [httpclient-4.5.jar:4.5] >>> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) >>> [httpclient-4.5.jar:4.5] >>> at >>> >>> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110 >>> ) >>> [httpclient-4.5.jar:4.5] >>> at >>> >>> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClie >>> nt >>> .java:184) [httpclient-4.5.jar:4.5] >>> at >>> >>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClie >>> nt >>> .java:82) [httpclient-4.5.jar:4.5] >>> at >>> >>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClie >>> nt >>> .java:107) [httpclient-4.5.jar:4.5] >>> at >>> io.searchbox.client.http.JestHttpClient.execute(JestHttpClient.java:50) >>> [jest-0.1.6.jar:] >>> at >>> >>> io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClientFact >>> or >>> y.java:193) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>> ... 39 more >>> >>> >>> >>> >>> >>> On 12/8/15, 11:48 AM, "Eric Wittmann" wrote: >>> >>>> You definitely need to set the protocol to 'https', for the record. >>>> Beyond that I'm not quite sure. Do you have a full stack trace or just >>>> that part of it? >>>> >>>> On 12/8/2015 11:19 AM, Paul Blair wrote: >>>>> Not quite sure what to make of this: I'm getting >>>>> >>>>> org.apache.http.NoHttpResponseException: [endpoint_URI]:443 >>>>> failed >>>>> to respond >>>>> >>>>> But if I do: >>>>> >>>>> curl https://[endpont_URI]:443 >>>>> >>>>> I get a response from Elasticsearch?this is because I have the Amazon >>>>> Elasticsearch instance permissioned to accept any connections from the >>>>> IP address where apiman is running. >>>>> >>>>> The apiman configurations look like this: >>>>> >>>>> apiman.es.protocol=http >>>>> apiman.es.host=[endpoint_URI] >>>>> apiman.es.port=443 >>>>> apiman.es.username= >>>>> apiman.es.password= >>>>> >>>>> Changing protocol from http to https doesn't appear to help, nor does >>>>> removing the username and password properties entirely. Any >>>>> suggestions? >>>>> >>>>> >>>>> _______________________________________________ >>>>> Apiman-user mailing list >>>>> Apiman-user at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>>> >>> > From ton at finalist.nl Tue Dec 8 13:00:18 2015 From: ton at finalist.nl (Ton Swieb) Date: Tue, 8 Dec 2015 19:00:18 +0100 Subject: [Apiman-user] Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password (Marc Savy) Message-ID: Hi Marc, I am using the following setup: 1. Client -> Keycloak (apiman realm) -> SAML 2.0 IdP -> Keycloak (apiman realm) -> Client 2. Client -> apiman gateway -> Keycloak OAuth policy -> back-end -> apiman gateway -> Client The IdP is a SAML 2.0 IdP. I believe it is SimpleSAMLPHP. It is unclear to me why it matters which IdP I am using, because my assumption is that: - I end up with a valid Keycloak session within the apiman realm - the SAML 2.0 token should only be used by Keycloak to issue a login session to the client. - the client itself will never directly use anyhting from the SAML 2.0 IdP, but should only use the stuff that Keycloak mapped from the SAML token onto its own token. I did ask the question on the keycloak mailinglist, but from a different angle. I am afraid the solution for my problem will be somewhere in between. Any help from your site is greatly appreciated :-) Regards, Ton Message: 5 Date: Tue, 8 Dec 2015 16:58:26 +0000 From: Marc Savy Subject: Re: [Apiman-user] Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password To: apiman-user at lists.jboss.org Message-ID: <56670C32.3060000 at redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed To expand on that - depending on exactly what type of IdP (and specifically which technology) you were delegating to, it may be possible to do what you're asking - or you may need to write something custom. Can you provide more detail? Also, if you have very specific Keycloak questions you might be best served on the keycloak-user mailing list, which is extremely active ( https://lists.jboss.org/mailman/listinfo/keycloak-user). On 08/12/2015 16:53, Marc Savy wrote: > Hi Ton, > > I'm not quite sure what you mean, but I think what you're asking for is > brokerage/delegation in the form: > > 1. Client <-> Keycloak <-> Other IdP. > 2. Client <-> apiman gateway > > Regards, > Marc > > On 08/12/2015 15:28, Ton Swieb wrote: > > Hi, > > > > I would like to secure my api's using the Keycloak OAuth2 policy. > > Similair to what is described in the blog post of Marc Savy: > > http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html > > > > > > Only with the difference that Keycloak delegates the login to a third > > party IdP. After logging in at this third party IdP I end up with an > > active session in the Apiman UI (the apiman realm of Keycloak). > > > > Now I am wondering how to get the bearer token, because I do not have a > > username/password combination I can use to make a call like: > > > > |curl -X POST > > http://127.0.0.1:8080/auth/realms/stottie/protocol/openid-connect/token > > -H "Content-Type: application/x-www-form-urlencoded" -d > > "username=rincewind" -d 'password=apiman' -d 'grant_type=password' -d > > 'client_id=apiman'| > > > > Because the username/password combination is linked to the third party > > IdP and not to Keycloak itself. > > > > Is there another way to obtain the bearer token? > > > > Perhaps this is aquestion which I should address at the keycloak > > mailinglist. I will try to ask the question there as well. > > > > 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/20151208/cae3a695/attachment.html From pblair at clearme.com Tue Dec 8 13:13:26 2015 From: pblair at clearme.com (Paul Blair) Date: Tue, 8 Dec 2015 18:13:26 +0000 Subject: [Apiman-user] Having trouble connecting to Amazon Elasticsearch service In-Reply-To: <566713A3.9040009@redhat.com> Message-ID: It isn't too complicated -- I started here https://aws.amazon.com/elasticsearch-service/ Basically you find "Elasticsearch Service" under the "Analytics" section of the AWS dashboard, hit the "Create a new domain" button, and follow the instructions. My access policy looks like this: { "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:*", "Resource": "arn:aws:es:us-west-2[ARN]/*", "Condition": { "IpAddress": { "aws:SourceIp": [ "[IP ADDRESS 1]", "[CIDR BLOCK 2]",... ] } } } ] } On 12/8/15, 12:30 PM, "Eric Wittmann" wrote: >Nope - I was worried that you were using 2.x, which we do not currently >support. > >Do you happen to have any instructions handy for setting up an AMZ >elasticsearch instance so I can try to reproduce this error? > >On 12/8/2015 12:28 PM, Paul Blair wrote: >> Amazon says their current version is 1.5.2. Does apiman require version >> 2.x? >> >> On 12/8/15, 12:21 PM, "Eric Wittmann" wrote: >> >>> What version of elasticsearch are you using? >>> >>> On 12/8/2015 12:12 PM, Paul Blair wrote: >>>> The stack trace is below. Note that the instance seems to start fine; >>>> it's >>>> only when I make a request to the Gateway that I get this error. >>>> >>>> Thanks! >>>> >>>> 16:18:04,746 ERROR [io.undertow.request] (default task-1) UT005023: >>>> Exception handling request to /apiman-gateway/test_api/1.7: >>>> java.lang.RuntimeException: org.apache.http.NoHttpResponseException: >>>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to respond >>>> at >>>> >>>> >>>>io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClientFa >>>>ct >>>> or >>>> y.java:200) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>> at >>>> >>>> >>>>io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClientFa >>>>ct >>>> or >>>> y.java:140) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>> at >>>> >>>> >>>>io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClientFa >>>>ct >>>> or >>>> y.java:101) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>> at >>>> >>>> >>>>io.apiman.gateway.engine.es.ESClientFactory.createClient(ESClientFactor >>>>y. >>>> ja >>>> va:66) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>> at >>>> >>>> >>>>io.apiman.gateway.engine.es.AbstractESComponent.getClient(AbstractESCom >>>>po >>>> ne >>>> nt.java:45) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>> at >>>> io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:315) >>>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>> at >>>> io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:304) >>>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>> at >>>> >>>> >>>>io.apiman.gateway.engine.es.CachingESRegistry.getService(CachingESRegis >>>>tr >>>> y. >>>> java:189) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>> at >>>> >>>> >>>>io.apiman.gateway.engine.impl.SecureRegistryWrapper.getService(SecureRe >>>>gi >>>> st >>>> ryWrapper.java:97) [apiman-gateway-engine-core-1.1.9.Final.jar:] >>>> at >>>> >>>> >>>>io.apiman.gateway.engine.impl.ServiceRequestExecutorImpl.execute(Servic >>>>eR >>>> eq >>>> uestExecutorImpl.java:252) >>>>[apiman-gateway-engine-core-1.1.9.Final.jar:] >>>> at >>>> >>>> >>>>io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServ >>>>le >>>> t. >>>> java:236) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>>> at >>>> >>>> >>>>io.apiman.gateway.platforms.servlet.GatewayServlet.doGet(GatewayServlet >>>>.j >>>> av >>>> a:82) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) >>>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>>> at >>>> >>>> >>>>io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandle >>>>r. >>>> ja >>>> va:86) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>> at >>>> >>>> >>>>io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handle >>>>Re >>>> qu >>>> est(ServletSecurityRoleHandler.java:62) >>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>> at >>>> >>>> >>>>io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(Se >>>>rv >>>> le >>>> tDispatchingHandler.java:36) >>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>> at >>>> >>>> >>>>org.wildfly.extension.undertow.security.SecurityContextAssociationHandl >>>>er >>>> .h >>>> andleRequest(SecurityContextAssociationHandler.java:78) >>>> at >>>> >>>> >>>>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHan >>>>dl >>>> er >>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>> at >>>> >>>> >>>>io.undertow.servlet.handlers.security.SSLInformationAssociationHandler. >>>>ha >>>> nd >>>> leRequest(SSLInformationAssociationHandler.java:131) >>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>> at >>>> >>>> >>>>io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler. >>>>ha >>>> nd >>>> leRequest(ServletAuthenticationCallHandler.java:57) >>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>> at >>>> >>>> >>>>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHan >>>>dl >>>> er >>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>> at >>>> >>>> >>>>io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequ >>>>es >>>> t( >>>> AbstractConfidentialityHandler.java:46) >>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>> at >>>> >>>> >>>>io.undertow.servlet.handlers.security.ServletConfidentialityConstraintH >>>>an >>>> dl >>>> er.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>> at >>>> >>>> >>>>io.undertow.security.handlers.AuthenticationMechanismsHandler.handleReq >>>>ue >>>> st >>>> (AuthenticationMechanismsHandler.java:58) >>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>> at >>>> >>>> >>>>io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler >>>>.h >>>> an >>>> dleRequest(CachedAuthenticatedSessionHandler.java:70) >>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>> at >>>> >>>> >>>>io.undertow.security.handlers.SecurityInitialHandler.handleRequest(Secu >>>>ri >>>> ty >>>> InitialHandler.java:76) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>> at >>>> >>>> >>>>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHan >>>>dl >>>> er >>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>> at >>>> >>>> >>>>org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handl >>>>eR >>>> eq >>>> uest(JACCContextIdHandler.java:61) >>>> at >>>> >>>> >>>>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHan >>>>dl >>>> er >>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>> at >>>> >>>> >>>>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHan >>>>dl >>>> er >>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>> at >>>> >>>> >>>>io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(S >>>>er >>>> vl >>>> etInitialHandler.java:261) >>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>> at >>>> >>>> >>>>io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(Serv >>>>le >>>> tI >>>> nitialHandler.java:248) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>> at >>>> >>>> >>>>io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletIn >>>>it >>>> ia >>>> lHandler.java:77) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>> at >>>> >>>> >>>>io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(Serv >>>>le >>>> tI >>>> nitialHandler.java:167) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>> at >>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) >>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>> at >>>> >>>>io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:761 >>>>) >>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>> at >>>> >>>> >>>>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.ja >>>>va >>>> :1 >>>> 142) [rt.jar:1.8.0_25] >>>> at >>>> >>>> >>>>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j >>>>av >>>> a: >>>> 617) [rt.jar:1.8.0_25] >>>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25] >>>> Caused by: org.apache.http.NoHttpResponseException: >>>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to respond >>>> at >>>> >>>> >>>>org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHt >>>>tp >>>> Re >>>> sponseParser.java:143) [httpclient-4.5.jar:4.5] >>>> at >>>> >>>> >>>>org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHt >>>>tp >>>> Re >>>> sponseParser.java:57) [httpclient-4.5.jar:4.5] >>>> at >>>> >>>> >>>>org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessagePars >>>>er >>>> .j >>>> ava:261) [httpcore-4.4.1.jar:4.4.1] >>>> at >>>> >>>> >>>>org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader >>>>(D >>>> ef >>>> aultBHttpClientConnection.java:165) [httpcore-4.4.1.jar:4.4.1] >>>> at >>>> >>>> >>>>org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.j >>>>av >>>> a: >>>> 167) [httpclient-4.5.jar:4.5] >>>> at >>>> >>>> >>>>org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequ >>>>es >>>> tE >>>> xecutor.java:272) [httpcore-4.4.1.jar:4.4.1] >>>> at >>>> >>>> >>>>org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecuto >>>>r. >>>> ja >>>> va:124) [httpcore-4.4.1.jar:4.4.1] >>>> at >>>> >>>> >>>>org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.ja >>>>va >>>> :2 >>>> 71) [httpclient-4.5.jar:4.5] >>>> at >>>> >>>> >>>>org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:1 >>>>84 >>>> ) >>>> [httpclient-4.5.jar:4.5] >>>> at >>>>org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) >>>> [httpclient-4.5.jar:4.5] >>>> at >>>> >>>> >>>>org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:1 >>>>10 >>>> ) >>>> [httpclient-4.5.jar:4.5] >>>> at >>>> >>>> >>>>org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpCl >>>>ie >>>> nt >>>> .java:184) [httpclient-4.5.jar:4.5] >>>> at >>>> >>>> >>>>org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpCl >>>>ie >>>> nt >>>> .java:82) [httpclient-4.5.jar:4.5] >>>> at >>>> >>>> >>>>org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpCl >>>>ie >>>> nt >>>> .java:107) [httpclient-4.5.jar:4.5] >>>> at >>>> >>>>io.searchbox.client.http.JestHttpClient.execute(JestHttpClient.java:50) >>>> [jest-0.1.6.jar:] >>>> at >>>> >>>> >>>>io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClientFa >>>>ct >>>> or >>>> y.java:193) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>> ... 39 more >>>> >>>> >>>> >>>> >>>> >>>> On 12/8/15, 11:48 AM, "Eric Wittmann" >>>>wrote: >>>> >>>>> You definitely need to set the protocol to 'https', for the record. >>>>> Beyond that I'm not quite sure. Do you have a full stack trace or >>>>>just >>>>> that part of it? >>>>> >>>>> On 12/8/2015 11:19 AM, Paul Blair wrote: >>>>>> Not quite sure what to make of this: I'm getting >>>>>> >>>>>> org.apache.http.NoHttpResponseException: [endpoint_URI]:443 >>>>>> failed >>>>>> to respond >>>>>> >>>>>> But if I do: >>>>>> >>>>>> curl https://[endpont_URI]:443 >>>>>> >>>>>> I get a response from Elasticsearch?this is because I have the >>>>>>Amazon >>>>>> Elasticsearch instance permissioned to accept any connections from >>>>>>the >>>>>> IP address where apiman is running. >>>>>> >>>>>> The apiman configurations look like this: >>>>>> >>>>>> apiman.es.protocol=http >>>>>> apiman.es.host=[endpoint_URI] >>>>>> apiman.es.port=443 >>>>>> apiman.es.username= >>>>>> apiman.es.password= >>>>>> >>>>>> Changing protocol from http to https doesn't appear to help, nor >>>>>>does >>>>>> removing the username and password properties entirely. Any >>>>>> suggestions? >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 Dec 8 14:14:13 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 8 Dec 2015 14:14:13 -0500 Subject: [Apiman-user] Having trouble connecting to Amazon Elasticsearch service In-Reply-To: References: Message-ID: <56672C05.3040505@redhat.com> OK thanks - I'll try to reproduce this soon. -Eric On 12/8/2015 1:13 PM, Paul Blair wrote: > It isn't too complicated -- I started here > https://aws.amazon.com/elasticsearch-service/ > > Basically you find "Elasticsearch Service" under the "Analytics" section > of the AWS dashboard, hit the "Create a new domain" button, and follow the > instructions. > > My access policy looks like this: > > { > "Version": "2012-10-17", > "Statement": [ > { > "Sid": "", > "Effect": "Allow", > "Principal": { > "AWS": "*" > }, > "Action": "es:*", > "Resource": "arn:aws:es:us-west-2[ARN]/*", > "Condition": { > "IpAddress": { > "aws:SourceIp": [ > "[IP ADDRESS 1]", "[CIDR BLOCK 2]",... > ] > } > } > } > ] > } > > > > On 12/8/15, 12:30 PM, "Eric Wittmann" wrote: > >> Nope - I was worried that you were using 2.x, which we do not currently >> support. >> >> Do you happen to have any instructions handy for setting up an AMZ >> elasticsearch instance so I can try to reproduce this error? >> >> On 12/8/2015 12:28 PM, Paul Blair wrote: >>> Amazon says their current version is 1.5.2. Does apiman require version >>> 2.x? >>> >>> On 12/8/15, 12:21 PM, "Eric Wittmann" wrote: >>> >>>> What version of elasticsearch are you using? >>>> >>>> On 12/8/2015 12:12 PM, Paul Blair wrote: >>>>> The stack trace is below. Note that the instance seems to start fine; >>>>> it's >>>>> only when I make a request to the Gateway that I get this error. >>>>> >>>>> Thanks! >>>>> >>>>> 16:18:04,746 ERROR [io.undertow.request] (default task-1) UT005023: >>>>> Exception handling request to /apiman-gateway/test_api/1.7: >>>>> java.lang.RuntimeException: org.apache.http.NoHttpResponseException: >>>>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to respond >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClientFa >>>>> ct >>>>> or >>>>> y.java:200) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClientFa >>>>> ct >>>>> or >>>>> y.java:140) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClientFa >>>>> ct >>>>> or >>>>> y.java:101) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.es.ESClientFactory.createClient(ESClientFactor >>>>> y. >>>>> ja >>>>> va:66) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.es.AbstractESComponent.getClient(AbstractESCom >>>>> po >>>>> ne >>>>> nt.java:45) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:315) >>>>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:304) >>>>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.es.CachingESRegistry.getService(CachingESRegis >>>>> tr >>>>> y. >>>>> java:189) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getService(SecureRe >>>>> gi >>>>> st >>>>> ryWrapper.java:97) [apiman-gateway-engine-core-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.impl.ServiceRequestExecutorImpl.execute(Servic >>>>> eR >>>>> eq >>>>> uestExecutorImpl.java:252) >>>>> [apiman-gateway-engine-core-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServ >>>>> le >>>>> t. >>>>> java:236) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.platforms.servlet.GatewayServlet.doGet(GatewayServlet >>>>> .j >>>>> av >>>>> a:82) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) >>>>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandle >>>>> r. >>>>> ja >>>>> va:86) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handle >>>>> Re >>>>> qu >>>>> est(ServletSecurityRoleHandler.java:62) >>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(Se >>>>> rv >>>>> le >>>>> tDispatchingHandler.java:36) >>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandl >>>>> er >>>>> .h >>>>> andleRequest(SecurityContextAssociationHandler.java:78) >>>>> at >>>>> >>>>> >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHan >>>>> dl >>>>> er >>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler. >>>>> ha >>>>> nd >>>>> leRequest(SSLInformationAssociationHandler.java:131) >>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler. >>>>> ha >>>>> nd >>>>> leRequest(ServletAuthenticationCallHandler.java:57) >>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHan >>>>> dl >>>>> er >>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequ >>>>> es >>>>> t( >>>>> AbstractConfidentialityHandler.java:46) >>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintH >>>>> an >>>>> dl >>>>> er.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleReq >>>>> ue >>>>> st >>>>> (AuthenticationMechanismsHandler.java:58) >>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler >>>>> .h >>>>> an >>>>> dleRequest(CachedAuthenticatedSessionHandler.java:70) >>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(Secu >>>>> ri >>>>> ty >>>>> InitialHandler.java:76) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHan >>>>> dl >>>>> er >>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handl >>>>> eR >>>>> eq >>>>> uest(JACCContextIdHandler.java:61) >>>>> at >>>>> >>>>> >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHan >>>>> dl >>>>> er >>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHan >>>>> dl >>>>> er >>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(S >>>>> er >>>>> vl >>>>> etInitialHandler.java:261) >>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(Serv >>>>> le >>>>> tI >>>>> nitialHandler.java:248) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletIn >>>>> it >>>>> ia >>>>> lHandler.java:77) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(Serv >>>>> le >>>>> tI >>>>> nitialHandler.java:167) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) >>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:761 >>>>> ) >>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.ja >>>>> va >>>>> :1 >>>>> 142) [rt.jar:1.8.0_25] >>>>> at >>>>> >>>>> >>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j >>>>> av >>>>> a: >>>>> 617) [rt.jar:1.8.0_25] >>>>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25] >>>>> Caused by: org.apache.http.NoHttpResponseException: >>>>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to respond >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHt >>>>> tp >>>>> Re >>>>> sponseParser.java:143) [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHt >>>>> tp >>>>> Re >>>>> sponseParser.java:57) [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessagePars >>>>> er >>>>> .j >>>>> ava:261) [httpcore-4.4.1.jar:4.4.1] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader >>>>> (D >>>>> ef >>>>> aultBHttpClientConnection.java:165) [httpcore-4.4.1.jar:4.4.1] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.j >>>>> av >>>>> a: >>>>> 167) [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequ >>>>> es >>>>> tE >>>>> xecutor.java:272) [httpcore-4.4.1.jar:4.4.1] >>>>> at >>>>> >>>>> >>>>> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecuto >>>>> r. >>>>> ja >>>>> va:124) [httpcore-4.4.1.jar:4.4.1] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.ja >>>>> va >>>>> :2 >>>>> 71) [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:1 >>>>> 84 >>>>> ) >>>>> [httpclient-4.5.jar:4.5] >>>>> at >>>>> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) >>>>> [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:1 >>>>> 10 >>>>> ) >>>>> [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpCl >>>>> ie >>>>> nt >>>>> .java:184) [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpCl >>>>> ie >>>>> nt >>>>> .java:82) [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpCl >>>>> ie >>>>> nt >>>>> .java:107) [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> io.searchbox.client.http.JestHttpClient.execute(JestHttpClient.java:50) >>>>> [jest-0.1.6.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClientFa >>>>> ct >>>>> or >>>>> y.java:193) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> ... 39 more >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 12/8/15, 11:48 AM, "Eric Wittmann" >>>>> wrote: >>>>> >>>>>> You definitely need to set the protocol to 'https', for the record. >>>>>> Beyond that I'm not quite sure. Do you have a full stack trace or >>>>>> just >>>>>> that part of it? >>>>>> >>>>>> On 12/8/2015 11:19 AM, Paul Blair wrote: >>>>>>> Not quite sure what to make of this: I'm getting >>>>>>> >>>>>>> org.apache.http.NoHttpResponseException: [endpoint_URI]:443 >>>>>>> failed >>>>>>> to respond >>>>>>> >>>>>>> But if I do: >>>>>>> >>>>>>> curl https://[endpont_URI]:443 >>>>>>> >>>>>>> I get a response from Elasticsearch?this is because I have the >>>>>>> Amazon >>>>>>> Elasticsearch instance permissioned to accept any connections from >>>>>>> the >>>>>>> IP address where apiman is running. >>>>>>> >>>>>>> The apiman configurations look like this: >>>>>>> >>>>>>> apiman.es.protocol=http >>>>>>> apiman.es.host=[endpoint_URI] >>>>>>> apiman.es.port=443 >>>>>>> apiman.es.username= >>>>>>> apiman.es.password= >>>>>>> >>>>>>> Changing protocol from http to https doesn't appear to help, nor >>>>>>> does >>>>>>> removing the username and password properties entirely. Any >>>>>>> suggestions? >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 Dec 8 14:47:32 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 8 Dec 2015 14:47:32 -0500 Subject: [Apiman-user] Having trouble connecting to Amazon Elasticsearch service In-Reply-To: References: Message-ID: <566733D4.8020708@redhat.com> Update: I have set up ES in AWS without issue. I tested using the latest (master) version of apiman and everything worked fine. The only difference is that I didn't restrict access based on IP address. I'm going to try testing in 1.1.9.Final next. If that works OK then I'll try adding the IP address restriction. -Eric On 12/8/2015 1:13 PM, Paul Blair wrote: > It isn't too complicated -- I started here > https://aws.amazon.com/elasticsearch-service/ > > Basically you find "Elasticsearch Service" under the "Analytics" section > of the AWS dashboard, hit the "Create a new domain" button, and follow the > instructions. > > My access policy looks like this: > > { > "Version": "2012-10-17", > "Statement": [ > { > "Sid": "", > "Effect": "Allow", > "Principal": { > "AWS": "*" > }, > "Action": "es:*", > "Resource": "arn:aws:es:us-west-2[ARN]/*", > "Condition": { > "IpAddress": { > "aws:SourceIp": [ > "[IP ADDRESS 1]", "[CIDR BLOCK 2]",... > ] > } > } > } > ] > } > > > > On 12/8/15, 12:30 PM, "Eric Wittmann" wrote: > >> Nope - I was worried that you were using 2.x, which we do not currently >> support. >> >> Do you happen to have any instructions handy for setting up an AMZ >> elasticsearch instance so I can try to reproduce this error? >> >> On 12/8/2015 12:28 PM, Paul Blair wrote: >>> Amazon says their current version is 1.5.2. Does apiman require version >>> 2.x? >>> >>> On 12/8/15, 12:21 PM, "Eric Wittmann" wrote: >>> >>>> What version of elasticsearch are you using? >>>> >>>> On 12/8/2015 12:12 PM, Paul Blair wrote: >>>>> The stack trace is below. Note that the instance seems to start fine; >>>>> it's >>>>> only when I make a request to the Gateway that I get this error. >>>>> >>>>> Thanks! >>>>> >>>>> 16:18:04,746 ERROR [io.undertow.request] (default task-1) UT005023: >>>>> Exception handling request to /apiman-gateway/test_api/1.7: >>>>> java.lang.RuntimeException: org.apache.http.NoHttpResponseException: >>>>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to respond >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClientFa >>>>> ct >>>>> or >>>>> y.java:200) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClientFa >>>>> ct >>>>> or >>>>> y.java:140) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClientFa >>>>> ct >>>>> or >>>>> y.java:101) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.es.ESClientFactory.createClient(ESClientFactor >>>>> y. >>>>> ja >>>>> va:66) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.es.AbstractESComponent.getClient(AbstractESCom >>>>> po >>>>> ne >>>>> nt.java:45) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:315) >>>>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:304) >>>>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.es.CachingESRegistry.getService(CachingESRegis >>>>> tr >>>>> y. >>>>> java:189) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getService(SecureRe >>>>> gi >>>>> st >>>>> ryWrapper.java:97) [apiman-gateway-engine-core-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.impl.ServiceRequestExecutorImpl.execute(Servic >>>>> eR >>>>> eq >>>>> uestExecutorImpl.java:252) >>>>> [apiman-gateway-engine-core-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServ >>>>> le >>>>> t. >>>>> java:236) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.platforms.servlet.GatewayServlet.doGet(GatewayServlet >>>>> .j >>>>> av >>>>> a:82) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) >>>>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandle >>>>> r. >>>>> ja >>>>> va:86) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handle >>>>> Re >>>>> qu >>>>> est(ServletSecurityRoleHandler.java:62) >>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(Se >>>>> rv >>>>> le >>>>> tDispatchingHandler.java:36) >>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandl >>>>> er >>>>> .h >>>>> andleRequest(SecurityContextAssociationHandler.java:78) >>>>> at >>>>> >>>>> >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHan >>>>> dl >>>>> er >>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler. >>>>> ha >>>>> nd >>>>> leRequest(SSLInformationAssociationHandler.java:131) >>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler. >>>>> ha >>>>> nd >>>>> leRequest(ServletAuthenticationCallHandler.java:57) >>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHan >>>>> dl >>>>> er >>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequ >>>>> es >>>>> t( >>>>> AbstractConfidentialityHandler.java:46) >>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintH >>>>> an >>>>> dl >>>>> er.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleReq >>>>> ue >>>>> st >>>>> (AuthenticationMechanismsHandler.java:58) >>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler >>>>> .h >>>>> an >>>>> dleRequest(CachedAuthenticatedSessionHandler.java:70) >>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(Secu >>>>> ri >>>>> ty >>>>> InitialHandler.java:76) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHan >>>>> dl >>>>> er >>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handl >>>>> eR >>>>> eq >>>>> uest(JACCContextIdHandler.java:61) >>>>> at >>>>> >>>>> >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHan >>>>> dl >>>>> er >>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHan >>>>> dl >>>>> er >>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(S >>>>> er >>>>> vl >>>>> etInitialHandler.java:261) >>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(Serv >>>>> le >>>>> tI >>>>> nitialHandler.java:248) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletIn >>>>> it >>>>> ia >>>>> lHandler.java:77) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(Serv >>>>> le >>>>> tI >>>>> nitialHandler.java:167) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) >>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:761 >>>>> ) >>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.ja >>>>> va >>>>> :1 >>>>> 142) [rt.jar:1.8.0_25] >>>>> at >>>>> >>>>> >>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j >>>>> av >>>>> a: >>>>> 617) [rt.jar:1.8.0_25] >>>>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25] >>>>> Caused by: org.apache.http.NoHttpResponseException: >>>>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to respond >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHt >>>>> tp >>>>> Re >>>>> sponseParser.java:143) [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHt >>>>> tp >>>>> Re >>>>> sponseParser.java:57) [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessagePars >>>>> er >>>>> .j >>>>> ava:261) [httpcore-4.4.1.jar:4.4.1] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader >>>>> (D >>>>> ef >>>>> aultBHttpClientConnection.java:165) [httpcore-4.4.1.jar:4.4.1] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.j >>>>> av >>>>> a: >>>>> 167) [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequ >>>>> es >>>>> tE >>>>> xecutor.java:272) [httpcore-4.4.1.jar:4.4.1] >>>>> at >>>>> >>>>> >>>>> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecuto >>>>> r. >>>>> ja >>>>> va:124) [httpcore-4.4.1.jar:4.4.1] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.ja >>>>> va >>>>> :2 >>>>> 71) [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:1 >>>>> 84 >>>>> ) >>>>> [httpclient-4.5.jar:4.5] >>>>> at >>>>> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) >>>>> [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:1 >>>>> 10 >>>>> ) >>>>> [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpCl >>>>> ie >>>>> nt >>>>> .java:184) [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpCl >>>>> ie >>>>> nt >>>>> .java:82) [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpCl >>>>> ie >>>>> nt >>>>> .java:107) [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> io.searchbox.client.http.JestHttpClient.execute(JestHttpClient.java:50) >>>>> [jest-0.1.6.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClientFa >>>>> ct >>>>> or >>>>> y.java:193) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> ... 39 more >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 12/8/15, 11:48 AM, "Eric Wittmann" >>>>> wrote: >>>>> >>>>>> You definitely need to set the protocol to 'https', for the record. >>>>>> Beyond that I'm not quite sure. Do you have a full stack trace or >>>>>> just >>>>>> that part of it? >>>>>> >>>>>> On 12/8/2015 11:19 AM, Paul Blair wrote: >>>>>>> Not quite sure what to make of this: I'm getting >>>>>>> >>>>>>> org.apache.http.NoHttpResponseException: [endpoint_URI]:443 >>>>>>> failed >>>>>>> to respond >>>>>>> >>>>>>> But if I do: >>>>>>> >>>>>>> curl https://[endpont_URI]:443 >>>>>>> >>>>>>> I get a response from Elasticsearch?this is because I have the >>>>>>> Amazon >>>>>>> Elasticsearch instance permissioned to accept any connections from >>>>>>> the >>>>>>> IP address where apiman is running. >>>>>>> >>>>>>> The apiman configurations look like this: >>>>>>> >>>>>>> apiman.es.protocol=http >>>>>>> apiman.es.host=[endpoint_URI] >>>>>>> apiman.es.port=443 >>>>>>> apiman.es.username= >>>>>>> apiman.es.password= >>>>>>> >>>>>>> Changing protocol from http to https doesn't appear to help, nor >>>>>>> does >>>>>>> removing the username and password properties entirely. Any >>>>>>> suggestions? >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 Dec 8 15:06:12 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 8 Dec 2015 15:06:12 -0500 Subject: [Apiman-user] Having trouble connecting to Amazon Elasticsearch service In-Reply-To: References: Message-ID: <56673834.7090106@redhat.com> Testing using 1.1.9.Final against the AWS instance of elastic was successful. The only thing left for me to try is the access policy. Otherwise everything looks like it's working fine. Here is the relevant section of my apiman.properties file, for reference: apiman.es.protocol=https apiman.es.host=search-apiman-elastic-sarog5jew3xacrec5szeefvdm4.us-east-1.es.amazonaws.com apiman.es.port=443 apiman.es.username= apiman.es.password= Here is some relevant curl output after my simple test: https://gist.github.com/EricWittmann/cc02a9ba6a2dee548a60 -Eric On 12/8/2015 1:13 PM, Paul Blair wrote: > It isn't too complicated -- I started here > https://aws.amazon.com/elasticsearch-service/ > > Basically you find "Elasticsearch Service" under the "Analytics" section > of the AWS dashboard, hit the "Create a new domain" button, and follow the > instructions. > > My access policy looks like this: > > { > "Version": "2012-10-17", > "Statement": [ > { > "Sid": "", > "Effect": "Allow", > "Principal": { > "AWS": "*" > }, > "Action": "es:*", > "Resource": "arn:aws:es:us-west-2[ARN]/*", > "Condition": { > "IpAddress": { > "aws:SourceIp": [ > "[IP ADDRESS 1]", "[CIDR BLOCK 2]",... > ] > } > } > } > ] > } > > > > On 12/8/15, 12:30 PM, "Eric Wittmann" wrote: > >> Nope - I was worried that you were using 2.x, which we do not currently >> support. >> >> Do you happen to have any instructions handy for setting up an AMZ >> elasticsearch instance so I can try to reproduce this error? >> >> On 12/8/2015 12:28 PM, Paul Blair wrote: >>> Amazon says their current version is 1.5.2. Does apiman require version >>> 2.x? >>> >>> On 12/8/15, 12:21 PM, "Eric Wittmann" wrote: >>> >>>> What version of elasticsearch are you using? >>>> >>>> On 12/8/2015 12:12 PM, Paul Blair wrote: >>>>> The stack trace is below. Note that the instance seems to start fine; >>>>> it's >>>>> only when I make a request to the Gateway that I get this error. >>>>> >>>>> Thanks! >>>>> >>>>> 16:18:04,746 ERROR [io.undertow.request] (default task-1) UT005023: >>>>> Exception handling request to /apiman-gateway/test_api/1.7: >>>>> java.lang.RuntimeException: org.apache.http.NoHttpResponseException: >>>>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to respond >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClientFa >>>>> ct >>>>> or >>>>> y.java:200) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClientFa >>>>> ct >>>>> or >>>>> y.java:140) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClientFa >>>>> ct >>>>> or >>>>> y.java:101) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.es.ESClientFactory.createClient(ESClientFactor >>>>> y. >>>>> ja >>>>> va:66) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.es.AbstractESComponent.getClient(AbstractESCom >>>>> po >>>>> ne >>>>> nt.java:45) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:315) >>>>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:304) >>>>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.es.CachingESRegistry.getService(CachingESRegis >>>>> tr >>>>> y. >>>>> java:189) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getService(SecureRe >>>>> gi >>>>> st >>>>> ryWrapper.java:97) [apiman-gateway-engine-core-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.impl.ServiceRequestExecutorImpl.execute(Servic >>>>> eR >>>>> eq >>>>> uestExecutorImpl.java:252) >>>>> [apiman-gateway-engine-core-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServ >>>>> le >>>>> t. >>>>> java:236) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.platforms.servlet.GatewayServlet.doGet(GatewayServlet >>>>> .j >>>>> av >>>>> a:82) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) >>>>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandle >>>>> r. >>>>> ja >>>>> va:86) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handle >>>>> Re >>>>> qu >>>>> est(ServletSecurityRoleHandler.java:62) >>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(Se >>>>> rv >>>>> le >>>>> tDispatchingHandler.java:36) >>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandl >>>>> er >>>>> .h >>>>> andleRequest(SecurityContextAssociationHandler.java:78) >>>>> at >>>>> >>>>> >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHan >>>>> dl >>>>> er >>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler. >>>>> ha >>>>> nd >>>>> leRequest(SSLInformationAssociationHandler.java:131) >>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler. >>>>> ha >>>>> nd >>>>> leRequest(ServletAuthenticationCallHandler.java:57) >>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHan >>>>> dl >>>>> er >>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequ >>>>> es >>>>> t( >>>>> AbstractConfidentialityHandler.java:46) >>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintH >>>>> an >>>>> dl >>>>> er.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleReq >>>>> ue >>>>> st >>>>> (AuthenticationMechanismsHandler.java:58) >>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler >>>>> .h >>>>> an >>>>> dleRequest(CachedAuthenticatedSessionHandler.java:70) >>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(Secu >>>>> ri >>>>> ty >>>>> InitialHandler.java:76) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHan >>>>> dl >>>>> er >>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handl >>>>> eR >>>>> eq >>>>> uest(JACCContextIdHandler.java:61) >>>>> at >>>>> >>>>> >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHan >>>>> dl >>>>> er >>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHan >>>>> dl >>>>> er >>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(S >>>>> er >>>>> vl >>>>> etInitialHandler.java:261) >>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(Serv >>>>> le >>>>> tI >>>>> nitialHandler.java:248) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletIn >>>>> it >>>>> ia >>>>> lHandler.java:77) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(Serv >>>>> le >>>>> tI >>>>> nitialHandler.java:167) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) >>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:761 >>>>> ) >>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>> at >>>>> >>>>> >>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.ja >>>>> va >>>>> :1 >>>>> 142) [rt.jar:1.8.0_25] >>>>> at >>>>> >>>>> >>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j >>>>> av >>>>> a: >>>>> 617) [rt.jar:1.8.0_25] >>>>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25] >>>>> Caused by: org.apache.http.NoHttpResponseException: >>>>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to respond >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHt >>>>> tp >>>>> Re >>>>> sponseParser.java:143) [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHt >>>>> tp >>>>> Re >>>>> sponseParser.java:57) [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessagePars >>>>> er >>>>> .j >>>>> ava:261) [httpcore-4.4.1.jar:4.4.1] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader >>>>> (D >>>>> ef >>>>> aultBHttpClientConnection.java:165) [httpcore-4.4.1.jar:4.4.1] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.j >>>>> av >>>>> a: >>>>> 167) [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequ >>>>> es >>>>> tE >>>>> xecutor.java:272) [httpcore-4.4.1.jar:4.4.1] >>>>> at >>>>> >>>>> >>>>> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecuto >>>>> r. >>>>> ja >>>>> va:124) [httpcore-4.4.1.jar:4.4.1] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.ja >>>>> va >>>>> :2 >>>>> 71) [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:1 >>>>> 84 >>>>> ) >>>>> [httpclient-4.5.jar:4.5] >>>>> at >>>>> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) >>>>> [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:1 >>>>> 10 >>>>> ) >>>>> [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpCl >>>>> ie >>>>> nt >>>>> .java:184) [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpCl >>>>> ie >>>>> nt >>>>> .java:82) [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> >>>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpCl >>>>> ie >>>>> nt >>>>> .java:107) [httpclient-4.5.jar:4.5] >>>>> at >>>>> >>>>> io.searchbox.client.http.JestHttpClient.execute(JestHttpClient.java:50) >>>>> [jest-0.1.6.jar:] >>>>> at >>>>> >>>>> >>>>> io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClientFa >>>>> ct >>>>> or >>>>> y.java:193) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>> ... 39 more >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 12/8/15, 11:48 AM, "Eric Wittmann" >>>>> wrote: >>>>> >>>>>> You definitely need to set the protocol to 'https', for the record. >>>>>> Beyond that I'm not quite sure. Do you have a full stack trace or >>>>>> just >>>>>> that part of it? >>>>>> >>>>>> On 12/8/2015 11:19 AM, Paul Blair wrote: >>>>>>> Not quite sure what to make of this: I'm getting >>>>>>> >>>>>>> org.apache.http.NoHttpResponseException: [endpoint_URI]:443 >>>>>>> failed >>>>>>> to respond >>>>>>> >>>>>>> But if I do: >>>>>>> >>>>>>> curl https://[endpont_URI]:443 >>>>>>> >>>>>>> I get a response from Elasticsearch?this is because I have the >>>>>>> Amazon >>>>>>> Elasticsearch instance permissioned to accept any connections from >>>>>>> the >>>>>>> IP address where apiman is running. >>>>>>> >>>>>>> The apiman configurations look like this: >>>>>>> >>>>>>> apiman.es.protocol=http >>>>>>> apiman.es.host=[endpoint_URI] >>>>>>> apiman.es.port=443 >>>>>>> apiman.es.username= >>>>>>> apiman.es.password= >>>>>>> >>>>>>> Changing protocol from http to https doesn't appear to help, nor >>>>>>> does >>>>>>> removing the username and password properties entirely. Any >>>>>>> suggestions? >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Apiman-user mailing list >>>>>>> Apiman-user at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>>>>> >>>>> >>> > From pblair at clearme.com Tue Dec 8 15:26:42 2015 From: pblair at clearme.com (Paul Blair) Date: Tue, 8 Dec 2015 20:26:42 +0000 Subject: [Apiman-user] Having trouble connecting to Amazon Elasticsearch service In-Reply-To: <56673834.7090106@redhat.com> Message-ID: When you create your domain, is it important what you name it? I named it testapi, so my endpoint looks like search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.amazonaws.com And the domain ARN is then arn:aws:es:us-west-2:577360696927:domain/testapi On 12/8/15, 3:06 PM, "Eric Wittmann" wrote: >Testing using 1.1.9.Final against the AWS instance of elastic was >successful. The only thing left for me to try is the access policy. >Otherwise everything looks like it's working fine. Here is the relevant >section of my apiman.properties file, for reference: > >apiman.es.protocol=https >apiman.es.host=search-apiman-elastic-sarog5jew3xacrec5szeefvdm4.us-east-1. >es.amazonaws.com >apiman.es.port=443 >apiman.es.username= >apiman.es.password= > >Here is some relevant curl output after my simple test: > >https://gist.github.com/EricWittmann/cc02a9ba6a2dee548a60 > >-Eric > >On 12/8/2015 1:13 PM, Paul Blair wrote: >> It isn't too complicated -- I started here >> https://aws.amazon.com/elasticsearch-service/ >> >> Basically you find "Elasticsearch Service" under the "Analytics" section >> of the AWS dashboard, hit the "Create a new domain" button, and follow >>the >> instructions. >> >> My access policy looks like this: >> >> { >> "Version": "2012-10-17", >> "Statement": [ >> { >> "Sid": "", >> "Effect": "Allow", >> "Principal": { >> "AWS": "*" >> }, >> "Action": "es:*", >> "Resource": "arn:aws:es:us-west-2[ARN]/*", >> "Condition": { >> "IpAddress": { >> "aws:SourceIp": [ >> "[IP ADDRESS 1]", "[CIDR BLOCK 2]",... >> ] >> } >> } >> } >> ] >> } >> >> >> >> On 12/8/15, 12:30 PM, "Eric Wittmann" wrote: >> >>> Nope - I was worried that you were using 2.x, which we do not currently >>> support. >>> >>> Do you happen to have any instructions handy for setting up an AMZ >>> elasticsearch instance so I can try to reproduce this error? >>> >>> On 12/8/2015 12:28 PM, Paul Blair wrote: >>>> Amazon says their current version is 1.5.2. Does apiman require >>>>version >>>> 2.x? >>>> >>>> On 12/8/15, 12:21 PM, "Eric Wittmann" >>>>wrote: >>>> >>>>> What version of elasticsearch are you using? >>>>> >>>>> On 12/8/2015 12:12 PM, Paul Blair wrote: >>>>>> The stack trace is below. Note that the instance seems to start >>>>>>fine; >>>>>> it's >>>>>> only when I make a request to the Gateway that I get this error. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> 16:18:04,746 ERROR [io.undertow.request] (default task-1) UT005023: >>>>>> Exception handling request to /apiman-gateway/test_api/1.7: >>>>>> java.lang.RuntimeException: org.apache.http.NoHttpResponseException: >>>>>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to respond >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClient >>>>>>Fa >>>>>> ct >>>>>> or >>>>>> y.java:200) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClient >>>>>>Fa >>>>>> ct >>>>>> or >>>>>> y.java:140) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClient >>>>>>Fa >>>>>> ct >>>>>> or >>>>>> y.java:101) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.apiman.gateway.engine.es.ESClientFactory.createClient(ESClientFact >>>>>>or >>>>>> y. >>>>>> ja >>>>>> va:66) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.apiman.gateway.engine.es.AbstractESComponent.getClient(AbstractESC >>>>>>om >>>>>> po >>>>>> ne >>>>>> nt.java:45) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>> at >>>>>> >>>>>>io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:315 >>>>>>) >>>>>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>> at >>>>>> >>>>>>io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:304 >>>>>>) >>>>>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.apiman.gateway.engine.es.CachingESRegistry.getService(CachingESReg >>>>>>is >>>>>> tr >>>>>> y. >>>>>> java:189) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.apiman.gateway.engine.impl.SecureRegistryWrapper.getService(Secure >>>>>>Re >>>>>> gi >>>>>> st >>>>>> ryWrapper.java:97) [apiman-gateway-engine-core-1.1.9.Final.jar:] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.apiman.gateway.engine.impl.ServiceRequestExecutorImpl.execute(Serv >>>>>>ic >>>>>> eR >>>>>> eq >>>>>> uestExecutorImpl.java:252) >>>>>> [apiman-gateway-engine-core-1.1.9.Final.jar:] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewaySe >>>>>>rv >>>>>> le >>>>>> t. >>>>>> java:236) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.apiman.gateway.platforms.servlet.GatewayServlet.doGet(GatewayServl >>>>>>et >>>>>> .j >>>>>> av >>>>>> a:82) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) >>>>>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHand >>>>>>le >>>>>> r. >>>>>> ja >>>>>> va:86) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.hand >>>>>>le >>>>>> Re >>>>>> qu >>>>>> est(ServletSecurityRoleHandler.java:62) >>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest( >>>>>>Se >>>>>> rv >>>>>> le >>>>>> tDispatchingHandler.java:36) >>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>org.wildfly.extension.undertow.security.SecurityContextAssociationHan >>>>>>dl >>>>>> er >>>>>> .h >>>>>> andleRequest(SecurityContextAssociationHandler.java:78) >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateH >>>>>>an >>>>>> dl >>>>>> er >>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.undertow.servlet.handlers.security.SSLInformationAssociationHandle >>>>>>r. >>>>>> ha >>>>>> nd >>>>>> leRequest(SSLInformationAssociationHandler.java:131) >>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.undertow.servlet.handlers.security.ServletAuthenticationCallHandle >>>>>>r. >>>>>> ha >>>>>> nd >>>>>> leRequest(ServletAuthenticationCallHandler.java:57) >>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateH >>>>>>an >>>>>> dl >>>>>> er >>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.undertow.security.handlers.AbstractConfidentialityHandler.handleRe >>>>>>qu >>>>>> es >>>>>> t( >>>>>> AbstractConfidentialityHandler.java:46) >>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.undertow.servlet.handlers.security.ServletConfidentialityConstrain >>>>>>tH >>>>>> an >>>>>> dl >>>>>> er.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.undertow.security.handlers.AuthenticationMechanismsHandler.handleR >>>>>>eq >>>>>> ue >>>>>> st >>>>>> (AuthenticationMechanismsHandler.java:58) >>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandl >>>>>>er >>>>>> .h >>>>>> an >>>>>> dleRequest(CachedAuthenticatedSessionHandler.java:70) >>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.undertow.security.handlers.SecurityInitialHandler.handleRequest(Se >>>>>>cu >>>>>> ri >>>>>> ty >>>>>> InitialHandler.java:76) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateH >>>>>>an >>>>>> dl >>>>>> er >>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.han >>>>>>dl >>>>>> eR >>>>>> eq >>>>>> uest(JACCContextIdHandler.java:61) >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateH >>>>>>an >>>>>> dl >>>>>> er >>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateH >>>>>>an >>>>>> dl >>>>>> er >>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest >>>>>>(S >>>>>> er >>>>>> vl >>>>>> etInitialHandler.java:261) >>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(Se >>>>>>rv >>>>>> le >>>>>> tI >>>>>> nitialHandler.java:248) >>>>>>[undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.undertow.servlet.handlers.ServletInitialHandler.access$000(Servlet >>>>>>In >>>>>> it >>>>>> ia >>>>>> lHandler.java:77) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(Se >>>>>>rv >>>>>> le >>>>>> tI >>>>>> nitialHandler.java:167) >>>>>>[undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>> at >>>>>> >>>>>>io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) >>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>> at >>>>>> >>>>>> >>>>>>io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:7 >>>>>>61 >>>>>> ) >>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. >>>>>>ja >>>>>> va >>>>>> :1 >>>>>> 142) [rt.jar:1.8.0_25] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor >>>>>>.j >>>>>> av >>>>>> a: >>>>>> 617) [rt.jar:1.8.0_25] >>>>>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25] >>>>>> Caused by: org.apache.http.NoHttpResponseException: >>>>>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to respond >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(Default >>>>>>Ht >>>>>> tp >>>>>> Re >>>>>> sponseParser.java:143) [httpclient-4.5.jar:4.5] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(Default >>>>>>Ht >>>>>> tp >>>>>> Re >>>>>> sponseParser.java:57) [httpclient-4.5.jar:4.5] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessagePa >>>>>>rs >>>>>> er >>>>>> .j >>>>>> ava:261) [httpcore-4.4.1.jar:4.4.1] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHead >>>>>>er >>>>>> (D >>>>>> ef >>>>>> aultBHttpClientConnection.java:165) [httpcore-4.4.1.jar:4.4.1] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy >>>>>>.j >>>>>> av >>>>>> a: >>>>>> 167) [httpclient-4.5.jar:4.5] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRe >>>>>>qu >>>>>> es >>>>>> tE >>>>>> xecutor.java:272) [httpcore-4.4.1.jar:4.4.1] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecu >>>>>>to >>>>>> r. >>>>>> ja >>>>>> va:124) [httpcore-4.4.1.jar:4.4.1] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec. >>>>>>ja >>>>>> va >>>>>> :2 >>>>>> 71) [httpclient-4.5.jar:4.5] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java >>>>>>:1 >>>>>> 84 >>>>>> ) >>>>>> [httpclient-4.5.jar:4.5] >>>>>> at >>>>>> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) >>>>>> [httpclient-4.5.jar:4.5] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java >>>>>>:1 >>>>>> 10 >>>>>> ) >>>>>> [httpclient-4.5.jar:4.5] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttp >>>>>>Cl >>>>>> ie >>>>>> nt >>>>>> .java:184) [httpclient-4.5.jar:4.5] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttp >>>>>>Cl >>>>>> ie >>>>>> nt >>>>>> .java:82) [httpclient-4.5.jar:4.5] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttp >>>>>>Cl >>>>>> ie >>>>>> nt >>>>>> .java:107) [httpclient-4.5.jar:4.5] >>>>>> at >>>>>> >>>>>> >>>>>>io.searchbox.client.http.JestHttpClient.execute(JestHttpClient.java:5 >>>>>>0) >>>>>> [jest-0.1.6.jar:] >>>>>> at >>>>>> >>>>>> >>>>>> >>>>>>io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClient >>>>>>Fa >>>>>> ct >>>>>> or >>>>>> y.java:193) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>> ... 39 more >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 12/8/15, 11:48 AM, "Eric Wittmann" >>>>>> wrote: >>>>>> >>>>>>> You definitely need to set the protocol to 'https', for the record. >>>>>>> Beyond that I'm not quite sure. Do you have a full stack trace or >>>>>>> just >>>>>>> that part of it? >>>>>>> >>>>>>> On 12/8/2015 11:19 AM, Paul Blair wrote: >>>>>>>> Not quite sure what to make of this: I'm getting >>>>>>>> >>>>>>>> org.apache.http.NoHttpResponseException: >>>>>>>>[endpoint_URI]:443 >>>>>>>> failed >>>>>>>> to respond >>>>>>>> >>>>>>>> But if I do: >>>>>>>> >>>>>>>> curl https://[endpont_URI]:443 >>>>>>>> >>>>>>>> I get a response from Elasticsearch?this is because I have the >>>>>>>> Amazon >>>>>>>> Elasticsearch instance permissioned to accept any connections from >>>>>>>> the >>>>>>>> IP address where apiman is running. >>>>>>>> >>>>>>>> The apiman configurations look like this: >>>>>>>> >>>>>>>> apiman.es.protocol=http >>>>>>>> apiman.es.host=[endpoint_URI] >>>>>>>> apiman.es.port=443 >>>>>>>> apiman.es.username= >>>>>>>> apiman.es.password= >>>>>>>> >>>>>>>> Changing protocol from http to https doesn't appear to help, nor >>>>>>>> does >>>>>>>> removing the username and password properties entirely. Any >>>>>>>> suggestions? >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 Dec 8 15:33:57 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 8 Dec 2015 15:33:57 -0500 Subject: [Apiman-user] Having trouble connecting to Amazon Elasticsearch service In-Reply-To: References: Message-ID: <56673EB5.6070203@redhat.com> I can't imagine the name of the domain could be important. Can you double-check your exact apiman.properties? It should be this: apiman.es.protocol=https apiman.es.host=search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.amazonaws.com apiman.es.port=443 apiman.es.username= apiman.es.password= On 12/8/2015 3:26 PM, Paul Blair wrote: > When you create your domain, is it important what you name it? I named it > testapi, so my endpoint looks like > > search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.amazonaws.com > > And the domain ARN is then > > arn:aws:es:us-west-2:577360696927:domain/testapi > > > On 12/8/15, 3:06 PM, "Eric Wittmann" wrote: > >> Testing using 1.1.9.Final against the AWS instance of elastic was >> successful. The only thing left for me to try is the access policy. >> Otherwise everything looks like it's working fine. Here is the relevant >> section of my apiman.properties file, for reference: >> >> apiman.es.protocol=https >> apiman.es.host=search-apiman-elastic-sarog5jew3xacrec5szeefvdm4.us-east-1. >> es.amazonaws.com >> apiman.es.port=443 >> apiman.es.username= >> apiman.es.password= >> >> Here is some relevant curl output after my simple test: >> >> https://gist.github.com/EricWittmann/cc02a9ba6a2dee548a60 >> >> -Eric >> >> On 12/8/2015 1:13 PM, Paul Blair wrote: >>> It isn't too complicated -- I started here >>> https://aws.amazon.com/elasticsearch-service/ >>> >>> Basically you find "Elasticsearch Service" under the "Analytics" section >>> of the AWS dashboard, hit the "Create a new domain" button, and follow >>> the >>> instructions. >>> >>> My access policy looks like this: >>> >>> { >>> "Version": "2012-10-17", >>> "Statement": [ >>> { >>> "Sid": "", >>> "Effect": "Allow", >>> "Principal": { >>> "AWS": "*" >>> }, >>> "Action": "es:*", >>> "Resource": "arn:aws:es:us-west-2[ARN]/*", >>> "Condition": { >>> "IpAddress": { >>> "aws:SourceIp": [ >>> "[IP ADDRESS 1]", "[CIDR BLOCK 2]",... >>> ] >>> } >>> } >>> } >>> ] >>> } >>> >>> >>> >>> On 12/8/15, 12:30 PM, "Eric Wittmann" wrote: >>> >>>> Nope - I was worried that you were using 2.x, which we do not currently >>>> support. >>>> >>>> Do you happen to have any instructions handy for setting up an AMZ >>>> elasticsearch instance so I can try to reproduce this error? >>>> >>>> On 12/8/2015 12:28 PM, Paul Blair wrote: >>>>> Amazon says their current version is 1.5.2. Does apiman require >>>>> version >>>>> 2.x? >>>>> >>>>> On 12/8/15, 12:21 PM, "Eric Wittmann" >>>>> wrote: >>>>> >>>>>> What version of elasticsearch are you using? >>>>>> >>>>>> On 12/8/2015 12:12 PM, Paul Blair wrote: >>>>>>> The stack trace is below. Note that the instance seems to start >>>>>>> fine; >>>>>>> it's >>>>>>> only when I make a request to the Gateway that I get this error. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> 16:18:04,746 ERROR [io.undertow.request] (default task-1) UT005023: >>>>>>> Exception handling request to /apiman-gateway/test_api/1.7: >>>>>>> java.lang.RuntimeException: org.apache.http.NoHttpResponseException: >>>>>>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to respond >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClient >>>>>>> Fa >>>>>>> ct >>>>>>> or >>>>>>> y.java:200) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClient >>>>>>> Fa >>>>>>> ct >>>>>>> or >>>>>>> y.java:140) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClient >>>>>>> Fa >>>>>>> ct >>>>>>> or >>>>>>> y.java:101) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.apiman.gateway.engine.es.ESClientFactory.createClient(ESClientFact >>>>>>> or >>>>>>> y. >>>>>>> ja >>>>>>> va:66) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.apiman.gateway.engine.es.AbstractESComponent.getClient(AbstractESC >>>>>>> om >>>>>>> po >>>>>>> ne >>>>>>> nt.java:45) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>> at >>>>>>> >>>>>>> io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:315 >>>>>>> ) >>>>>>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>> at >>>>>>> >>>>>>> io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:304 >>>>>>> ) >>>>>>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.apiman.gateway.engine.es.CachingESRegistry.getService(CachingESReg >>>>>>> is >>>>>>> tr >>>>>>> y. >>>>>>> java:189) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getService(Secure >>>>>>> Re >>>>>>> gi >>>>>>> st >>>>>>> ryWrapper.java:97) [apiman-gateway-engine-core-1.1.9.Final.jar:] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.apiman.gateway.engine.impl.ServiceRequestExecutorImpl.execute(Serv >>>>>>> ic >>>>>>> eR >>>>>>> eq >>>>>>> uestExecutorImpl.java:252) >>>>>>> [apiman-gateway-engine-core-1.1.9.Final.jar:] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewaySe >>>>>>> rv >>>>>>> le >>>>>>> t. >>>>>>> java:236) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.apiman.gateway.platforms.servlet.GatewayServlet.doGet(GatewayServl >>>>>>> et >>>>>>> .j >>>>>>> av >>>>>>> a:82) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) >>>>>>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>>>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHand >>>>>>> le >>>>>>> r. >>>>>>> ja >>>>>>> va:86) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.hand >>>>>>> le >>>>>>> Re >>>>>>> qu >>>>>>> est(ServletSecurityRoleHandler.java:62) >>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest( >>>>>>> Se >>>>>>> rv >>>>>>> le >>>>>>> tDispatchingHandler.java:36) >>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> org.wildfly.extension.undertow.security.SecurityContextAssociationHan >>>>>>> dl >>>>>>> er >>>>>>> .h >>>>>>> andleRequest(SecurityContextAssociationHandler.java:78) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateH >>>>>>> an >>>>>>> dl >>>>>>> er >>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandle >>>>>>> r. >>>>>>> ha >>>>>>> nd >>>>>>> leRequest(SSLInformationAssociationHandler.java:131) >>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandle >>>>>>> r. >>>>>>> ha >>>>>>> nd >>>>>>> leRequest(ServletAuthenticationCallHandler.java:57) >>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateH >>>>>>> an >>>>>>> dl >>>>>>> er >>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRe >>>>>>> qu >>>>>>> es >>>>>>> t( >>>>>>> AbstractConfidentialityHandler.java:46) >>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstrain >>>>>>> tH >>>>>>> an >>>>>>> dl >>>>>>> er.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleR >>>>>>> eq >>>>>>> ue >>>>>>> st >>>>>>> (AuthenticationMechanismsHandler.java:58) >>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandl >>>>>>> er >>>>>>> .h >>>>>>> an >>>>>>> dleRequest(CachedAuthenticatedSessionHandler.java:70) >>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(Se >>>>>>> cu >>>>>>> ri >>>>>>> ty >>>>>>> InitialHandler.java:76) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateH >>>>>>> an >>>>>>> dl >>>>>>> er >>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.han >>>>>>> dl >>>>>>> eR >>>>>>> eq >>>>>>> uest(JACCContextIdHandler.java:61) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateH >>>>>>> an >>>>>>> dl >>>>>>> er >>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateH >>>>>>> an >>>>>>> dl >>>>>>> er >>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest >>>>>>> (S >>>>>>> er >>>>>>> vl >>>>>>> etInitialHandler.java:261) >>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(Se >>>>>>> rv >>>>>>> le >>>>>>> tI >>>>>>> nitialHandler.java:248) >>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(Servlet >>>>>>> In >>>>>>> it >>>>>>> ia >>>>>>> lHandler.java:77) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(Se >>>>>>> rv >>>>>>> le >>>>>>> tI >>>>>>> nitialHandler.java:167) >>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>> at >>>>>>> >>>>>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) >>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:7 >>>>>>> 61 >>>>>>> ) >>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. >>>>>>> ja >>>>>>> va >>>>>>> :1 >>>>>>> 142) [rt.jar:1.8.0_25] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor >>>>>>> .j >>>>>>> av >>>>>>> a: >>>>>>> 617) [rt.jar:1.8.0_25] >>>>>>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25] >>>>>>> Caused by: org.apache.http.NoHttpResponseException: >>>>>>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to respond >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(Default >>>>>>> Ht >>>>>>> tp >>>>>>> Re >>>>>>> sponseParser.java:143) [httpclient-4.5.jar:4.5] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(Default >>>>>>> Ht >>>>>>> tp >>>>>>> Re >>>>>>> sponseParser.java:57) [httpclient-4.5.jar:4.5] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessagePa >>>>>>> rs >>>>>>> er >>>>>>> .j >>>>>>> ava:261) [httpcore-4.4.1.jar:4.4.1] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHead >>>>>>> er >>>>>>> (D >>>>>>> ef >>>>>>> aultBHttpClientConnection.java:165) [httpcore-4.4.1.jar:4.4.1] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy >>>>>>> .j >>>>>>> av >>>>>>> a: >>>>>>> 167) [httpclient-4.5.jar:4.5] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRe >>>>>>> qu >>>>>>> es >>>>>>> tE >>>>>>> xecutor.java:272) [httpcore-4.4.1.jar:4.4.1] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecu >>>>>>> to >>>>>>> r. >>>>>>> ja >>>>>>> va:124) [httpcore-4.4.1.jar:4.4.1] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec. >>>>>>> ja >>>>>>> va >>>>>>> :2 >>>>>>> 71) [httpclient-4.5.jar:4.5] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java >>>>>>> :1 >>>>>>> 84 >>>>>>> ) >>>>>>> [httpclient-4.5.jar:4.5] >>>>>>> at >>>>>>> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) >>>>>>> [httpclient-4.5.jar:4.5] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java >>>>>>> :1 >>>>>>> 10 >>>>>>> ) >>>>>>> [httpclient-4.5.jar:4.5] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttp >>>>>>> Cl >>>>>>> ie >>>>>>> nt >>>>>>> .java:184) [httpclient-4.5.jar:4.5] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttp >>>>>>> Cl >>>>>>> ie >>>>>>> nt >>>>>>> .java:82) [httpclient-4.5.jar:4.5] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttp >>>>>>> Cl >>>>>>> ie >>>>>>> nt >>>>>>> .java:107) [httpclient-4.5.jar:4.5] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> io.searchbox.client.http.JestHttpClient.execute(JestHttpClient.java:5 >>>>>>> 0) >>>>>>> [jest-0.1.6.jar:] >>>>>>> at >>>>>>> >>>>>>> >>>>>>> >>>>>>> io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClient >>>>>>> Fa >>>>>>> ct >>>>>>> or >>>>>>> y.java:193) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>> ... 39 more >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 12/8/15, 11:48 AM, "Eric Wittmann" >>>>>>> wrote: >>>>>>> >>>>>>>> You definitely need to set the protocol to 'https', for the record. >>>>>>>> Beyond that I'm not quite sure. Do you have a full stack trace or >>>>>>>> just >>>>>>>> that part of it? >>>>>>>> >>>>>>>> On 12/8/2015 11:19 AM, Paul Blair wrote: >>>>>>>>> Not quite sure what to make of this: I'm getting >>>>>>>>> >>>>>>>>> org.apache.http.NoHttpResponseException: >>>>>>>>> [endpoint_URI]:443 >>>>>>>>> failed >>>>>>>>> to respond >>>>>>>>> >>>>>>>>> But if I do: >>>>>>>>> >>>>>>>>> curl https://[endpont_URI]:443 >>>>>>>>> >>>>>>>>> I get a response from Elasticsearch?this is because I have the >>>>>>>>> Amazon >>>>>>>>> Elasticsearch instance permissioned to accept any connections from >>>>>>>>> the >>>>>>>>> IP address where apiman is running. >>>>>>>>> >>>>>>>>> The apiman configurations look like this: >>>>>>>>> >>>>>>>>> apiman.es.protocol=http >>>>>>>>> apiman.es.host=[endpoint_URI] >>>>>>>>> apiman.es.port=443 >>>>>>>>> apiman.es.username= >>>>>>>>> apiman.es.password= >>>>>>>>> >>>>>>>>> Changing protocol from http to https doesn't appear to help, nor >>>>>>>>> does >>>>>>>>> removing the username and password properties entirely. Any >>>>>>>>> suggestions? >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Apiman-user mailing list >>>>>>>>> Apiman-user at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>>>>>>> >>>>>>> >>>>> >>> > From pblair at clearme.com Tue Dec 8 15:42:52 2015 From: pblair at clearme.com (Paul Blair) Date: Tue, 8 Dec 2015 20:42:52 +0000 Subject: [Apiman-user] Having trouble connecting to Amazon Elasticsearch service In-Reply-To: <56673EB5.6070203@redhat.com> Message-ID: Mine looks like this, because I have the properties in the standalone-apiman.xml -- but I'm pretty sure they are being read correctly because the error message I get indicates that there is no response coming from that host at that port, and then I curl using the host and port that I copy from the error message. When I start, I have only ES_HOST and ES_PORT in my environment. This is in a Docker container, so the command looks like this: docker run --name apiman-gateway -p 9443:9443 -e GATEWAY_PUBLIC_ENDPOINT=[URI] -e ES_HOST=search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.amazonaws.co m -e ES_PORT=443 [OTHER_ENV_VARIABLES] clear/api-gateway When I curl from the Docker container, I get a response that looks like this: $ curl https://search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.amazonaws.co m:443 { "status" : 200, "name" : "Magnum", "cluster_name" : "577360696927:testapi", "version" : { "number" : "1.5.2", "build_hash" : "62ff9868b4c8a0c45860bebb259e21980778ab1c", "build_timestamp" : "2015-04-27T09:21:06Z", "build_snapshot" : false, "lucene_version" : "4.10.4" }, "tagline" : "You Know, for Search" } On 12/8/15, 3:33 PM, "Eric Wittmann" wrote: >I can't imagine the name of the domain could be important. Can you >double-check your exact apiman.properties? It should be this: > >apiman.es.protocol=https >apiman.es.host=search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.amaz >onaws.com >apiman.es.port=443 >apiman.es.username= >apiman.es.password= > > > >On 12/8/2015 3:26 PM, Paul Blair wrote: >> When you create your domain, is it important what you name it? I named >>it >> testapi, so my endpoint looks like >> >> search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.amazonaws.com >> >> And the domain ARN is then >> >> arn:aws:es:us-west-2:577360696927:domain/testapi >> >> >> On 12/8/15, 3:06 PM, "Eric Wittmann" wrote: >> >>> Testing using 1.1.9.Final against the AWS instance of elastic was >>> successful. The only thing left for me to try is the access policy. >>> Otherwise everything looks like it's working fine. Here is the >>>relevant >>> section of my apiman.properties file, for reference: >>> >>> apiman.es.protocol=https >>> >>>apiman.es.host=search-apiman-elastic-sarog5jew3xacrec5szeefvdm4.us-east- >>>1. >>> es.amazonaws.com >>> apiman.es.port=443 >>> apiman.es.username= >>> apiman.es.password= >>> >>> Here is some relevant curl output after my simple test: >>> >>> https://gist.github.com/EricWittmann/cc02a9ba6a2dee548a60 >>> >>> -Eric >>> >>> On 12/8/2015 1:13 PM, Paul Blair wrote: >>>> It isn't too complicated -- I started here >>>> https://aws.amazon.com/elasticsearch-service/ >>>> >>>> Basically you find "Elasticsearch Service" under the "Analytics" >>>>section >>>> of the AWS dashboard, hit the "Create a new domain" button, and follow >>>> the >>>> instructions. >>>> >>>> My access policy looks like this: >>>> >>>> { >>>> "Version": "2012-10-17", >>>> "Statement": [ >>>> { >>>> "Sid": "", >>>> "Effect": "Allow", >>>> "Principal": { >>>> "AWS": "*" >>>> }, >>>> "Action": "es:*", >>>> "Resource": "arn:aws:es:us-west-2[ARN]/*", >>>> "Condition": { >>>> "IpAddress": { >>>> "aws:SourceIp": [ >>>> "[IP ADDRESS 1]", "[CIDR BLOCK 2]",... >>>> ] >>>> } >>>> } >>>> } >>>> ] >>>> } >>>> >>>> >>>> >>>> On 12/8/15, 12:30 PM, "Eric Wittmann" >>>>wrote: >>>> >>>>> Nope - I was worried that you were using 2.x, which we do not >>>>>currently >>>>> support. >>>>> >>>>> Do you happen to have any instructions handy for setting up an AMZ >>>>> elasticsearch instance so I can try to reproduce this error? >>>>> >>>>> On 12/8/2015 12:28 PM, Paul Blair wrote: >>>>>> Amazon says their current version is 1.5.2. Does apiman require >>>>>> version >>>>>> 2.x? >>>>>> >>>>>> On 12/8/15, 12:21 PM, "Eric Wittmann" >>>>>> wrote: >>>>>> >>>>>>> What version of elasticsearch are you using? >>>>>>> >>>>>>> On 12/8/2015 12:12 PM, Paul Blair wrote: >>>>>>>> The stack trace is below. Note that the instance seems to start >>>>>>>> fine; >>>>>>>> it's >>>>>>>> only when I make a request to the Gateway that I get this error. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> 16:18:04,746 ERROR [io.undertow.request] (default task-1) >>>>>>>>UT005023: >>>>>>>> Exception handling request to /apiman-gateway/test_api/1.7: >>>>>>>> java.lang.RuntimeException: >>>>>>>>org.apache.http.NoHttpResponseException: >>>>>>>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to >>>>>>>>respond >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClie >>>>>>>>nt >>>>>>>> Fa >>>>>>>> ct >>>>>>>> or >>>>>>>> y.java:200) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClie >>>>>>>>nt >>>>>>>> Fa >>>>>>>> ct >>>>>>>> or >>>>>>>> y.java:140) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClie >>>>>>>>nt >>>>>>>> Fa >>>>>>>> ct >>>>>>>> or >>>>>>>> y.java:101) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.apiman.gateway.engine.es.ESClientFactory.createClient(ESClientFa >>>>>>>>ct >>>>>>>> or >>>>>>>> y. >>>>>>>> ja >>>>>>>> va:66) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.apiman.gateway.engine.es.AbstractESComponent.getClient(AbstractE >>>>>>>>SC >>>>>>>> om >>>>>>>> po >>>>>>>> ne >>>>>>>> nt.java:45) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>>io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:3 >>>>>>>>15 >>>>>>>> ) >>>>>>>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>>io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:3 >>>>>>>>04 >>>>>>>> ) >>>>>>>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.apiman.gateway.engine.es.CachingESRegistry.getService(CachingESR >>>>>>>>eg >>>>>>>> is >>>>>>>> tr >>>>>>>> y. >>>>>>>> java:189) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.apiman.gateway.engine.impl.SecureRegistryWrapper.getService(Secu >>>>>>>>re >>>>>>>> Re >>>>>>>> gi >>>>>>>> st >>>>>>>> ryWrapper.java:97) [apiman-gateway-engine-core-1.1.9.Final.jar:] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.apiman.gateway.engine.impl.ServiceRequestExecutorImpl.execute(Se >>>>>>>>rv >>>>>>>> ic >>>>>>>> eR >>>>>>>> eq >>>>>>>> uestExecutorImpl.java:252) >>>>>>>> [apiman-gateway-engine-core-1.1.9.Final.jar:] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(Gateway >>>>>>>>Se >>>>>>>> rv >>>>>>>> le >>>>>>>> t. >>>>>>>> java:236) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.apiman.gateway.platforms.servlet.GatewayServlet.doGet(GatewaySer >>>>>>>>vl >>>>>>>> et >>>>>>>> .j >>>>>>>> av >>>>>>>> a:82) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>>>>>>> at >>>>>>>>javax.servlet.http.HttpServlet.service(HttpServlet.java:687) >>>>>>>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>>>>>>> at >>>>>>>>javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>>>>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHa >>>>>>>>nd >>>>>>>> le >>>>>>>> r. >>>>>>>> ja >>>>>>>> va:86) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.ha >>>>>>>>nd >>>>>>>> le >>>>>>>> Re >>>>>>>> qu >>>>>>>> est(ServletSecurityRoleHandler.java:62) >>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.undertow.servlet.handlers.ServletDispatchingHandler.handleReques >>>>>>>>t( >>>>>>>> Se >>>>>>>> rv >>>>>>>> le >>>>>>>> tDispatchingHandler.java:36) >>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>org.wildfly.extension.undertow.security.SecurityContextAssociationH >>>>>>>>an >>>>>>>> dl >>>>>>>> er >>>>>>>> .h >>>>>>>> andleRequest(SecurityContextAssociationHandler.java:78) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.undertow.server.handlers.PredicateHandler.handleRequest(Predicat >>>>>>>>eH >>>>>>>> an >>>>>>>> dl >>>>>>>> er >>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.undertow.servlet.handlers.security.SSLInformationAssociationHand >>>>>>>>le >>>>>>>> r. >>>>>>>> ha >>>>>>>> nd >>>>>>>> leRequest(SSLInformationAssociationHandler.java:131) >>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.undertow.servlet.handlers.security.ServletAuthenticationCallHand >>>>>>>>le >>>>>>>> r. >>>>>>>> ha >>>>>>>> nd >>>>>>>> leRequest(ServletAuthenticationCallHandler.java:57) >>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.undertow.server.handlers.PredicateHandler.handleRequest(Predicat >>>>>>>>eH >>>>>>>> an >>>>>>>> dl >>>>>>>> er >>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.undertow.security.handlers.AbstractConfidentialityHandler.handle >>>>>>>>Re >>>>>>>> qu >>>>>>>> es >>>>>>>> t( >>>>>>>> AbstractConfidentialityHandler.java:46) >>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.undertow.servlet.handlers.security.ServletConfidentialityConstra >>>>>>>>in >>>>>>>> tH >>>>>>>> an >>>>>>>> dl >>>>>>>> er.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.undertow.security.handlers.AuthenticationMechanismsHandler.handl >>>>>>>>eR >>>>>>>> eq >>>>>>>> ue >>>>>>>> st >>>>>>>> (AuthenticationMechanismsHandler.java:58) >>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHan >>>>>>>>dl >>>>>>>> er >>>>>>>> .h >>>>>>>> an >>>>>>>> dleRequest(CachedAuthenticatedSessionHandler.java:70) >>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.undertow.security.handlers.SecurityInitialHandler.handleRequest( >>>>>>>>Se >>>>>>>> cu >>>>>>>> ri >>>>>>>> ty >>>>>>>> InitialHandler.java:76) >>>>>>>>[undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.undertow.server.handlers.PredicateHandler.handleRequest(Predicat >>>>>>>>eH >>>>>>>> an >>>>>>>> dl >>>>>>>> er >>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.h >>>>>>>>an >>>>>>>> dl >>>>>>>> eR >>>>>>>> eq >>>>>>>> uest(JACCContextIdHandler.java:61) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.undertow.server.handlers.PredicateHandler.handleRequest(Predicat >>>>>>>>eH >>>>>>>> an >>>>>>>> dl >>>>>>>> er >>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.undertow.server.handlers.PredicateHandler.handleRequest(Predicat >>>>>>>>eH >>>>>>>> an >>>>>>>> dl >>>>>>>> er >>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.undertow.servlet.handlers.ServletInitialHandler.handleFirstReque >>>>>>>>st >>>>>>>> (S >>>>>>>> er >>>>>>>> vl >>>>>>>> etInitialHandler.java:261) >>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest( >>>>>>>>Se >>>>>>>> rv >>>>>>>> le >>>>>>>> tI >>>>>>>> nitialHandler.java:248) >>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.undertow.servlet.handlers.ServletInitialHandler.access$000(Servl >>>>>>>>et >>>>>>>> In >>>>>>>> it >>>>>>>> ia >>>>>>>> lHandler.java:77) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest( >>>>>>>>Se >>>>>>>> rv >>>>>>>> le >>>>>>>> tI >>>>>>>> nitialHandler.java:167) >>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>>io.undertow.server.Connectors.executeRootHandler(Connectors.java:19 >>>>>>>>9) >>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java >>>>>>>>:7 >>>>>>>> 61 >>>>>>>> ) >>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecuto >>>>>>>>r. >>>>>>>> ja >>>>>>>> va >>>>>>>> :1 >>>>>>>> 142) [rt.jar:1.8.0_25] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecut >>>>>>>>or >>>>>>>> .j >>>>>>>> av >>>>>>>> a: >>>>>>>> 617) [rt.jar:1.8.0_25] >>>>>>>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25] >>>>>>>> Caused by: org.apache.http.NoHttpResponseException: >>>>>>>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to >>>>>>>>respond >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(Defau >>>>>>>>lt >>>>>>>> Ht >>>>>>>> tp >>>>>>>> Re >>>>>>>> sponseParser.java:143) [httpclient-4.5.jar:4.5] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(Defau >>>>>>>>lt >>>>>>>> Ht >>>>>>>> tp >>>>>>>> Re >>>>>>>> sponseParser.java:57) [httpclient-4.5.jar:4.5] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessage >>>>>>>>Pa >>>>>>>> rs >>>>>>>> er >>>>>>>> .j >>>>>>>> ava:261) [httpcore-4.4.1.jar:4.4.1] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHe >>>>>>>>ad >>>>>>>> er >>>>>>>> (D >>>>>>>> ef >>>>>>>> aultBHttpClientConnection.java:165) [httpcore-4.4.1.jar:4.4.1] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolPro >>>>>>>>xy >>>>>>>> .j >>>>>>>> av >>>>>>>> a: >>>>>>>> 167) [httpclient-4.5.jar:4.5] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(Http >>>>>>>>Re >>>>>>>> qu >>>>>>>> es >>>>>>>> tE >>>>>>>> xecutor.java:272) [httpcore-4.4.1.jar:4.4.1] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExe >>>>>>>>cu >>>>>>>> to >>>>>>>> r. >>>>>>>> ja >>>>>>>> va:124) [httpcore-4.4.1.jar:4.4.1] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>org.apache.http.impl.execchain.MainClientExec.execute(MainClientExe >>>>>>>>c. >>>>>>>> ja >>>>>>>> va >>>>>>>> :2 >>>>>>>> 71) [httpclient-4.5.jar:4.5] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.ja >>>>>>>>va >>>>>>>> :1 >>>>>>>> 84 >>>>>>>> ) >>>>>>>> [httpclient-4.5.jar:4.5] >>>>>>>> at >>>>>>>> >>>>>>>>org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) >>>>>>>> [httpclient-4.5.jar:4.5] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.ja >>>>>>>>va >>>>>>>> :1 >>>>>>>> 10 >>>>>>>> ) >>>>>>>> [httpclient-4.5.jar:4.5] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHt >>>>>>>>tp >>>>>>>> Cl >>>>>>>> ie >>>>>>>> nt >>>>>>>> .java:184) [httpclient-4.5.jar:4.5] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHt >>>>>>>>tp >>>>>>>> Cl >>>>>>>> ie >>>>>>>> nt >>>>>>>> .java:82) [httpclient-4.5.jar:4.5] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHt >>>>>>>>tp >>>>>>>> Cl >>>>>>>> ie >>>>>>>> nt >>>>>>>> .java:107) [httpclient-4.5.jar:4.5] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.searchbox.client.http.JestHttpClient.execute(JestHttpClient.java >>>>>>>>:5 >>>>>>>> 0) >>>>>>>> [jest-0.1.6.jar:] >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClie >>>>>>>>nt >>>>>>>> Fa >>>>>>>> ct >>>>>>>> or >>>>>>>> y.java:193) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>> ... 39 more >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 12/8/15, 11:48 AM, "Eric Wittmann" >>>>>>>> wrote: >>>>>>>> >>>>>>>>> You definitely need to set the protocol to 'https', for the >>>>>>>>>record. >>>>>>>>> Beyond that I'm not quite sure. Do you have a full stack trace >>>>>>>>>or >>>>>>>>> just >>>>>>>>> that part of it? >>>>>>>>> >>>>>>>>> On 12/8/2015 11:19 AM, Paul Blair wrote: >>>>>>>>>> Not quite sure what to make of this: I'm getting >>>>>>>>>> >>>>>>>>>> org.apache.http.NoHttpResponseException: >>>>>>>>>> [endpoint_URI]:443 >>>>>>>>>> failed >>>>>>>>>> to respond >>>>>>>>>> >>>>>>>>>> But if I do: >>>>>>>>>> >>>>>>>>>> curl https://[endpont_URI]:443 >>>>>>>>>> >>>>>>>>>> I get a response from Elasticsearch?this is because I have the >>>>>>>>>> Amazon >>>>>>>>>> Elasticsearch instance permissioned to accept any connections >>>>>>>>>>from >>>>>>>>>> the >>>>>>>>>> IP address where apiman is running. >>>>>>>>>> >>>>>>>>>> The apiman configurations look like this: >>>>>>>>>> >>>>>>>>>> apiman.es.protocol=http >>>>>>>>>> apiman.es.host=[endpoint_URI] >>>>>>>>>> apiman.es.port=443 >>>>>>>>>> apiman.es.username= >>>>>>>>>> apiman.es.password= >>>>>>>>>> >>>>>>>>>> Changing protocol from http to https doesn't appear to help, nor >>>>>>>>>> does >>>>>>>>>> removing the username and password properties entirely. Any >>>>>>>>>> suggestions? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Apiman-user mailing list >>>>>>>>>> Apiman-user at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> From pblair at clearme.com Tue Dec 8 20:53:05 2015 From: pblair at clearme.com (Paul Blair) Date: Wed, 9 Dec 2015 01:53:05 +0000 Subject: [Apiman-user] Strange exception trying to initialize apiman database with Postgres Message-ID: I'm getting a weird data type exception when issuing a request to the API manager running against a Postgres instance: I'm using apiman 1.1.9 with the DDL for Postgres found here: https://raw.githubusercontent.com/apiman/apiman/apiman-1.1.9.Final/distro/wildfly8/src/main/resources/overlay/apiman/ddls/apiman_postgresql9.ddl The DDL does make that into a text column; I'm not sure why Hibernate doesn't like it and instead wants a VARCHAR that is too big for Postgres. This is on PostgreSQL 9.4.4; my driver configuration in the standalone-apiman.xml uses postgresql-9.3-1102-jdbc41.jar and doesn't have any particular validation configuration. Relevant stack: UT005023: Exception handling request to /apiman/currentuser/info: org.jboss.resteasy.spi.UnhandledException: org.jboss.weld.exceptions.WeldException: WELD-000049: Unable to invoke public void io.apiman.manager.api.jpa.EntityManagerFactoryAccessor.postConstruct() on io.apiman.manager.api.jpa.EntityManagerFactoryAccessor at 325203f1 ... Caused by: javax.persistence.PersistenceException: Unable to build entity manager factory ... Caused by: org.hibernate.HibernateException: Wrong column type in public.auditlog for column data. Found: text, expected : varchar(2147483647) at org.hibernate.mapping.Table.validateColumns(Table.java:372) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.cfg.Configuration.validateSchema(Configuration.java:1338) [hibernate-core-4.3.7.Final.jar:4.3.7 .Final] ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151209/01183ef6/attachment-0001.html From pblair at clearme.com Tue Dec 8 21:09:21 2015 From: pblair at clearme.com (Paul Blair) Date: Wed, 9 Dec 2015 02:09:21 +0000 Subject: [Apiman-user] Strange exception trying to initialize apiman database with Postgres In-Reply-To: Message-ID: I was able to work around this problem with the auditlog data column and a few other columns using the ALTER TABLE statements below to convert to a VARCHAR of shorter length than the error message demanded. However, I'm now stymied by a subsequent error: "Wrong column type in public.service_defs for column data. Found: oid, expected: blob" -- I tried converting the type to bytea but this doesn't satisfy Hibernate. I feel like I've got the wrong version of a script here, but I was careful to get the PostgreSQL script for apiman 1.1.9.Final. ALTER TABLE auditlog ALTER COLUMN data TYPE varchar(10485760); ALTER TABLE gateways ALTER COLUMN configuration TYPE varchar(10485760); ALTER TABLE policies ALTER COLUMN configuration TYPE varchar(10485760); From: "pblair at clearme.com" > Date: Wed, 9 Dec 2015 01:53:05 +0000 To: "apiman-user at lists.jboss.org" > Subject: [Apiman-user] Strange exception trying to initialize apiman database with Postgres I'm getting a weird data type exception when issuing a request to the API manager running against a Postgres instance: I'm using apiman 1.1.9 with the DDL for Postgres found here: https://raw.githubusercontent.com/apiman/apiman/apiman-1.1.9.Final/distro/wildfly8/src/main/resources/overlay/apiman/ddls/apiman_postgresql9.ddl The DDL does make that into a text column; I'm not sure why Hibernate doesn't like it and instead wants a VARCHAR that is too big for Postgres. This is on PostgreSQL 9.4.4; my driver configuration in the standalone-apiman.xml uses postgresql-9.3-1102-jdbc41.jar and doesn't have any particular validation configuration. Relevant stack: UT005023: Exception handling request to /apiman/currentuser/info: org.jboss.resteasy.spi.UnhandledException: org.jboss.weld.exceptions.WeldException: WELD-000049: Unable to invoke public void io.apiman.manager.api.jpa.EntityManagerFactoryAccessor.postConstruct() on io.apiman.manager.api.jpa.EntityManagerFactoryAccessor at 325203f1 ... Caused by: javax.persistence.PersistenceException: Unable to build entity manager factory ... Caused by: org.hibernate.HibernateException: Wrong column type in public.auditlog for column data. Found: text, expected : varchar(2147483647) at org.hibernate.mapping.Table.validateColumns(Table.java:372) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.cfg.Configuration.validateSchema(Configuration.java:1338) [hibernate-core-4.3.7.Final.jar:4.3.7 .Final] ... _______________________________________________ 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/20151209/8f118f03/attachment.html From eric.wittmann at redhat.com Wed Dec 9 07:40:19 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 9 Dec 2015 07:40:19 -0500 Subject: [Apiman-user] Strange exception trying to initialize apiman database with Postgres In-Reply-To: References: Message-ID: <56682133.1060200@redhat.com> These sorts of errors are more typically caused by problems with the version of hibernate or with the dialect being used. Can you verify the dialect you're using? And can I assume you're hitting this error using WildFly 8? I'll try this out using your particular versions of postgres and the driver... -Eric On 12/8/2015 9:09 PM, Paul Blair wrote: > I was able to work around this problem with the auditlog data column and > a few other columns using the ALTER TABLE statements below to convert to > a VARCHAR of shorter length than the error message demanded. However, > I'm now stymied by a subsequent error: "Wrong column type in > public.service_defs for column data. Found: oid, expected: blob" -- I > tried converting the type to bytea but this doesn't satisfy Hibernate. > > I feel like I've got the wrong version of a script here, but I was > careful to get the PostgreSQL script for apiman 1.1.9.Final. > > ALTER TABLE auditlog > ALTER COLUMN data TYPE varchar(10485760); > > ALTER TABLE gateways > ALTER COLUMN configuration TYPE varchar(10485760); > > ALTER TABLE policies > ALTER COLUMN configuration TYPE varchar(10485760); > > > > From: "pblair at clearme.com " > > > Date: Wed, 9 Dec 2015 01:53:05 +0000 > To: "apiman-user at lists.jboss.org " > > > Subject: [Apiman-user] Strange exception trying to initialize apiman > database with Postgres > > I'm getting a weird data type exception when issuing a request to the > API manager running against a Postgres instance: > > I'm using apiman 1.1.9 with the DDL for Postgres found here: > https://raw.githubusercontent.com/apiman/apiman/apiman-1.1.9.Final/distro/wildfly8/src/main/resources/overlay/apiman/ddls/apiman_postgresql9.ddl > > The DDL does make that into a text column; I'm not sure why Hibernate > doesn't like it and instead wants a VARCHAR that is too big for > Postgres. This is on PostgreSQL 9.4.4; my driver configuration in the > standalone-apiman.xml uses postgresql-9.3-1102-jdbc41.jar and doesn't > have any particular validation configuration. > > Relevant stack: > > UT005023: Exception handling request to /apiman/currentuser/info: > org.jboss.resteasy.spi.UnhandledException: > org.jboss.weld.exceptions.WeldException: WELD-000049: Unable to invoke > public void > io.apiman.manager.api.jpa.EntityManagerFactoryAccessor.postConstruct() > on io.apiman.manager.api.jpa.EntityManagerFactoryAccessor at 325203f1 > ? > Caused by: javax.persistence.PersistenceException: Unable to build > entity manager factory > ? > Caused by: org.hibernate.HibernateException: Wrong column type in > public.auditlog for column data. Found: text, expected > : varchar(2147483647) > at org.hibernate.mapping.Table.validateColumns(Table.java:372) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at > org.hibernate.cfg.Configuration.validateSchema(Configuration.java:1338) > [hibernate-core-4.3.7.Final.jar:4.3.7 > .Final] > ? > > > _______________________________________________ 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 Wed Dec 9 08:14:25 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 9 Dec 2015 08:14:25 -0500 Subject: [Apiman-user] Having trouble connecting to Amazon Elasticsearch service In-Reply-To: References: Message-ID: <56682931.3080303@redhat.com> Update: I added the IP address policy to the AWS instance and everything continued working OK. Note that I have been testing this with a standalone wildfly running on centos, not via docker. I can't think of any reason why that would make a difference. I'm going to change the IP address of the policy to one that is *not* mine to see what I get in that case (should be a failure of some kind, obviously). On 12/8/2015 3:42 PM, Paul Blair wrote: > Mine looks like this, because I have the properties in the > standalone-apiman.xml -- but I'm pretty sure they are being read correctly > because the error message I get indicates that there is no response coming > from that host at that port, and then I curl using the host and port that > I copy from the error message. > > > value="${env.GATEWAY_PUBLIC_ENDPOINT:}"/> > > > > > > > > > When I start, I have only ES_HOST and ES_PORT in my environment. This is > in a Docker container, so the command looks like this: > > docker run --name apiman-gateway -p 9443:9443 -e > GATEWAY_PUBLIC_ENDPOINT=[URI] -e > ES_HOST=search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.amazonaws.co > m -e ES_PORT=443 [OTHER_ENV_VARIABLES] clear/api-gateway > > > When I curl from the Docker container, I get a response that looks like > this: > > $ curl > https://search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.amazonaws.co > m:443 > { > "status" : 200, > "name" : "Magnum", > "cluster_name" : "577360696927:testapi", > "version" : { > "number" : "1.5.2", > "build_hash" : "62ff9868b4c8a0c45860bebb259e21980778ab1c", > "build_timestamp" : "2015-04-27T09:21:06Z", > "build_snapshot" : false, > "lucene_version" : "4.10.4" > }, > "tagline" : "You Know, for Search" > } > > > > On 12/8/15, 3:33 PM, "Eric Wittmann" wrote: > >> I can't imagine the name of the domain could be important. Can you >> double-check your exact apiman.properties? It should be this: >> >> apiman.es.protocol=https >> apiman.es.host=search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.amaz >> onaws.com >> apiman.es.port=443 >> apiman.es.username= >> apiman.es.password= >> >> >> >> On 12/8/2015 3:26 PM, Paul Blair wrote: >>> When you create your domain, is it important what you name it? I named >>> it >>> testapi, so my endpoint looks like >>> >>> search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.amazonaws.com >>> >>> And the domain ARN is then >>> >>> arn:aws:es:us-west-2:577360696927:domain/testapi >>> >>> >>> On 12/8/15, 3:06 PM, "Eric Wittmann" wrote: >>> >>>> Testing using 1.1.9.Final against the AWS instance of elastic was >>>> successful. The only thing left for me to try is the access policy. >>>> Otherwise everything looks like it's working fine. Here is the >>>> relevant >>>> section of my apiman.properties file, for reference: >>>> >>>> apiman.es.protocol=https >>>> >>>> apiman.es.host=search-apiman-elastic-sarog5jew3xacrec5szeefvdm4.us-east- >>>> 1. >>>> es.amazonaws.com >>>> apiman.es.port=443 >>>> apiman.es.username= >>>> apiman.es.password= >>>> >>>> Here is some relevant curl output after my simple test: >>>> >>>> https://gist.github.com/EricWittmann/cc02a9ba6a2dee548a60 >>>> >>>> -Eric >>>> >>>> On 12/8/2015 1:13 PM, Paul Blair wrote: >>>>> It isn't too complicated -- I started here >>>>> https://aws.amazon.com/elasticsearch-service/ >>>>> >>>>> Basically you find "Elasticsearch Service" under the "Analytics" >>>>> section >>>>> of the AWS dashboard, hit the "Create a new domain" button, and follow >>>>> the >>>>> instructions. >>>>> >>>>> My access policy looks like this: >>>>> >>>>> { >>>>> "Version": "2012-10-17", >>>>> "Statement": [ >>>>> { >>>>> "Sid": "", >>>>> "Effect": "Allow", >>>>> "Principal": { >>>>> "AWS": "*" >>>>> }, >>>>> "Action": "es:*", >>>>> "Resource": "arn:aws:es:us-west-2[ARN]/*", >>>>> "Condition": { >>>>> "IpAddress": { >>>>> "aws:SourceIp": [ >>>>> "[IP ADDRESS 1]", "[CIDR BLOCK 2]",... >>>>> ] >>>>> } >>>>> } >>>>> } >>>>> ] >>>>> } >>>>> >>>>> >>>>> >>>>> On 12/8/15, 12:30 PM, "Eric Wittmann" >>>>> wrote: >>>>> >>>>>> Nope - I was worried that you were using 2.x, which we do not >>>>>> currently >>>>>> support. >>>>>> >>>>>> Do you happen to have any instructions handy for setting up an AMZ >>>>>> elasticsearch instance so I can try to reproduce this error? >>>>>> >>>>>> On 12/8/2015 12:28 PM, Paul Blair wrote: >>>>>>> Amazon says their current version is 1.5.2. Does apiman require >>>>>>> version >>>>>>> 2.x? >>>>>>> >>>>>>> On 12/8/15, 12:21 PM, "Eric Wittmann" >>>>>>> wrote: >>>>>>> >>>>>>>> What version of elasticsearch are you using? >>>>>>>> >>>>>>>> On 12/8/2015 12:12 PM, Paul Blair wrote: >>>>>>>>> The stack trace is below. Note that the instance seems to start >>>>>>>>> fine; >>>>>>>>> it's >>>>>>>>> only when I make a request to the Gateway that I get this error. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> 16:18:04,746 ERROR [io.undertow.request] (default task-1) >>>>>>>>> UT005023: >>>>>>>>> Exception handling request to /apiman-gateway/test_api/1.7: >>>>>>>>> java.lang.RuntimeException: >>>>>>>>> org.apache.http.NoHttpResponseException: >>>>>>>>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to >>>>>>>>> respond >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClie >>>>>>>>> nt >>>>>>>>> Fa >>>>>>>>> ct >>>>>>>>> or >>>>>>>>> y.java:200) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClie >>>>>>>>> nt >>>>>>>>> Fa >>>>>>>>> ct >>>>>>>>> or >>>>>>>>> y.java:140) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClie >>>>>>>>> nt >>>>>>>>> Fa >>>>>>>>> ct >>>>>>>>> or >>>>>>>>> y.java:101) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.engine.es.ESClientFactory.createClient(ESClientFa >>>>>>>>> ct >>>>>>>>> or >>>>>>>>> y. >>>>>>>>> ja >>>>>>>>> va:66) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.engine.es.AbstractESComponent.getClient(AbstractE >>>>>>>>> SC >>>>>>>>> om >>>>>>>>> po >>>>>>>>> ne >>>>>>>>> nt.java:45) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:3 >>>>>>>>> 15 >>>>>>>>> ) >>>>>>>>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:3 >>>>>>>>> 04 >>>>>>>>> ) >>>>>>>>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.engine.es.CachingESRegistry.getService(CachingESR >>>>>>>>> eg >>>>>>>>> is >>>>>>>>> tr >>>>>>>>> y. >>>>>>>>> java:189) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getService(Secu >>>>>>>>> re >>>>>>>>> Re >>>>>>>>> gi >>>>>>>>> st >>>>>>>>> ryWrapper.java:97) [apiman-gateway-engine-core-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.engine.impl.ServiceRequestExecutorImpl.execute(Se >>>>>>>>> rv >>>>>>>>> ic >>>>>>>>> eR >>>>>>>>> eq >>>>>>>>> uestExecutorImpl.java:252) >>>>>>>>> [apiman-gateway-engine-core-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(Gateway >>>>>>>>> Se >>>>>>>>> rv >>>>>>>>> le >>>>>>>>> t. >>>>>>>>> java:236) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.platforms.servlet.GatewayServlet.doGet(GatewaySer >>>>>>>>> vl >>>>>>>>> et >>>>>>>>> .j >>>>>>>>> av >>>>>>>>> a:82) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:687) >>>>>>>>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>>>>>>>> at >>>>>>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>>>>>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHa >>>>>>>>> nd >>>>>>>>> le >>>>>>>>> r. >>>>>>>>> ja >>>>>>>>> va:86) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.ha >>>>>>>>> nd >>>>>>>>> le >>>>>>>>> Re >>>>>>>>> qu >>>>>>>>> est(ServletSecurityRoleHandler.java:62) >>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleReques >>>>>>>>> t( >>>>>>>>> Se >>>>>>>>> rv >>>>>>>>> le >>>>>>>>> tDispatchingHandler.java:36) >>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.wildfly.extension.undertow.security.SecurityContextAssociationH >>>>>>>>> an >>>>>>>>> dl >>>>>>>>> er >>>>>>>>> .h >>>>>>>>> andleRequest(SecurityContextAssociationHandler.java:78) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(Predicat >>>>>>>>> eH >>>>>>>>> an >>>>>>>>> dl >>>>>>>>> er >>>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHand >>>>>>>>> le >>>>>>>>> r. >>>>>>>>> ha >>>>>>>>> nd >>>>>>>>> leRequest(SSLInformationAssociationHandler.java:131) >>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHand >>>>>>>>> le >>>>>>>>> r. >>>>>>>>> ha >>>>>>>>> nd >>>>>>>>> leRequest(ServletAuthenticationCallHandler.java:57) >>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(Predicat >>>>>>>>> eH >>>>>>>>> an >>>>>>>>> dl >>>>>>>>> er >>>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handle >>>>>>>>> Re >>>>>>>>> qu >>>>>>>>> es >>>>>>>>> t( >>>>>>>>> AbstractConfidentialityHandler.java:46) >>>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstra >>>>>>>>> in >>>>>>>>> tH >>>>>>>>> an >>>>>>>>> dl >>>>>>>>> er.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handl >>>>>>>>> eR >>>>>>>>> eq >>>>>>>>> ue >>>>>>>>> st >>>>>>>>> (AuthenticationMechanismsHandler.java:58) >>>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHan >>>>>>>>> dl >>>>>>>>> er >>>>>>>>> .h >>>>>>>>> an >>>>>>>>> dleRequest(CachedAuthenticatedSessionHandler.java:70) >>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.security.handlers.SecurityInitialHandler.handleRequest( >>>>>>>>> Se >>>>>>>>> cu >>>>>>>>> ri >>>>>>>>> ty >>>>>>>>> InitialHandler.java:76) >>>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(Predicat >>>>>>>>> eH >>>>>>>>> an >>>>>>>>> dl >>>>>>>>> er >>>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.h >>>>>>>>> an >>>>>>>>> dl >>>>>>>>> eR >>>>>>>>> eq >>>>>>>>> uest(JACCContextIdHandler.java:61) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(Predicat >>>>>>>>> eH >>>>>>>>> an >>>>>>>>> dl >>>>>>>>> er >>>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(Predicat >>>>>>>>> eH >>>>>>>>> an >>>>>>>>> dl >>>>>>>>> er >>>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstReque >>>>>>>>> st >>>>>>>>> (S >>>>>>>>> er >>>>>>>>> vl >>>>>>>>> etInitialHandler.java:261) >>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest( >>>>>>>>> Se >>>>>>>>> rv >>>>>>>>> le >>>>>>>>> tI >>>>>>>>> nitialHandler.java:248) >>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(Servl >>>>>>>>> et >>>>>>>>> In >>>>>>>>> it >>>>>>>>> ia >>>>>>>>> lHandler.java:77) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest( >>>>>>>>> Se >>>>>>>>> rv >>>>>>>>> le >>>>>>>>> tI >>>>>>>>> nitialHandler.java:167) >>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:19 >>>>>>>>> 9) >>>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java >>>>>>>>> :7 >>>>>>>>> 61 >>>>>>>>> ) >>>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecuto >>>>>>>>> r. >>>>>>>>> ja >>>>>>>>> va >>>>>>>>> :1 >>>>>>>>> 142) [rt.jar:1.8.0_25] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecut >>>>>>>>> or >>>>>>>>> .j >>>>>>>>> av >>>>>>>>> a: >>>>>>>>> 617) [rt.jar:1.8.0_25] >>>>>>>>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25] >>>>>>>>> Caused by: org.apache.http.NoHttpResponseException: >>>>>>>>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to >>>>>>>>> respond >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(Defau >>>>>>>>> lt >>>>>>>>> Ht >>>>>>>>> tp >>>>>>>>> Re >>>>>>>>> sponseParser.java:143) [httpclient-4.5.jar:4.5] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(Defau >>>>>>>>> lt >>>>>>>>> Ht >>>>>>>>> tp >>>>>>>>> Re >>>>>>>>> sponseParser.java:57) [httpclient-4.5.jar:4.5] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessage >>>>>>>>> Pa >>>>>>>>> rs >>>>>>>>> er >>>>>>>>> .j >>>>>>>>> ava:261) [httpcore-4.4.1.jar:4.4.1] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHe >>>>>>>>> ad >>>>>>>>> er >>>>>>>>> (D >>>>>>>>> ef >>>>>>>>> aultBHttpClientConnection.java:165) [httpcore-4.4.1.jar:4.4.1] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolPro >>>>>>>>> xy >>>>>>>>> .j >>>>>>>>> av >>>>>>>>> a: >>>>>>>>> 167) [httpclient-4.5.jar:4.5] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(Http >>>>>>>>> Re >>>>>>>>> qu >>>>>>>>> es >>>>>>>>> tE >>>>>>>>> xecutor.java:272) [httpcore-4.4.1.jar:4.4.1] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExe >>>>>>>>> cu >>>>>>>>> to >>>>>>>>> r. >>>>>>>>> ja >>>>>>>>> va:124) [httpcore-4.4.1.jar:4.4.1] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExe >>>>>>>>> c. >>>>>>>>> ja >>>>>>>>> va >>>>>>>>> :2 >>>>>>>>> 71) [httpclient-4.5.jar:4.5] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.ja >>>>>>>>> va >>>>>>>>> :1 >>>>>>>>> 84 >>>>>>>>> ) >>>>>>>>> [httpclient-4.5.jar:4.5] >>>>>>>>> at >>>>>>>>> >>>>>>>>> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) >>>>>>>>> [httpclient-4.5.jar:4.5] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.ja >>>>>>>>> va >>>>>>>>> :1 >>>>>>>>> 10 >>>>>>>>> ) >>>>>>>>> [httpclient-4.5.jar:4.5] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHt >>>>>>>>> tp >>>>>>>>> Cl >>>>>>>>> ie >>>>>>>>> nt >>>>>>>>> .java:184) [httpclient-4.5.jar:4.5] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHt >>>>>>>>> tp >>>>>>>>> Cl >>>>>>>>> ie >>>>>>>>> nt >>>>>>>>> .java:82) [httpclient-4.5.jar:4.5] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHt >>>>>>>>> tp >>>>>>>>> Cl >>>>>>>>> ie >>>>>>>>> nt >>>>>>>>> .java:107) [httpclient-4.5.jar:4.5] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.searchbox.client.http.JestHttpClient.execute(JestHttpClient.java >>>>>>>>> :5 >>>>>>>>> 0) >>>>>>>>> [jest-0.1.6.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClie >>>>>>>>> nt >>>>>>>>> Fa >>>>>>>>> ct >>>>>>>>> or >>>>>>>>> y.java:193) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>> ... 39 more >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 12/8/15, 11:48 AM, "Eric Wittmann" >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> You definitely need to set the protocol to 'https', for the >>>>>>>>>> record. >>>>>>>>>> Beyond that I'm not quite sure. Do you have a full stack trace >>>>>>>>>> or >>>>>>>>>> just >>>>>>>>>> that part of it? >>>>>>>>>> >>>>>>>>>> On 12/8/2015 11:19 AM, Paul Blair wrote: >>>>>>>>>>> Not quite sure what to make of this: I'm getting >>>>>>>>>>> >>>>>>>>>>> org.apache.http.NoHttpResponseException: >>>>>>>>>>> [endpoint_URI]:443 >>>>>>>>>>> failed >>>>>>>>>>> to respond >>>>>>>>>>> >>>>>>>>>>> But if I do: >>>>>>>>>>> >>>>>>>>>>> curl https://[endpont_URI]:443 >>>>>>>>>>> >>>>>>>>>>> I get a response from Elasticsearch?this is because I have the >>>>>>>>>>> Amazon >>>>>>>>>>> Elasticsearch instance permissioned to accept any connections >>>>>>>>>>> from >>>>>>>>>>> the >>>>>>>>>>> IP address where apiman is running. >>>>>>>>>>> >>>>>>>>>>> The apiman configurations look like this: >>>>>>>>>>> >>>>>>>>>>> apiman.es.protocol=http >>>>>>>>>>> apiman.es.host=[endpoint_URI] >>>>>>>>>>> apiman.es.port=443 >>>>>>>>>>> apiman.es.username= >>>>>>>>>>> apiman.es.password= >>>>>>>>>>> >>>>>>>>>>> Changing protocol from http to https doesn't appear to help, nor >>>>>>>>>>> does >>>>>>>>>>> removing the username and password properties entirely. Any >>>>>>>>>>> suggestions? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 Dec 9 09:20:28 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 9 Dec 2015 09:20:28 -0500 Subject: [Apiman-user] Strange exception trying to initialize apiman database with Postgres In-Reply-To: References: Message-ID: <566838AC.9060805@redhat.com> OK - so I did some testing with not quite the same version of postgres. I think perhaps you didn't change the hibernate dialect? In the apiman.properties file (or in your case in the standalone-apiman.xml file) you need to set the dialect via this property: apiman.hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect I tried using postgres without changing the dialect and I got the same errors you did. So I'm hoping that's the issue. :) -Eric On 12/8/2015 9:09 PM, Paul Blair wrote: > I was able to work around this problem with the auditlog data column and > a few other columns using the ALTER TABLE statements below to convert to > a VARCHAR of shorter length than the error message demanded. However, > I'm now stymied by a subsequent error: "Wrong column type in > public.service_defs for column data. Found: oid, expected: blob" -- I > tried converting the type to bytea but this doesn't satisfy Hibernate. > > I feel like I've got the wrong version of a script here, but I was > careful to get the PostgreSQL script for apiman 1.1.9.Final. > > ALTER TABLE auditlog > ALTER COLUMN data TYPE varchar(10485760); > > ALTER TABLE gateways > ALTER COLUMN configuration TYPE varchar(10485760); > > ALTER TABLE policies > ALTER COLUMN configuration TYPE varchar(10485760); > > > > From: "pblair at clearme.com " > > > Date: Wed, 9 Dec 2015 01:53:05 +0000 > To: "apiman-user at lists.jboss.org " > > > Subject: [Apiman-user] Strange exception trying to initialize apiman > database with Postgres > > I'm getting a weird data type exception when issuing a request to the > API manager running against a Postgres instance: > > I'm using apiman 1.1.9 with the DDL for Postgres found here: > https://raw.githubusercontent.com/apiman/apiman/apiman-1.1.9.Final/distro/wildfly8/src/main/resources/overlay/apiman/ddls/apiman_postgresql9.ddl > > The DDL does make that into a text column; I'm not sure why Hibernate > doesn't like it and instead wants a VARCHAR that is too big for > Postgres. This is on PostgreSQL 9.4.4; my driver configuration in the > standalone-apiman.xml uses postgresql-9.3-1102-jdbc41.jar and doesn't > have any particular validation configuration. > > Relevant stack: > > UT005023: Exception handling request to /apiman/currentuser/info: > org.jboss.resteasy.spi.UnhandledException: > org.jboss.weld.exceptions.WeldException: WELD-000049: Unable to invoke > public void > io.apiman.manager.api.jpa.EntityManagerFactoryAccessor.postConstruct() > on io.apiman.manager.api.jpa.EntityManagerFactoryAccessor at 325203f1 > ? > Caused by: javax.persistence.PersistenceException: Unable to build > entity manager factory > ? > Caused by: org.hibernate.HibernateException: Wrong column type in > public.auditlog for column data. Found: text, expected > : varchar(2147483647) > at org.hibernate.mapping.Table.validateColumns(Table.java:372) > [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at > org.hibernate.cfg.Configuration.validateSchema(Configuration.java:1338) > [hibernate-core-4.3.7.Final.jar:4.3.7 > .Final] > ? > > > _______________________________________________ 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 Wed Dec 9 11:02:05 2015 From: ton at finalist.nl (Ton Swieb) Date: Wed, 9 Dec 2015 17:02:05 +0100 Subject: [Apiman-user] Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password Message-ID: Hi Marc, I got it working, without the SAML IdP, using the Keycloak Javascript adapter. I used the Keycloak JS-Console example and extended it with a javascript function that does a call the apiman-gateway after I have a logged in session with Keycloak. Something like: var client = new XMLHttpRequest(); client.open("GET", url, false); client.setRequestHeader("Accept", "application/json"); client.setRequestHeader("Authorization", "Bearer " + keycloak.token); client.send(); The keycloak.token is available after a call to keycloak.login(). Both are part of the Keycloak javascript adapter. Underneath the Javascript adapter still does a call similair to http://127.0.0.1:8080/auth/realms/stottie/protocol/openid-connect/token to retrieve the access token. With the difference that the grant_type used is authorization_code instead of password and a code is supplied instead of a username/password combination. I assume the code is retrieved from the keycloak session. Not sure how it exactly works, but it works. Next step will be to test it with the SAML IdP instead of standalone Keycloak, but I do not expect it to behave any differently. Regards, Ton 2015-12-08 19:00 GMT+01:00 Ton Swieb : > Hi Marc, > > I am using the following setup: > 1. Client -> Keycloak (apiman realm) -> SAML 2.0 IdP -> Keycloak (apiman > realm) -> Client > 2. Client -> apiman gateway -> Keycloak OAuth policy -> back-end -> apiman > gateway -> Client > > The IdP is a SAML 2.0 IdP. I believe it is SimpleSAMLPHP. > It is unclear to me why it matters which IdP I am using, because my > assumption is that: > > - I end up with a valid Keycloak session within the apiman realm > - the SAML 2.0 token should only be used by Keycloak to issue a login > session to the client. > - the client itself will never directly use anyhting from the SAML 2.0 > IdP, but should only use the stuff that Keycloak mapped from the SAML token > onto its own token. > > I did ask the question on the keycloak mailinglist, but from a different > angle. I am afraid the solution for my problem will be somewhere in between. > Any help from your site is greatly appreciated :-) > > Regards, > > Ton > > > Message: 5 > Date: Tue, 8 Dec 2015 16:58:26 +0000 > From: Marc Savy > Subject: Re: [Apiman-user] Keycloak OAuth2 policy: Get bearer token > for logged in user without using username/password > To: apiman-user at lists.jboss.org > Message-ID: <56670C32.3060000 at redhat.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > To expand on that - depending on exactly what type of IdP (and > specifically which technology) you were delegating to, it may be possible > to do what you're asking - or you may need to write something custom. > > Can you provide more detail? > > Also, if you have very specific Keycloak questions you might be best > served on the keycloak-user mailing list, which is extremely active ( > https://lists.jboss.org/mailman/listinfo/keycloak-user). > > On 08/12/2015 16:53, Marc Savy wrote: > > Hi Ton, > > > > I'm not quite sure what you mean, but I think what you're asking for is > > brokerage/delegation in the form: > > > > 1. Client <-> Keycloak <-> Other IdP. > > 2. Client <-> apiman gateway > > > > Regards, > > Marc > > > > On 08/12/2015 15:28, Ton Swieb wrote: > > > Hi, > > > > > > I would like to secure my api's using the Keycloak OAuth2 policy. > > > Similair to what is described in the blog post of Marc Savy: > > > > http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html > > > > > > > > > Only with the difference that Keycloak delegates the login to a third > > > party IdP. After logging in at this third party IdP I end up with an > > > active session in the Apiman UI (the apiman realm of Keycloak). > > > > > > Now I am wondering how to get the bearer token, because I do not have a > > > username/password combination I can use to make a call like: > > > > > > |curl -X POST > > > > http://127.0.0.1:8080/auth/realms/stottie/protocol/openid-connect/token > > > -H "Content-Type: application/x-www-form-urlencoded" -d > > > "username=rincewind" -d 'password=apiman' -d 'grant_type=password' -d > > > 'client_id=apiman'| > > > > > > Because the username/password combination is linked to the third party > > > IdP and not to Keycloak itself. > > > > > > Is there another way to obtain the bearer token? > > > > > > Perhaps this is aquestion which I should address at the keycloak > > > mailinglist. I will try to ask the question there as well. > > > > > > 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/20151209/c7b2375a/attachment.html From ton at finalist.nl Wed Dec 9 11:19:37 2015 From: ton at finalist.nl (Ton Swieb) Date: Wed, 9 Dec 2015 17:19:37 +0100 Subject: [Apiman-user] Using property placeholder in policy configuration which evaluate at runtime using system properties Message-ID: Hi, Is it possible to use property placeholders in policy configuration. The property placeholders should be evaluated at runtime based on a Java system property. For example. I have configured the realm property in the Keycloak Oauth policy to be: http://localhost:8080/auth/realms/apiman But instead of setting protocol://host:port hardcoded I want to use something like: {{protocol}}://{{host}:{port}/auth/realms/apiman or {{baseUrl}}/auth/realms/apiman The reason I want to use property placeholders is because of our Docker build. The Docker image is setup with a preconfigured Apiman installation. So the image already has some service published an policies applied. Only when building the image it is unknown on which host the image will run. In particular. The Keycloak OAuth policy is complaining as follows: { "type": "Authentication", "failureCode": 11004, "responseCode": 401, "message": "Token audience doesn't match domain. Token issuer is http://192.168.99.100:8080/auth/realms/apiman, but URL from configuration is http://localhost:8080/auth/realms/apiman", "headers": {} } I hope to solve this by using property placeholders which evaluate at runtime using a system property. Regards, Ton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151209/ebb7d336/attachment.html From eric.wittmann at redhat.com Wed Dec 9 11:35:04 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 9 Dec 2015 11:35:04 -0500 Subject: [Apiman-user] Using property placeholder in policy configuration which evaluate at runtime using system properties In-Reply-To: References: Message-ID: <56685838.6020603@redhat.com> Unfortunately that isn't currently supported. However it would be a relatively simple feature to add. Perhaps you could submit a JIRA feature request? If you do I'm sure we can have that included in 1.2.0.Final (due by the end of the month). -Eric On 12/9/2015 11:19 AM, Ton Swieb wrote: > Hi, > > Is it possible to use property placeholders in policy configuration. The > property placeholders should be evaluated at runtime based on a Java > system property. > > For example. > I have configured the realm property in the Keycloak Oauth policy to be: > http://localhost:8080/auth/realms/apiman > > But instead of setting protocol://host:port hardcoded I want to use > something like: > {{protocol}}://{{host}:{port}/auth/realms/apiman > or > {{baseUrl}}/auth/realms/apiman > > The reason I want to use property placeholders is because of our Docker > build. > The Docker image is setup with a preconfigured Apiman installation. So > the image already has some service published an policies applied. Only > when building the image it is unknown on which host the image will run. > > In particular. The Keycloak OAuth policy is complaining as follows: > > { > "type": "Authentication", > "failureCode": 11004, > "responseCode": 401, > "message": "Token audience doesn't match domain. Token issuer ishttp://192.168.99.100:8080/auth/realms/apiman, but URL from configuration ishttp://localhost:8080/auth/realms/apiman", > "headers": {} > } > > I hope to solve this by using property placeholders which evaluate at > runtime using a system property. > > 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 Wed Dec 9 11:37:01 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 9 Dec 2015 11:37:01 -0500 Subject: [Apiman-user] Having trouble connecting to Amazon Elasticsearch service In-Reply-To: References: Message-ID: <566858AD.5050604@redhat.com> Another update - I reset the allowed IP in AWS to be different from mine, and as expected it failed to connect. But I didn't get the same error as you - so it seems that you are running into something else that I can't reproduce. :( I could try using docker, but it will be awhile before I get a chance... On 12/8/2015 3:42 PM, Paul Blair wrote: > Mine looks like this, because I have the properties in the > standalone-apiman.xml -- but I'm pretty sure they are being read correctly > because the error message I get indicates that there is no response coming > from that host at that port, and then I curl using the host and port that > I copy from the error message. > > > value="${env.GATEWAY_PUBLIC_ENDPOINT:}"/> > > > > > > > > > When I start, I have only ES_HOST and ES_PORT in my environment. This is > in a Docker container, so the command looks like this: > > docker run --name apiman-gateway -p 9443:9443 -e > GATEWAY_PUBLIC_ENDPOINT=[URI] -e > ES_HOST=search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.amazonaws.co > m -e ES_PORT=443 [OTHER_ENV_VARIABLES] clear/api-gateway > > > When I curl from the Docker container, I get a response that looks like > this: > > $ curl > https://search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.amazonaws.co > m:443 > { > "status" : 200, > "name" : "Magnum", > "cluster_name" : "577360696927:testapi", > "version" : { > "number" : "1.5.2", > "build_hash" : "62ff9868b4c8a0c45860bebb259e21980778ab1c", > "build_timestamp" : "2015-04-27T09:21:06Z", > "build_snapshot" : false, > "lucene_version" : "4.10.4" > }, > "tagline" : "You Know, for Search" > } > > > > On 12/8/15, 3:33 PM, "Eric Wittmann" wrote: > >> I can't imagine the name of the domain could be important. Can you >> double-check your exact apiman.properties? It should be this: >> >> apiman.es.protocol=https >> apiman.es.host=search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.amaz >> onaws.com >> apiman.es.port=443 >> apiman.es.username= >> apiman.es.password= >> >> >> >> On 12/8/2015 3:26 PM, Paul Blair wrote: >>> When you create your domain, is it important what you name it? I named >>> it >>> testapi, so my endpoint looks like >>> >>> search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.amazonaws.com >>> >>> And the domain ARN is then >>> >>> arn:aws:es:us-west-2:577360696927:domain/testapi >>> >>> >>> On 12/8/15, 3:06 PM, "Eric Wittmann" wrote: >>> >>>> Testing using 1.1.9.Final against the AWS instance of elastic was >>>> successful. The only thing left for me to try is the access policy. >>>> Otherwise everything looks like it's working fine. Here is the >>>> relevant >>>> section of my apiman.properties file, for reference: >>>> >>>> apiman.es.protocol=https >>>> >>>> apiman.es.host=search-apiman-elastic-sarog5jew3xacrec5szeefvdm4.us-east- >>>> 1. >>>> es.amazonaws.com >>>> apiman.es.port=443 >>>> apiman.es.username= >>>> apiman.es.password= >>>> >>>> Here is some relevant curl output after my simple test: >>>> >>>> https://gist.github.com/EricWittmann/cc02a9ba6a2dee548a60 >>>> >>>> -Eric >>>> >>>> On 12/8/2015 1:13 PM, Paul Blair wrote: >>>>> It isn't too complicated -- I started here >>>>> https://aws.amazon.com/elasticsearch-service/ >>>>> >>>>> Basically you find "Elasticsearch Service" under the "Analytics" >>>>> section >>>>> of the AWS dashboard, hit the "Create a new domain" button, and follow >>>>> the >>>>> instructions. >>>>> >>>>> My access policy looks like this: >>>>> >>>>> { >>>>> "Version": "2012-10-17", >>>>> "Statement": [ >>>>> { >>>>> "Sid": "", >>>>> "Effect": "Allow", >>>>> "Principal": { >>>>> "AWS": "*" >>>>> }, >>>>> "Action": "es:*", >>>>> "Resource": "arn:aws:es:us-west-2[ARN]/*", >>>>> "Condition": { >>>>> "IpAddress": { >>>>> "aws:SourceIp": [ >>>>> "[IP ADDRESS 1]", "[CIDR BLOCK 2]",... >>>>> ] >>>>> } >>>>> } >>>>> } >>>>> ] >>>>> } >>>>> >>>>> >>>>> >>>>> On 12/8/15, 12:30 PM, "Eric Wittmann" >>>>> wrote: >>>>> >>>>>> Nope - I was worried that you were using 2.x, which we do not >>>>>> currently >>>>>> support. >>>>>> >>>>>> Do you happen to have any instructions handy for setting up an AMZ >>>>>> elasticsearch instance so I can try to reproduce this error? >>>>>> >>>>>> On 12/8/2015 12:28 PM, Paul Blair wrote: >>>>>>> Amazon says their current version is 1.5.2. Does apiman require >>>>>>> version >>>>>>> 2.x? >>>>>>> >>>>>>> On 12/8/15, 12:21 PM, "Eric Wittmann" >>>>>>> wrote: >>>>>>> >>>>>>>> What version of elasticsearch are you using? >>>>>>>> >>>>>>>> On 12/8/2015 12:12 PM, Paul Blair wrote: >>>>>>>>> The stack trace is below. Note that the instance seems to start >>>>>>>>> fine; >>>>>>>>> it's >>>>>>>>> only when I make a request to the Gateway that I get this error. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> 16:18:04,746 ERROR [io.undertow.request] (default task-1) >>>>>>>>> UT005023: >>>>>>>>> Exception handling request to /apiman-gateway/test_api/1.7: >>>>>>>>> java.lang.RuntimeException: >>>>>>>>> org.apache.http.NoHttpResponseException: >>>>>>>>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to >>>>>>>>> respond >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClie >>>>>>>>> nt >>>>>>>>> Fa >>>>>>>>> ct >>>>>>>>> or >>>>>>>>> y.java:200) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClie >>>>>>>>> nt >>>>>>>>> Fa >>>>>>>>> ct >>>>>>>>> or >>>>>>>>> y.java:140) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESClie >>>>>>>>> nt >>>>>>>>> Fa >>>>>>>>> ct >>>>>>>>> or >>>>>>>>> y.java:101) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.engine.es.ESClientFactory.createClient(ESClientFa >>>>>>>>> ct >>>>>>>>> or >>>>>>>>> y. >>>>>>>>> ja >>>>>>>>> va:66) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.engine.es.AbstractESComponent.getClient(AbstractE >>>>>>>>> SC >>>>>>>>> om >>>>>>>>> po >>>>>>>>> ne >>>>>>>>> nt.java:45) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:3 >>>>>>>>> 15 >>>>>>>>> ) >>>>>>>>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java:3 >>>>>>>>> 04 >>>>>>>>> ) >>>>>>>>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.engine.es.CachingESRegistry.getService(CachingESR >>>>>>>>> eg >>>>>>>>> is >>>>>>>>> tr >>>>>>>>> y. >>>>>>>>> java:189) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getService(Secu >>>>>>>>> re >>>>>>>>> Re >>>>>>>>> gi >>>>>>>>> st >>>>>>>>> ryWrapper.java:97) [apiman-gateway-engine-core-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.engine.impl.ServiceRequestExecutorImpl.execute(Se >>>>>>>>> rv >>>>>>>>> ic >>>>>>>>> eR >>>>>>>>> eq >>>>>>>>> uestExecutorImpl.java:252) >>>>>>>>> [apiman-gateway-engine-core-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(Gateway >>>>>>>>> Se >>>>>>>>> rv >>>>>>>>> le >>>>>>>>> t. >>>>>>>>> java:236) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.platforms.servlet.GatewayServlet.doGet(GatewaySer >>>>>>>>> vl >>>>>>>>> et >>>>>>>>> .j >>>>>>>>> av >>>>>>>>> a:82) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>>>>>>>> at >>>>>>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:687) >>>>>>>>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>>>>>>>> at >>>>>>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>>>>>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHa >>>>>>>>> nd >>>>>>>>> le >>>>>>>>> r. >>>>>>>>> ja >>>>>>>>> va:86) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.ha >>>>>>>>> nd >>>>>>>>> le >>>>>>>>> Re >>>>>>>>> qu >>>>>>>>> est(ServletSecurityRoleHandler.java:62) >>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleReques >>>>>>>>> t( >>>>>>>>> Se >>>>>>>>> rv >>>>>>>>> le >>>>>>>>> tDispatchingHandler.java:36) >>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.wildfly.extension.undertow.security.SecurityContextAssociationH >>>>>>>>> an >>>>>>>>> dl >>>>>>>>> er >>>>>>>>> .h >>>>>>>>> andleRequest(SecurityContextAssociationHandler.java:78) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(Predicat >>>>>>>>> eH >>>>>>>>> an >>>>>>>>> dl >>>>>>>>> er >>>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHand >>>>>>>>> le >>>>>>>>> r. >>>>>>>>> ha >>>>>>>>> nd >>>>>>>>> leRequest(SSLInformationAssociationHandler.java:131) >>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHand >>>>>>>>> le >>>>>>>>> r. >>>>>>>>> ha >>>>>>>>> nd >>>>>>>>> leRequest(ServletAuthenticationCallHandler.java:57) >>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(Predicat >>>>>>>>> eH >>>>>>>>> an >>>>>>>>> dl >>>>>>>>> er >>>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handle >>>>>>>>> Re >>>>>>>>> qu >>>>>>>>> es >>>>>>>>> t( >>>>>>>>> AbstractConfidentialityHandler.java:46) >>>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstra >>>>>>>>> in >>>>>>>>> tH >>>>>>>>> an >>>>>>>>> dl >>>>>>>>> er.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handl >>>>>>>>> eR >>>>>>>>> eq >>>>>>>>> ue >>>>>>>>> st >>>>>>>>> (AuthenticationMechanismsHandler.java:58) >>>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHan >>>>>>>>> dl >>>>>>>>> er >>>>>>>>> .h >>>>>>>>> an >>>>>>>>> dleRequest(CachedAuthenticatedSessionHandler.java:70) >>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.security.handlers.SecurityInitialHandler.handleRequest( >>>>>>>>> Se >>>>>>>>> cu >>>>>>>>> ri >>>>>>>>> ty >>>>>>>>> InitialHandler.java:76) >>>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(Predicat >>>>>>>>> eH >>>>>>>>> an >>>>>>>>> dl >>>>>>>>> er >>>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.h >>>>>>>>> an >>>>>>>>> dl >>>>>>>>> eR >>>>>>>>> eq >>>>>>>>> uest(JACCContextIdHandler.java:61) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(Predicat >>>>>>>>> eH >>>>>>>>> an >>>>>>>>> dl >>>>>>>>> er >>>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(Predicat >>>>>>>>> eH >>>>>>>>> an >>>>>>>>> dl >>>>>>>>> er >>>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstReque >>>>>>>>> st >>>>>>>>> (S >>>>>>>>> er >>>>>>>>> vl >>>>>>>>> etInitialHandler.java:261) >>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest( >>>>>>>>> Se >>>>>>>>> rv >>>>>>>>> le >>>>>>>>> tI >>>>>>>>> nitialHandler.java:248) >>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(Servl >>>>>>>>> et >>>>>>>>> In >>>>>>>>> it >>>>>>>>> ia >>>>>>>>> lHandler.java:77) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest( >>>>>>>>> Se >>>>>>>>> rv >>>>>>>>> le >>>>>>>>> tI >>>>>>>>> nitialHandler.java:167) >>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:19 >>>>>>>>> 9) >>>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java >>>>>>>>> :7 >>>>>>>>> 61 >>>>>>>>> ) >>>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecuto >>>>>>>>> r. >>>>>>>>> ja >>>>>>>>> va >>>>>>>>> :1 >>>>>>>>> 142) [rt.jar:1.8.0_25] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecut >>>>>>>>> or >>>>>>>>> .j >>>>>>>>> av >>>>>>>>> a: >>>>>>>>> 617) [rt.jar:1.8.0_25] >>>>>>>>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25] >>>>>>>>> Caused by: org.apache.http.NoHttpResponseException: >>>>>>>>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to >>>>>>>>> respond >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(Defau >>>>>>>>> lt >>>>>>>>> Ht >>>>>>>>> tp >>>>>>>>> Re >>>>>>>>> sponseParser.java:143) [httpclient-4.5.jar:4.5] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(Defau >>>>>>>>> lt >>>>>>>>> Ht >>>>>>>>> tp >>>>>>>>> Re >>>>>>>>> sponseParser.java:57) [httpclient-4.5.jar:4.5] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessage >>>>>>>>> Pa >>>>>>>>> rs >>>>>>>>> er >>>>>>>>> .j >>>>>>>>> ava:261) [httpcore-4.4.1.jar:4.4.1] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHe >>>>>>>>> ad >>>>>>>>> er >>>>>>>>> (D >>>>>>>>> ef >>>>>>>>> aultBHttpClientConnection.java:165) [httpcore-4.4.1.jar:4.4.1] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolPro >>>>>>>>> xy >>>>>>>>> .j >>>>>>>>> av >>>>>>>>> a: >>>>>>>>> 167) [httpclient-4.5.jar:4.5] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(Http >>>>>>>>> Re >>>>>>>>> qu >>>>>>>>> es >>>>>>>>> tE >>>>>>>>> xecutor.java:272) [httpcore-4.4.1.jar:4.4.1] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExe >>>>>>>>> cu >>>>>>>>> to >>>>>>>>> r. >>>>>>>>> ja >>>>>>>>> va:124) [httpcore-4.4.1.jar:4.4.1] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExe >>>>>>>>> c. >>>>>>>>> ja >>>>>>>>> va >>>>>>>>> :2 >>>>>>>>> 71) [httpclient-4.5.jar:4.5] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.ja >>>>>>>>> va >>>>>>>>> :1 >>>>>>>>> 84 >>>>>>>>> ) >>>>>>>>> [httpclient-4.5.jar:4.5] >>>>>>>>> at >>>>>>>>> >>>>>>>>> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) >>>>>>>>> [httpclient-4.5.jar:4.5] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.ja >>>>>>>>> va >>>>>>>>> :1 >>>>>>>>> 10 >>>>>>>>> ) >>>>>>>>> [httpclient-4.5.jar:4.5] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHt >>>>>>>>> tp >>>>>>>>> Cl >>>>>>>>> ie >>>>>>>>> nt >>>>>>>>> .java:184) [httpclient-4.5.jar:4.5] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHt >>>>>>>>> tp >>>>>>>>> Cl >>>>>>>>> ie >>>>>>>>> nt >>>>>>>>> .java:82) [httpclient-4.5.jar:4.5] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHt >>>>>>>>> tp >>>>>>>>> Cl >>>>>>>>> ie >>>>>>>>> nt >>>>>>>>> .java:107) [httpclient-4.5.jar:4.5] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.searchbox.client.http.JestHttpClient.execute(JestHttpClient.java >>>>>>>>> :5 >>>>>>>>> 0) >>>>>>>>> [jest-0.1.6.jar:] >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESClie >>>>>>>>> nt >>>>>>>>> Fa >>>>>>>>> ct >>>>>>>>> or >>>>>>>>> y.java:193) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>> ... 39 more >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 12/8/15, 11:48 AM, "Eric Wittmann" >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> You definitely need to set the protocol to 'https', for the >>>>>>>>>> record. >>>>>>>>>> Beyond that I'm not quite sure. Do you have a full stack trace >>>>>>>>>> or >>>>>>>>>> just >>>>>>>>>> that part of it? >>>>>>>>>> >>>>>>>>>> On 12/8/2015 11:19 AM, Paul Blair wrote: >>>>>>>>>>> Not quite sure what to make of this: I'm getting >>>>>>>>>>> >>>>>>>>>>> org.apache.http.NoHttpResponseException: >>>>>>>>>>> [endpoint_URI]:443 >>>>>>>>>>> failed >>>>>>>>>>> to respond >>>>>>>>>>> >>>>>>>>>>> But if I do: >>>>>>>>>>> >>>>>>>>>>> curl https://[endpont_URI]:443 >>>>>>>>>>> >>>>>>>>>>> I get a response from Elasticsearch?this is because I have the >>>>>>>>>>> Amazon >>>>>>>>>>> Elasticsearch instance permissioned to accept any connections >>>>>>>>>>> from >>>>>>>>>>> the >>>>>>>>>>> IP address where apiman is running. >>>>>>>>>>> >>>>>>>>>>> The apiman configurations look like this: >>>>>>>>>>> >>>>>>>>>>> apiman.es.protocol=http >>>>>>>>>>> apiman.es.host=[endpoint_URI] >>>>>>>>>>> apiman.es.port=443 >>>>>>>>>>> apiman.es.username= >>>>>>>>>>> apiman.es.password= >>>>>>>>>>> >>>>>>>>>>> Changing protocol from http to https doesn't appear to help, nor >>>>>>>>>>> does >>>>>>>>>>> removing the username and password properties entirely. Any >>>>>>>>>>> suggestions? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Apiman-user mailing list >>>>>>>>>>> Apiman-user at lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> > From ton at finalist.nl Wed Dec 9 14:31:56 2015 From: ton at finalist.nl (Ton Swieb) Date: Wed, 9 Dec 2015 20:31:56 +0100 Subject: [Apiman-user] Using property placeholder in policy configuration which evaluate at runtime using system properties In-Reply-To: <56685838.6020603@redhat.com> References: <56685838.6020603@redhat.com> Message-ID: Hi Eric, That would be great. I created: https://issues.jboss.org/browse/APIMAN-831 and https://issues.jboss.org/browse/APIMAN-832 The last one is a seperate issue for property placeholders in the gateway configuration endpoint. Regards, Ton 2015-12-09 17:35 GMT+01:00 Eric Wittmann : > Unfortunately that isn't currently supported. However it would be a > relatively simple feature to add. Perhaps you could submit a JIRA feature > request? If you do I'm sure we can have that included in 1.2.0.Final (due > by the end of the month). > > -Eric > > On 12/9/2015 11:19 AM, Ton Swieb wrote: > >> Hi, >> >> Is it possible to use property placeholders in policy configuration. The >> property placeholders should be evaluated at runtime based on a Java >> system property. >> >> For example. >> I have configured the realm property in the Keycloak Oauth policy to be: >> http://localhost:8080/auth/realms/apiman >> >> But instead of setting protocol://host:port hardcoded I want to use >> something like: >> {{protocol}}://{{host}:{port}/auth/realms/apiman >> or >> {{baseUrl}}/auth/realms/apiman >> >> The reason I want to use property placeholders is because of our Docker >> build. >> The Docker image is setup with a preconfigured Apiman installation. So >> the image already has some service published an policies applied. Only >> when building the image it is unknown on which host the image will run. >> >> In particular. The Keycloak OAuth policy is complaining as follows: >> >> { >> "type": "Authentication", >> "failureCode": 11004, >> "responseCode": 401, >> "message": "Token audience doesn't match domain. Token issuer ishttp:// >> 192.168.99.100:8080/auth/realms/apiman, but URL from configuration >> ishttp://localhost:8080/auth/realms/apiman", >> "headers": {} >> } >> >> I hope to solve this by using property placeholders which evaluate at >> runtime using a system property. >> >> 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/20151209/21e4c9d4/attachment-0001.html From eric.wittmann at redhat.com Wed Dec 9 15:29:34 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 9 Dec 2015 15:29:34 -0500 Subject: [Apiman-user] Using property placeholder in policy configuration which evaluate at runtime using system properties In-Reply-To: References: <56685838.6020603@redhat.com> Message-ID: <56688F2E.1040004@redhat.com> OK no problem. I've categorized and prioritized those two JIRAs appropriately. On 12/9/2015 2:31 PM, Ton Swieb wrote: > Hi Eric, > > That would be great. > I created: https://issues.jboss.org/browse/APIMAN-831 and > https://issues.jboss.org/browse/APIMAN-832 > > The last one is a seperate issue for property placeholders in the > gateway configuration endpoint. > > Regards, > > Ton > > > 2015-12-09 17:35 GMT+01:00 Eric Wittmann >: > > Unfortunately that isn't currently supported. However it would be a > relatively simple feature to add. Perhaps you could submit a JIRA > feature request? If you do I'm sure we can have that included in > 1.2.0.Final (due by the end of the month). > > -Eric > > On 12/9/2015 11:19 AM, Ton Swieb wrote: > > Hi, > > Is it possible to use property placeholders in policy > configuration. The > property placeholders should be evaluated at runtime based on a Java > system property. > > For example. > I have configured the realm property in the Keycloak Oauth > policy to be: > http://localhost:8080/auth/realms/apiman > > But instead of setting protocol://host:port hardcoded I want to use > something like: > {{protocol}}://{{host}:{port}/auth/realms/apiman > or > {{baseUrl}}/auth/realms/apiman > > The reason I want to use property placeholders is because of our > Docker > build. > The Docker image is setup with a preconfigured Apiman > installation. So > the image already has some service published an policies > applied. Only > when building the image it is unknown on which host the image > will run. > > In particular. The Keycloak OAuth policy is complaining as follows: > > { > "type": "Authentication", > "failureCode": 11004, > "responseCode": 401, > "message": "Token audience doesn't match domain. Token > issuer ishttp://192.168.99.100:8080/auth/realms/apiman > , but URL from > configuration ishttp://localhost:8080/auth/realms/apiman", > "headers": {} > } > > I hope to solve this by using property placeholders which > evaluate at > runtime using a system property. > > Regards, > > Ton > > > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > > From pblair at clearme.com Wed Dec 9 18:07:45 2015 From: pblair at clearme.com (Paul Blair) Date: Wed, 9 Dec 2015 23:07:45 +0000 Subject: [Apiman-user] Strange exception trying to initialize apiman database with Postgres In-Reply-To: <566838AC.9060805@redhat.com> Message-ID: OK, I see what's happening. I changed the dialect in the apiman.properties file that was supposed to be copied into the Docker container, but it wasn't actually being copied in, so the old H2 version was still there. Thanks for the tip; this really helped. On 12/9/15, 9:20 AM, "Eric Wittmann" wrote: >OK - so I did some testing with not quite the same version of postgres. > I think perhaps you didn't change the hibernate dialect? > >In the apiman.properties file (or in your case in the >standalone-apiman.xml file) you need to set the dialect via this property: > >apiman.hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect > >I tried using postgres without changing the dialect and I got the same >errors you did. So I'm hoping that's the issue. :) > >-Eric > >On 12/8/2015 9:09 PM, Paul Blair wrote: >> I was able to work around this problem with the auditlog data column and >> a few other columns using the ALTER TABLE statements below to convert to >> a VARCHAR of shorter length than the error message demanded. However, >> I'm now stymied by a subsequent error: "Wrong column type in >> public.service_defs for column data. Found: oid, expected: blob" -- I >> tried converting the type to bytea but this doesn't satisfy Hibernate. >> >> I feel like I've got the wrong version of a script here, but I was >> careful to get the PostgreSQL script for apiman 1.1.9.Final. >> >> ALTER TABLE auditlog >> ALTER COLUMN data TYPE varchar(10485760); >> >> ALTER TABLE gateways >> ALTER COLUMN configuration TYPE varchar(10485760); >> >> ALTER TABLE policies >> ALTER COLUMN configuration TYPE varchar(10485760); >> >> >> >> From: "pblair at clearme.com " >> > >> Date: Wed, 9 Dec 2015 01:53:05 +0000 >> To: "apiman-user at lists.jboss.org " >> > >> Subject: [Apiman-user] Strange exception trying to initialize apiman >> database with Postgres >> >> I'm getting a weird data type exception when issuing a request to the >> API manager running against a Postgres instance: >> >> I'm using apiman 1.1.9 with the DDL for Postgres found here: >> >>https://raw.githubusercontent.com/apiman/apiman/apiman-1.1.9.Final/distro >>/wildfly8/src/main/resources/overlay/apiman/ddls/apiman_postgresql9.ddl >> >> The DDL does make that into a text column; I'm not sure why Hibernate >> doesn't like it and instead wants a VARCHAR that is too big for >> Postgres. This is on PostgreSQL 9.4.4; my driver configuration in the >> standalone-apiman.xml uses postgresql-9.3-1102-jdbc41.jar and doesn't >> have any particular validation configuration. >> >> Relevant stack: >> >> UT005023: Exception handling request to /apiman/currentuser/info: >> org.jboss.resteasy.spi.UnhandledException: >> org.jboss.weld.exceptions.WeldException: WELD-000049: Unable to invoke >> public void >> io.apiman.manager.api.jpa.EntityManagerFactoryAccessor.postConstruct() >> on io.apiman.manager.api.jpa.EntityManagerFactoryAccessor at 325203f1 >> ? >> Caused by: javax.persistence.PersistenceException: Unable to build >> entity manager factory >> ? >> Caused by: org.hibernate.HibernateException: Wrong column type in >> public.auditlog for column data. Found: text, expected >> : varchar(2147483647) >> at org.hibernate.mapping.Table.validateColumns(Table.java:372) >> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at >> org.hibernate.cfg.Configuration.validateSchema(Configuration.java:1338) >> [hibernate-core-4.3.7.Final.jar:4.3.7 >> .Final] >> ? >> >> >> _______________________________________________ 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 Thu Dec 10 05:58:53 2015 From: marc.savy at redhat.com (Marc Savy) Date: Thu, 10 Dec 2015 10:58:53 +0000 Subject: [Apiman-user] Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password In-Reply-To: References: Message-ID: <56695AED.5070501@redhat.com> Your JS snippet is indeed typical of what happens in the real world - you generally wouldn't use a username and password in a plaintext JS app - instead you would use a client secret that can easily be regenerated (or login redirection for UI apps). What you're doing is the typical work-flow in JS; Keycloak's JS library does the work behind the scenes to do the heavy lifting for you. > Next step will be to test it with the SAML IdP instead of standalone > Keycloak, but I do not expect it to behave any differently. You mean you are setting up Keycloak to delegate to your SAML IdP? On 09/12/2015 16:02, Ton Swieb wrote: > Hi Marc, > > I got it working, without the SAML IdP, using the Keycloak Javascript > adapter. > > I used the Keycloak JS-Console example and extended it with a javascript > function that does a call the apiman-gateway after I have a logged in > session with Keycloak. Something like: > var client = new XMLHttpRequest(); > client.open("GET", url, false); > client.setRequestHeader("Accept", "application/json"); > client.setRequestHeader("Authorization", "Bearer " + > keycloak.token); > client.send(); > > The keycloak.token is available after a call to keycloak.login(). Both > are part of the Keycloak javascript adapter. > > Underneath the Javascript adapter still does a call similair to > http://127.0.0.1:8080/auth/realms/stottie/protocol/openid-connect/token > to retrieve the access token. With the difference that the grant_type > used is authorization_code instead of password and a code is supplied > instead of a username/password combination. I assume the code is > retrieved from the keycloak session. Not sure how it exactly works, but > it works. > > Next step will be to test it with the SAML IdP instead of standalone > Keycloak, but I do not expect it to behave any differently. > > Regards, > > Ton > > 2015-12-08 19:00 GMT+01:00 Ton Swieb >: > > Hi Marc, > > I am using the following setup: > 1. Client -> Keycloak (apiman realm) -> SAML 2.0 IdP -> Keycloak > (apiman realm) -> Client > 2. Client -> apiman gateway -> Keycloak OAuth policy -> back-end -> > apiman gateway -> Client > > The IdP is a SAML 2.0 IdP. I believe it is SimpleSAMLPHP. > It is unclear to me why it matters which IdP I am using, because my > assumption is that: > > * I end up with a valid Keycloak session within the apiman realm > * the SAML 2.0 token should only be used by Keycloak to issue a > login session to the client. > * the client itself will never directly use anyhting from the SAML > 2.0 IdP, but should only use the stuff that Keycloak mapped from > the SAML token onto its own token. > > I did ask the question on the keycloak mailinglist, but from a > different angle. I am afraid the solution for my problem will be > somewhere in between. > Any help from your site is greatly appreciated :-) > > Regards, > > Ton > > > Message: 5 > Date: Tue, 8 Dec 2015 16:58:26 +0000 > From: Marc Savy > > Subject: Re: [Apiman-user] Keycloak OAuth2 policy: Get bearer token > for logged in user without using username/password > To: apiman-user at lists.jboss.org > Message-ID: <56670C32.3060000 at redhat.com > > > Content-Type: text/plain; charset=UTF-8; format=flowed > > To expand on that - depending on exactly what type of IdP (and > specifically which technology) you were delegating to, it may be > possible to do what you're asking - or you may need to write > something custom. > > Can you provide more detail? > > Also, if you have very specific Keycloak questions you might be best > served on the keycloak-user mailing list, which is extremely active > (https://lists.jboss.org/mailman/listinfo/keycloak-user). > > On 08/12/2015 16:53, Marc Savy wrote: > > Hi Ton, > > > > I'm not quite sure what you mean, but I think what you're asking > for is > > brokerage/delegation in the form: > > > > 1. Client <-> Keycloak <-> Other IdP. > > 2. Client <-> apiman gateway > > > > Regards, > > Marc > > > > On 08/12/2015 15:28, Ton Swieb wrote: > > > Hi, > > > > > > I would like to secure my api's using the Keycloak OAuth2 policy. > > > Similair to what is described in the blog post of Marc Savy: > > > > http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html > > > > > > > > > Only with the difference that Keycloak delegates the login to a > third > > > party IdP. After logging in at this third party IdP I end up > with an > > > active session in the Apiman UI (the apiman realm of Keycloak). > > > > > > Now I am wondering how to get the bearer token, because I do > not have a > > > username/password combination I can use to make a call like: > > > > > > |curl -X POST > > > > http://127.0.0.1:8080/auth/realms/stottie/protocol/openid-connect/token > > > -H "Content-Type: application/x-www-form-urlencoded" -d > > > "username=rincewind" -d 'password=apiman' -d > 'grant_type=password' -d > > > 'client_id=apiman'| > > > > > > Because the username/password combination is linked to the > third party > > > IdP and not to Keycloak itself. > > > > > > Is there another way to obtain the bearer token? > > > > > > Perhaps this is aquestion which I should address at the keycloak > > > mailinglist. I will try to ask the question there as well. > > > > > > Regards, > > > > > > Ton > > > > > > > > > _______________________________________________ > > > Apiman-user mailing list > > > Apiman-user at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/apiman-user > > > > > > > From ton at finalist.nl Thu Dec 10 06:06:17 2015 From: ton at finalist.nl (Ton Swieb) Date: Thu, 10 Dec 2015 12:06:17 +0100 Subject: [Apiman-user] Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password In-Reply-To: <56695AED.5070501@redhat.com> References: <56695AED.5070501@redhat.com> Message-ID: Yes we have set up Keycloak to delegate to a SAML IdP. So a user is redirected to a SAML IdP for login. After successfull login the user is automatically logged in in Keycloak and we can use the JS adapter to obtain an access token for accessing the Apiman gateway. We have this roundtrip working now, but we do still have some challenges with the mapping the SAML attributes to the Keycloak token. 2015-12-10 11:58 GMT+01:00 Marc Savy : > Your JS snippet is indeed typical of what happens in the real world - > you generally wouldn't use a username and password in a plaintext > JS app - instead you would use a client secret that can easily be > regenerated (or login redirection for UI apps). > > What you're doing is the typical work-flow in JS; Keycloak's JS library > does the work behind the scenes to do the heavy lifting for you. > > Next step will be to test it with the SAML IdP instead of standalone >> Keycloak, but I do not expect it to behave any differently. >> > > You mean you are setting up Keycloak to delegate to your SAML IdP? > > On 09/12/2015 16:02, Ton Swieb wrote: > >> Hi Marc, >> >> I got it working, without the SAML IdP, using the Keycloak Javascript >> adapter. >> >> I used the Keycloak JS-Console example and extended it with a javascript >> function that does a call the apiman-gateway after I have a logged in >> session with Keycloak. Something like: >> var client = new XMLHttpRequest(); >> client.open("GET", url, false); >> client.setRequestHeader("Accept", "application/json"); >> client.setRequestHeader("Authorization", "Bearer " + >> keycloak.token); >> client.send(); >> >> The keycloak.token is available after a call to keycloak.login(). Both >> are part of the Keycloak javascript adapter. >> >> Underneath the Javascript adapter still does a call similair to >> http://127.0.0.1:8080/auth/realms/stottie/protocol/openid-connect/token >> to retrieve the access token. With the difference that the grant_type >> used is authorization_code instead of password and a code is supplied >> instead of a username/password combination. I assume the code is >> retrieved from the keycloak session. Not sure how it exactly works, but >> it works. >> >> Next step will be to test it with the SAML IdP instead of standalone >> Keycloak, but I do not expect it to behave any differently. >> >> Regards, >> >> Ton >> >> 2015-12-08 19:00 GMT+01:00 Ton Swieb > >: >> >> Hi Marc, >> >> I am using the following setup: >> 1. Client -> Keycloak (apiman realm) -> SAML 2.0 IdP -> Keycloak >> (apiman realm) -> Client >> 2. Client -> apiman gateway -> Keycloak OAuth policy -> back-end -> >> apiman gateway -> Client >> >> The IdP is a SAML 2.0 IdP. I believe it is SimpleSAMLPHP. >> It is unclear to me why it matters which IdP I am using, because my >> assumption is that: >> >> * I end up with a valid Keycloak session within the apiman realm >> * the SAML 2.0 token should only be used by Keycloak to issue a >> login session to the client. >> * the client itself will never directly use anyhting from the SAML >> 2.0 IdP, but should only use the stuff that Keycloak mapped from >> the SAML token onto its own token. >> >> I did ask the question on the keycloak mailinglist, but from a >> different angle. I am afraid the solution for my problem will be >> somewhere in between. >> Any help from your site is greatly appreciated :-) >> >> Regards, >> >> Ton >> >> >> Message: 5 >> Date: Tue, 8 Dec 2015 16:58:26 +0000 >> From: Marc Savy > >> Subject: Re: [Apiman-user] Keycloak OAuth2 policy: Get bearer token >> for logged in user without using username/password >> To: apiman-user at lists.jboss.org >> Message-ID: <56670C32.3060000 at redhat.com >> > >> Content-Type: text/plain; charset=UTF-8; format=flowed >> >> To expand on that - depending on exactly what type of IdP (and >> specifically which technology) you were delegating to, it may be >> possible to do what you're asking - or you may need to write >> something custom. >> >> Can you provide more detail? >> >> Also, if you have very specific Keycloak questions you might be best >> served on the keycloak-user mailing list, which is extremely active >> (https://lists.jboss.org/mailman/listinfo/keycloak-user). >> >> On 08/12/2015 16:53, Marc Savy wrote: >> > Hi Ton, >> > >> > I'm not quite sure what you mean, but I think what you're asking >> for is >> > brokerage/delegation in the form: >> > >> > 1. Client <-> Keycloak <-> Other IdP. >> > 2. Client <-> apiman gateway >> > >> > Regards, >> > Marc >> > >> > On 08/12/2015 15:28, Ton Swieb wrote: >> > > Hi, >> > > >> > > I would like to secure my api's using the Keycloak OAuth2 policy. >> > > Similair to what is described in the blog post of Marc Savy: >> > > >> >> http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html >> > > >> > > >> > > Only with the difference that Keycloak delegates the login to a >> third >> > > party IdP. After logging in at this third party IdP I end up >> with an >> > > active session in the Apiman UI (the apiman realm of Keycloak). >> > > >> > > Now I am wondering how to get the bearer token, because I do >> not have a >> > > username/password combination I can use to make a call like: >> > > >> > > |curl -X POST >> > > >> >> http://127.0.0.1:8080/auth/realms/stottie/protocol/openid-connect/token >> > > -H "Content-Type: application/x-www-form-urlencoded" -d >> > > "username=rincewind" -d 'password=apiman' -d >> 'grant_type=password' -d >> > > 'client_id=apiman'| >> > > >> > > Because the username/password combination is linked to the >> third party >> > > IdP and not to Keycloak itself. >> > > >> > > Is there another way to obtain the bearer token? >> > > >> > > Perhaps this is aquestion which I should address at the keycloak >> > > mailinglist. I will try to ask the question there as well. >> > > >> > > 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/20151210/2c0e998e/attachment-0001.html From marc.savy at redhat.com Thu Dec 10 06:10:05 2015 From: marc.savy at redhat.com (Marc Savy) Date: Thu, 10 Dec 2015 11:10:05 +0000 Subject: [Apiman-user] Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password In-Reply-To: References: <56695AED.5070501@redhat.com> Message-ID: <56695D8D.5040707@redhat.com> Nice! And understood - that should all work. If you feel the configuration options offered by the Keycloak OAuth2 policy let me know, and we can work out what changes might be possible to help. On 10/12/2015 11:06, Ton Swieb wrote: > Yes we have set up Keycloak to delegate to a SAML IdP. So a user is > redirected to a SAML IdP for login. After successfull login the user is > automatically logged in in Keycloak and we can use the JS adapter to > obtain an access token for accessing the Apiman gateway. > We have this roundtrip working now, but we do still have some challenges > with the mapping the SAML attributes to the Keycloak token. > > > 2015-12-10 11:58 GMT+01:00 Marc Savy >: > > Your JS snippet is indeed typical of what happens in the real world - > you generally wouldn't use a username and password in a plaintext > JS app - instead you would use a client secret that can easily be > regenerated (or login redirection for UI apps). > > What you're doing is the typical work-flow in JS; Keycloak's JS library > does the work behind the scenes to do the heavy lifting for you. > > Next step will be to test it with the SAML IdP instead of standalone > Keycloak, but I do not expect it to behave any differently. > > > You mean you are setting up Keycloak to delegate to your SAML IdP? > > On 09/12/2015 16:02, Ton Swieb wrote: > > Hi Marc, > > I got it working, without the SAML IdP, using the Keycloak > Javascript > adapter. > > I used the Keycloak JS-Console example and extended it with a > javascript > function that does a call the apiman-gateway after I have a > logged in > session with Keycloak. Something like: > var client = new XMLHttpRequest(); > client.open("GET", url, false); > client.setRequestHeader("Accept", "application/json"); > client.setRequestHeader("Authorization", "Bearer " + > keycloak.token); > client.send(); > > The keycloak.token is available after a call to > keycloak.login(). Both > are part of the Keycloak javascript adapter. > > Underneath the Javascript adapter still does a call similair to > http://127.0.0.1:8080/auth/realms/stottie/protocol/openid-connect/token > to retrieve the access token. With the difference that the > grant_type > used is authorization_code instead of password and a code is > supplied > instead of a username/password combination. I assume the code is > retrieved from the keycloak session. Not sure how it exactly > works, but > it works. > > Next step will be to test it with the SAML IdP instead of standalone > Keycloak, but I do not expect it to behave any differently. > > Regards, > > Ton > > 2015-12-08 19:00 GMT+01:00 Ton Swieb > >>: > > Hi Marc, > > I am using the following setup: > 1. Client -> Keycloak (apiman realm) -> SAML 2.0 IdP -> > Keycloak > (apiman realm) -> Client > 2. Client -> apiman gateway -> Keycloak OAuth policy -> > back-end -> > apiman gateway -> Client > > The IdP is a SAML 2.0 IdP. I believe it is SimpleSAMLPHP. > It is unclear to me why it matters which IdP I am using, > because my > assumption is that: > > * I end up with a valid Keycloak session within the > apiman realm > * the SAML 2.0 token should only be used by Keycloak to > issue a > login session to the client. > * the client itself will never directly use anyhting from > the SAML > 2.0 IdP, but should only use the stuff that Keycloak > mapped from > the SAML token onto its own token. > > I did ask the question on the keycloak mailinglist, but from a > different angle. I am afraid the solution for my problem > will be > somewhere in between. > Any help from your site is greatly appreciated :-) > > Regards, > > Ton > > > Message: 5 > Date: Tue, 8 Dec 2015 16:58:26 +0000 > From: Marc Savy >> > Subject: Re: [Apiman-user] Keycloak OAuth2 policy: Get > bearer token > for logged in user without using username/password > To: apiman-user at lists.jboss.org > > > > Message-ID: <56670C32.3060000 at redhat.com > > >> > Content-Type: text/plain; charset=UTF-8; format=flowed > > To expand on that - depending on exactly what type of IdP (and > specifically which technology) you were delegating to, it > may be > possible to do what you're asking - or you may need to write > something custom. > > Can you provide more detail? > > Also, if you have very specific Keycloak questions you > might be best > served on the keycloak-user mailing list, which is > extremely active > (https://lists.jboss.org/mailman/listinfo/keycloak-user). > > On 08/12/2015 16:53, Marc Savy wrote: > > Hi Ton, > > > > I'm not quite sure what you mean, but I think what > you're asking > for is > > brokerage/delegation in the form: > > > > 1. Client <-> Keycloak <-> Other IdP. > > 2. Client <-> apiman gateway > > > > Regards, > > Marc > > > > On 08/12/2015 15:28, Ton Swieb wrote: > > > Hi, > > > > > > I would like to secure my api's using the Keycloak > OAuth2 policy. > > > Similair to what is described in the blog post of Marc > Savy: > > > > http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html > > > > > > > > > Only with the difference that Keycloak delegates the > login to a > third > > > party IdP. After logging in at this third party IdP I > end up > with an > > > active session in the Apiman UI (the apiman realm of > Keycloak). > > > > > > Now I am wondering how to get the bearer token, > because I do > not have a > > > username/password combination I can use to make a call > like: > > > > > > |curl -X POST > > > > http://127.0.0.1:8080/auth/realms/stottie/protocol/openid-connect/token > > > -H "Content-Type: application/x-www-form-urlencoded" -d > > > "username=rincewind" -d 'password=apiman' -d > 'grant_type=password' -d > > > 'client_id=apiman'| > > > > > > Because the username/password combination is linked to the > third party > > > IdP and not to Keycloak itself. > > > > > > Is there another way to obtain the bearer token? > > > > > > Perhaps this is aquestion which I should address at > the keycloak > > > mailinglist. I will try to ask the question there as well. > > > > > > Regards, > > > > > > Ton > > > > > > > > > _______________________________________________ > > > Apiman-user mailing list > > > Apiman-user at lists.jboss.org > > > > > > https://lists.jboss.org/mailman/listinfo/apiman-user > > > > > > > > > From marc.savy at redhat.com Thu Dec 10 06:12:10 2015 From: marc.savy at redhat.com (Marc Savy) Date: Thu, 10 Dec 2015 11:12:10 +0000 Subject: [Apiman-user] Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password In-Reply-To: <56695D8D.5040707@redhat.com> References: <56695AED.5070501@redhat.com> <56695D8D.5040707@redhat.com> Message-ID: <56695E0A.8050709@redhat.com> Sorry, missed out part of my sentence: If you feel the configuration options offered by the Keycloak OAuth2 policy *are insufficient* let me know, and we can work out what changes might be possible to help. On 10/12/2015 11:10, Marc Savy wrote: > Nice! And understood - that should all work. If you feel the > configuration options offered by the Keycloak OAuth2 policy let me know, > and we can work out what changes might be possible to help. > > On 10/12/2015 11:06, Ton Swieb wrote: > > Yes we have set up Keycloak to delegate to a SAML IdP. So a user is > > redirected to a SAML IdP for login. After successfull login the user is > > automatically logged in in Keycloak and we can use the JS adapter to > > obtain an access token for accessing the Apiman gateway. > > We have this roundtrip working now, but we do still have some challenges > > with the mapping the SAML attributes to the Keycloak token. > > > > > > 2015-12-10 11:58 GMT+01:00 Marc Savy > >: > > > > Your JS snippet is indeed typical of what happens in the real world - > > you generally wouldn't use a username and password in a plaintext > > JS app - instead you would use a client secret that can easily be > > regenerated (or login redirection for UI apps). > > > > What you're doing is the typical work-flow in JS; Keycloak's JS library > > does the work behind the scenes to do the heavy lifting for you. > > > > Next step will be to test it with the SAML IdP instead of standalone > > Keycloak, but I do not expect it to behave any differently. > > > > > > You mean you are setting up Keycloak to delegate to your SAML IdP? > > > > On 09/12/2015 16:02, Ton Swieb wrote: > > > > Hi Marc, > > > > I got it working, without the SAML IdP, using the Keycloak > > Javascript > > adapter. > > > > I used the Keycloak JS-Console example and extended it with a > > javascript > > function that does a call the apiman-gateway after I have a > > logged in > > session with Keycloak. Something like: > > var client = new XMLHttpRequest(); > > client.open("GET", url, false); > > client.setRequestHeader("Accept", "application/json"); > > client.setRequestHeader("Authorization", "Bearer " + > > keycloak.token); > > client.send(); > > > > The keycloak.token is available after a call to > > keycloak.login(). Both > > are part of the Keycloak javascript adapter. > > > > Underneath the Javascript adapter still does a call similair to > > http://127.0.0.1:8080/auth/realms/stottie/protocol/openid-connect/token > > to retrieve the access token. With the difference that the > > grant_type > > used is authorization_code instead of password and a code is > > supplied > > instead of a username/password combination. I assume the code is > > retrieved from the keycloak session. Not sure how it exactly > > works, but > > it works. > > > > Next step will be to test it with the SAML IdP instead of standalone > > Keycloak, but I do not expect it to behave any differently. > > > > Regards, > > > > Ton > > > > 2015-12-08 19:00 GMT+01:00 Ton Swieb > > > >>: > > > > Hi Marc, > > > > I am using the following setup: > > 1. Client -> Keycloak (apiman realm) -> SAML 2.0 IdP -> > > Keycloak > > (apiman realm) -> Client > > 2. Client -> apiman gateway -> Keycloak OAuth policy -> > > back-end -> > > apiman gateway -> Client > > > > The IdP is a SAML 2.0 IdP. I believe it is SimpleSAMLPHP. > > It is unclear to me why it matters which IdP I am using, > > because my > > assumption is that: > > > > * I end up with a valid Keycloak session within the > > apiman realm > > * the SAML 2.0 token should only be used by Keycloak to > > issue a > > login session to the client. > > * the client itself will never directly use anyhting from > > the SAML > > 2.0 IdP, but should only use the stuff that Keycloak > > mapped from > > the SAML token onto its own token. > > > > I did ask the question on the keycloak mailinglist, but from a > > different angle. I am afraid the solution for my problem > > will be > > somewhere in between. > > Any help from your site is greatly appreciated :-) > > > > Regards, > > > > Ton > > > > > > Message: 5 > > Date: Tue, 8 Dec 2015 16:58:26 +0000 > > From: Marc Savy > > >> > > Subject: Re: [Apiman-user] Keycloak OAuth2 policy: Get > > bearer token > > for logged in user without using username/password > > To: apiman-user at lists.jboss.org > > > > > > > > Message-ID: <56670C32.3060000 at redhat.com > > > > > >> > > Content-Type: text/plain; charset=UTF-8; format=flowed > > > > To expand on that - depending on exactly what type of IdP (and > > specifically which technology) you were delegating to, it > > may be > > possible to do what you're asking - or you may need to write > > something custom. > > > > Can you provide more detail? > > > > Also, if you have very specific Keycloak questions you > > might be best > > served on the keycloak-user mailing list, which is > > extremely active > > (https://lists.jboss.org/mailman/listinfo/keycloak-user). > > > > On 08/12/2015 16:53, Marc Savy wrote: > > > Hi Ton, > > > > > > I'm not quite sure what you mean, but I think what > > you're asking > > for is > > > brokerage/delegation in the form: > > > > > > 1. Client <-> Keycloak <-> Other IdP. > > > 2. Client <-> apiman gateway > > > > > > Regards, > > > Marc > > > > > > On 08/12/2015 15:28, Ton Swieb wrote: > > > > Hi, > > > > > > > > I would like to secure my api's using the Keycloak > > OAuth2 policy. > > > > Similair to what is described in the blog post of Marc > > Savy: > > > > > > http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html > > > > > > > > > > > > Only with the difference that Keycloak delegates the > > login to a > > third > > > > party IdP. After logging in at this third party IdP I > > end up > > with an > > > > active session in the Apiman UI (the apiman realm of > > Keycloak). > > > > > > > > Now I am wondering how to get the bearer token, > > because I do > > not have a > > > > username/password combination I can use to make a call > > like: > > > > > > > > |curl -X POST > > > > > > http://127.0.0.1:8080/auth/realms/stottie/protocol/openid-connect/token > > > > -H "Content-Type: application/x-www-form-urlencoded" -d > > > > "username=rincewind" -d 'password=apiman' -d > > 'grant_type=password' -d > > > > 'client_id=apiman'| > > > > > > > > Because the username/password combination is linked to the > > third party > > > > IdP and not to Keycloak itself. > > > > > > > > Is there another way to obtain the bearer token? > > > > > > > > Perhaps this is aquestion which I should address at > > the keycloak > > > > mailinglist. I will try to ask the question there as well. > > > > > > > > Regards, > > > > > > > > Ton > > > > > > > > > > > > _______________________________________________ > > > > 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 Dec 10 07:40:55 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 10 Dec 2015 07:40:55 -0500 Subject: [Apiman-user] Strange exception trying to initialize apiman database with Postgres In-Reply-To: References: Message-ID: <566972D7.9060906@redhat.com> OK no worries. I should probably add this to an FAQ somewhere. Happens more than you'd think. On 12/9/2015 6:07 PM, Paul Blair wrote: > OK, I see what's happening. I changed the dialect in the apiman.properties > file that was supposed to be > copied into the Docker container, but it wasn't actually being copied in, > so the old H2 version was still there. > > Thanks for the tip; this really helped. > > On 12/9/15, 9:20 AM, "Eric Wittmann" wrote: > >> OK - so I did some testing with not quite the same version of postgres. >> I think perhaps you didn't change the hibernate dialect? >> >> In the apiman.properties file (or in your case in the >> standalone-apiman.xml file) you need to set the dialect via this property: >> >> apiman.hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect >> >> I tried using postgres without changing the dialect and I got the same >> errors you did. So I'm hoping that's the issue. :) >> >> -Eric >> >> On 12/8/2015 9:09 PM, Paul Blair wrote: >>> I was able to work around this problem with the auditlog data column and >>> a few other columns using the ALTER TABLE statements below to convert to >>> a VARCHAR of shorter length than the error message demanded. However, >>> I'm now stymied by a subsequent error: "Wrong column type in >>> public.service_defs for column data. Found: oid, expected: blob" -- I >>> tried converting the type to bytea but this doesn't satisfy Hibernate. >>> >>> I feel like I've got the wrong version of a script here, but I was >>> careful to get the PostgreSQL script for apiman 1.1.9.Final. >>> >>> ALTER TABLE auditlog >>> ALTER COLUMN data TYPE varchar(10485760); >>> >>> ALTER TABLE gateways >>> ALTER COLUMN configuration TYPE varchar(10485760); >>> >>> ALTER TABLE policies >>> ALTER COLUMN configuration TYPE varchar(10485760); >>> >>> >>> >>> From: "pblair at clearme.com " >>> > >>> Date: Wed, 9 Dec 2015 01:53:05 +0000 >>> To: "apiman-user at lists.jboss.org " >>> > >>> Subject: [Apiman-user] Strange exception trying to initialize apiman >>> database with Postgres >>> >>> I'm getting a weird data type exception when issuing a request to the >>> API manager running against a Postgres instance: >>> >>> I'm using apiman 1.1.9 with the DDL for Postgres found here: >>> >>> https://raw.githubusercontent.com/apiman/apiman/apiman-1.1.9.Final/distro >>> /wildfly8/src/main/resources/overlay/apiman/ddls/apiman_postgresql9.ddl >>> >>> The DDL does make that into a text column; I'm not sure why Hibernate >>> doesn't like it and instead wants a VARCHAR that is too big for >>> Postgres. This is on PostgreSQL 9.4.4; my driver configuration in the >>> standalone-apiman.xml uses postgresql-9.3-1102-jdbc41.jar and doesn't >>> have any particular validation configuration. >>> >>> Relevant stack: >>> >>> UT005023: Exception handling request to /apiman/currentuser/info: >>> org.jboss.resteasy.spi.UnhandledException: >>> org.jboss.weld.exceptions.WeldException: WELD-000049: Unable to invoke >>> public void >>> io.apiman.manager.api.jpa.EntityManagerFactoryAccessor.postConstruct() >>> on io.apiman.manager.api.jpa.EntityManagerFactoryAccessor at 325203f1 >>> ? >>> Caused by: javax.persistence.PersistenceException: Unable to build >>> entity manager factory >>> ? >>> Caused by: org.hibernate.HibernateException: Wrong column type in >>> public.auditlog for column data. Found: text, expected >>> : varchar(2147483647) >>> at org.hibernate.mapping.Table.validateColumns(Table.java:372) >>> [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at >>> org.hibernate.cfg.Configuration.validateSchema(Configuration.java:1338) >>> [hibernate-core-4.3.7.Final.jar:4.3.7 >>> .Final] >>> ? >>> >>> >>> _______________________________________________ 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 Thu Dec 10 10:56:54 2015 From: ton at finalist.nl (Ton Swieb) Date: Thu, 10 Dec 2015 16:56:54 +0100 Subject: [Apiman-user] Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password In-Reply-To: <56695E0A.8050709@redhat.com> References: <56695AED.5070501@redhat.com> <56695D8D.5040707@redhat.com> <56695E0A.8050709@redhat.com> Message-ID: Hi Marc, Thanks. The plugin functionality for the roundtrip in our Proof of Concept setup is sufficient. In the future I expect that we would need more flexibility in the mapping of access token properties onto headers. Regards, Ton 2015-12-10 12:12 GMT+01:00 Marc Savy : > Sorry, missed out part of my sentence: > > If you feel the configuration options offered by the Keycloak OAuth2 > policy *are insufficient* let me know, > and we can work out what changes might be possible to help. > > On 10/12/2015 11:10, Marc Savy wrote: > >> Nice! And understood - that should all work. If you feel the >> configuration options offered by the Keycloak OAuth2 policy let me know, >> and we can work out what changes might be possible to help. >> >> On 10/12/2015 11:06, Ton Swieb wrote: >> > Yes we have set up Keycloak to delegate to a SAML IdP. So a user is >> > redirected to a SAML IdP for login. After successfull login the user is >> > automatically logged in in Keycloak and we can use the JS adapter to >> > obtain an access token for accessing the Apiman gateway. >> > We have this roundtrip working now, but we do still have some challenges >> > with the mapping the SAML attributes to the Keycloak token. >> > >> > >> > 2015-12-10 11:58 GMT+01:00 Marc Savy > > >: >> > >> > Your JS snippet is indeed typical of what happens in the real >> world - >> > you generally wouldn't use a username and password in a plaintext >> > JS app - instead you would use a client secret that can easily be >> > regenerated (or login redirection for UI apps). >> > >> > What you're doing is the typical work-flow in JS; Keycloak's JS >> library >> > does the work behind the scenes to do the heavy lifting for you. >> > >> > Next step will be to test it with the SAML IdP instead of >> standalone >> > Keycloak, but I do not expect it to behave any differently. >> > >> > >> > You mean you are setting up Keycloak to delegate to your SAML IdP? >> > >> > On 09/12/2015 16:02, Ton Swieb wrote: >> > >> > Hi Marc, >> > >> > I got it working, without the SAML IdP, using the Keycloak >> > Javascript >> > adapter. >> > >> > I used the Keycloak JS-Console example and extended it with a >> > javascript >> > function that does a call the apiman-gateway after I have a >> > logged in >> > session with Keycloak. Something like: >> > var client = new XMLHttpRequest(); >> > client.open("GET", url, false); >> > client.setRequestHeader("Accept", >> "application/json"); >> > client.setRequestHeader("Authorization", "Bearer " + >> > keycloak.token); >> > client.send(); >> > >> > The keycloak.token is available after a call to >> > keycloak.login(). Both >> > are part of the Keycloak javascript adapter. >> > >> > Underneath the Javascript adapter still does a call similair to >> > >> http://127.0.0.1:8080/auth/realms/stottie/protocol/openid-connect/token >> > to retrieve the access token. With the difference that the >> > grant_type >> > used is authorization_code instead of password and a code is >> > supplied >> > instead of a username/password combination. I assume the code >> is >> > retrieved from the keycloak session. Not sure how it exactly >> > works, but >> > it works. >> > >> > Next step will be to test it with the SAML IdP instead of >> standalone >> > Keycloak, but I do not expect it to behave any differently. >> > >> > Regards, >> > >> > Ton >> > >> > 2015-12-08 19:00 GMT+01:00 Ton Swieb > > >> > >>: >> > >> > Hi Marc, >> > >> > I am using the following setup: >> > 1. Client -> Keycloak (apiman realm) -> SAML 2.0 IdP -> >> > Keycloak >> > (apiman realm) -> Client >> > 2. Client -> apiman gateway -> Keycloak OAuth policy -> >> > back-end -> >> > apiman gateway -> Client >> > >> > The IdP is a SAML 2.0 IdP. I believe it is SimpleSAMLPHP. >> > It is unclear to me why it matters which IdP I am using, >> > because my >> > assumption is that: >> > >> > * I end up with a valid Keycloak session within the >> > apiman realm >> > * the SAML 2.0 token should only be used by Keycloak to >> > issue a >> > login session to the client. >> > * the client itself will never directly use anyhting >> from >> > the SAML >> > 2.0 IdP, but should only use the stuff that Keycloak >> > mapped from >> > the SAML token onto its own token. >> > >> > I did ask the question on the keycloak mailinglist, but >> from a >> > different angle. I am afraid the solution for my problem >> > will be >> > somewhere in between. >> > Any help from your site is greatly appreciated :-) >> > >> > Regards, >> > >> > Ton >> > >> > >> > Message: 5 >> > Date: Tue, 8 Dec 2015 16:58:26 +0000 >> > From: Marc Savy > > > > >> >> > Subject: Re: [Apiman-user] Keycloak OAuth2 policy: Get >> > bearer token >> > for logged in user without using >> username/password >> > To: apiman-user at lists.jboss.org >> > >> > > > > >> > Message-ID: <56670C32.3060000 at redhat.com >> > >> > > > >> >> > Content-Type: text/plain; charset=UTF-8; format=flowed >> > >> > To expand on that - depending on exactly what type of IdP >> (and >> > specifically which technology) you were delegating to, it >> > may be >> > possible to do what you're asking - or you may need to >> write >> > something custom. >> > >> > Can you provide more detail? >> > >> > Also, if you have very specific Keycloak questions you >> > might be best >> > served on the keycloak-user mailing list, which is >> > extremely active >> > (https://lists.jboss.org/mailman/listinfo/keycloak-user). >> > >> > On 08/12/2015 16:53, Marc Savy wrote: >> > > Hi Ton, >> > > >> > > I'm not quite sure what you mean, but I think what >> > you're asking >> > for is >> > > brokerage/delegation in the form: >> > > >> > > 1. Client <-> Keycloak <-> Other IdP. >> > > 2. Client <-> apiman gateway >> > > >> > > Regards, >> > > Marc >> > > >> > > On 08/12/2015 15:28, Ton Swieb wrote: >> > > > Hi, >> > > > >> > > > I would like to secure my api's using the Keycloak >> > OAuth2 policy. >> > > > Similair to what is described in the blog post of >> Marc >> > Savy: >> > > > >> > >> http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html >> > > > >> > > > >> > > > Only with the difference that Keycloak delegates the >> > login to a >> > third >> > > > party IdP. After logging in at this third party IdP I >> > end up >> > with an >> > > > active session in the Apiman UI (the apiman realm of >> > Keycloak). >> > > > >> > > > Now I am wondering how to get the bearer token, >> > because I do >> > not have a >> > > > username/password combination I can use to make a >> call >> > like: >> > > > >> > > > |curl -X POST >> > > > >> > >> http://127.0.0.1:8080/auth/realms/stottie/protocol/openid-connect/token >> > > > -H "Content-Type: application/x-www-form-urlencoded" >> -d >> > > > "username=rincewind" -d 'password=apiman' -d >> > 'grant_type=password' -d >> > > > 'client_id=apiman'| >> > > > >> > > > Because the username/password combination is linked >> to the >> > third party >> > > > IdP and not to Keycloak itself. >> > > > >> > > > Is there another way to obtain the bearer token? >> > > > >> > > > Perhaps this is aquestion which I should address at >> > the keycloak >> > > > mailinglist. I will try to ask the question there as >> well. >> > > > >> > > > Regards, >> > > > >> > > > Ton >> > > > >> > > > >> > > > _______________________________________________ >> > > > 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/20151210/1cf64506/attachment-0001.html From msavy at redhat.com Thu Dec 10 11:41:43 2015 From: msavy at redhat.com (Marc Savy) Date: Thu, 10 Dec 2015 11:41:43 -0500 (EST) Subject: [Apiman-user] Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password In-Reply-To: References: <56695AED.5070501@redhat.com> <56695D8D.5040707@redhat.com> <56695E0A.8050709@redhat.com> Message-ID: <201260241.37561026.1449765703238.JavaMail.zimbra@redhat.com> Ton, I've added a JIRA for your feature request/enhancement - https://issues.jboss.org/browse/APIMAN-834 Marc ----- Original Message ----- From: "Ton Swieb" To: "Marc Savy" Cc: apiman-user at lists.jboss.org Sent: Thursday, 10 December, 2015 3:56:54 PM Subject: Re: [Apiman-user] Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password Hi Marc, Thanks. The plugin functionality for the roundtrip in our Proof of Concept setup is sufficient. In the future I expect that we would need more flexibility in the mapping of access token properties onto headers. Regards, Ton 2015-12-10 12:12 GMT+01:00 Marc Savy < marc.savy at redhat.com > : Sorry, missed out part of my sentence: If you feel the configuration options offered by the Keycloak OAuth2 policy *are insufficient* let me know, and we can work out what changes might be possible to help. On 10/12/2015 11:10, Marc Savy wrote: Nice! And understood - that should all work. If you feel the configuration options offered by the Keycloak OAuth2 policy let me know, and we can work out what changes might be possible to help. On 10/12/2015 11:06, Ton Swieb wrote: > Yes we have set up Keycloak to delegate to a SAML IdP. So a user is > redirected to a SAML IdP for login. After successfull login the user is > automatically logged in in Keycloak and we can use the JS adapter to > obtain an access token for accessing the Apiman gateway. > We have this roundtrip working now, but we do still have some challenges > with the mapping the SAML attributes to the Keycloak token. > > > 2015-12-10 11:58 GMT+01:00 Marc Savy < marc.savy at redhat.com > >: > > Your JS snippet is indeed typical of what happens in the real world - > you generally wouldn't use a username and password in a plaintext > JS app - instead you would use a client secret that can easily be > regenerated (or login redirection for UI apps). > > What you're doing is the typical work-flow in JS; Keycloak's JS library > does the work behind the scenes to do the heavy lifting for you. > > Next step will be to test it with the SAML IdP instead of standalone > Keycloak, but I do not expect it to behave any differently. > > > You mean you are setting up Keycloak to delegate to your SAML IdP? > > On 09/12/2015 16:02, Ton Swieb wrote: > > Hi Marc, > > I got it working, without the SAML IdP, using the Keycloak > Javascript > adapter. > > I used the Keycloak JS-Console example and extended it with a > javascript > function that does a call the apiman-gateway after I have a > logged in > session with Keycloak. Something like: > var client = new XMLHttpRequest(); > client.open("GET", url, false); > client.setRequestHeader("Accept", "application/json"); > client.setRequestHeader("Authorization", "Bearer " + > keycloak.token); > client.send(); > > The keycloak.token is available after a call to > keycloak.login(). Both > are part of the Keycloak javascript adapter. > > Underneath the Javascript adapter still does a call similair to > http://127.0.0.1:8080/auth/realms/stottie/protocol/openid-connect/token > to retrieve the access token. With the difference that the > grant_type > used is authorization_code instead of password and a code is > supplied > instead of a username/password combination. I assume the code is > retrieved from the keycloak session. Not sure how it exactly > works, but > it works. > > Next step will be to test it with the SAML IdP instead of standalone > Keycloak, but I do not expect it to behave any differently. > > Regards, > > Ton > > 2015-12-08 19:00 GMT+01:00 Ton Swieb < ton at finalist.nl > > >>: > > Hi Marc, > > I am using the following setup: > 1. Client -> Keycloak (apiman realm) -> SAML 2.0 IdP -> > Keycloak > (apiman realm) -> Client > 2. Client -> apiman gateway -> Keycloak OAuth policy -> > back-end -> > apiman gateway -> Client > > The IdP is a SAML 2.0 IdP. I believe it is SimpleSAMLPHP. > It is unclear to me why it matters which IdP I am using, > because my > assumption is that: > > * I end up with a valid Keycloak session within the > apiman realm > * the SAML 2.0 token should only be used by Keycloak to > issue a > login session to the client. > * the client itself will never directly use anyhting from > the SAML > 2.0 IdP, but should only use the stuff that Keycloak > mapped from > the SAML token onto its own token. > > I did ask the question on the keycloak mailinglist, but from a > different angle. I am afraid the solution for my problem > will be > somewhere in between. > Any help from your site is greatly appreciated :-) > > Regards, > > Ton > > > Message: 5 > Date: Tue, 8 Dec 2015 16:58:26 +0000 > From: Marc Savy < marc.savy at redhat.com > >> > Subject: Re: [Apiman-user] Keycloak OAuth2 policy: Get > bearer token > for logged in user without using username/password > To: apiman-user at lists.jboss.org > > > > Message-ID: < 56670C32.3060000 at redhat.com > > >> > Content-Type: text/plain; charset=UTF-8; format=flowed > > To expand on that - depending on exactly what type of IdP (and > specifically which technology) you were delegating to, it > may be > possible to do what you're asking - or you may need to write > something custom. > > Can you provide more detail? > > Also, if you have very specific Keycloak questions you > might be best > served on the keycloak-user mailing list, which is > extremely active > ( https://lists.jboss.org/mailman/listinfo/keycloak-user ). > > On 08/12/2015 16:53, Marc Savy wrote: > > Hi Ton, > > > > I'm not quite sure what you mean, but I think what > you're asking > for is > > brokerage/delegation in the form: > > > > 1. Client <-> Keycloak <-> Other IdP. > > 2. Client <-> apiman gateway > > > > Regards, > > Marc > > > > On 08/12/2015 15:28, Ton Swieb wrote: > > > Hi, > > > > > > I would like to secure my api's using the Keycloak > OAuth2 policy. > > > Similair to what is described in the blog post of Marc > Savy: > > > > http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html > > > > > > > > > Only with the difference that Keycloak delegates the > login to a > third > > > party IdP. After logging in at this third party IdP I > end up > with an > > > active session in the Apiman UI (the apiman realm of > Keycloak). > > > > > > Now I am wondering how to get the bearer token, > because I do > not have a > > > username/password combination I can use to make a call > like: > > > > > > |curl -X POST > > > > http://127.0.0.1:8080/auth/realms/stottie/protocol/openid-connect/token > > > -H "Content-Type: application/x-www-form-urlencoded" -d > > > "username=rincewind" -d 'password=apiman' -d > 'grant_type=password' -d > > > 'client_id=apiman'| > > > > > > Because the username/password combination is linked to the > third party > > > IdP and not to Keycloak itself. > > > > > > Is there another way to obtain the bearer token? > > > > > > Perhaps this is aquestion which I should address at > the keycloak > > > mailinglist. I will try to ask the question there as well. > > > > > > Regards, > > > > > > Ton > > > > > > > > > _______________________________________________ > > > 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 From pblair at clearme.com Mon Dec 14 16:27:07 2015 From: pblair at clearme.com (Paul Blair) Date: Mon, 14 Dec 2015 21:27:07 +0000 Subject: [Apiman-user] Having trouble connecting to Amazon Elasticsearch service In-Reply-To: <566858AD.5050604@redhat.com> Message-ID: Pretty sure I figured it out: If properties are set standalone-apiman.xml rather than apiman.properties, then all the es-related properties should be set in the xml file. I.e., properties such as apiman-gateway.registry.client.host which in apiman.properties are set to equal ${apiman.es.host} apparently also need to be set in standalone-apiman.xml if the referenced property is set in that file. On 12/9/15, 11:37 AM, "Eric Wittmann" wrote: >Another update - I reset the allowed IP in AWS to be different from >mine, and as expected it failed to connect. But I didn't get the same >error as you - so it seems that you are running into something else that >I can't reproduce. :( > >I could try using docker, but it will be awhile before I get a chance... > > >On 12/8/2015 3:42 PM, Paul Blair wrote: >> Mine looks like this, because I have the properties in the >> standalone-apiman.xml -- but I'm pretty sure they are being read >>correctly >> because the error message I get indicates that there is no response >>coming >> from that host at that port, and then I curl using the host and port >>that >> I copy from the error message. >> >> >> > value="${env.GATEWAY_PUBLIC_ENDPOINT:}"/> >> >> >> >> >> >> >> >> >> When I start, I have only ES_HOST and ES_PORT in my environment. This is >> in a Docker container, so the command looks like this: >> >> docker run --name apiman-gateway -p 9443:9443 -e >> GATEWAY_PUBLIC_ENDPOINT=[URI] -e >> >>ES_HOST=search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.amazonaws. >>co >> m -e ES_PORT=443 [OTHER_ENV_VARIABLES] clear/api-gateway >> >> >> When I curl from the Docker container, I get a response that looks like >> this: >> >> $ curl >> >>https://search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.amazonaws. >>co >> m:443 >> { >> "status" : 200, >> "name" : "Magnum", >> "cluster_name" : "577360696927:testapi", >> "version" : { >> "number" : "1.5.2", >> "build_hash" : "62ff9868b4c8a0c45860bebb259e21980778ab1c", >> "build_timestamp" : "2015-04-27T09:21:06Z", >> "build_snapshot" : false, >> "lucene_version" : "4.10.4" >> }, >> "tagline" : "You Know, for Search" >> } >> >> >> >> On 12/8/15, 3:33 PM, "Eric Wittmann" wrote: >> >>> I can't imagine the name of the domain could be important. Can you >>> double-check your exact apiman.properties? It should be this: >>> >>> apiman.es.protocol=https >>> >>>apiman.es.host=search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.am >>>az >>> onaws.com >>> apiman.es.port=443 >>> apiman.es.username= >>> apiman.es.password= >>> >>> >>> >>> On 12/8/2015 3:26 PM, Paul Blair wrote: >>>> When you create your domain, is it important what you name it? I named >>>> it >>>> testapi, so my endpoint looks like >>>> >>>> search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.amazonaws.com >>>> >>>> And the domain ARN is then >>>> >>>> arn:aws:es:us-west-2:577360696927:domain/testapi >>>> >>>> >>>> On 12/8/15, 3:06 PM, "Eric Wittmann" wrote: >>>> >>>>> Testing using 1.1.9.Final against the AWS instance of elastic was >>>>> successful. The only thing left for me to try is the access policy. >>>>> Otherwise everything looks like it's working fine. Here is the >>>>> relevant >>>>> section of my apiman.properties file, for reference: >>>>> >>>>> apiman.es.protocol=https >>>>> >>>>> >>>>>apiman.es.host=search-apiman-elastic-sarog5jew3xacrec5szeefvdm4.us-eas >>>>>t- >>>>> 1. >>>>> es.amazonaws.com >>>>> apiman.es.port=443 >>>>> apiman.es.username= >>>>> apiman.es.password= >>>>> >>>>> Here is some relevant curl output after my simple test: >>>>> >>>>> https://gist.github.com/EricWittmann/cc02a9ba6a2dee548a60 >>>>> >>>>> -Eric >>>>> >>>>> On 12/8/2015 1:13 PM, Paul Blair wrote: >>>>>> It isn't too complicated -- I started here >>>>>> https://aws.amazon.com/elasticsearch-service/ >>>>>> >>>>>> Basically you find "Elasticsearch Service" under the "Analytics" >>>>>> section >>>>>> of the AWS dashboard, hit the "Create a new domain" button, and >>>>>>follow >>>>>> the >>>>>> instructions. >>>>>> >>>>>> My access policy looks like this: >>>>>> >>>>>> { >>>>>> "Version": "2012-10-17", >>>>>> "Statement": [ >>>>>> { >>>>>> "Sid": "", >>>>>> "Effect": "Allow", >>>>>> "Principal": { >>>>>> "AWS": "*" >>>>>> }, >>>>>> "Action": "es:*", >>>>>> "Resource": "arn:aws:es:us-west-2[ARN]/*", >>>>>> "Condition": { >>>>>> "IpAddress": { >>>>>> "aws:SourceIp": [ >>>>>> "[IP ADDRESS 1]", "[CIDR BLOCK 2]",... >>>>>> ] >>>>>> } >>>>>> } >>>>>> } >>>>>> ] >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> On 12/8/15, 12:30 PM, "Eric Wittmann" >>>>>> wrote: >>>>>> >>>>>>> Nope - I was worried that you were using 2.x, which we do not >>>>>>> currently >>>>>>> support. >>>>>>> >>>>>>> Do you happen to have any instructions handy for setting up an AMZ >>>>>>> elasticsearch instance so I can try to reproduce this error? >>>>>>> >>>>>>> On 12/8/2015 12:28 PM, Paul Blair wrote: >>>>>>>> Amazon says their current version is 1.5.2. Does apiman require >>>>>>>> version >>>>>>>> 2.x? >>>>>>>> >>>>>>>> On 12/8/15, 12:21 PM, "Eric Wittmann" >>>>>>>> wrote: >>>>>>>> >>>>>>>>> What version of elasticsearch are you using? >>>>>>>>> >>>>>>>>> On 12/8/2015 12:12 PM, Paul Blair wrote: >>>>>>>>>> The stack trace is below. Note that the instance seems to start >>>>>>>>>> fine; >>>>>>>>>> it's >>>>>>>>>> only when I make a request to the Gateway that I get this error. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> 16:18:04,746 ERROR [io.undertow.request] (default task-1) >>>>>>>>>> UT005023: >>>>>>>>>> Exception handling request to /apiman-gateway/test_api/1.7: >>>>>>>>>> java.lang.RuntimeException: >>>>>>>>>> org.apache.http.NoHttpResponseException: >>>>>>>>>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to >>>>>>>>>> respond >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESCl >>>>>>>>>>ie >>>>>>>>>> nt >>>>>>>>>> Fa >>>>>>>>>> ct >>>>>>>>>> or >>>>>>>>>> y.java:200) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESCl >>>>>>>>>>ie >>>>>>>>>> nt >>>>>>>>>> Fa >>>>>>>>>> ct >>>>>>>>>> or >>>>>>>>>> y.java:140) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESCl >>>>>>>>>>ie >>>>>>>>>> nt >>>>>>>>>> Fa >>>>>>>>>> ct >>>>>>>>>> or >>>>>>>>>> y.java:101) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.apiman.gateway.engine.es.ESClientFactory.createClient(ESClient >>>>>>>>>>Fa >>>>>>>>>> ct >>>>>>>>>> or >>>>>>>>>> y. >>>>>>>>>> ja >>>>>>>>>> va:66) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.apiman.gateway.engine.es.AbstractESComponent.getClient(Abstrac >>>>>>>>>>tE >>>>>>>>>> SC >>>>>>>>>> om >>>>>>>>>> po >>>>>>>>>> ne >>>>>>>>>> nt.java:45) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java >>>>>>>>>>:3 >>>>>>>>>> 15 >>>>>>>>>> ) >>>>>>>>>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java >>>>>>>>>>:3 >>>>>>>>>> 04 >>>>>>>>>> ) >>>>>>>>>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.apiman.gateway.engine.es.CachingESRegistry.getService(CachingE >>>>>>>>>>SR >>>>>>>>>> eg >>>>>>>>>> is >>>>>>>>>> tr >>>>>>>>>> y. >>>>>>>>>> java:189) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.apiman.gateway.engine.impl.SecureRegistryWrapper.getService(Se >>>>>>>>>>cu >>>>>>>>>> re >>>>>>>>>> Re >>>>>>>>>> gi >>>>>>>>>> st >>>>>>>>>> ryWrapper.java:97) [apiman-gateway-engine-core-1.1.9.Final.jar:] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.apiman.gateway.engine.impl.ServiceRequestExecutorImpl.execute( >>>>>>>>>>Se >>>>>>>>>> rv >>>>>>>>>> ic >>>>>>>>>> eR >>>>>>>>>> eq >>>>>>>>>> uestExecutorImpl.java:252) >>>>>>>>>> [apiman-gateway-engine-core-1.1.9.Final.jar:] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(Gatew >>>>>>>>>>ay >>>>>>>>>> Se >>>>>>>>>> rv >>>>>>>>>> le >>>>>>>>>> t. >>>>>>>>>> java:236) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.apiman.gateway.platforms.servlet.GatewayServlet.doGet(GatewayS >>>>>>>>>>er >>>>>>>>>> vl >>>>>>>>>> et >>>>>>>>>> .j >>>>>>>>>> av >>>>>>>>>> a:82) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>>>>>>>>> at >>>>>>>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:687) >>>>>>>>>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>>>>>>>>> at >>>>>>>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>>>>>>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.undertow.servlet.handlers.ServletHandler.handleRequest(Servlet >>>>>>>>>>Ha >>>>>>>>>> nd >>>>>>>>>> le >>>>>>>>>> r. >>>>>>>>>> ja >>>>>>>>>> va:86) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.undertow.servlet.handlers.security.ServletSecurityRoleHandler. >>>>>>>>>>ha >>>>>>>>>> nd >>>>>>>>>> le >>>>>>>>>> Re >>>>>>>>>> qu >>>>>>>>>> est(ServletSecurityRoleHandler.java:62) >>>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequ >>>>>>>>>>es >>>>>>>>>> t( >>>>>>>>>> Se >>>>>>>>>> rv >>>>>>>>>> le >>>>>>>>>> tDispatchingHandler.java:36) >>>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>org.wildfly.extension.undertow.security.SecurityContextAssociatio >>>>>>>>>>nH >>>>>>>>>> an >>>>>>>>>> dl >>>>>>>>>> er >>>>>>>>>> .h >>>>>>>>>> andleRequest(SecurityContextAssociationHandler.java:78) >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.undertow.server.handlers.PredicateHandler.handleRequest(Predic >>>>>>>>>>at >>>>>>>>>> eH >>>>>>>>>> an >>>>>>>>>> dl >>>>>>>>>> er >>>>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.undertow.servlet.handlers.security.SSLInformationAssociationHa >>>>>>>>>>nd >>>>>>>>>> le >>>>>>>>>> r. >>>>>>>>>> ha >>>>>>>>>> nd >>>>>>>>>> leRequest(SSLInformationAssociationHandler.java:131) >>>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.undertow.servlet.handlers.security.ServletAuthenticationCallHa >>>>>>>>>>nd >>>>>>>>>> le >>>>>>>>>> r. >>>>>>>>>> ha >>>>>>>>>> nd >>>>>>>>>> leRequest(ServletAuthenticationCallHandler.java:57) >>>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.undertow.server.handlers.PredicateHandler.handleRequest(Predic >>>>>>>>>>at >>>>>>>>>> eH >>>>>>>>>> an >>>>>>>>>> dl >>>>>>>>>> er >>>>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.undertow.security.handlers.AbstractConfidentialityHandler.hand >>>>>>>>>>le >>>>>>>>>> Re >>>>>>>>>> qu >>>>>>>>>> es >>>>>>>>>> t( >>>>>>>>>> AbstractConfidentialityHandler.java:46) >>>>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.undertow.servlet.handlers.security.ServletConfidentialityConst >>>>>>>>>>ra >>>>>>>>>> in >>>>>>>>>> tH >>>>>>>>>> an >>>>>>>>>> dl >>>>>>>>>> >>>>>>>>>>er.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.undertow.security.handlers.AuthenticationMechanismsHandler.han >>>>>>>>>>dl >>>>>>>>>> eR >>>>>>>>>> eq >>>>>>>>>> ue >>>>>>>>>> st >>>>>>>>>> (AuthenticationMechanismsHandler.java:58) >>>>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.undertow.servlet.handlers.security.CachedAuthenticatedSessionH >>>>>>>>>>an >>>>>>>>>> dl >>>>>>>>>> er >>>>>>>>>> .h >>>>>>>>>> an >>>>>>>>>> dleRequest(CachedAuthenticatedSessionHandler.java:70) >>>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.undertow.security.handlers.SecurityInitialHandler.handleReques >>>>>>>>>>t( >>>>>>>>>> Se >>>>>>>>>> cu >>>>>>>>>> ri >>>>>>>>>> ty >>>>>>>>>> InitialHandler.java:76) >>>>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.undertow.server.handlers.PredicateHandler.handleRequest(Predic >>>>>>>>>>at >>>>>>>>>> eH >>>>>>>>>> an >>>>>>>>>> dl >>>>>>>>>> er >>>>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler >>>>>>>>>>.h >>>>>>>>>> an >>>>>>>>>> dl >>>>>>>>>> eR >>>>>>>>>> eq >>>>>>>>>> uest(JACCContextIdHandler.java:61) >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.undertow.server.handlers.PredicateHandler.handleRequest(Predic >>>>>>>>>>at >>>>>>>>>> eH >>>>>>>>>> an >>>>>>>>>> dl >>>>>>>>>> er >>>>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.undertow.server.handlers.PredicateHandler.handleRequest(Predic >>>>>>>>>>at >>>>>>>>>> eH >>>>>>>>>> an >>>>>>>>>> dl >>>>>>>>>> er >>>>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.undertow.servlet.handlers.ServletInitialHandler.handleFirstReq >>>>>>>>>>ue >>>>>>>>>> st >>>>>>>>>> (S >>>>>>>>>> er >>>>>>>>>> vl >>>>>>>>>> etInitialHandler.java:261) >>>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.undertow.servlet.handlers.ServletInitialHandler.dispatchReques >>>>>>>>>>t( >>>>>>>>>> Se >>>>>>>>>> rv >>>>>>>>>> le >>>>>>>>>> tI >>>>>>>>>> nitialHandler.java:248) >>>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.undertow.servlet.handlers.ServletInitialHandler.access$000(Ser >>>>>>>>>>vl >>>>>>>>>> et >>>>>>>>>> In >>>>>>>>>> it >>>>>>>>>> ia >>>>>>>>>> lHandler.java:77) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.undertow.servlet.handlers.ServletInitialHandler$1.handleReques >>>>>>>>>>t( >>>>>>>>>> Se >>>>>>>>>> rv >>>>>>>>>> le >>>>>>>>>> tI >>>>>>>>>> nitialHandler.java:167) >>>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.undertow.server.Connectors.executeRootHandler(Connectors.java: >>>>>>>>>>19 >>>>>>>>>> 9) >>>>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.ja >>>>>>>>>>va >>>>>>>>>> :7 >>>>>>>>>> 61 >>>>>>>>>> ) >>>>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecu >>>>>>>>>>to >>>>>>>>>> r. >>>>>>>>>> ja >>>>>>>>>> va >>>>>>>>>> :1 >>>>>>>>>> 142) [rt.jar:1.8.0_25] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExec >>>>>>>>>>ut >>>>>>>>>> or >>>>>>>>>> .j >>>>>>>>>> av >>>>>>>>>> a: >>>>>>>>>> 617) [rt.jar:1.8.0_25] >>>>>>>>>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25] >>>>>>>>>> Caused by: org.apache.http.NoHttpResponseException: >>>>>>>>>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to >>>>>>>>>> respond >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(Def >>>>>>>>>>au >>>>>>>>>> lt >>>>>>>>>> Ht >>>>>>>>>> tp >>>>>>>>>> Re >>>>>>>>>> sponseParser.java:143) [httpclient-4.5.jar:4.5] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(Def >>>>>>>>>>au >>>>>>>>>> lt >>>>>>>>>> Ht >>>>>>>>>> tp >>>>>>>>>> Re >>>>>>>>>> sponseParser.java:57) [httpclient-4.5.jar:4.5] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessa >>>>>>>>>>ge >>>>>>>>>> Pa >>>>>>>>>> rs >>>>>>>>>> er >>>>>>>>>> .j >>>>>>>>>> ava:261) [httpcore-4.4.1.jar:4.4.1] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>org.apache.http.impl.DefaultBHttpClientConnection.receiveResponse >>>>>>>>>>He >>>>>>>>>> ad >>>>>>>>>> er >>>>>>>>>> (D >>>>>>>>>> ef >>>>>>>>>> aultBHttpClientConnection.java:165) [httpcore-4.4.1.jar:4.4.1] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolP >>>>>>>>>>ro >>>>>>>>>> xy >>>>>>>>>> .j >>>>>>>>>> av >>>>>>>>>> a: >>>>>>>>>> 167) [httpclient-4.5.jar:4.5] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(Ht >>>>>>>>>>tp >>>>>>>>>> Re >>>>>>>>>> qu >>>>>>>>>> es >>>>>>>>>> tE >>>>>>>>>> xecutor.java:272) [httpcore-4.4.1.jar:4.4.1] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestE >>>>>>>>>>xe >>>>>>>>>> cu >>>>>>>>>> to >>>>>>>>>> r. >>>>>>>>>> ja >>>>>>>>>> va:124) [httpcore-4.4.1.jar:4.4.1] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>org.apache.http.impl.execchain.MainClientExec.execute(MainClientE >>>>>>>>>>xe >>>>>>>>>> c. >>>>>>>>>> ja >>>>>>>>>> va >>>>>>>>>> :2 >>>>>>>>>> 71) [httpclient-4.5.jar:4.5] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec. >>>>>>>>>>ja >>>>>>>>>> va >>>>>>>>>> :1 >>>>>>>>>> 84 >>>>>>>>>> ) >>>>>>>>>> [httpclient-4.5.jar:4.5] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:8 >>>>>>>>>>8) >>>>>>>>>> [httpclient-4.5.jar:4.5] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec. >>>>>>>>>>ja >>>>>>>>>> va >>>>>>>>>> :1 >>>>>>>>>> 10 >>>>>>>>>> ) >>>>>>>>>> [httpclient-4.5.jar:4.5] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>org.apache.http.impl.client.InternalHttpClient.doExecute(Internal >>>>>>>>>>Ht >>>>>>>>>> tp >>>>>>>>>> Cl >>>>>>>>>> ie >>>>>>>>>> nt >>>>>>>>>> .java:184) [httpclient-4.5.jar:4.5] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>org.apache.http.impl.client.CloseableHttpClient.execute(Closeable >>>>>>>>>>Ht >>>>>>>>>> tp >>>>>>>>>> Cl >>>>>>>>>> ie >>>>>>>>>> nt >>>>>>>>>> .java:82) [httpclient-4.5.jar:4.5] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>org.apache.http.impl.client.CloseableHttpClient.execute(Closeable >>>>>>>>>>Ht >>>>>>>>>> tp >>>>>>>>>> Cl >>>>>>>>>> ie >>>>>>>>>> nt >>>>>>>>>> .java:107) [httpclient-4.5.jar:4.5] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.searchbox.client.http.JestHttpClient.execute(JestHttpClient.ja >>>>>>>>>>va >>>>>>>>>> :5 >>>>>>>>>> 0) >>>>>>>>>> [jest-0.1.6.jar:] >>>>>>>>>> at >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESCl >>>>>>>>>>ie >>>>>>>>>> nt >>>>>>>>>> Fa >>>>>>>>>> ct >>>>>>>>>> or >>>>>>>>>> y.java:193) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>>> ... 39 more >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 12/8/15, 11:48 AM, "Eric Wittmann" >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> You definitely need to set the protocol to 'https', for the >>>>>>>>>>> record. >>>>>>>>>>> Beyond that I'm not quite sure. Do you have a full stack trace >>>>>>>>>>> or >>>>>>>>>>> just >>>>>>>>>>> that part of it? >>>>>>>>>>> >>>>>>>>>>> On 12/8/2015 11:19 AM, Paul Blair wrote: >>>>>>>>>>>> Not quite sure what to make of this: I'm getting >>>>>>>>>>>> >>>>>>>>>>>> org.apache.http.NoHttpResponseException: >>>>>>>>>>>> [endpoint_URI]:443 >>>>>>>>>>>> failed >>>>>>>>>>>> to respond >>>>>>>>>>>> >>>>>>>>>>>> But if I do: >>>>>>>>>>>> >>>>>>>>>>>> curl https://[endpont_URI]:443 >>>>>>>>>>>> >>>>>>>>>>>> I get a response from Elasticsearch?this is because I have the >>>>>>>>>>>> Amazon >>>>>>>>>>>> Elasticsearch instance permissioned to accept any connections >>>>>>>>>>>> from >>>>>>>>>>>> the >>>>>>>>>>>> IP address where apiman is running. >>>>>>>>>>>> >>>>>>>>>>>> The apiman configurations look like this: >>>>>>>>>>>> >>>>>>>>>>>> apiman.es.protocol=http >>>>>>>>>>>> apiman.es.host=[endpoint_URI] >>>>>>>>>>>> apiman.es.port=443 >>>>>>>>>>>> apiman.es.username= >>>>>>>>>>>> apiman.es.password= >>>>>>>>>>>> >>>>>>>>>>>> Changing protocol from http to https doesn't appear to help, >>>>>>>>>>>>nor >>>>>>>>>>>> does >>>>>>>>>>>> removing the username and password properties entirely. Any >>>>>>>>>>>> suggestions? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Apiman-user mailing list >>>>>>>>>>>> Apiman-user at lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> From pblair at clearme.com Mon Dec 14 17:00:14 2015 From: pblair at clearme.com (Paul Blair) Date: Mon, 14 Dec 2015 22:00:14 +0000 Subject: [Apiman-user] Receiving HTML instead of JSON from Keycloak when trying to point apimanui to the API gateway Message-ID: I'm getting a strange error in my production deployment which I'm having difficulty troubleshooting. After deploying the apiman UI and gateway on separate hosts, according to the production guide I have to point the API Manager to the API gateway. If I hit the "New Gateway" button, I need to add the URI of the gateway. I'm assuming this should be [PROTOCOL]://[GATEWAY_HOST]:[GATEWAY_PORT]/apiman-gateway-api/ -- which should also be set as the redirect URI for the gateway in the Apiman realm in Keycloak (followed by a star). This is different from my public endpoint, which is [PROTOCOL]://[GATEWAY_HOST]:[GATEWAY_PORT]/apiman-gateway When I use the apimanager user (set up in the default realm file) to test the gateway in the "New Gateway" screen I'm getting this error: Gateway Configuration Invalid Something has gone wrong when testing the Gateway. Hopefully the details (below) will help you figure out what. org.codehaus.jackson.JsonParseException: Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null') at [Source: org.apache.http.conn.EofSensorInputStream at 450a7e3f; line: 1, column: 2] If I look at what's happening in the API manager log, it looks like the error is coming from getting HTML back from Keycloak where it's expecting JSON. Is there some configuration I'm missing? Here are the relevant API manager server logs: 21:38:49,715 DEBUG [org.keycloak.adapters.RequestAuthenticator] (default task-1) Bearer AUTHENTICATED 21:38:49,717 DEBUG [org.keycloak.adapters.AuthenticatedActionsHandler] (default task-1) AuthenticatedActionsValve.invoke https://[APIMANUI]/apiman/gateways ... 21:38:50,796 DEBUG [org.apache.http.impl.execchain.MainClientExec] (default task-1) Opening connection {s}->https://[GATEWAY] ... 21:38:50,864 DEBUG [org.apache.http.impl.execchain.MainClientExec] (default task-1) Executing request GET /apiman-gateway-api/system/status HTTP/1.1 21:38:50,864 DEBUG [org.apache.http.impl.execchain.MainClientExec] (default task-1) Proxy auth state: UNCHALLENGED 21:38:50,866 DEBUG [org.apache.http.headers] (default task-1) http-outgoing-0 >> GET /apiman-gateway-api/system/status HTTP/1.1 21:38:50,866 DEBUG [org.apache.http.headers] (default task-1) http-outgoing-0 >> Authorization: Basic YXBpbWFuYWdlcjphcGltYW4xMjMh 21:38:50,866 DEBUG [org.apache.http.headers] (default task-1) http-outgoing-0 >> Host: [GATEWAY] ... 21:38:50,881 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-0 << "HTTP/1.1 302 Found[\r][\n]" 21:38:50,881 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-0 << "Expires: 0[\r][\n]" 21:38:50,881 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-0 << "Set-Cookie: OAuth_Token_Request_State=19/8069a233-7d97-4f9d-8696-673f72815124; secure[\r][\n]" 21:38:50,882 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-0 << "Location: https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?response_type=code&client_id=apiman-gateway-api&redirect_uri=https%3A%2F%2F[GATEWAY]%2Fapiman-gateway-api%2Fsystem%2Fstatus&state=19%2F8069a233-7d97-4f9d-8696-673f72815124&login=true[\r][\n]" ... 21:38:50,894 DEBUG [org.apache.http.client.protocol.ResponseProcessCookies] (default task-1) Cookie accepted [OAuth_Token_Request_State="19/8069a233-7d97-4f9d-8696-673f72815124", version:0, domain:ec2-52-34-81-26.us-west-2.compute.amazonaws.com, path:/apiman-gateway-api/system, expiry:null] 21:38:50,894 DEBUG [org.apache.http.impl.client.DefaultRedirectStrategy] (default task-1) Redirect requested to location 'https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?response_type=code&client_id=apiman-gateway-api&redirect_uri=https%3A%2F%2F[GATEWAY]%2Fapiman-gateway-api%2Fsystem%2Fstatus&state=19%2F8069a233-7d97-4f9d-8696-673f72815124&login=true' 21:38:50,900 DEBUG [org.apache.http.impl.execchain.RedirectExec] (default task-1) Resetting target auth state 21:38:50,900 DEBUG [org.apache.http.impl.execchain.RedirectExec] (default task-1) Redirecting to 'https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?response_type=code&client_id=apiman-gateway-api&redirect_uri=https%3A%2F%2F[GATEWAY]%2Fapiman-gateway-api%2Fsystem%2Fstatus&state=19%2F8069a233-7d97-4f9d-8696-673f72815124&login=true' via {s}->https://[KEYCLOAK] ... 21:38:50,902 DEBUG [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] (default task-1) Connection request: [route: {s}->https://[KEYCLOAK]][total kept alive: 1; route allocated: 0 of 2; total allocated: 1 of 20] ... 21:38:50,935 DEBUG [org.apache.http.impl.conn.DefaultHttpClientConnectionOperator] (default task-1) Connection established 172.17.1.52:46173<->172.31.41.242:8443 21:38:50,936 DEBUG [org.apache.http.impl.execchain.MainClientExec] (default task-1) Executing request GET /auth/realms/apiman/protocol/openid-connect/auth?response_type=code&client_id=apiman-gateway-api&redirect_uri=https%3A%2F%2F[GATEWAY]%2Fapiman-gateway-api%2Fsystem%2Fstatus&state=19%2F8069a233-7d97-4f9d-8696-673f72815124&login=true HTTP/1.1 21:38:50,936 DEBUG [org.apache.http.impl.execchain.MainClientExec] (default task-1) Proxy auth state: UNCHALLENGED 21:38:50,936 DEBUG [org.apache.http.headers] (default task-1) http-outgoing-1 >> GET /auth/realms/apiman/protocol/openid-connect/auth?response_type=code&client_id=apiman-gateway-api&redirect_uri=https%3A%2F%2F[GATEWAY]%2Fapiman-gateway-api%2Fsystem%2Fstatus&state=19%2F8069a233-7d97-4f9d-8696-673f72815124&login=true HTTP/1.1 21:38:50,936 DEBUG [org.apache.http.headers] (default task-1) http-outgoing-1 >> Authorization: Basic YXBpbWFuYWdlcjphcGltYW4xMjMh 21:38:50,936 DEBUG [org.apache.http.headers] (default task-1) http-outgoing-1 >> Host: [KEYCLOAK] 21:38:50,936 DEBUG [org.apache.http.headers] (default task-1) http-outgoing-1 >> User-Agent: Apache-HttpClient/4.5 (Java/1.8.0_25) 21:38:50,936 DEBUG [org.apache.http.headers] (default task-1) http-outgoing-1 >> Accept-Encoding: gzip,deflate ... 21:38:50,960 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-1 << "HTTP/1.1 200 OK[\r][\n]" 21:38:50,960 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-1 << "X-Powered-By: Undertow/1[\r][\n]" 21:38:50,960 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-1 << "Set-Cookie: KC_RESTART=[COOKIE]; Version=1; Path=/auth/realms/apiman; HttpOnly[\r][\n]" 21:38:50,960 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-1 << "Server: WildFly/9[\r][\n]" 21:38:50,960 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-1 << "X-Frame-Options: SAMEORIGIN[\r][\n]" 21:38:50,960 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-1 << "Content-Security-Policy: frame-src 'self'[\r][\n]" 21:38:50,960 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-1 << "Date: Mon, 14 Dec 2015 21:38:50 GMT[\r][\n]" 21:38:50,960 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-1 << "Connection: keep-alive[\r][\n]" 21:38:50,960 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-1 << "Content-Type: text/html[\r][\n]" 21:38:50,960 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-1 << "Content-Length: 4171[\r][\n]" 21:38:50,960 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-1 << "[\r][\n]" 21:38:50,961 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-1 << "[\n]" 21:38:50,961 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-1 << "[\n]" 21:38:50,961 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-1 << "[\n]" 21:38:50,961 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-1 << "[\n]" 21:38:50,961 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-1 << " [\n]" 21:38:50,961 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-1 << " [\n]" 21:38:50,961 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-1 << " Log in to apiman[\n]" 21:38:50,961 DEBUG [org.apache.http.wire] (default task-1) http-outgoing-1 << "[\n]" ... more html... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151214/326bc13d/attachment.html From eric.wittmann at redhat.com Mon Dec 14 18:12:30 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Mon, 14 Dec 2015 18:12:30 -0500 Subject: [Apiman-user] Having trouble connecting to Amazon Elasticsearch service In-Reply-To: References: Message-ID: <566F4CDE.1020201@redhat.com> Ah that's interesting. The values in standalone.xml are basically system properties. So yeah - you can't use properties in apiman.properties in the values of your system properties. That does make sense. On 12/14/2015 4:27 PM, Paul Blair wrote: > Pretty sure I figured it out: If properties are set standalone-apiman.xml > rather than apiman.properties, then all the es-related properties should > be set in the xml file. I.e., properties such as > apiman-gateway.registry.client.host which in apiman.properties are set to > equal ${apiman.es.host} apparently also need to be set in > standalone-apiman.xml if the referenced property is set in that file. > > > On 12/9/15, 11:37 AM, "Eric Wittmann" wrote: > >> Another update - I reset the allowed IP in AWS to be different from >> mine, and as expected it failed to connect. But I didn't get the same >> error as you - so it seems that you are running into something else that >> I can't reproduce. :( >> >> I could try using docker, but it will be awhile before I get a chance... >> >> >> On 12/8/2015 3:42 PM, Paul Blair wrote: >>> Mine looks like this, because I have the properties in the >>> standalone-apiman.xml -- but I'm pretty sure they are being read >>> correctly >>> because the error message I get indicates that there is no response >>> coming >>> from that host at that port, and then I curl using the host and port >>> that >>> I copy from the error message. >>> >>> >>> >> value="${env.GATEWAY_PUBLIC_ENDPOINT:}"/> >>> >>> >>> >>> >>> >>> >>> >>> >>> When I start, I have only ES_HOST and ES_PORT in my environment. This is >>> in a Docker container, so the command looks like this: >>> >>> docker run --name apiman-gateway -p 9443:9443 -e >>> GATEWAY_PUBLIC_ENDPOINT=[URI] -e >>> >>> ES_HOST=search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.amazonaws. >>> co >>> m -e ES_PORT=443 [OTHER_ENV_VARIABLES] clear/api-gateway >>> >>> >>> When I curl from the Docker container, I get a response that looks like >>> this: >>> >>> $ curl >>> >>> https://search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.amazonaws. >>> co >>> m:443 >>> { >>> "status" : 200, >>> "name" : "Magnum", >>> "cluster_name" : "577360696927:testapi", >>> "version" : { >>> "number" : "1.5.2", >>> "build_hash" : "62ff9868b4c8a0c45860bebb259e21980778ab1c", >>> "build_timestamp" : "2015-04-27T09:21:06Z", >>> "build_snapshot" : false, >>> "lucene_version" : "4.10.4" >>> }, >>> "tagline" : "You Know, for Search" >>> } >>> >>> >>> >>> On 12/8/15, 3:33 PM, "Eric Wittmann" wrote: >>> >>>> I can't imagine the name of the domain could be important. Can you >>>> double-check your exact apiman.properties? It should be this: >>>> >>>> apiman.es.protocol=https >>>> >>>> apiman.es.host=search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.am >>>> az >>>> onaws.com >>>> apiman.es.port=443 >>>> apiman.es.username= >>>> apiman.es.password= >>>> >>>> >>>> >>>> On 12/8/2015 3:26 PM, Paul Blair wrote: >>>>> When you create your domain, is it important what you name it? I named >>>>> it >>>>> testapi, so my endpoint looks like >>>>> >>>>> search-testapi-6ygyetc5y43j6xhuwhc24nwwzu.us-west-2.es.amazonaws.com >>>>> >>>>> And the domain ARN is then >>>>> >>>>> arn:aws:es:us-west-2:577360696927:domain/testapi >>>>> >>>>> >>>>> On 12/8/15, 3:06 PM, "Eric Wittmann" wrote: >>>>> >>>>>> Testing using 1.1.9.Final against the AWS instance of elastic was >>>>>> successful. The only thing left for me to try is the access policy. >>>>>> Otherwise everything looks like it's working fine. Here is the >>>>>> relevant >>>>>> section of my apiman.properties file, for reference: >>>>>> >>>>>> apiman.es.protocol=https >>>>>> >>>>>> >>>>>> apiman.es.host=search-apiman-elastic-sarog5jew3xacrec5szeefvdm4.us-eas >>>>>> t- >>>>>> 1. >>>>>> es.amazonaws.com >>>>>> apiman.es.port=443 >>>>>> apiman.es.username= >>>>>> apiman.es.password= >>>>>> >>>>>> Here is some relevant curl output after my simple test: >>>>>> >>>>>> https://gist.github.com/EricWittmann/cc02a9ba6a2dee548a60 >>>>>> >>>>>> -Eric >>>>>> >>>>>> On 12/8/2015 1:13 PM, Paul Blair wrote: >>>>>>> It isn't too complicated -- I started here >>>>>>> https://aws.amazon.com/elasticsearch-service/ >>>>>>> >>>>>>> Basically you find "Elasticsearch Service" under the "Analytics" >>>>>>> section >>>>>>> of the AWS dashboard, hit the "Create a new domain" button, and >>>>>>> follow >>>>>>> the >>>>>>> instructions. >>>>>>> >>>>>>> My access policy looks like this: >>>>>>> >>>>>>> { >>>>>>> "Version": "2012-10-17", >>>>>>> "Statement": [ >>>>>>> { >>>>>>> "Sid": "", >>>>>>> "Effect": "Allow", >>>>>>> "Principal": { >>>>>>> "AWS": "*" >>>>>>> }, >>>>>>> "Action": "es:*", >>>>>>> "Resource": "arn:aws:es:us-west-2[ARN]/*", >>>>>>> "Condition": { >>>>>>> "IpAddress": { >>>>>>> "aws:SourceIp": [ >>>>>>> "[IP ADDRESS 1]", "[CIDR BLOCK 2]",... >>>>>>> ] >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> ] >>>>>>> } >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 12/8/15, 12:30 PM, "Eric Wittmann" >>>>>>> wrote: >>>>>>> >>>>>>>> Nope - I was worried that you were using 2.x, which we do not >>>>>>>> currently >>>>>>>> support. >>>>>>>> >>>>>>>> Do you happen to have any instructions handy for setting up an AMZ >>>>>>>> elasticsearch instance so I can try to reproduce this error? >>>>>>>> >>>>>>>> On 12/8/2015 12:28 PM, Paul Blair wrote: >>>>>>>>> Amazon says their current version is 1.5.2. Does apiman require >>>>>>>>> version >>>>>>>>> 2.x? >>>>>>>>> >>>>>>>>> On 12/8/15, 12:21 PM, "Eric Wittmann" >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> What version of elasticsearch are you using? >>>>>>>>>> >>>>>>>>>> On 12/8/2015 12:12 PM, Paul Blair wrote: >>>>>>>>>>> The stack trace is below. Note that the instance seems to start >>>>>>>>>>> fine; >>>>>>>>>>> it's >>>>>>>>>>> only when I make a request to the Gateway that I get this error. >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> >>>>>>>>>>> 16:18:04,746 ERROR [io.undertow.request] (default task-1) >>>>>>>>>>> UT005023: >>>>>>>>>>> Exception handling request to /apiman-gateway/test_api/1.7: >>>>>>>>>>> java.lang.RuntimeException: >>>>>>>>>>> org.apache.http.NoHttpResponseException: >>>>>>>>>>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to >>>>>>>>>>> respond >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESCl >>>>>>>>>>> ie >>>>>>>>>>> nt >>>>>>>>>>> Fa >>>>>>>>>>> ct >>>>>>>>>>> or >>>>>>>>>>> y.java:200) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESCl >>>>>>>>>>> ie >>>>>>>>>>> nt >>>>>>>>>>> Fa >>>>>>>>>>> ct >>>>>>>>>>> or >>>>>>>>>>> y.java:140) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.apiman.gateway.engine.es.ESClientFactory.createJestClient(ESCl >>>>>>>>>>> ie >>>>>>>>>>> nt >>>>>>>>>>> Fa >>>>>>>>>>> ct >>>>>>>>>>> or >>>>>>>>>>> y.java:101) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.apiman.gateway.engine.es.ESClientFactory.createClient(ESClient >>>>>>>>>>> Fa >>>>>>>>>>> ct >>>>>>>>>>> or >>>>>>>>>>> y. >>>>>>>>>>> ja >>>>>>>>>>> va:66) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.apiman.gateway.engine.es.AbstractESComponent.getClient(Abstrac >>>>>>>>>>> tE >>>>>>>>>>> SC >>>>>>>>>>> om >>>>>>>>>>> po >>>>>>>>>>> ne >>>>>>>>>>> nt.java:45) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java >>>>>>>>>>> :3 >>>>>>>>>>> 15 >>>>>>>>>>> ) >>>>>>>>>>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.apiman.gateway.engine.es.ESRegistry.getService(ESRegistry.java >>>>>>>>>>> :3 >>>>>>>>>>> 04 >>>>>>>>>>> ) >>>>>>>>>>> [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.apiman.gateway.engine.es.CachingESRegistry.getService(CachingE >>>>>>>>>>> SR >>>>>>>>>>> eg >>>>>>>>>>> is >>>>>>>>>>> tr >>>>>>>>>>> y. >>>>>>>>>>> java:189) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getService(Se >>>>>>>>>>> cu >>>>>>>>>>> re >>>>>>>>>>> Re >>>>>>>>>>> gi >>>>>>>>>>> st >>>>>>>>>>> ryWrapper.java:97) [apiman-gateway-engine-core-1.1.9.Final.jar:] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.apiman.gateway.engine.impl.ServiceRequestExecutorImpl.execute( >>>>>>>>>>> Se >>>>>>>>>>> rv >>>>>>>>>>> ic >>>>>>>>>>> eR >>>>>>>>>>> eq >>>>>>>>>>> uestExecutorImpl.java:252) >>>>>>>>>>> [apiman-gateway-engine-core-1.1.9.Final.jar:] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(Gatew >>>>>>>>>>> ay >>>>>>>>>>> Se >>>>>>>>>>> rv >>>>>>>>>>> le >>>>>>>>>>> t. >>>>>>>>>>> java:236) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.apiman.gateway.platforms.servlet.GatewayServlet.doGet(GatewayS >>>>>>>>>>> er >>>>>>>>>>> vl >>>>>>>>>>> et >>>>>>>>>>> .j >>>>>>>>>>> av >>>>>>>>>>> a:82) [apiman-gateway-platforms-servlet-1.1.9.Final.jar:] >>>>>>>>>>> at >>>>>>>>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:687) >>>>>>>>>>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>>>>>>>>>> at >>>>>>>>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>>>>>>>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(Servlet >>>>>>>>>>> Ha >>>>>>>>>>> nd >>>>>>>>>>> le >>>>>>>>>>> r. >>>>>>>>>>> ja >>>>>>>>>>> va:86) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler. >>>>>>>>>>> ha >>>>>>>>>>> nd >>>>>>>>>>> le >>>>>>>>>>> Re >>>>>>>>>>> qu >>>>>>>>>>> est(ServletSecurityRoleHandler.java:62) >>>>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequ >>>>>>>>>>> es >>>>>>>>>>> t( >>>>>>>>>>> Se >>>>>>>>>>> rv >>>>>>>>>>> le >>>>>>>>>>> tDispatchingHandler.java:36) >>>>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> org.wildfly.extension.undertow.security.SecurityContextAssociatio >>>>>>>>>>> nH >>>>>>>>>>> an >>>>>>>>>>> dl >>>>>>>>>>> er >>>>>>>>>>> .h >>>>>>>>>>> andleRequest(SecurityContextAssociationHandler.java:78) >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(Predic >>>>>>>>>>> at >>>>>>>>>>> eH >>>>>>>>>>> an >>>>>>>>>>> dl >>>>>>>>>>> er >>>>>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHa >>>>>>>>>>> nd >>>>>>>>>>> le >>>>>>>>>>> r. >>>>>>>>>>> ha >>>>>>>>>>> nd >>>>>>>>>>> leRequest(SSLInformationAssociationHandler.java:131) >>>>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHa >>>>>>>>>>> nd >>>>>>>>>>> le >>>>>>>>>>> r. >>>>>>>>>>> ha >>>>>>>>>>> nd >>>>>>>>>>> leRequest(ServletAuthenticationCallHandler.java:57) >>>>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(Predic >>>>>>>>>>> at >>>>>>>>>>> eH >>>>>>>>>>> an >>>>>>>>>>> dl >>>>>>>>>>> er >>>>>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.undertow.security.handlers.AbstractConfidentialityHandler.hand >>>>>>>>>>> le >>>>>>>>>>> Re >>>>>>>>>>> qu >>>>>>>>>>> es >>>>>>>>>>> t( >>>>>>>>>>> AbstractConfidentialityHandler.java:46) >>>>>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.undertow.servlet.handlers.security.ServletConfidentialityConst >>>>>>>>>>> ra >>>>>>>>>>> in >>>>>>>>>>> tH >>>>>>>>>>> an >>>>>>>>>>> dl >>>>>>>>>>> >>>>>>>>>>> er.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>>>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.han >>>>>>>>>>> dl >>>>>>>>>>> eR >>>>>>>>>>> eq >>>>>>>>>>> ue >>>>>>>>>>> st >>>>>>>>>>> (AuthenticationMechanismsHandler.java:58) >>>>>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionH >>>>>>>>>>> an >>>>>>>>>>> dl >>>>>>>>>>> er >>>>>>>>>>> .h >>>>>>>>>>> an >>>>>>>>>>> dleRequest(CachedAuthenticatedSessionHandler.java:70) >>>>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.undertow.security.handlers.SecurityInitialHandler.handleReques >>>>>>>>>>> t( >>>>>>>>>>> Se >>>>>>>>>>> cu >>>>>>>>>>> ri >>>>>>>>>>> ty >>>>>>>>>>> InitialHandler.java:76) >>>>>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(Predic >>>>>>>>>>> at >>>>>>>>>>> eH >>>>>>>>>>> an >>>>>>>>>>> dl >>>>>>>>>>> er >>>>>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler >>>>>>>>>>> .h >>>>>>>>>>> an >>>>>>>>>>> dl >>>>>>>>>>> eR >>>>>>>>>>> eq >>>>>>>>>>> uest(JACCContextIdHandler.java:61) >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(Predic >>>>>>>>>>> at >>>>>>>>>>> eH >>>>>>>>>>> an >>>>>>>>>>> dl >>>>>>>>>>> er >>>>>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(Predic >>>>>>>>>>> at >>>>>>>>>>> eH >>>>>>>>>>> an >>>>>>>>>>> dl >>>>>>>>>>> er >>>>>>>>>>> .java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstReq >>>>>>>>>>> ue >>>>>>>>>>> st >>>>>>>>>>> (S >>>>>>>>>>> er >>>>>>>>>>> vl >>>>>>>>>>> etInitialHandler.java:261) >>>>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchReques >>>>>>>>>>> t( >>>>>>>>>>> Se >>>>>>>>>>> rv >>>>>>>>>>> le >>>>>>>>>>> tI >>>>>>>>>>> nitialHandler.java:248) >>>>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(Ser >>>>>>>>>>> vl >>>>>>>>>>> et >>>>>>>>>>> In >>>>>>>>>>> it >>>>>>>>>>> ia >>>>>>>>>>> lHandler.java:77) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleReques >>>>>>>>>>> t( >>>>>>>>>>> Se >>>>>>>>>>> rv >>>>>>>>>>> le >>>>>>>>>>> tI >>>>>>>>>>> nitialHandler.java:167) >>>>>>>>>>> [undertow-servlet-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java: >>>>>>>>>>> 19 >>>>>>>>>>> 9) >>>>>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.ja >>>>>>>>>>> va >>>>>>>>>>> :7 >>>>>>>>>>> 61 >>>>>>>>>>> ) >>>>>>>>>>> [undertow-core-1.1.8.Final.jar:1.1.8.Final] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecu >>>>>>>>>>> to >>>>>>>>>>> r. >>>>>>>>>>> ja >>>>>>>>>>> va >>>>>>>>>>> :1 >>>>>>>>>>> 142) [rt.jar:1.8.0_25] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExec >>>>>>>>>>> ut >>>>>>>>>>> or >>>>>>>>>>> .j >>>>>>>>>>> av >>>>>>>>>>> a: >>>>>>>>>>> 617) [rt.jar:1.8.0_25] >>>>>>>>>>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25] >>>>>>>>>>> Caused by: org.apache.http.NoHttpResponseException: >>>>>>>>>>> search-testapi-....us-west-2.es.amazonaws.com:443 failed to >>>>>>>>>>> respond >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(Def >>>>>>>>>>> au >>>>>>>>>>> lt >>>>>>>>>>> Ht >>>>>>>>>>> tp >>>>>>>>>>> Re >>>>>>>>>>> sponseParser.java:143) [httpclient-4.5.jar:4.5] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(Def >>>>>>>>>>> au >>>>>>>>>>> lt >>>>>>>>>>> Ht >>>>>>>>>>> tp >>>>>>>>>>> Re >>>>>>>>>>> sponseParser.java:57) [httpclient-4.5.jar:4.5] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessa >>>>>>>>>>> ge >>>>>>>>>>> Pa >>>>>>>>>>> rs >>>>>>>>>>> er >>>>>>>>>>> .j >>>>>>>>>>> ava:261) [httpcore-4.4.1.jar:4.4.1] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponse >>>>>>>>>>> He >>>>>>>>>>> ad >>>>>>>>>>> er >>>>>>>>>>> (D >>>>>>>>>>> ef >>>>>>>>>>> aultBHttpClientConnection.java:165) [httpcore-4.4.1.jar:4.4.1] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolP >>>>>>>>>>> ro >>>>>>>>>>> xy >>>>>>>>>>> .j >>>>>>>>>>> av >>>>>>>>>>> a: >>>>>>>>>>> 167) [httpclient-4.5.jar:4.5] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(Ht >>>>>>>>>>> tp >>>>>>>>>>> Re >>>>>>>>>>> qu >>>>>>>>>>> es >>>>>>>>>>> tE >>>>>>>>>>> xecutor.java:272) [httpcore-4.4.1.jar:4.4.1] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestE >>>>>>>>>>> xe >>>>>>>>>>> cu >>>>>>>>>>> to >>>>>>>>>>> r. >>>>>>>>>>> ja >>>>>>>>>>> va:124) [httpcore-4.4.1.jar:4.4.1] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> org.apache.http.impl.execchain.MainClientExec.execute(MainClientE >>>>>>>>>>> xe >>>>>>>>>>> c. >>>>>>>>>>> ja >>>>>>>>>>> va >>>>>>>>>>> :2 >>>>>>>>>>> 71) [httpclient-4.5.jar:4.5] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec. >>>>>>>>>>> ja >>>>>>>>>>> va >>>>>>>>>>> :1 >>>>>>>>>>> 84 >>>>>>>>>>> ) >>>>>>>>>>> [httpclient-4.5.jar:4.5] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:8 >>>>>>>>>>> 8) >>>>>>>>>>> [httpclient-4.5.jar:4.5] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec. >>>>>>>>>>> ja >>>>>>>>>>> va >>>>>>>>>>> :1 >>>>>>>>>>> 10 >>>>>>>>>>> ) >>>>>>>>>>> [httpclient-4.5.jar:4.5] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> org.apache.http.impl.client.InternalHttpClient.doExecute(Internal >>>>>>>>>>> Ht >>>>>>>>>>> tp >>>>>>>>>>> Cl >>>>>>>>>>> ie >>>>>>>>>>> nt >>>>>>>>>>> .java:184) [httpclient-4.5.jar:4.5] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> org.apache.http.impl.client.CloseableHttpClient.execute(Closeable >>>>>>>>>>> Ht >>>>>>>>>>> tp >>>>>>>>>>> Cl >>>>>>>>>>> ie >>>>>>>>>>> nt >>>>>>>>>>> .java:82) [httpclient-4.5.jar:4.5] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> org.apache.http.impl.client.CloseableHttpClient.execute(Closeable >>>>>>>>>>> Ht >>>>>>>>>>> tp >>>>>>>>>>> Cl >>>>>>>>>>> ie >>>>>>>>>>> nt >>>>>>>>>>> .java:107) [httpclient-4.5.jar:4.5] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.searchbox.client.http.JestHttpClient.execute(JestHttpClient.ja >>>>>>>>>>> va >>>>>>>>>>> :5 >>>>>>>>>>> 0) >>>>>>>>>>> [jest-0.1.6.jar:] >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> io.apiman.gateway.engine.es.ESClientFactory.initializeClient(ESCl >>>>>>>>>>> ie >>>>>>>>>>> nt >>>>>>>>>>> Fa >>>>>>>>>>> ct >>>>>>>>>>> or >>>>>>>>>>> y.java:193) [apiman-gateway-engine-es-1.1.9.Final.jar:] >>>>>>>>>>> ... 39 more >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 12/8/15, 11:48 AM, "Eric Wittmann" >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> You definitely need to set the protocol to 'https', for the >>>>>>>>>>>> record. >>>>>>>>>>>> Beyond that I'm not quite sure. Do you have a full stack trace >>>>>>>>>>>> or >>>>>>>>>>>> just >>>>>>>>>>>> that part of it? >>>>>>>>>>>> >>>>>>>>>>>> On 12/8/2015 11:19 AM, Paul Blair wrote: >>>>>>>>>>>>> Not quite sure what to make of this: I'm getting >>>>>>>>>>>>> >>>>>>>>>>>>> org.apache.http.NoHttpResponseException: >>>>>>>>>>>>> [endpoint_URI]:443 >>>>>>>>>>>>> failed >>>>>>>>>>>>> to respond >>>>>>>>>>>>> >>>>>>>>>>>>> But if I do: >>>>>>>>>>>>> >>>>>>>>>>>>> curl https://[endpont_URI]:443 >>>>>>>>>>>>> >>>>>>>>>>>>> I get a response from Elasticsearch?this is because I have the >>>>>>>>>>>>> Amazon >>>>>>>>>>>>> Elasticsearch instance permissioned to accept any connections >>>>>>>>>>>>> from >>>>>>>>>>>>> the >>>>>>>>>>>>> IP address where apiman is running. >>>>>>>>>>>>> >>>>>>>>>>>>> The apiman configurations look like this: >>>>>>>>>>>>> >>>>>>>>>>>>> apiman.es.protocol=http >>>>>>>>>>>>> apiman.es.host=[endpoint_URI] >>>>>>>>>>>>> apiman.es.port=443 >>>>>>>>>>>>> apiman.es.username= >>>>>>>>>>>>> apiman.es.password= >>>>>>>>>>>>> >>>>>>>>>>>>> Changing protocol from http to https doesn't appear to help, >>>>>>>>>>>>> nor >>>>>>>>>>>>> does >>>>>>>>>>>>> removing the username and password properties entirely. Any >>>>>>>>>>>>> suggestions? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Apiman-user mailing list >>>>>>>>>>>>> Apiman-user at lists.jboss.org >>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> > From pblair at clearme.com Tue Dec 15 09:56:54 2015 From: pblair at clearme.com (Paul Blair) Date: Tue, 15 Dec 2015 14:56:54 +0000 Subject: [Apiman-user] Production deployment questions In-Reply-To: <566633D8.2010804@redhat.com> Message-ID: I've received a response from the Keycloak list about the credential in the secure-deployment configuration for Keycloak; this looks like something that should be part of the apiman deployment instructions. I've included the response below: On 12/9/15, 7:40 AM, "Juraci Paix?o Kr?hling" wrote: > I don't know about the specifics of apiman, but this secret is not used > only for direct access grants, in general. All in all, I'm not a big fan > of shipping with a default secret/password (or any security "token"). > > If that also makes you feel not comfortable, you might want to try to > change the "credential" for the "apiman" client on the "apiman" realm > via the Keycloak admin console: > > - login to the auth console (admin:admin are the default credentials) > - select the apiman realm on the top-left > - select "Clients" and then "apiman" > - select the second tab, "Credentials" > - "Regenerate secret" > > This new secret should go into the standalone.xml, as value for all > "kc:credential[name=secret]" whose realm/resource are "apiman". > >- Juca. On 12/7/15, 8:35 PM, "Eric Wittmann" wrote: >Hi Paul - answers inline below. > >> 1. Is "password" supposed to be replaced by some credential? This isn't >> mentioned in the instructions; my guess is that this credential is used >> only for applications that request REST Direct Access Grants, and that >> apiman doesn't. Is that correct? > >Embarrassingly I'm not 100% sure what that setting is all about. Here >is the documentation from keycloak: > >---- >credentials >Specify the credentials of the application. This is an object notation >where the key is the credential type and the value is the value of the >credential type. Currently only 'password' is supported. This is REQUIRED. >---- > >It would be a good question to ask on the keycloak mailing list. > >@msavy - any idea? > >> 2. If I'm configuring the gateway as a separate service, can I remove >> the apimanui.war secure-deployment entry? Correspondingly, when I >> configure the standalone API manager, do I remove the >> apiman-gateway-api.war entry? > >Yep! It's not *required* to remove them, but you can certainly remove >them without ill effect. > >> 3. Is it possible to set properties that appear in apiman.properties by >> way of Java system properties or in a configuration >> in the standalone-apiman.xml file? > >Yes it is! :) Either of those approaches should work. You can also >use environment variables and eap/wildfly vaulted values if you like. >It's also possible to encrypt values (using our AesEncrypter class) and >put the encrypted value in the config. Not really secure but it's >better than having a password in clear text. > >-Eric > > From marc.savy at redhat.com Tue Dec 15 10:59:36 2015 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 15 Dec 2015 15:59:36 +0000 Subject: [Apiman-user] Receiving HTML instead of JSON from Keycloak when trying to point apimanui to the API gateway In-Reply-To: References: Message-ID: <567038E8.2060305@redhat.com> Can you try a couple of things that might help debug this, please: - Log into the KC console, go to the apiman-gateway-api client (or whatever you called it), and flip on `direct grants only`. - Save and try again Please let me know the result! On 14/12/2015 22:00, Paul Blair wrote: > I'm getting a strange error in my production deployment which I'm having > difficulty troubleshooting. > > After deploying the apiman UI and gateway on separate hosts, according > to the production guide I have to point the API Manager to the API > gateway. If I hit the "New Gateway" button, I need to add the URI of the > gateway. I'm assuming this should be > > [PROTOCOL]://[GATEWAY_HOST]:[GATEWAY_PORT]/apiman-gateway-api/ -- which > should also be set as the redirect URI for the gateway in the Apiman > realm in Keycloak (followed by a star). This is different from my public > endpoint, which is [PROTOCOL]://[GATEWAY_HOST]:[GATEWAY_PORT]/apiman-gateway > > When I use the apimanager user (set up in the default realm file) to > test the gateway in the "New Gateway" screen I'm getting this error: > > *Gateway Configuration Invalid* > Something has gone wrong when testing the Gateway. Hopefully the details > (below) will help you figure out what. > > org.codehaus.jackson.JsonParseException: Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null') > at [Source: org.apache.http.conn.EofSensorInputStream at 450a7e3f; line: 1, column: 2] > > > If I look at what's happening in the API manager log, it looks like the > error is coming from getting HTML back from Keycloak where it's > expecting JSON. Is there some configuration I'm missing? Here are the > relevant API manager server logs: > > > 21:38:49,715 DEBUG [org.keycloak.adapters.RequestAuthenticator] (default > task-1) Bearer AUTHENTICATED > 21:38:49,717 DEBUG [org.keycloak.adapters.AuthenticatedActionsHandler] > (default task-1) AuthenticatedActionsValve.invoke > https://[APIMANUI]/apiman/gateways > ... > 21:38:50,796 DEBUG [org.apache.http.impl.execchain.MainClientExec] > (default task-1) Opening connection {s}->https://[GATEWAY] > ... > 21:38:50,864 DEBUG [org.apache.http.impl.execchain.MainClientExec] > (default task-1) Executing request GET /apiman-gateway-api/system/status > HTTP/1.1 > 21:38:50,864 DEBUG [org.apache.http.impl.execchain.MainClientExec] > (default task-1) Proxy auth state: UNCHALLENGED > 21:38:50,866 DEBUG [org.apache.http.headers] (default task-1) > http-outgoing-0 >> GET /apiman-gateway-api/system/status HTTP/1.1 > 21:38:50,866 DEBUG [org.apache.http.headers] (default task-1) > http-outgoing-0 >> Authorization: Basic YXBpbWFuYWdlcjphcGltYW4xMjMh > 21:38:50,866 DEBUG [org.apache.http.headers] (default task-1) > http-outgoing-0 >> Host: [GATEWAY] > ... > 21:38:50,881 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-0 << "HTTP/1.1 302 Found[\r][\n]" > 21:38:50,881 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-0 << "Expires: 0[\r][\n]" > 21:38:50,881 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-0 << "Set-Cookie: > OAuth_Token_Request_State=19/8069a233-7d97-4f9d-8696-673f72815124; > secure[\r][\n]" > 21:38:50,882 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-0 << "Location: > https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?response_type=code&client_id=apiman-gateway-api&redirect_uri=https%3A%2F%2F[GATEWAY]%2Fapiman-gateway-api%2Fsystem%2Fstatus&state=19%2F8069a233-7d97-4f9d-8696-673f72815124&login=true[\r][\n]" > ... > 21:38:50,894 DEBUG > [org.apache.http.client.protocol.ResponseProcessCookies] (default > task-1) Cookie accepted > [OAuth_Token_Request_State="19/8069a233-7d97-4f9d-8696-673f72815124", > version:0, domain:ec2-52-34-81-26.us-west-2.compute.amazonaws.com, > path:/apiman-gateway-api/system, expiry:null] > 21:38:50,894 DEBUG [org.apache.http.impl.client.DefaultRedirectStrategy] > (default task-1) Redirect requested to location > 'https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?response_type=code&client_id=apiman-gateway-api&redirect_uri=https%3A%2F%2F[GATEWAY]%2Fapiman-gateway-api%2Fsystem%2Fstatus&state=19%2F8069a233-7d97-4f9d-8696-673f72815124&login=true' > 21:38:50,900 DEBUG [org.apache.http.impl.execchain.RedirectExec] > (default task-1) Resetting target auth state > 21:38:50,900 DEBUG [org.apache.http.impl.execchain.RedirectExec] > (default task-1) Redirecting to > 'https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?response_type=code&client_id=apiman-gateway-api&redirect_uri=https%3A%2F%2F[GATEWAY]%2Fapiman-gateway-api%2Fsystem%2Fstatus&state=19%2F8069a233-7d97-4f9d-8696-673f72815124&login=true' > via {s}->https://[KEYCLOAK] > ... > 21:38:50,902 DEBUG > [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] (default > task-1) Connection request: [route: {s}->https://[KEYCLOAK]][total kept > alive: 1; route allocated: 0 of 2; total allocated: 1 of 20] > ... > 21:38:50,935 DEBUG > [org.apache.http.impl.conn.DefaultHttpClientConnectionOperator] (default > task-1) Connection established 172.17.1.52:46173<->172.31.41.242:8443 > 21:38:50,936 DEBUG [org.apache.http.impl.execchain.MainClientExec] > (default task-1) Executing request GET > /auth/realms/apiman/protocol/openid-connect/auth?response_type=code&client_id=apiman-gateway-api&redirect_uri=https%3A%2F%2F[GATEWAY]%2Fapiman-gateway-api%2Fsystem%2Fstatus&state=19%2F8069a233-7d97-4f9d-8696-673f72815124&login=true > HTTP/1.1 > 21:38:50,936 DEBUG [org.apache.http.impl.execchain.MainClientExec] > (default task-1) Proxy auth state: UNCHALLENGED > 21:38:50,936 DEBUG [org.apache.http.headers] (default task-1) > http-outgoing-1 >> GET > /auth/realms/apiman/protocol/openid-connect/auth?response_type=code&client_id=apiman-gateway-api&redirect_uri=https%3A%2F%2F[GATEWAY]%2Fapiman-gateway-api%2Fsystem%2Fstatus&state=19%2F8069a233-7d97-4f9d-8696-673f72815124&login=true > HTTP/1.1 > 21:38:50,936 DEBUG [org.apache.http.headers] (default task-1) > http-outgoing-1 >> Authorization: Basic YXBpbWFuYWdlcjphcGltYW4xMjMh > 21:38:50,936 DEBUG [org.apache.http.headers] (default task-1) > http-outgoing-1 >> Host: [KEYCLOAK] > 21:38:50,936 DEBUG [org.apache.http.headers] (default task-1) > http-outgoing-1 >> User-Agent: Apache-HttpClient/4.5 (Java/1.8.0_25) > 21:38:50,936 DEBUG [org.apache.http.headers] (default task-1) > http-outgoing-1 >> Accept-Encoding: gzip,deflate > ... > 21:38:50,960 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-1 << "HTTP/1.1 200 OK[\r][\n]" > 21:38:50,960 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-1 << "X-Powered-By: Undertow/1[\r][\n]" > 21:38:50,960 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-1 << "Set-Cookie: KC_RESTART=[COOKIE]; Version=1; > Path=/auth/realms/apiman; HttpOnly[\r][\n]" > 21:38:50,960 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-1 << "Server: WildFly/9[\r][\n]" > 21:38:50,960 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-1 << "X-Frame-Options: SAMEORIGIN[\r][\n]" > 21:38:50,960 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-1 << "Content-Security-Policy: frame-src 'self'[\r][\n]" > 21:38:50,960 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-1 << "Date: Mon, 14 Dec 2015 21:38:50 GMT[\r][\n]" > 21:38:50,960 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-1 << "Connection: keep-alive[\r][\n]" > 21:38:50,960 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-1 << "Content-Type: text/html[\r][\n]" > 21:38:50,960 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-1 << "Content-Length: 4171[\r][\n]" > 21:38:50,960 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-1 << "[\r][\n]" > 21:38:50,961 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-1 << " Transitional//EN" > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">[\n]" > 21:38:50,961 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-1 << " class="login-pf">[\n]" > 21:38:50,961 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-1 << "[\n]" > 21:38:50,961 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-1 << "[\n]" > 21:38:50,961 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-1 << " content="text/html; charset=UTF-8" />[\n]" > 21:38:50,961 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-1 << " content="width=device-width,initial-scale=1"/>[\n]" > 21:38:50,961 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-1 << " Log in to apiman[\n]" > 21:38:50,961 DEBUG [org.apache.http.wire] (default task-1) > http-outgoing-1 << "[\n]" > ? more html? > > > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From pblair at clearme.com Tue Dec 15 11:46:17 2015 From: pblair at clearme.com (Paul Blair) Date: Tue, 15 Dec 2015 16:46:17 +0000 Subject: [Apiman-user] Receiving HTML instead of JSON from Keycloak when trying to point apimanui to the API gateway In-Reply-To: <567038E8.2060305@redhat.com> Message-ID: I'm still seeing the same behavior. Under "Clients > Settings" in Keycloak I turned on "Direct Access Grants Enabled" -- is that the setting you were referring to? I then tried also turning off "Standard Flow Enabled" and get back the error: "Client is not allowed to initiate browser login with given response_type. Standard flow is disabled for the client." I get the same errors using a REST client. On 12/15/15, 10:59 AM, "Marc Savy" wrote: >apimanager From marc.savy at redhat.com Tue Dec 15 11:53:59 2015 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 15 Dec 2015 16:53:59 +0000 Subject: [Apiman-user] Receiving HTML instead of JSON from Keycloak when trying to point apimanui to the API gateway In-Reply-To: References: Message-ID: <567045A7.90300@redhat.com> No, at least in the version of KC I'm using, it is clients -> "apiman-gateway-api" -> settings -> "Direct Grants Only" http://i.imgur.com/1pDlEiQ.png On 15/12/2015 16:46, Paul Blair wrote: > I'm still seeing the same behavior. > > Under "Clients > Settings" in Keycloak I turned on "Direct Access Grants > Enabled" -- is that the setting you were referring to? > > I then tried also turning off "Standard Flow Enabled" and get back the > error: "Client is not allowed to initiate browser login with given > response_type. Standard flow is disabled for the client." > > I get the same errors using a REST client. > > > On 12/15/15, 10:59 AM, "Marc Savy" wrote: > >> apimanager > From pblair at clearme.com Tue Dec 15 12:04:24 2015 From: pblair at clearme.com (Paul Blair) Date: Tue, 15 Dec 2015 17:04:24 +0000 Subject: [Apiman-user] Receiving HTML instead of JSON from Keycloak when trying to point apimanui to the API gateway In-Reply-To: <567045A7.90300@redhat.com> Message-ID: Looks like they must have changed this screen significantly with the Keycloak 1.7.0.Final release: http://tinypic.com/r/vy9shx/9 I am not wedded to Keycloak 1.7 -- should I go back to 1.6.1.Final? On 12/15/15, 11:53 AM, "Marc Savy" wrote: >No, at least in the version of KC I'm using, it is clients -> >"apiman-gateway-api" -> settings -> "Direct Grants Only" > >http://i.imgur.com/1pDlEiQ.png > > >On 15/12/2015 16:46, Paul Blair wrote: >> I'm still seeing the same behavior. >> >> Under "Clients > Settings" in Keycloak I turned on "Direct Access Grants >> Enabled" -- is that the setting you were referring to? >> >> I then tried also turning off "Standard Flow Enabled" and get back the >> error: "Client is not allowed to initiate browser login with given >> response_type. Standard flow is disabled for the client." >> >> I get the same errors using a REST client. >> >> >> On 12/15/15, 10:59 AM, "Marc Savy" wrote: >> >>> apimanager >> > From msavy at redhat.com Tue Dec 15 12:29:46 2015 From: msavy at redhat.com (Marc Savy) Date: Tue, 15 Dec 2015 12:29:46 -0500 (EST) Subject: [Apiman-user] Receiving HTML instead of JSON from Keycloak when trying to point apimanui to the API gateway In-Reply-To: References: Message-ID: <641497565.41057875.1450200586658.JavaMail.zimbra@redhat.com> Aha. So, we haven't done any testing whatsoever with KC 1.7. So we're not really familiar with it (yet). I think in our quickstarts (etc) we're actually still using 1.2.x. That being said, if you hit (for instance) the status endpoint using `curl` do you have any luck? curl -v --user apimanager:apiman123! http://localhost:8080/apiman-gateway-api/system/status/ Substitute auth info if needed. I'm not sure what our adapters will do, given the large changes that have happened in the intervening period. ----- Original Message ----- From: "Paul Blair" To: "Marc Savy" Cc: apiman-user at lists.jboss.org Sent: Tuesday, 15 December, 2015 5:04:24 PM Subject: Re: [Apiman-user] Receiving HTML instead of JSON from Keycloak when trying to point apimanui to the API gateway Looks like they must have changed this screen significantly with the Keycloak 1.7.0.Final release: http://tinypic.com/r/vy9shx/9 I am not wedded to Keycloak 1.7 -- should I go back to 1.6.1.Final? On 12/15/15, 11:53 AM, "Marc Savy" wrote: >No, at least in the version of KC I'm using, it is clients -> >"apiman-gateway-api" -> settings -> "Direct Grants Only" > >http://i.imgur.com/1pDlEiQ.png > > >On 15/12/2015 16:46, Paul Blair wrote: >> I'm still seeing the same behavior. >> >> Under "Clients > Settings" in Keycloak I turned on "Direct Access Grants >> Enabled" -- is that the setting you were referring to? >> >> I then tried also turning off "Standard Flow Enabled" and get back the >> error: "Client is not allowed to initiate browser login with given >> response_type. Standard flow is disabled for the client." >> >> I get the same errors using a REST client. >> >> >> On 12/15/15, 10:59 AM, "Marc Savy" wrote: >> >>> apimanager >> > _______________________________________________ Apiman-user mailing list Apiman-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/apiman-user From pblair at clearme.com Tue Dec 15 12:42:05 2015 From: pblair at clearme.com (Paul Blair) Date: Tue, 15 Dec 2015 17:42:05 +0000 Subject: [Apiman-user] Receiving HTML instead of JSON from Keycloak when trying to point apimanui to the API gateway In-Reply-To: <641497565.41057875.1450200586658.JavaMail.zimbra@redhat.com> Message-ID: If I use the curl command you provided, I get a 302 with a redirect to Keycloak at /auth/realms/apiman/protocol/openid-connect/auth ... I changed the password for the apimanager user to make sure I was using the right password. If I hit that URI with a REST client, I get a "Login to apiman" HTML page back -- presumably it followed the redirect. I have a feeling Keycloak 1.7 may be expecting an additional parameter in the redirect URI. I wasn't seeing this when using 1.6.1.Final last week. On 12/15/15, 12:29 PM, "Marc Savy" wrote: >/apiman-gateway-api/system/status/ > From marc.savy at redhat.com Tue Dec 15 14:05:42 2015 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 15 Dec 2015 19:05:42 +0000 Subject: [Apiman-user] Receiving HTML instead of JSON from Keycloak when trying to point apimanui to the API gateway In-Reply-To: References: <641497565.41057875.1450200586658.JavaMail.zimbra@redhat.com> Message-ID: <56706486.9030000@redhat.com> I've just finished attempting to reproduce your situation - but unfortunately (!) it works fine for me! All I needed to do was turn on 'direct grants API' for apiman-gateway-api. Can you (suggest it to be off-list) send me your standalone.xml for apiman, please? Feel free to anonymise as appropriate. On 15/12/2015 17:42, Paul Blair wrote: > If I use the curl command you provided, I get a 302 with a redirect to > Keycloak at /auth/realms/apiman/protocol/openid-connect/auth ... I changed > the password for the apimanager user to make sure I was using the right > password. > > If I hit that URI with a REST client, I get a "Login to apiman" HTML page > back -- presumably it followed the redirect. > > I have a feeling Keycloak 1.7 may be expecting an additional parameter in > the redirect URI. I wasn't seeing this when using 1.6.1.Final last week. > > On 12/15/15, 12:29 PM, "Marc Savy" wrote: > > > /apiman-gateway-api/system/status/ > > > From eric.wittmann at redhat.com Tue Dec 15 15:11:53 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 15 Dec 2015 15:11:53 -0500 Subject: [Apiman-user] Production deployment questions In-Reply-To: References: Message-ID: <56707409.3000104@redhat.com> You are right - we need to update the production guide. Thanks! -Eric On 12/15/2015 9:56 AM, Paul Blair wrote: > I've received a response from the Keycloak list about the credential in > the secure-deployment configuration for Keycloak; this looks like > something that should be part of the apiman deployment instructions. I've > included the response below: > > > On 12/9/15, 7:40 AM, "Juraci Paix?o Kr?hling" wrote: > >> I don't know about the specifics of apiman, but this secret is not used >> only for direct access grants, in general. All in all, I'm not a big fan >> of shipping with a default secret/password (or any security "token"). >> >> If that also makes you feel not comfortable, you might want to try to >> change the "credential" for the "apiman" client on the "apiman" realm >> via the Keycloak admin console: >> >> - login to the auth console (admin:admin are the default credentials) >> - select the apiman realm on the top-left >> - select "Clients" and then "apiman" >> - select the second tab, "Credentials" >> - "Regenerate secret" >> >> This new secret should go into the standalone.xml, as value for all >> "kc:credential[name=secret]" whose realm/resource are "apiman". >> >> - Juca. > > > > > On 12/7/15, 8:35 PM, "Eric Wittmann" wrote: > >> Hi Paul - answers inline below. >> >>> 1. Is "password" supposed to be replaced by some credential? This isn't >>> mentioned in the instructions; my guess is that this credential is used >>> only for applications that request REST Direct Access Grants, and that >>> apiman doesn't. Is that correct? >> >> Embarrassingly I'm not 100% sure what that setting is all about. Here >> is the documentation from keycloak: >> >> ---- >> credentials >> Specify the credentials of the application. This is an object notation >> where the key is the credential type and the value is the value of the >> credential type. Currently only 'password' is supported. This is REQUIRED. >> ---- >> >> It would be a good question to ask on the keycloak mailing list. >> >> @msavy - any idea? >> >>> 2. If I'm configuring the gateway as a separate service, can I remove >>> the apimanui.war secure-deployment entry? Correspondingly, when I >>> configure the standalone API manager, do I remove the >>> apiman-gateway-api.war entry? >> >> Yep! It's not *required* to remove them, but you can certainly remove >> them without ill effect. >> >>> 3. Is it possible to set properties that appear in apiman.properties by >>> way of Java system properties or in a configuration >>> in the standalone-apiman.xml file? >> >> Yes it is! :) Either of those approaches should work. You can also >> use environment variables and eap/wildfly vaulted values if you like. >> It's also possible to encrypt values (using our AesEncrypter class) and >> put the encrypted value in the config. Not really secure but it's >> better than having a password in clear text. >> >> -Eric >> >> > From pblair at clearme.com Tue Dec 15 16:01:10 2015 From: pblair at clearme.com (Paul Blair) Date: Tue, 15 Dec 2015 21:01:10 +0000 Subject: [Apiman-user] Receiving HTML instead of JSON from Keycloak when trying to point apimanui to the API gateway In-Reply-To: <56706486.9030000@redhat.com> Message-ID: For the benefit of the list -- thanks to Marc and Eric's help, this issue was resolved. Currently the standalone.xml has to have enable-basic-auth set to true; i.e., true -- no other auth mechanism is currently supported. On 12/15/15, 2:05 PM, "Marc Savy" wrote: >I've just finished attempting to reproduce your situation - but >unfortunately (!) it works fine for me! All I needed to do was turn on >'direct grants API' for apiman-gateway-api. > >Can you (suggest it to be off-list) send me your standalone.xml for >apiman, please? Feel free to anonymise as appropriate. > >On 15/12/2015 17:42, Paul Blair wrote: >> If I use the curl command you provided, I get a 302 with a redirect to >> Keycloak at /auth/realms/apiman/protocol/openid-connect/auth ... I >>changed >> the password for the apimanager user to make sure I was using the right >> password. >> >> If I hit that URI with a REST client, I get a "Login to apiman" HTML >>page >> back -- presumably it followed the redirect. >> >> I have a feeling Keycloak 1.7 may be expecting an additional parameter >>in >> the redirect URI. I wasn't seeing this when using 1.6.1.Final last week. >> >> On 12/15/15, 12:29 PM, "Marc Savy" wrote: >> >> > /apiman-gateway-api/system/status/ >> > >> > From marc.savy at redhat.com Tue Dec 15 16:54:28 2015 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 15 Dec 2015 21:54:28 +0000 Subject: [Apiman-user] Receiving HTML instead of JSON from Keycloak when trying to point apimanui to the API gateway In-Reply-To: References: <56706486.9030000@redhat.com> Message-ID: <56708C14.5080602@redhat.com> To clarify - this is specifically referring to communication between the manager and the api gateway. Glad to be of assistance! On 15/12/2015 21:01, Paul Blair wrote: > For the benefit of the list -- thanks to Marc and Eric's help, this issue > was resolved. > > Currently the standalone.xml has to have enable-basic-auth set to true; > i.e., > > true > > -- no other auth mechanism is currently supported. > > > On 12/15/15, 2:05 PM, "Marc Savy" wrote: > > > I've just finished attempting to reproduce your situation - but > > unfortunately (!) it works fine for me! All I needed to do was turn on > > 'direct grants API' for apiman-gateway-api. > > > > Can you (suggest it to be off-list) send me your standalone.xml for > > apiman, please? Feel free to anonymise as appropriate. > > > > On 15/12/2015 17:42, Paul Blair wrote: > >> If I use the curl command you provided, I get a 302 with a redirect to > >> Keycloak at /auth/realms/apiman/protocol/openid-connect/auth ... I > >> changed > >> the password for the apimanager user to make sure I was using the right > >> password. > >> > >> If I hit that URI with a REST client, I get a "Login to apiman" HTML > >> page > >> back -- presumably it followed the redirect. > >> > >> I have a feeling Keycloak 1.7 may be expecting an additional parameter > >> in > >> the redirect URI. I wasn't seeing this when using 1.6.1.Final last week. > >> > >> On 12/15/15, 12:29 PM, "Marc Savy" wrote: > >> > >>> /apiman-gateway-api/system/status/ > >>> > >> > > > > > _______________________________________________ > 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 Dec 16 07:20:25 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 16 Dec 2015 07:20:25 -0500 Subject: [Apiman-user] Receiving HTML instead of JSON from Keycloak when trying to point apimanui to the API gateway In-Reply-To: <56708C14.5080602@redhat.com> References: <56706486.9030000@redhat.com> <56708C14.5080602@redhat.com> Message-ID: <56715709.30201@redhat.com> Additionally, we do have a feature request for supporting auth mechanisms other than BASIC for connecting the Manager to the Gateway API: https://issues.jboss.org/browse/APIMAN-205 If anyone has specific auth schemes they'd like to see supported, feel free to add that as a comment to the jira ticket. Finally, it's worth noting that OAuth *is* supported by the Gateway API, but not by the Manager (which connects *to* the Gateway API). -Eric On 12/15/2015 4:54 PM, Marc Savy wrote: > To clarify - this is specifically referring to communication between the manager and the api gateway. > > Glad to be of assistance! > > On 15/12/2015 21:01, Paul Blair wrote: >> For the benefit of the list -- thanks to Marc and Eric's help, this issue >> was resolved. >> >> Currently the standalone.xml has to have enable-basic-auth set to true; >> i.e., >> >> true >> >> -- no other auth mechanism is currently supported. >> >> >> On 12/15/15, 2:05 PM, "Marc Savy" wrote: >> >>> I've just finished attempting to reproduce your situation - but >>> unfortunately (!) it works fine for me! All I needed to do was turn on >>> 'direct grants API' for apiman-gateway-api. >>> >>> Can you (suggest it to be off-list) send me your standalone.xml for >>> apiman, please? Feel free to anonymise as appropriate. >>> >>> On 15/12/2015 17:42, Paul Blair wrote: >>>> If I use the curl command you provided, I get a 302 with a redirect to >>>> Keycloak at /auth/realms/apiman/protocol/openid-connect/auth ... I >>>> changed >>>> the password for the apimanager user to make sure I was using the right >>>> password. >>>> >>>> If I hit that URI with a REST client, I get a "Login to apiman" HTML >>>> page >>>> back -- presumably it followed the redirect. >>>> >>>> I have a feeling Keycloak 1.7 may be expecting an additional parameter >>>> in >>>> the redirect URI. I wasn't seeing this when using 1.6.1.Final last week. >>>> >>>> On 12/15/15, 12:29 PM, "Marc Savy" wrote: >>>> >>>>> /apiman-gateway-api/system/status/ >>>>> >>>> >>> >> >> >> _______________________________________________ >> 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 Dec 16 09:33:41 2015 From: marc.savy at redhat.com (Marc Savy) Date: Wed, 16 Dec 2015 14:33:41 +0000 Subject: [Apiman-user] Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password In-Reply-To: <201260241.37561026.1449765703238.JavaMail.zimbra@redhat.com> References: <56695AED.5070501@redhat.com> <56695D8D.5040707@redhat.com> <56695E0A.8050709@redhat.com> <201260241.37561026.1449765703238.JavaMail.zimbra@redhat.com> Message-ID: <56717645.8030506@redhat.com> Hi Ton, This feature is now implemented, and is on master. It works with standard and custom claims (custom token properties). I think custom claims are likely a nice solution to your problem. If you want to test drive it, please check out the apiman-plugins repo, build with `mvn clean install`, and in the plugin management section reload your keycloak-aouth plugin. Otherwise, it'll be out with 1.2.0 :) For more info, see: https://github.com/apiman/apiman-plugins/pull/43 Regards, Marc On 10/12/2015 16:41, Marc Savy wrote: > Ton, > > I've added a JIRA for your feature request/enhancement - https://issues.jboss.org/browse/APIMAN-834 > > Marc > > ----- Original Message ----- > From: "Ton Swieb" > To: "Marc Savy" > Cc: apiman-user at lists.jboss.org > Sent: Thursday, 10 December, 2015 3:56:54 PM > Subject: Re: [Apiman-user] Keycloak OAuth2 policy: Get bearer token for logged in user without using username/password > > Hi Marc, > > Thanks. > The plugin functionality for the roundtrip in our Proof of Concept setup is sufficient. > In the future I expect that we would need more flexibility in the mapping of access token properties onto headers. > > Regards, > > Ton > > 2015-12-10 12:12 GMT+01:00 Marc Savy < marc.savy at redhat.com > : > > > Sorry, missed out part of my sentence: > > If you feel the configuration options offered by the Keycloak OAuth2 policy *are insufficient* let me know, > and we can work out what changes might be possible to help. > > On 10/12/2015 11:10, Marc Savy wrote: > > > Nice! And understood - that should all work. If you feel the > configuration options offered by the Keycloak OAuth2 policy let me know, > and we can work out what changes might be possible to help. > > On 10/12/2015 11:06, Ton Swieb wrote: >> Yes we have set up Keycloak to delegate to a SAML IdP. So a user is >> redirected to a SAML IdP for login. After successfull login the user is >> automatically logged in in Keycloak and we can use the JS adapter to >> obtain an access token for accessing the Apiman gateway. >> We have this roundtrip working now, but we do still have some challenges >> with the mapping the SAML attributes to the Keycloak token. >> >> >> 2015-12-10 11:58 GMT+01:00 Marc Savy < marc.savy at redhat.com >> >: >> >> Your JS snippet is indeed typical of what happens in the real world - >> you generally wouldn't use a username and password in a plaintext >> JS app - instead you would use a client secret that can easily be >> regenerated (or login redirection for UI apps). >> >> What you're doing is the typical work-flow in JS; Keycloak's JS library >> does the work behind the scenes to do the heavy lifting for you. >> >> Next step will be to test it with the SAML IdP instead of standalone >> Keycloak, but I do not expect it to behave any differently. >> >> >> You mean you are setting up Keycloak to delegate to your SAML IdP? >> >> On 09/12/2015 16:02, Ton Swieb wrote: >> >> Hi Marc, >> >> I got it working, without the SAML IdP, using the Keycloak >> Javascript >> adapter. >> >> I used the Keycloak JS-Console example and extended it with a >> javascript >> function that does a call the apiman-gateway after I have a >> logged in >> session with Keycloak. Something like: >> var client = new XMLHttpRequest(); >> client.open("GET", url, false); >> client.setRequestHeader("Accept", "application/json"); >> client.setRequestHeader("Authorization", "Bearer " + >> keycloak.token); >> client.send(); >> >> The keycloak.token is available after a call to >> keycloak.login(). Both >> are part of the Keycloak javascript adapter. >> >> Underneath the Javascript adapter still does a call similair to >> http://127.0.0.1:8080/auth/realms/stottie/protocol/openid-connect/token >> to retrieve the access token. With the difference that the >> grant_type >> used is authorization_code instead of password and a code is >> supplied >> instead of a username/password combination. I assume the code is >> retrieved from the keycloak session. Not sure how it exactly >> works, but >> it works. >> >> Next step will be to test it with the SAML IdP instead of standalone >> Keycloak, but I do not expect it to behave any differently. >> >> Regards, >> >> Ton >> >> 2015-12-08 19:00 GMT+01:00 Ton Swieb < ton at finalist.nl >> >> >>: >> >> Hi Marc, >> >> I am using the following setup: >> 1. Client -> Keycloak (apiman realm) -> SAML 2.0 IdP -> >> Keycloak >> (apiman realm) -> Client >> 2. Client -> apiman gateway -> Keycloak OAuth policy -> >> back-end -> >> apiman gateway -> Client >> >> The IdP is a SAML 2.0 IdP. I believe it is SimpleSAMLPHP. >> It is unclear to me why it matters which IdP I am using, >> because my >> assumption is that: >> >> * I end up with a valid Keycloak session within the >> apiman realm >> * the SAML 2.0 token should only be used by Keycloak to >> issue a >> login session to the client. >> * the client itself will never directly use anyhting from >> the SAML >> 2.0 IdP, but should only use the stuff that Keycloak >> mapped from >> the SAML token onto its own token. >> >> I did ask the question on the keycloak mailinglist, but from a >> different angle. I am afraid the solution for my problem >> will be >> somewhere in between. >> Any help from your site is greatly appreciated :-) >> >> Regards, >> >> Ton >> >> >> Message: 5 >> Date: Tue, 8 Dec 2015 16:58:26 +0000 >> From: Marc Savy < marc.savy at redhat.com >> > >> >> Subject: Re: [Apiman-user] Keycloak OAuth2 policy: Get >> bearer token >> for logged in user without using username/password >> To: apiman-user at lists.jboss.org >> >> > > >> Message-ID: < 56670C32.3060000 at redhat.com >> >> > >> >> Content-Type: text/plain; charset=UTF-8; format=flowed >> >> To expand on that - depending on exactly what type of IdP (and >> specifically which technology) you were delegating to, it >> may be >> possible to do what you're asking - or you may need to write >> something custom. >> >> Can you provide more detail? >> >> Also, if you have very specific Keycloak questions you >> might be best >> served on the keycloak-user mailing list, which is >> extremely active >> ( https://lists.jboss.org/mailman/listinfo/keycloak-user ). >> >> On 08/12/2015 16:53, Marc Savy wrote: >>> Hi Ton, >>> >>> I'm not quite sure what you mean, but I think what >> you're asking >> for is >>> brokerage/delegation in the form: >>> >>> 1. Client <-> Keycloak <-> Other IdP. >>> 2. Client <-> apiman gateway >>> >>> Regards, >>> Marc >>> >>> On 08/12/2015 15:28, Ton Swieb wrote: >>>> Hi, >>>> >>>> I would like to secure my api's using the Keycloak >> OAuth2 policy. >>>> Similair to what is described in the blog post of Marc >> Savy: >>>> >> http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html >>>> >>>> >>>> Only with the difference that Keycloak delegates the >> login to a >> third >>>> party IdP. After logging in at this third party IdP I >> end up >> with an >>>> active session in the Apiman UI (the apiman realm of >> Keycloak). >>>> >>>> Now I am wondering how to get the bearer token, >> because I do >> not have a >>>> username/password combination I can use to make a call >> like: >>>> >>>> |curl -X POST >>>> >> http://127.0.0.1:8080/auth/realms/stottie/protocol/openid-connect/token >>>> -H "Content-Type: application/x-www-form-urlencoded" -d >>>> "username=rincewind" -d 'password=apiman' -d >> 'grant_type=password' -d >>>> 'client_id=apiman'| >>>> >>>> Because the username/password combination is linked to the >> third party >>>> IdP and not to Keycloak itself. >>>> >>>> Is there another way to obtain the bearer token? >>>> >>>> Perhaps this is aquestion which I should address at >> the keycloak >>>> mailinglist. I will try to ask the question there as well. >>>> >>>> Regards, >>>> >>>> Ton >>>> >>>> >>>> _______________________________________________ >>>> 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 > _______________________________________________ > 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 Dec 17 15:48:48 2015 From: guydavis.ca at gmail.com (Guy Davis) Date: Thu, 17 Dec 2015 13:48:48 -0700 Subject: [Apiman-user] Integration with separate Keycloak server? Message-ID: 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 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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151217/939c3d5c/attachment.html From eric.wittmann at redhat.com Thu Dec 17 17:35:31 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 17 Dec 2015 17:35:31 -0500 Subject: [Apiman-user] Integration with separate Keycloak server? In-Reply-To: References: Message-ID: <567338B3.1050706@redhat.com> 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 > > 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 > 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 guydavis.ca at gmail.com Thu Dec 31 01:00:23 2015 From: guydavis.ca at gmail.com (Guy Davis) Date: Wed, 30 Dec 2015 23:00:23 -0700 Subject: [Apiman-user] Integration with separate Keycloak server? In-Reply-To: <567338B3.1050706@redhat.com> References: <567338B3.1050706@redhat.com> Message-ID: 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 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 >> >> 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/20151230/ad88d535/attachment.html From mssanjay at gmail.com Tue Dec 29 12:19:29 2015 From: mssanjay at gmail.com (Sanjay Melinamani) Date: Tue, 29 Dec 2015 12:19:29 -0500 Subject: [Apiman-user] How to update backend implementation URL for published Service without changing the version Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151229/d3bd7e2c/attachment.html