We are trying to setup WSO2 API manager cluster with F5 as the load balancer and been having issues with having F5 in the mix. One manager instance is setup on a server (server/Admin port: node1.xyz.com:9443) with F5 (manager.xyz.com that maps to node1.xyz.com:9443).
After several trial and error methods, we found the issue to be with API key manager URL configuration in the worker instance. Using direct server/port URL (i.e. node1.xyz.com:9443) works fine. However, when we use the F5 url (i.e. manager.xyz.com) results in the exception below. Any thoughts as to what may be incorrect or missing?
Eventually we want to have two manager instances running. So, we like to get this F5 setup working such that worker instances can point to F5 instead of individual manager node.
Thanks for the help in advance!
Configuration in the Worker node that works:
<APIKeyManager>
<!--
Server URL of the API key manager
-->
<ServerURL>https://node1.xyz.com:9443${carbon.context}/services/</ServerURL>
Configuration in the Worker node that causes error with F5:
<APIKeyManager>
<!--
Server URL of the API key manager
-->
<ServerURL>https://manager.xyz.com${carbon.context}/services/</ServerURL>
Exception when using F5:
TID: [0] [AM] [2014-12-11 16:03:37,697] ERROR {org.wso2.carbon.apimgt.gateway.handlers.security.APIAuthenticationHandler} - API authentication failure {org.wso2.carbon.apimgt.gateway.handlers.security.APIAuthenticationHandler}
org.wso2.carbon.apimgt.gateway.handlers.security.APISecurityException: Error while accessing backend services for API key validation
at org.wso2.carbon.apimgt.gateway.handlers.security.thrift.ThriftAPIDataStore.getAllURITemplates(ThriftAPIDataStore.java:99)
at org.wso2.carbon.apimgt.gateway.handlers.security.APIKeyValidator.getAllURITemplates(APIKeyValidator.java:516)
at org.wso2.carbon.apimgt.gateway.handlers.security.APIKeyValidator.doGetAPIInfo(APIKeyValidator.java:368)
at org.wso2.carbon.apimgt.gateway.handlers.security.APIKeyValidator.findMatchingVerb(APIKeyValidator.java:343)
at org.wso2.carbon.apimgt.gateway.handlers.security.APIKeyValidator.getResourceAuthenticationScheme(APIKeyValidator.java:172)
at org.wso2.carbon.apimgt.gateway.handlers.security.oauth.OAuthAuthenticator.authenticate(OAuthAuthenticator.java:93)
at org.wso2.carbon.apimgt.gateway.handlers.security.APIAuthenticationHandler.handleRequest(APIAuthenticationHandler.java:92)
Few immediate things you could check -
Make sure the <HostName> and <MgtHostName> elements in KeyManager_HOME/repository/conf/carbon.xml are set to the hostname of the F5. ie. "manager.xyz.com"
Add the proxyPort=443 attribute to the https connector in KeyManager_HOME/repository/conf/tomcat/catalina-server.xml. Configure http connector as well if desired.
If you did not set above two settings, then the http 302 redirects fail which might explain your scenario. And, we ask users to configure ProxyPassReverse in addition to ProxyPass when using Apache HTTPD as the reverse proxy. I'm not sure the equivalent config for F5.
If the above didn't help we need to know how your deployment looks like to better help you. ie. how do you cluster the nodes. Do you have separate API gateway, keymanager instances etc.
I think it will worth your while to go through the WSO2 cluster guide to understand the clustering logic better.
With APIM, you can have separate Keymanager, API gateway (and API store, API publisher) nodes. The worker-manager separation only applies to the API Gateway. And, There is no worker-manager separation needed for the keymanager. So, you may think the all the API keymanager nodes are hybrid nodes that provide both manager and worker functionality.
We can see further if you do not have separate keymanagers.
Related
my scenario is about two servers one running wso2 api manager and one running wso2 analytics and I want to show statics of api manager on analytics server .how to configure this servers? (analytics dashboard conf , analytics worker conf , api manager conf) thanx
WARN {org.wso2.msf4j.internal.MSF4JHttpConnectorListener} - Unmapped exception
feign.RetryableException: No subject alternative names matching IP address 192.168.115.132
found executing GET https://192.168.115.132:9443/api/am/admin/v1/custom-urls/carbon.super
This is due to the hostname verification. The recommended option is to use proper certs with hostnames. Otherwise, you can disable hostname verification by adding the following.
hostnameVerificationEnabled: false
https://github.com/wso2/docker-apim/blob/3.2.x/docker-compose/apim-with-analytics/conf/apim-analytics-dashboard/conf/dashboard/deployment.yaml#L25
I am doing a POC with my team as we are introducing WSO2 components and am working with the API Manager 3.0.
I seem to be having issues loading the WSO2 API Manager / API Publisher on the defined URL;
https://[ip address]/publisher
The page is not loading and I keep getting a spinning circle.
Steps I have taken:
Stop API Manager at command prompt with [Ctrl + C] command
Modified deployment.toml file specified paths for the localhost to our IP Address, API [publisher, gateway and store] URL values to use our IP Address as well.
Changed carbon.xml and api_manager.xml
Start API Manager with wso2server.bat --run command
Issues are as follows;
api_manager.xml values are reset to localhost and not the IP Address I modified it to.
The API Publisher page is not loading and I am not able to get to the API Publisher login page.
I am an administrator on the Windows Server hosting this, so all changes are made as admin.
First of all, APIM 3.0 has a new config model, where all configurations are available (only) in deployment.toml. All other configurations are populated based on that, and shouldn't be changed manually.
Second, you don't need to replace all occurrences of localhost to IP as many are local calls.
Third, the correct URL should have the port, unless you have a reverse proxy in front of API.
eg. https://[ip address]:9443/publisher
Sounds good and thanks for the input. I will give this a try and post back to the thread.
I am using the IP and Port for now with no reverse proxy but plan to add one, once I can get through this part.
Much appreciated.
I have been trying to configure the WSO2 Admin console for HTTP access and not HTTPS. I have a load balancer infant of my WSO2 ESB server that will terminate the inbound HTTPS connections and forward to the WSO2 server as HTTP.
I have tried various different configurations in the catalina-server.xml file without any success. It either does not work at all or when connecting using HTTP it simply redirects to HTTPS, even after removing the 'redirect' setting from the HTTP connector configuration.
I have spent several hours 'playing' and searching for something similar on the web to no avail.
Hopefully someone here has done something similar or can help.
Regards,
Graham
I'm using wso2 esb 4.8.1,Go to the following location in your esb carbon server ,
CARBON_HOME\repository\conf open carbon.xml file and uncomment the following line
<!-- Enable accessing Admin Console via HTTP -->
<EnableHTTPAdminConsole>true</EnableHTTPAdminConsole>
and you will have HTTP access to your wso2esb admin console. After enabling HTTP access, you can access the admin console via port 9763.
I am configuring our API Manager, but running into troubles authenticating via OAuth, seems to be an issue with the API Key Manager. I haven't dug into it yet, but does this come with the API Manager (as I have assumed) or is this a separate installation?
I had the same issue when using the wso2 api manager on a Amazon hosted machine, turn out that Thrift was not working correctly because some problem with multicasting and broadcasting.
What I did to get it working was to switch from ThriftClient to WSClient. If you have a huge amount of requests coming in then Thrift is the recommended solution from wso2 but in any "normal" case you will not have any differences between thrift and WS.
Here is how you switch:
Shut down the API Manager
Open up <api manager install dir>\repository\conf\api-manager.xml
Find ThriftClient
Change this to
<KeyValidatorClientType>WSClient</KeyValidatorClientType>
Start the API Manager
You may get some Warnings while starting up but, try it before you jump to the conclusion that it doesn't work.
Hope it helps!
you can use APIM manager product in a distributed setup as keymanger,gateway,store,publisher..but all functionality come in a single distribution.. ..
Go through the documentation for further guides
I was facing the same issue. Everything started when I created my own jks in order to use SSL without a self-signed certificate. I successfully created the jks and changed it in the carbon file. When I started the server, everything seemed ok; but when I used SOAPUI to test an API call, I got this (in the logs of the api manager):
APIAuthenticationHandler API authentication failure due to Unclassified Authentication Failure
I started digging what was the problem by enabling Debug level in the log4j.properties file, and then tried again a tested with SOAPUI and I got:
APISecurityException: Could not connect to <my api ip address> on port 10397
Then, I read the comment of OneMuppet and I checked that file and I found that the Thrift config has a host option, so I uncommented it:
<KeyValidatorClientType>ThriftClient</KeyValidatorClientType>
<ThriftClientPort>10397</ThriftClientPort>
<ThriftClientConnectionTimeOut>10000</ThriftClientConnectionTimeOut>
<ThriftServerPort>10397</ThriftServerPort>
This Line --> <ThriftServerHost>localhost</ThriftServerHost>
<EnableThriftServer>true</EnableThriftServer>
Save, restarted the server and everything start working correctly.
I got the same below issue after my installation, when i try to invoke the api service it is throwing below error:
900900 Unclassified Authentication Failure Error while accessing backend services for API key validation
After some random checks i have seen the axis2.xml file in /repository/conf/axis2 there it is refering a differnt ip's instead. I change these ip's to my local ip and restarted. The issue is resolved now.
I was facing the same issue. when I was trying to setup API Manager as an API Gateway in a different machine as per the steps given here,
https://docs.wso2.com/display/AM250/Publish+through+Multiple+API+Gateways
Once the setup is done and when I am trying to use this gateway URL, I was getting the below response,
{"fault":{"code":900900,"message":"Unclassified Authentication Failure","description":"Error while accessing backend services for API key validation"}}
After changing the KeyValidatorClientType value to WSClient from ThriftClient on the <api manager install dir>\repository\conf\api-manager.xml
It started working fine. And I was able to get the expected response.
If you changed the admin password, then you also have to update the repository/conf/api-manager.xml file with the new password. The 2 places I have changed (so far) are:
<AuthManager>
and
<APIKeyManager>
but there are other admin usernames in that file. No doubt, I'll get to them....
I have the same mule webservice application with 2 different versions deployed on the same mule server. Let's call it MuleApp.1.0 and MuleApp.1.1. The flow is as simple as the example of webservice flow on mulesoft website. Their wsdl urls are different as:
http://www.myhost.com:25101/MuleApp.1.0/Service?wsdl
http://www.myhost.com:25101/MuleApp.1.1/Service?wsdl
Both of them are working as expected when the other is not deploying on the mule server. The issue happens when I having both of them deployed on the same mule server like what I used to do in WebLogic. Now I am able to access MuleApp.1.1, but when I tried to access MuleApp.1.0, I got the error as below
07-Mar-2013:14:52:57.142 VWILVM3667 [MuleApp.1.1].connector.http.mule.default.receiver.03
WARN org.mule.transport.http.HttpMessageReceiver NA
No receiver found with secondary lookup on connector: connector.http.mule.default with URI key: http://www.myhost.com:25101/MuleApp.1.0/Service
This is supposed to be a very common versionning case. What did I miss in my config?
You can't have two different applications sharing the same HTTP port in the same Mule instance.
So what probably happens is that MuleApp.1.0 doesn't deploy properly (check the logs), which is why there is no endpoint listening on /MuleApp.1.0.
Either:
Use a different port in the two apps,
Put both flows in a single app.
Create a frontal app that listens on port 25101 and both /MuleApp.1.0 and /MuleApp.1.1 paths and that dispatches requests to MuleApp.1.0 and MuleApp.1.1 on private ports (say 25102 and 25103).
I finally deployed my application on tomcat, and replaced http inbound endpoint with servlet inbound endpoint. I configure the web.xml with servlet class org.mule.transport.servlet.MuleReceiverServlet. Now I am able to deploy multiple applications on the same port.