Tailspin Surveys is a multitenant, SaaS solution, targeting many different customers. Some of these customers might be “enterprise” with “Big-IT” and are likely to demand advanced integration capabilities for identity (e.g. identity federation). Others, potentially smaller, are likely to not require these. Even smaller companies (e.g. someone working from home) might even want to reuse one of their existing identities (their e-mail provider, their LiveID, etc)

These 3 possibilities are illustrated above:

1. Adatum (the “big company”) uses ADFS to issue tokens for TailSpin Surveys. They want their employees (e.g. John) to have SSO between their own applications (potentially on-premises, but not necessarily). TailSpin Surveys will just trust their identity provider (ADFS in the example). Tokens issued by Adatum’s identity provider are therefore accepted in Tailspin Surveys.
2. Fabrikam (the “small company”). It has AD, but no ADFS (or any other equivalent infrastructure). The can’t issue tokens that TailSpin can understand and they have no desire to change anything from their side. For customers like Fabrikam, TailSpin provides an identity provider of their own that they can use (they federate with themselves). The biggest drawback is that Fabrikam users will have to remember another username/password, but…not many employees in Fabrikam use Surveys anyway. With this architecture however, TailSpin prepares better for the future. When Fabrikam upgrades their infrastructure, they would simply change the trust relationship.
3. Mark working from Home (a super small company). Mark doesn’t have an ADFS under his desk. It is likely that Mark does most of his work from a single PC, with quite a bit of software being delivered to him as a service (like Surveys). Mark however, already uses LiveID for mail (e.g.Hotmail) and various other things. For people like Mark, TailSpin offers the opportunity to associate this external identities with the application.

What’s important is that the application (Surveys) is completely agnostic of how the users authenticates. All this is delegated. trust is established as part of the on-boarding process when a new tenant subscribes to Surveys. This of course can be highly automated or completely manual.

If all this sounds familiar to you, don’t worry. You are not crazy :-). We have covered this same scenario many times already:

Exploring the Service Provider track – First station: Fabrikam Shipping – Part I (the scenario & challenges)

Exploring the Service Provider track – Fabrikam Shipping Part II (Solution)

Fortunately, most of the design needed for TailSpin is already covered in the “Claims Identity Guide”. There’s quite a bit we are reusing from it. Since Surveys is an MVC application we will be using exactly the same approach for securing it with claims. This other post describes how it works:WIF and MVC – How it works