Introduction
For the last months I´ve been working on a Project called SaaSyLongTail that consists on a sample application which highlights the key architecture principles of SaaS (software as a service) applications. In this context, one of the key pieces of the application we are building is the one who takes care of setting up the environment needed for a tenant to use the SaaS application. That is the tenant provisioning and in this post I will explain the main steps of it at SaaSyLongTail:
· Data Provisioning
· Web Server Provisioning
· Authentication Store Provisioning
· Authorization Store Provisioning
Data Provisioning
Tenant is added to the tenant Table at the provider database all along with other tables that are filled with default provisioning data.
Tenant Provisioning can be used in cases where the tenant only wants to try the application (“try before you buy”) so we think is important for the tenant to start trying the application without worrying to configure it if he doesn´t want to. We make this by inserting default tenant UI preferences, workflow rules, etc. which can be later changed by the tenant from his back office.
Web Server Provisioning
Each tenant web application (in this case “contoso” and “fabrikam”) has its own virtual directory inside of the SaaS provider Web Site (in this case “peoplewareHR” website) in the IIS. Inside of each tenant´s virtual directory there are 3 other application virtual directories: Back Office, Front Office and Services web applications. The “Services” virtual directory at the SaaS provider level provides tenant provisioning services:
All this virtual separation allows for example one tenant services to fall without harming the rest of the tenants.
The structure is purely virtual: one tenants Back Office physical path is the same as another tenant´s Back Office physical location. This way tenants configuration and data live only inside of the database and no physical changes are needed for the application in the case of tenant provisioning or deprovisioning.
Hierarchical structure: Contoso Front Office configuration extends Contoso main configuration which extends peoplewareHR configuration. This way each application only takes care about his own domain configuration.
Web Provisioning could also be distributed having the application services running in a different server than the UI (Front Office and Back Office in this case) in the case that the IT infrastructure requires so.
Authentication Store Provisioning
We use Active Directory Application Mode (ADAM) as the authentication store with one application partition for the SaaS provider (“peoplewareHR”), which stores one organizational unit (OU) for each tenant:
This structure lets each tenant to manage its own users and giving tenant-independency at the authentication level.
One detail we cannot let go is that we use a unique value for the userPrincipalName attribute of tenant’s users with a mask like “[user name]@[tenant alias]”. This is done in order to keep users principal names unique so that the roles provider can have unique references to users:
Regarding authorization, the tenant provisioning only takes care about creating the new OU for the tenant, with the default users.
What about if there are two tenants named Contoso that want to use peoplewareHR services? You can’t have two OU=Contoso in the ADAM, as well as two running virtual directories named the same (that goes for the IIS part…). We opted to keep the tenant alias as key in the ADAM and in the IIS as well just like two companies can’t have the same URL for their websites or two persons the same email address. Following the example, the second tenant named Contoso should choose a different alias like “contoso_corp”. But just as you enter your full name in an email registration the tenant should enter its own too: this is a not unique field and this is the information that will be visible in the Front Office and Back Office so that the alias remains only for identification purposes.
Authorization Store Provisioning
We use SqlRoleProvider using the tenant for the applicationId in the authorization store. This way we accomplish the scenario where two different tenants have same user names or roles:
Conclusion
In the context of SaaSyLongTail reference application, the Tenant Provisioning has a lot of work to do. This work requires the Data model, Web and Application servers, Authentication and Authorization providers to support a way of performing multitenancy in an efficient way. For each of these system components the important thing is to find the most efficient and simple configuration in order to match the SaaS application requirements.
