apiman using external keycloak and elasticsearch
by jazz
Hi,
I would like to use apiman deployed on wildfly 10, without the included
keyloak and elasticsearch instances.
keycloak (v1.9.1): localhost:8080/auth
elasticsearch (v2.2.1): localhost:9200
apiman (v1.2.3): localhost:8080/apiman
This guide got me started: http://www.apiman.io/latest/production-guide
.html
I use the overlay: http://downloads.jboss.org/apiman/1.2.3.Final/apiman
-distro-wildfly10-1.2.3.Final-overlay.zip
2016-03-29 11:41:01,770 ERROR [org.jboss.as.controller.management-
operation] (DeploymentScanner-threads
- 2) WFLYCTL0013: Operation ("full-replace-deployment") failed -
address: ([]) - failure description:
{"WFLYCTL0288: One or more services were unable to start due to one or
more indirect dependencies not being available." => {
"Services that were unable to start:" =>
["jboss.deployment.unit.\"apiman-gateway-engine-beans.jar\".PARSE"],
"Services that may be the cause:" => [
"jboss.module.spec.service.\"deployment.apiman-gateway-engine-
beans.jar\".main",
"jboss.remoting.remotingConnectorInfoService.http-remoting-
connector",
"module.resolved.service.\"deployment.apiman-gateway-
api.war\".main",
"module.resolved.service.\"deployment.apiman-
gateway.war\".main"
]
}}
2016-03-29 12:05:47,782 ERROR [org.jboss.msc.service.fail] (MSC service
thread 1-2) MSC000001: Failed t
o start service jboss.deployment.unit."apiman-gateway-
api.war".STRUCTURE: org.jboss.msc.service.StartEx
ception in service jboss.deployment.unit."apiman-gateway-
api.war".STRUCTURE: WFLYSRV0153: Failed to pro
cess phase STRUCTURE of deployment "apiman-gateway-api.war"
Deployment in the web console works fine for these wars
apiman.war
apimanui.war
The apiman-gateway.war and apiman-gateway-api.war fail.
Question: how to deploy apiman using external keycloak and
elasticsearch instances running on the same host?
Thanks in advance for any pointers.
Regards, Bart
8 years, 10 months
Re: [Apiman-user] keycloak question
by Marc Savy
> You meant the diagram in the link you provided for using the Mutual TLS, correct? I just want to make sure that you were referring to that solution. And thanks so much for providing these information—really, really helpful.
Yes, that’s right.
Communications between a client (e.g. web app) and apiman are secured by Keycloak; communications between apiman and APIs are secured by mutual TLS (or whichever scheme you choose).
Regards,
Marc
> On 21 Mar 2016, at 15:23, Cabardo, Jeanette <jeanette_cabardo(a)merck.com> wrote:
>
> Just to clarify your statement:
>
> Instead of protecting your APIs directly, you could instead remove the auth from them and let apiman deal with it (see the diagram in the linked blog post) and simply stop unauthorised folk calling those services directly. That would likely be a good option to evaluate.
>
> You meant the diagram in the link you provided for using the Mutual TLS, correct? I just want to make sure that you were referring to that solution. And thanks so much for providing these information—really, really helpful.
>
> Jeanette
>
> From: Marc Savy <marc(a)rhymewithgravy.com <mailto:marc@rhymewithgravy.com>>
> Date: Monday, March 21, 2016 at 11:15 AM
> To: "Cabardo, Jeanette" <jeanette_cabardo(a)merck.com <mailto:jeanette_cabardo@merck.com>>
> Subject: Re: keycloak question
>
>> (I have recommended doing it on the network level as you noted in the embedded link that I provided but our network engineer is adamant on protecting the endpoints explicitly).
>
> I suggest using Mutual TLS (good solution, high security) or BASIC (development or lower security). MTLS blog is below. It’s an excellent option for your requirements:
>
> http://www.apiman.io/blog/gateway/security/mutual-auth/ssl/mtls/1.2.x/201... <http://www.apiman.io/blog/gateway/security/mutual-auth/ssl/mtls/1.2.x/201...>
>
>
> The downside of both of these is that it requires some modification of your existing APIs, whereas the network solution is more transparent. Either way, the above is well supported :).
>
> Instead of protecting your APIs directly, you could instead remove the auth from them and let apiman deal with it (see the diagram in the linked blog post) and simply stop unauthorised folk calling those services directly. That would likely be a good option to evaluate.
>
>
>
>> On 21 Mar 2016, at 14:53, Cabardo, Jeanette <jeanette_cabardo(a)merck.com <mailto:jeanette_cabardo@merck.com>> wrote:
>>
>> Yes, Marc, please feel free to copy my posting. I am fairly new to Apiman and keycloak, and been struggling finding examples/documentation that can help. I think these blogs definitely helped a lot in the past few days.
>>
>> And yes, my requirement is to explicitly protect the endpoints (I have recommended doing it on the network level as you noted in the embedded link that I provided but our network engineer is adamant on protecting the endpoints explicitly). I was able to protect the endpoints by using the nodejs library (connect-keycloak) though I’m finding I have to make adjustments as it was developed on the older version of keycloak and I think it’s really primarily if you have a client app more than just a back-end api. I know that this issue that I have raised maybe a combination of apiman/keycloak but it would be good to know if what I’m doing is feasible or am I chasing something that’s not even possible at this time, is what I am trying to at least find out. As a back-up we can opt to do the protection on the network level.
>>
>> Jeanette
>>
>> From: Marc Savy <marc(a)rhymewithgravy.com <mailto:marc@rhymewithgravy.com>>
>> Date: Monday, March 21, 2016 at 10:41 AM
>> To: "Cabardo, Jeanette" <jeanette_cabardo(a)merck.com <mailto:jeanette_cabardo@merck.com>>
>> Subject: Re: keycloak question
>>
>> Hi Jeanette,
>>
>> The blog-post refers to a use-case where you are applying your Keycloak authentication [1] against your API configured in apiman; not directly on the API itself. That is, apiman provides and performs the authentication *on behalf* of your API:
>>
>> i.e
>>
>>
>> /---> Keycloak
>> |
>> v [Validate]
>> client <—> apiman <—> API
>>
>> Notice, the API itself is not protected directly by Keycloak. apiman does it on the API’s behalf.
>>
>>
>>> means that you are protecting this api explicitly, I.e., that without using any additional network level protection, one cannot just simply go into the browser or Postman and type in the url: http://localhost:8080/apiman-echo? <http://localhost:8080/apiman-echo?>
>>
>> If you want to stop people calling your API endpoint explicitly then you need to protect it . For instance, network level configuration or OOTB endpoint protection options: MTLS (Mutual TLS) or BASIC. The blog is simply for demonstrating the concepts, so it would indeed be useless in a production setup if developers could bypass the gateway.
>>
>> Would you object if I copy this over to the apiman-user mailing list so that more people can participate?
>>
>> Regards,
>> Marc
>>
>> [1] OpenID Connect JWT
>>
>>> On 18 Mar 2016, at 19:59, Cabardo, Jeanette <jeanette_cabardo(a)merck.com <mailto:jeanette_cabardo@merck.com>> wrote:
>>>
>>> Hi, Marc. I just have a quick question regarding your blog post (http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication... <http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication...>)
>>>
>>> We currently have managed to set up our api to use Apiman to manage access to it and is also trying to use keycloak to potentially protect the back-end api endpoints. In you post, I just wasn’t clear whether your statement…
>>>
>>> “Let’s assume we’re going to protect a very simple echo service, which echoes back to the requestor the details of any request made to it. It is located athttp://localhost:8080/apiman-echo <http://localhost:8080/apiman-echo>.”
>>>
>>> means that you are protecting this api explicitly, I.e., that without using any additional network level protection, one cannot just simply go into the browser or Postman and type in the url: http://localhost:8080/apiman-echo <http://localhost:8080/apiman-echo>? I was using this middleware connect-keycloak to protect my endpoints but after doing so, my endpoint configuration in apiman also can’t get to the endpoint. So, when I saw your post, I thought maybe this will be the solution to my problem but just not sure if on the api side itself (in your example, apiman-echo), there is also some keycloak setup/config that needs to happen.
>>>
>>> I have been struggling to get this to work but maybe you can shed some light for me to understand whether what I’m doing even make sense. Appreciate any help you can provide.
>>>
>>> Jeanette
>>>
>>> Jeanette U. Cabardo
>>> IT Planning & Innovation – Applied Technology
>>> Mail Room: 1131, Mail Code: BRN-1161A
>>> Merck Sharp & Dohme Corp.
>>> 3070 Route 22
>>> Branchburg, NJ 08876 USA
>>> 908-243-8818
>>> Email: jeanette_cabardo(a)merck.com <mailto:jeanette.cabardo@spcorp.com>
>>> Notice: This e-mail message, together with any attachments, contains
>>> information of Merck & Co., Inc. (2000 Galloping Hill Road, Kenilworth,
>>> New Jersey, USA 07033), and/or its affiliates Direct contact information
>>> for affiliates is available at
>>> http://www.merck.com/contact/contacts.html <http://www.merck.com/contact/contacts.html>) that may be confidential,
>>> proprietary copyrighted and/or legally privileged. It is intended solely
>>> for the use of the individual or entity named on this message. If you are
>>> not the intended recipient, and have received this message in error,
>>> please notify us immediately by reply e-mail and then delete it from
>>> your system.
>>
>> Notice: This e-mail message, together with any attachments, contains
>> information of Merck & Co., Inc. (2000 Galloping Hill Road, Kenilworth,
>> New Jersey, USA 07033), and/or its affiliates Direct contact information
>> for affiliates is available at
>> http://www.merck.com/contact/contacts.html <http://www.merck.com/contact/contacts.html>) that may be confidential,
>> proprietary copyrighted and/or legally privileged. It is intended solely
>> for the use of the individual or entity named on this message. If you are
>> not the intended recipient, and have received this message in error,
>> please notify us immediately by reply e-mail and then delete it from
>> your system.
>
> Notice: This e-mail message, together with any attachments, contains
> information of Merck & Co., Inc. (2000 Galloping Hill Road, Kenilworth,
> New Jersey, USA 07033), and/or its affiliates Direct contact information
> for affiliates is available at
> http://www.merck.com/contact/contacts.html) that may be confidential,
> proprietary copyrighted and/or legally privileged. It is intended solely
> for the use of the individual or entity named on this message. If you are
> not the intended recipient, and have received this message in error,
> please notify us immediately by reply e-mail and then delete it from
> your system.
8 years, 11 months
Securing back-end API endpoints with keycloak renders apis inaccessible via Apiman
by Cabardo, Jeanette
Hi. Not sure if there are already posting similar to the issue I’m having (or maybe the feature may not be in place yet). My requirement is to secure the back-end API endpoints with keycloak. It was a bit of a pain because the apis were developed in node.js and there was really not a whole lot of examples or library on how to accomplish this. Anyway, I think I was finally able to do this, however, once I had put the protection in place, the endpoints stopped working in Apiman. I’m not quite sure how to forward the credentials to allow it to access the endpoints. I think the closest posting I found that may be similar to what I need is:
http://lists.jboss.org/pipermail/apiman-user/2015-March/000030.html
I guess what I wanted to find out is whether or not what I’m trying to do is possible at this time as I have researching and trying to search for more info on how to accomplish this and haven’t had any luck doing so.
I appreciate any help you can extend. Thanks in advance.
Jeanette
Notice: This e-mail message, together with any attachments, contains
information of Merck & Co., Inc. (2000 Galloping Hill Road, Kenilworth,
New Jersey, USA 07033), and/or its affiliates Direct contact information
for affiliates is available at
http://www.merck.com/contact/contacts.html) that may be confidential,
proprietary copyrighted and/or legally privileged. It is intended solely
for the use of the individual or entity named on this message. If you are
not the intended recipient, and have received this message in error,
please notify us immediately by reply e-mail and then delete it from
your system.
8 years, 11 months
Trying to get echo example working...
by Joel Schuster
Folks,
I'm working through the echo example and I'm running into a couple of issues:
java version "1.8.0_73"
Java(TM) SE Runtime Environment (build 1.8.0_73-b02)
Java HotSpot(TM) 64-Bit Server VM (build 25.73-b02, mixed mode)
wildfly-10.0.0.Final
apiman-distro-wildfly10-1.2.2.Final-overlay
When I try to add the basic authentication policy the 'Add Policy' button never becomes enabled.
So I skipped that step and tried to publish as-is. I get this error (Full stack trace below):
Caused by: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
The only reference I find to this is in this bug, which should be fixed in this version: https://issues.jboss.org/browse/APIMAN-443
Any help would be appreciated.
Thanks!
- Joel
io.apiman.manager.api.rest.contract.exceptions.ActionException: Failed to publish API.
at io.apiman.manager.api.rest.impl.util.ExceptionFactory.actionException(ExceptionFactory.java:311)
at io.apiman.manager.api.rest.impl.ActionResourceImpl.publishApi(ActionResourceImpl.java:229)
at io.apiman.manager.api.rest.impl.ActionResourceImpl.performAction(ActionResourceImpl.java:105)
at io.apiman.manager.api.rest.impl.ActionResourceImpl$Proxy$_$$_WeldClientProxy.performAction(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at io.apiman.common.servlet.RootResourceFilter.doFilter(RootResourceFilter.java:59)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.apiman.manager.api.war.TransactionWatchdogFilter.doFilter(TransactionWatchdogFilter.java:57)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.apiman.manager.api.security.impl.DefaultSecurityContextFilter.doFilter(DefaultSecurityContextFilter.java:56)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.apiman.common.servlet.DisableCachingFilter.doFilter(DisableCachingFilter.java:59)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.apiman.common.servlet.ApimanCorsFilter.doFilter(ApimanCorsFilter.java:71)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.apiman.common.servlet.LocaleFilter.doFilter(LocaleFilter.java:61)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handleRequest(UndertowAuthenticatedActionsHandler.java:66)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
at io.apiman.manager.api.gateway.rest.GatewayClient.getStatus(GatewayClient.java:98)
at io.apiman.manager.api.gateway.rest.RestGatewayLink.isGatewayUp(RestGatewayLink.java:134)
at io.apiman.manager.api.gateway.rest.RestGatewayLink.publishApi(RestGatewayLink.java:160)
at io.apiman.manager.api.rest.impl.ActionResourceImpl.publishApi(ActionResourceImpl.java:203)
... 68 more
Caused by: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
at sun.security.ssl.InputRecord.read(InputRecord.java:527)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:394)
at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:353)
at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:134)
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at io.apiman.manager.api.gateway.rest.GatewayClient.getStatus(GatewayClient.java:86)
... 71 more
CONFIDENTIALITY NOTICE: THIS MESSAGE IS CONFIDENTIAL, INTENDED FOR THE NAMED RECIPIENT(S) AND MAY CONTAIN INFORMATION THAT IS (I) PROPRIETARY TO THE SENDER, AND/OR, (II) PRIVILEGED, CONFIDENTIAL, AND/OR OTHERWISE EXEMPT FROM DISCLOSURE UNDER APPLICABLE STATE AND FEDERAL LAW, INCLUDING, BUT NOT LIMITED TO, PRIVACY STANDARDS IMPOSED PURSUANT TO THE FEDERAL HEALTH INSURANCE PORTABILITY AND ACCOUNTABILITY ACT OF 1996 ("HIPAA"). IF YOU ARE NOT THE INTENDED RECIPIENT, OR THE EMPLOYEE OR AGENT RESPONSIBLE FOR DELIVERING THE MESSAGE TO THE INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY DISSEMINATION, DISTRIBUTION OR COPYING OF THIS COMMUNICATION IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS TRANSMISSION IN ERROR, PLEASE (I) NOTIFY US IMMEDIATELY BY REPLY E-MAIL OR BY TELEPHONE AT (855.472.9822), (II) REMOVE IT FROM YOUR SYSTEM, AND (III) DESTROY THE ORIGINAL TRANSMISSION AND ITS ATTACHMENTS WITHOUT READING OR SAVING THEM. THANK YOU.
-DaVita Healthcare Partners Inc.-
8 years, 11 months
How to change the default API URL
by Joel Schuster
By default APIs end up here:
http://gatewayhost:port/apiman-gateway/{organizationId}/{apiId}/{version}/<http://gatewayhost:port/apiman-gateway/%7borganizationId%7d/%7bapiId%7d/%...>
I'd like to change this so it ends up here:
http://gatewayhost:port/apiman-gateway/{organizationId}/{version}/{apiId}/<http://gatewayhost:port/apiman-gateway/%7borganizationId%7d/%7bversion%7d...>
I'd also like to change the 'apiman-gateway' to simply 'gateway'.
How can I do that?
Thanks!
- Joel
CONFIDENTIALITY NOTICE: THIS MESSAGE IS CONFIDENTIAL, INTENDED FOR THE NAMED RECIPIENT(S) AND MAY CONTAIN INFORMATION THAT IS (I) PROPRIETARY TO THE SENDER, AND/OR, (II) PRIVILEGED, CONFIDENTIAL, AND/OR OTHERWISE EXEMPT FROM DISCLOSURE UNDER APPLICABLE STATE AND FEDERAL LAW, INCLUDING, BUT NOT LIMITED TO, PRIVACY STANDARDS IMPOSED PURSUANT TO THE FEDERAL HEALTH INSURANCE PORTABILITY AND ACCOUNTABILITY ACT OF 1996 ("HIPAA"). IF YOU ARE NOT THE INTENDED RECIPIENT, OR THE EMPLOYEE OR AGENT RESPONSIBLE FOR DELIVERING THE MESSAGE TO THE INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY DISSEMINATION, DISTRIBUTION OR COPYING OF THIS COMMUNICATION IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS TRANSMISSION IN ERROR, PLEASE (I) NOTIFY US IMMEDIATELY BY REPLY E-MAIL OR BY TELEPHONE AT (855.472.9822), (II) REMOVE IT FROM YOUR SYSTEM, AND (III) DESTROY THE ORIGINAL TRANSMISSION AND ITS ATTACHMENTS WITHOUT READING OR SAVING THEM. THANK YOU.
-DaVita Healthcare Partners Inc.-
8 years, 11 months
Elasticsearch configuration
by Aikeaguinea
I'm moving toward a production deployment of apiman on AWS. At least for
now we're using Amazon's Elasticsearch service and have been able to
configure and use it.
For production, we need to pay attention to some of the finer details of
clustering, etc. It looks like sharding is mainly controlled when an
index is created. How does apiman manage creating replica shards? Does
this need to be configured somehow?
--
http://www.fastmail.com - IMAP accessible web-mail
8 years, 11 months
