Windows Azure Guidance – a-Expense “before” on CodePlex

  • Article

First build of our samples is now available on CodePlex. This initial version is the “before the cloud” baseline application, so you won’t find anything related to Windows Azure here.

This week we will take this simple baseline and start moving it to the cloud.

Goals for this next iteration are to:

  1. Claims-enable the application to keep SSO experience for users. We will use WIF for this.
  2. Remove dependency with AD for querying the user Manager and Cost Center. This will be done by sending this information as claims as opposed to having the application querying AD. We want to avoid having to call back into Adatum from a-Expense.
  3. Deploy an Identity Provider on Adatum (e.g ADFS). This is the issuer of security tokens for a-Expense. It will be configured to issue the claim set a-Expense needs (e.g. employee, Cost Center, employee manager)
  4. Move database to SQL Azure. This is straight forward. We may add some connection retry logic to the data access layer to increase resiliency. But it should “just work”.
  5. Move the Profile storage to Azure Table storage. This database is fairly small and has a simple data model. There’s really no need for full relational support.

 

How it works:

  1. John @ Adatum opens the browser from his domain joined machine (he’d be already authenticated against AD)
  2. John browses a-Expense (hosted on Azure)
  3. Since there’s no session yet between a-Expense and John, a-Expense will redirect him to the configured trusted claims issuer (in this case Adatum’s ADFS)
  4. ADFS authenticates John (using the Kerberos ticket in John obtained at logon) and issues a token including: John’s name, his manager name (e.g. Mary) and the Cost center he belongs to.
  5. John’s browser posts this information back to a-Expense where WIF parses the token, validates it and creates an IClaimsPrincipal
  6. John’s preferences (e.g. the reimbursement method) are retrieved from his profile. There are no changes to the application as it is using the contract of ASP.NET Profile provider.
  7. Any exceptions are logged to Windows Azure diagnostics. Again, no changes to application as it was using EntLib for this. It just requires a configuration update.

In a nutshell:

image

 

We are trying to keep things as simple as possible.