Once again, thanks everybody that wrote us with reviews, feedback and suggestions! Please keep it coming! Also: we hope to have soon a CodePlex site where we can start sharing more. We are still working out some details.
As usual, the Disclaimer: this post and the next ones are early drafts to share with you the direction we are taking. They might (and I hope they will) change quite a bit in the actual Guide! We might end up not covering one of these scenarios in the book.
An additional disclaimer for this post: I wrote the whole scenario following the same template of the previous posts and it resulted in a very loooong article. So I divided it into two parts. This is Part I –> the scenario, the challenges and the requirements. Part II will be the solution.
An Ode to Simplification: there’s been quite some debate internally to this project as how to name things, especially “STS” vs. “Issuer” vs. “I-STS” vs. “R-STS” vs. “FP”, etc. Keith has started this on his blog some time ago. We definitely want to keep things simple. As simple as possible, but not simpler. For now we have settled on the term “Issuer”, independently of the logical role it takes part in. In simpler words: what we used to call “Identity Provider” is now an “Issuer”. What we called a “Federation provider” is also an “Issuer”.
Keith is writing a whole section of our book on “Jargon” and meaning of the different terms.
Credits: this scenario is largely inspired on Vittorio’s PDC demo. See here.
The themes for the first “Service Provider” scenario are:
There’s 1 variations in this scenario:
Fabrikam is a company that provides shipping services. As part of their offering, they have an application (Fabrikam Shipping – FS) that allows its customers to create new shipping orders, track them, etc. Fabrikam Shipping is delivered as a service and runs in Fabrikam’s datacenter. Fabrikam Customers use a browser to access it.
FS is a fairly standard .NET web application: the web site is based on ASP.NET 3.5, the backend is SQL Server, etc. In the current version, users are required to authenticate using (guess what): username and password!!
Fabrikam uses ASP.NET standard providers for authentication (Membership), authorization (Roles provider) and personalization (Profile).
Fabrikam Shipping is also a multi-tenant application: the same instance of the app is used by many customers.
One sunny day in Seattle, they sign a great deal with a marquee Customer: Adatum Corp. And Adatum doesn’t like the username and password, because they are working hard to get rid of identity silos. They have 3 concerns:
Back to FS:
Access Control to FS is based on Roles. There are 3 roles:
FS also keeps profile information for users, to avoid repeatedly entering common information and preferences. More concretely, FS allows its users to store:
Fabrikam can open the bills to its Customers by Cost Center. With this, 2 employees from Adatum belonging to 2 different departments would get 2 different bills.
Adatum wants SSO for its employees.
Fabrikam wants to avoid storing configuration information about the shipment that can become stale later on (e.g. the package sender information).
Fabrikam wants to bill customers by Cost Center if they supply one.
We’ll look at the solution space in the next post.