This shows you how to write multitenant applications. If you haven’t already, please read the following two posts before you read this. Those two sets the stage for the rest of this post.
Before proceeding further let me clarify some terms that we’ll be using . It has become a bit cloudy (no pun intended) since many people mean different things for the same word.
Multitenancy – In the context of Stratos, I’m using the word multitenancy to mean as defined in Wikipedia.
Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client organizations (tenants).
When you register and get an account in Stratos, that’s a tenant. An organization. Your data will be isolated from other tenants/organizations in the system. When you sign up, you’ll be creating the administrator account for your tenant. Which we naturally refer to as the tenant admin. Tenant admin can add users to your domain, turn off/on various Stratos services such as the ESB, App Server, Data Services Server etc… Monitor data and bandwidth usage of your users, grant/revoke permissions to users.
Let’s me take a little step back here. When you talk about Stratos, there are two major deployment scenarios. One that’s hosted by WSO2. That’s available to users as a service, you sign up, you get an account, your data is hosted on hardware that we manage. This version is called StratosLive. Other scenario, you setup Stratos on your hardware in your private data center, you control everything it’s not accessible to anyone else.
2 scenarios. StratosLive vs Stratos on your private cloud.
Now, coming back to multitenancy, there’s one user we called the super tenant. This acts as an admin account for all the tenants in Stratos. It’s configured at the time of setting up Stratos. In StratosLive scenario, super tenant is WSO2. In the other scenario, super tenant is you. You can do stuff which will affect to all the tenants across the system. Why would you need this? It’s necessary when you’re developing SaaS applications. You’re providing a service which all the tenants can use.
In Stratos, to make your applications SaaSify you need to add a context parameter to your deployment descriptor.
<context-param>
<param-name>carbon.enable.saas</param-name>
<param-value>true</param-value>
</context-param>
Authentication mechanism will be the standard form based authentication that we configured in the Jwitter app we developed earlier. This however, does not mean that this is the only thing that you need to build SaaS applications, nor does it allow you to take any existing web app out their and magically turn it to a multitenanted app. For that you need to have a multitenant data architecture for you application.
When you add the context parameter and deploy the web application as the super tenant, Stratos will authenticate against any user account in the system that has sufficient permissions. When you call request.getPrincipal().getName(), user account will appear in the format foo@example.com. From this point on it’s upto you to move to the bits of your application.