Here at ObjectSharp we’ve been having some internal discussions on certain architectural designs in the cloud. The biggest question here lately has been:
Single-tenant or multi-tenant?
Short answer: It depends on what you want to do with the system.
Long answer: It depends on what you want to do with the system.
Smartass comments aside, that question is a post on its own. This post is about the different ways you can deal with multiple identity providers in a system that allows multi-tenancy.
Maybe an example will help.
Imagine you’ve built a super-awesome web application, and you are providing it as (in?) a SaaS model. You can have any number of customers, and you want to let the customers log in with their own identity providers. More concretely, lets say a customer wants to log in to your application with their Active Directory credentials.
In a single-tenant model, the application could just make a hardcoded request directly to the given ADFS server for a token.
This can’t work in a multi-tenant model because each customer would have their own STS.
Alright, so how do we solve this problem? We need to break it down a little further.
The first problem is that the application needs to know about each STS, and each user in the application needs to be linked to an STS.
Things start getting hinky when you need to support different token formats from STS’s.
Windows Azure Access Control Services (ACS) is a good example of how to solve parts of each problem. ACS can consume tokens from multiple IdP’s of varying formats and normalize them into a single format that your application can them consume. Part of the normalization is a potential transformation of claim types and values to something that the application can understand.
Here it is up to the customer’s IdP to provide the correct information, but you don’t have much control of that.
Once the application has received a token that it understands, there are a couple considerations. How do you track new users within the application? By this I mean, do you create a new user when they log in for the first time, or must an administrator create a record in the application for any new users?
This is important for a couple reasons.
First is licensing. How do you define how many users can log in to your application at any given point? Must they be named users?
Second is authorization. Can anyone with a valid token just start using the application immediately, or do they need to be explicitly allowed? Are roles defined in the token?
Another question that needs to be raised is how does the customer configure the application to use their STS? Can they just provide a couple pieces of information like a link to Federation Metadata and let the application automagically configure a new identity provider with ACS, or must they submit a request so you can do it manually?
Once all of these questions have been answered you are a step closer to building the identity model for your application.
In the end, I think we end up with something kinda like this:
Within the application, you can then partition data based on the user, the user’s STS, or any combination of the claims within the received token.
