fb
WSO2 Enterprise Integrator 3 min

Tenants in WSO2 ESB & Inbound Endpoints

Rob Blaauboer
Rob Blaauboer
Integration Consultant & WSO2 Trainer
WSO2Torial witruimte 2
Scroll

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.

Regular WSO2 ESB login screen.png

So how do we create a tenant?

Create tenant WSO2 ESB - 1.png

Create tenant WSO2 ESB - 2.png

Create tenant WSO2 ESB - 3.png

Create tenant WSO2 ESB - 4.png

Tenants have a specific startup screen that differs from the admin@super startscreen.

Tenants specific startup screen - WSO2 ESB.png

Service Dashboard (Echo Proxy_ WSO2 ESB.png

When we look at a deployed service in a tenant we see the /t/[tenantdomain]/ clearly indicating a tenant environment.

Request 1 - EchoProxy - WSO2ESB.png

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.

new inbound endpoint - WSO2 ESB.png

We simply indicate the new port number (8285) where we want to make the endpoints available.

Update Inbound Endpoint - WSO2ESB.png

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:

dispatch.filer.papptern-WSO2ESB.png

Or with /services/t/yenlowso2.com/EchoProxy.* we even allow everything starting with the pattern with additional characters allowed.

servicestyenlowso2.comEchoProxy.png

But also on the regular port it is still available

servicestyenlowso2.comEchoProxy-regular port.png

We need to add a parameter to the proxy

<parameter name="inbound.only">true</parameter> to remove it from the regular port.

Add parameter to proxy-wso2 esb.png

tenant running on different port - WSO2ESB.png

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 SupportWSO2 Development SupportWSO2 Operational Support and WSO2 Training Programs.

Full API lifecycle Management Selection Guide

WHITEPAPER

smartmockups l0qqucke