Organizations often have the desire/need/requirement to separate data and information flows. To start with the requirement, in banking there is the requirement for so called Chinese walls between departments so that insider knowledge cannot be shared with traders. From a needs perspective it can be that separating services is needed to maintain a clear overview of services offered for developers.
Lastly, the desire aspect could be to separate the slew of available services from the start to prevent for instance too many irrelevant services for developers.
Whatever the reason is, the WSO2 ESB can accommodate your wish!
Tenants
Let’s talk about tenants first. Tenants in WSO2 ESB ideally should be an isolated environment where nothing is shared between tenants apart from the general structure. You can compare it to an apartment in an apartment building. You have your own bathroom, bedroom, kitchen and so on but share the outer structure together. The tenants in WSO2 ESB work in a similar fashion.
However, even in an apartment building you still share the main electricity cables and sewage. By this I mean you do not have a dedicated cable to your utility or water supplier. In the ESB there is a similar concept where some elements are shared (like transports and so on) and others are indeed dedicated for each tenant like the proxies, APIs and other artifacts.
This is a regular screen when you log into the ESB with the (super) admin/admin credentials.
So how do we create a tenant?
Tenants have a specific startup screen that differs from the admin@super startscreen.
When we look at a deployed service in a tenant we see the /t/[tenantdomain]/ clearly indicating a tenant environment.
As you can see the proxy (a simple echo proxy using the Axis2 Echo service available on the ESB) is available on a different URL, namely /t/yenlowso2.com/EchoProxy. However, it is still on the same port as all the other proxies, either from a tenant or from the default no tenant environment.
So let’s see if we can create a solution to make the tenant available on port 8285 rather than 8280.
Inbound Endpoint
Let create an Inbound Endpoint.
We simply indicate the new port number (8285) where we want to make the endpoints available.
The dispatch.filter.pattern indicates (a regex) indicates that all services are to be available on that port. This is of course a template for all (.* as regular expression) proxies. We can specify exactly the dispatch filter like:
Or with /services/t/yenlowso2.com/EchoProxy.* we even allow everything starting with the pattern with additional characters allowed.
But also on the regular port it is still available
We need to add a parameter to the proxy
<parameter name="inbound.only">true</parameter> to remove it from the regular port.
In this case we have a tenant environment with services only visible to the tenant environment and running on a different port (i.e. 8285 in stead of 8280).
However, the services are still available to all users if you know the URL of the service and the port. You can indicate that a proxy runs on a specific server (pinned server) but again if you want to have services available only to tenants you need some sort of WS-Security tied to a username password in the user database.
However, there is no ‘real’ separation, it is rather a logical separation more than a true physical separation with the exception of the pinned servers which do specify a different location. Things like the transports and so on are still shared.
If indeed Chinese walls are needed, separate ESB environments (other VM/SERVER/Datacenter) to make a separation that will be more like the requirements from Risk & Compliance.
For other situations where you might want to separate proxies, this blog will help you get started.
If you have any questions about this blogpost contact us via the comments section of this blog. View also our WSO2 Tutorials, webinars or white papers for more technical information. Need support? We do deliver WSO2 Product Support, WSO2 Development Support, WSO2 Operational Support and WSO2 Training Programs.
