Staging Windows Azure Cloud Applications and Service Integrated With ACS
This post outlines my thinking on possible ways to stage application and services that are integrated with ACS.
It’s a common practice to have at least three environments – development, test, production - when developing applications and services. Application that use ACS should not be an exception. The key question here is how to move the application between the environments and how to maintain the environments regarding ACS?
One approach is specifically targeted at Windows Azure outlined here. In this post I’d like to explore manual options that are available. In a nut shell, there are two ways:
- 1 ACS namespace with 3 configured relying parties – development, test, production.
- 3 ACS namespaces – one per environment – and 1 relying party that represents the application.
1 ACS Namespace 3 Relying Parties
Consider the following diagram that represents single ACS namespace with 3 configured relying parties and key configuration elements:
- Single ACS namespace
- 3 different relying parties with its own Return URL and realm pairs.
What varies here is the realm of each relying party application to reflect on the environment – Dev, Test, Prod. The return URL also varies between the relying parties to reflect on the environments.
Consider the following diagram for the application configuration that uses the above ACS configuration:
- In each environment the application shares the same trusted issuer thumbprint since it was issued by the same ACS namespace.
- federatedAuthentication/wsFederation/issuer URL stays the same.
- The realm changes according to the environment
When deploying to Windows Azure staging environment the application assigned a URL that includes GUID that’s not known beforehand. It means there is no possible way to properly configure related ACS relying party. To fix this configure the Return URL of Relying Party: Test after deploying to Windows Azure. Another approach is to leverage OnStart event of the WebRole outlined here.
3 ACS Namespaces 1 Relying Party
Consider the following diagram that depicts three different ACS namespaces for each environment:
- 3 different ACS namespaces for each environment – Dev, Test, Prod.
- One Relying Party in each namespace.
What varies here is the Return URL for each Relying Party while realm is the same. Since there are different ACS namespaces the issuer is different for each one and also the signing certificate would be different. It will reflect on the configuration in the web.config file of the application.
Consider the following diagram that depicts the key attributes in the configuration file of the application:
- Issuer thumbprint is different since it was issued by different ACS namespaces.
- federatedAuthentication/wsFederation/issuer URL is different.
- The realm stays the same.
When deploying the application or a service to Windows Azure staging environment which includes GUID in the URL the ACS testing environment should be updated accordingly with relevant Return URL each time you deploy. That’s not the case though with Dev and Prod environments.