Zulfiqar's weblog

Architecture, security & random .Net

Archive for the ‘Windows Azure’ Category

Federating Azure AD with thinktecture Identity Server – Notes

Posted by zamd on February 6, 2015

First of all my apologies for not doing a good job here. I always planned to contribute this to the excellent identity server  but I never got enough bandwidth to do so. I’m constantly receiving request to share the details here so I decided to share notes/steps required to enable this and hopefully someone from community would do the bits I have long promised.

Here are steps…

  1. Create a basic STS or tweak & use the lovely thinktecture IdentityServer v2 (my recommendation)
  2. Within identity server, add a Relying Party Trust to ‘urn:federation:MicrosoftOnline’ which is the unique identifier used by of Azure AD for federation.
  3. Establish a trust relationship between identity server and Azure AD using the Set-MsolDomainAuthentication cmdlet. This is how my trust relationship look like:

Office365 Federation Working

4. The IssuerUri MUST match the issuer URI of SAML assertion.



5. The protocol MSUT be WS-Federation for browser-based SSO

6. Following claims MUST be included in the issued tokens

7. The UPN must also be set as a name identifier.

Identity server code change # 1

var nameid = new Claim(ClaimTypes.NameIdentifier, “7960192”);
nameid.Properties[ClaimProperties.SamlNameIdentifierFormat] = “urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified”;
var outputClaims = new List<Claim> {

new Claim(“http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID”,”7960192″),
new Claim(“http://schemas.xmlsoap.org/claims/UPN”, “zulfiqar@bccoss.com”),




8. The signing algorithm MUST be SHA-1. Signing certificate can be a self-signed SSL certificate.

Identity server code change # 2

scope.SigningCredentials = new X509SigningCredentials(signingCert, SecurityAlgorithms.RsaSha1Signature, SecurityAlgorithms.Sha1Digest);


9. The token MUST be sent to: https://login.microsoftonline.com/login.srf

Looking forward to see this in identity server soon…

Posted in Azure AD, Federation/STS, Office 365, SSO, Windows Azure | Tagged: | Leave a Comment »

Deploying Umbraco to Windows Azure

Posted by zamd on January 27, 2012

Umbraco is a fairly mature CMS system and recently I was engaged in an assignment to deploy Umbraco CMS to Windows Azure. In this post, I’ll share some of my learning’s.

  • Umbraco accelerator (I call it bootstrapper) works well for small to medium web sites but you definitely have to increase the default blob sync interval which by default is set to 1 second.
  • In the context of Windows Azure, accelerator/bootstrapper become your main application which gets deployed to Azure Web Roles using Azure service model.
  • Umbraco installation (I used standard Umbraco download) is stored in blob storage while accelerator is configured to pick this and install it on the web roles where accelerator itself is running. Accelerator does both push & pull so file system changes done by Umbraco would be pushed to blob storage and automatically be synced to other web roles by the accelerator.
  • The standard Azure staging/production deployment doesn’t really fit with accelerator style deployment used by Umbraco. So instead of using staging & production, we used azure production environment only(with well known DNS) and decided to use two hosted services representing UAT & Live environments. Our plan is to use end to end separation i.e. separate blob storage & separate SQL Azure databases. This setup would give us required change management & content management control.
  • Using accelerator I was quickly able to deploy Umbraco web app to two Azure web roles.
  • Soon after the deployment I was welcomed by ASP.net yellow screen of death.
  • I RDP into the server and debugged the W3P.exe to realize ASP.net was failing to validate ViewState.  Make sense! 🙂 Azure is load-balanced & requests were sent to two web role instances in a round robin scheme. ASP.net machine key scheme was set to default Autogenerate which resulted in both web roles using different keys to secure/validate ViewState. Once we knew the issue the fix was simple:
  • Use pre-generated fixed key values for <machineKey>
<machineKey validationKey="21F090935F6E49C2C797F69BBAAD8402ABD2EE0B667A8B44EA7DD4374267A75D7"
  • Next step was to create the Umbraco database for which we decided to use SQL Azure as the DB platform.
  • My first thoughts were to use the basic approach of manually creating a blank DB in Sql Azure and then run Umbraco configuration wizard to populate the schema & data. Even though this approach won’t give us necessary control for the DB assets it was simple to use.
  • Turns out this approach doesn’t work & Umbraco simply hangs. I debugged & found Umbraco configuration wizard was unable to create couple of columns (of bit data type) & data access was failing because of the missing columns. I discarded this approach without going any further.
  • I then installed a local Umbraco instance and configured a local Sql Server database which worked smoothly.
  • I used data tier application framework to export local SQL Server database as a package. As SQL Azure natively supports import of dacpac packages, the import was fairly simple process using the Sql Azure management portal.
  • The dacpac approach also solved the lack of control issues with the simple in-place DB creation option as it gave us a golden copy of the database for future use. We are also planning to use dacpac feature as the basis for backup & restore requirements.
  • Once DB is ready in SQL Azure,  Umbraco was configured to use this DB and we have a somewhat working Umbraco installation.
  • During testing, I quickly realized that by default Umbraco stores session state in memory and this would not work in Window Azure load balanced environment.
  • I could use SQL Azure for session state storage but it’s NOT supported in SQL Azure and also adds quite a bit of overhead in terms of session state clean up as there is no SQL Agent in Azure.
  • I decided to use Windows Azure Cache (a.k.a AppFabric cache) as the session state storage mechanism. It’s fast & also doesn’t require additional data purge solutions. I created a 128MB cache and configured Umbaco web app to use AppFabric cache (instead of local machine’s memory) as the session state storage.
  • And finally Umbraco is up & running in Azure 🙂


Posted in Windows Azure | 4 Comments »

WCF Certificates in Compute Emulator

Posted by zamd on December 21, 2010

Windows Azure SDK 1.3 introduced significant changes to the local development environment. The old DevFabric is broken down into “Compute emulator” & “Storage emulator” which are the local emulated environments for the compute and storage respectively.

Azure SDK 1.3 uses the ‘full IIS’ feature for the WebRole running in the compute emulator which makes it much easier to configure and debug applications in the emulator. For example, when you run your azure project (containing a WebRole) in the Compute emulator it transparently creates web sites and application pools in IIS and configures them correctly by pointing to the physical application directory. Your WebRole code executes inside the good-old worker process (w3wp.exe) and can be configured using the appPool properties plus you can directly edit the web.config to change application settings.

image image

You can configure HTTPs endpoints for you application and the emulator automatically setup SSL bindings using a test certificate. These bindings can be viewed using the netsh.exe utility.image

If your WebRole however requires additional certificates then you have to manually deploy those. For example, WCF message security would require a service certificate which needs to be referenced in the web.config. 

  1. <serviceCredentials>
  2.   <serviceCertificate findValue="bc2b61b66fda75dbaae50ae2757ad756cfeff016" x509FindType="FindByThumbprint" storeLocation="LocalMachine" storeName="My" />
  3. </serviceCredentials>

The AppPool created by the Compute emulator is configured to run under ‘Network Service’ account so additional certificate needs to be copied in the local machine store (inside personal folder) and ‘Network Service’ account needs to have read permissions to the private keys.

Posted in Windows Azure | Leave a Comment »