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:

1. Identity in a SaaS application
2. Federation with multiple Customers

There’s 1 variations in this scenario:

1. Automating the on-boarding process

The Introduction

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:

1. Usability for their employees. Lack of SSO, forgetting passwords, using sticky notes to remember them, etc.
2. Maintenance costs:
1. What happens if an employee forgets his or her corporate password? He will probably call Adatum’s IT help desk. What happens if they use FS and they forget its password? who should they call? Consider this:
1. If they instruct employees to call Fabrikam’s help desk, there would be a special procedure for IT guys, would probably require training, etc.
2. If they instruct employees to call Fabrikam directly, they would impact #1
2. When a new employee is hired, he is already provisioned in Adatum’s systems. They don’t want special processes for FS.
3. Liability:
   1. Adatum has authentication policies that are there for a reason. They also want to retail control on who has access to what (regardless of where that is deployed) and FS is no exception.
   2. If an employee leaves the company, he should not have access to FS anymore, effective immediately. If they used username / passwords, they could potentially access FS from other places, even if they are not an Adatum employee anymore.

Back to FS:

Access Control to FS is based on Roles. There are 3 roles:

1. “Shipment Creators”. Anyone in this role can create new orders.
2. “Shipment Managers”. Can create and modify existing shipment orders.
3. “Administrators”. Can configure the system (e.g. look and feel, shipping preferences, billing, etc).

FS also keeps profile information for users, to avoid repeatedly entering common information and preferences. More concretely, FS allows its users to store:

1. Package Sender information (sender address)
2. Cost Center information for billing

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.

Key Requirements.

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.

Some assumptions:

1. Adatum has an Issuer (see Scenario #1)
2. Fabrikam can change anything in their application

We’ll look at the solution space in the next post.