WSO2 API Manager Clustering: Login error to Publisher and Store

Question

we are trying to configure WSO2 API Manager 2.1.0 in a cluster following the WSO2 documents. We have:

• a cluster of two Gateways
• a cluster of two Key Managers
• a cluster of two Traffic managers

As a front-end Load balancer, we are using NGINX. Everything works fine except this aspect:

When I try to login to the publisher or store the request is sent to the load balancer that redirects the request to the Key managers. The logs of the KM1 is:

INFO {org.wso2.carbon.core.services.util.CarbonAuthenticationUtil} - 'admin@carbon.super [-1234]' logged in at [2018-02-01 15:23:15,102+0100] {org.wso2.carbon.core.services.util.CarbonAuthenticationUtil}

while in the other the log (KM2) is:

TID: [-1234] [] [2018-02-01 15:23:15,165] WARN {org.wso2.carbon.server.admin.module.handler.AuthenticationHandler} - Illegal access attempt at [2018-02-01 15:23:15,0165] from IP address xxxxx while trying to authenticate access to service LoggedUserInfoAdmin {org.wso2.carbon.server.admin.module.handler.AuthenticationHandler}

The final result is that I can not access to the store or publisher. If one of the two KM is stopped everything works fine. Do you have any suggestions how i should configure the KM or TM? Thank you very much

Answer 1

This is happening because you haven't enabled sticky session for the key manager.

There are two calls going to the key manager and both calls should be redirected to the same key manager. In your case, the requests are load balanced in a round-robin manner. Therefore the second call fails as the session is created in another node.

Please refer article below. https://wso2.com/library/articles/2015/01/wso2-api-manager-deployment-customization-and-troubleshooting-part-02/

https://docs.wso2.com/display/CLUSTER44x/Configuring+NGINX

Why thrift key validation is not recommend in production deployments

Thrift key validation does not work when we have a load balancer fronted key manager. The reason for this is that most load balancers are not capable of routing traffic in a session-aware manner. Therefore, in such cases, it's always recommended to use the WS key validation client. When we use web service clients we need to enable a sticky session at the load balancer level. Moreover, we need to give a session cookie that we've used to handle session stickiness.