Deployment pattern of WSO2 Identity Server in production

In my previous blog post, we understood how to deploy in WSO2IS with proxy server or load balancer. But it is about a basic deployment.

When it comes to the real production. Lets try to understand the most common deployment pattern.

Followings are the important points to consider when it comes to the production deployment.

Point 1. WSO2IS must be deployed in the LAN by connecting to the enterprise user store.

Usually; we can not expose the user store in to the DMZ. This is one of the main reason for deploying WSO2IS in LAN. If we deploy WSO2IS in DMZ, we need to expose the user store in to the DMZ which is bad. Therefore, WSO2IS must be deployed in the LAN with the user store and databases.

Point 2. Management console of the WSO2IS must not be exposed to the outsiders. It must be only exposed in the LAN.

Point 3. End users must be authenticated WSO2 for SSO login. Therefore SAML2 SSO, OAuth2, OpenId and other authentication end point must be reachable by the end user.
When we consider above following is the most common deployment pattern.


1. WSO2IS instances have been deployed in LAN by connecting the user store and the databases which are also resided in LAN.
HTTPS ports of the WSO2IS instances are exposed to the DMZ.

2. Proxy/Load Balancer server (such as nginx or apache httpd) must be deployed in the DMZ.

HTTPS port (443) of the Proxy/LB must be exposed to external environment.

3. There is a firewall between LAN and DMZ. This firewall limits the access to the LAN environment. It has a rule that only the proxy server (which is in DMZ) can access the open HTTPS ports in the WSO2IS instances in the LAN.

Further; firewall can be used to block the management console by limiting the access to the web context “/carbon”. But this can be achieved through proxy server as well.

4. Proxy/LB is the only entity which can access the WSO2IS instances in the LAN and it is the entry point. It contains a load balancing logic and reverse proxy logic.

As SSO end points must be reachable for end users. There must be a reverse proxy configuration in the Proxy/LB.

Lets identify what are the reachable end points for SSO

  1. /commonauth
  2.  /authenticationendpoint (By default, end point is deployed inside WSO2IS. But if you need, you can change it as well)
  3.  Protocol related end points.
  • /samlsso  – SAML2 SSO end point for SSO
  • /openid   –  Openid end point for SSO
  • /passivests – Passive STS end point for SSO
  • /oauth2  –  OAuth2/Openid Connect end point for SSO.

As an example, If your using only the SAML2 SSO protocols, you need to expose only the /samlsso end point. So; Based on the protocol, you can define which endpoint you need to expose.

As an example, Following are the sample reverse proxy configuration for apache httpd server. (For oauth2 and samlsso end point)

ProxyPass /commonauth
ProxyPassReverse /commonauth

ProxyPass /authenticationendpoint
ProxyPassReverse /authenticationendpoint

ProxyPass /samlsso
ProxyPassReverse /samlsso

ProxyPass /oauth2
ProxyPassReverse /oauth2

5. Proxy/LB server must accept external request for port 443 and it must deny the request which are coming other than above defined reverse proxy endpoints.

6. There is a firewall between DMZ and external network. This firewall can allow only the port 443 for external clients.

7. Mostly Proxy/LB server is bridging the SSL (Terminate the SSL). So; there is separate SSL connection with external clients and Proxy/LB server and another connection with Proxy/LB server and WSO2IS instances. Therefore SSL certificate which is exposed to outside would be the Proxy/LB server’s certificate.
Above are the main points, you may need to remember when deploying WSO2IS in real production.

Thanks for reading..!!!

Discuss this article on Stack Overflow


Leave a Reply

Your email address will not be published. Required fields are marked *