Quite some people asked me about an Azure version of StarterSTS. While I kinda knew
what I had to do to make the move, I couldn’t find the time. Until recently.
This blog post briefly documents the necessary changes and design decisions for the
next version of StarterSTS which will work both on-premise and on Azure.
Provider
Fortunately StarterSTS is already based on the idea of “providers”. Authentication,
roles and claims generation is based on the standard ASP.NET provider infrastructure.
This makes the migration to different data stores less painful. In my case I simply
moved the ASP.NET provider database to SQL Azure and still use the standard SQL Server
based membership, roles and profile provider.
In addition StarterSTS has its own providers to abstract resource access for certificates,
relying party registration, client certificate registration and delegation. So I only
had to provide new implementations. Signing and SSL keys now go in the Azure certificate
store and user mappings (client certificates and delegation settings) have been moved
to Azure table storage.
The one thing I didn’t anticipate when I originally wrote StarterSTS was the need
to also encapsulate configuration. Currently configuration is “locked” to the standard
.NET configuration system. The new version will have a pluggable SettingsProvider with
versions for .NET configuration as well as Azure service configuration. If you want
to externalize these settings into e.g. a database, it is now just a matter of supplying
a corresponding provider.
Moving between the on-premise and Azure version will be just a matter of using different
providers.
URL Handling
Another thing that’s substantially different on Azure (and load balanced
scenarios in general) is the handling of URLs. In farm scenarios, the standard APIs
like ASP.NET’s Request.Url return the current (internal) machine name, but you typically
need the address of the external facing load balancer.
There’s a hotfix for WCF 3.5 (included in v4) that fixes this for WCF metadata. This
was accomplished by using the HTTP Host header to generate URLs instead of the local
machine name. I now use the same approach for generating WS-Federation metadata as
well as information card files.
New Features
I introduced a cache provider. Since we now have slightly more expensive
lookups (e.g. relying party data from table storage), it makes sense to cache certain
data in the front end. The default implementation uses the ASP.NET web cache and can
be easily extended to use products like memcached or AppFabric Caching.
Starting with the relying party provider, I now also provide a read/write interface.
This allows building management interfaces on top of this provider. I also include
a (very) simple web page that allows working with the relying party provider data.
I guess I will use the same approach for other providers in the future as well.
I am also doing some work on the tracing and health monitoring area. Especially important
for the Azure version.
Stay tuned.
