Single Sign On and Federated Security in the Cloud

Some time ago I wrote a couple of blog posts on Claims based SSO in Azure for the Windows Azure Architect training – but they seem to have gone AWOL so I’m re-posting as a series of posts here:

Single Sign On and Federated Security in the Cloud – part 1 – The SSO-challenge when moving your application to the cloud

Single Sign On and Federated Security in the Cloud – part 2 – Claims Based Identity

Single Sign On and Federated Security in the Cloud – part 3 – Windows Identity Foundation and AD FS 2.0

Single Sign On and Federated Security in the Cloud – part 4 – Identity Federation

Single Sign On and Federated Security in the Cloud – part 5 -Windows Azure AppFabric Access Control

Single Sign On and Federated Security in the Cloud – part 6 – some recommended resources

Category: sso, azure, english

Single Sign on and Federated Security in the cloud – part 6

Recommended resources

The great sample application FabrikamShipping is developed by the Windows Azure Platform Evangelism Team. This project contains both a working demo and the complete source code showing you have to create an end to end SAAS solution running in Windows Azure using federated security both against public identity providers and private Security Token Services.

My colleague Chris Klug has written an excellent blog post on implementing Federated Security with Access Control Service.

Here are some other good resources if you want to get more information on Claims based SSO, WIF and Access Control Serivce:

Category: sso, azure, english

Single Sign On and Federated Security in the cloud – part 5

Federation with Azure Access Control Service

Windows Azure AppFabric Access Control

Access Control is part of the AppFabric set of middleware services in Windows Azure. It provides a central point for handling federated security and access control to your services and applications, running in the cloud or on premise. AppFabric Access Control has built in support for federating against AD FS 2.0 – or any custom identity provider that supports the WS-Federation protocol.

In addition to supporting web based and SOAP based federation scenarios, Access Control also support federation using the OAuth protocol and REST based services. It has a web based management portal as well as OData based management services for configuring and managing the service.

The Access Control service has a rule engine that can be used to transform the incoming claims, thus being able to translate from a certain set of claims to another set of claims. It can also translate token formats to/from SAML 1.0, SAML 2.0 and Simple Web Token (SWT) formats.

Using the Access Control service you set up trust between the service and every STS that you want to federate with, including your own AD FS 2.0 STS:

Federated Identity through Windows Azure AppFabric Access Control

In this case your application running in Windows Azure still only has one point to point trust – to the Access Control service – and all the dependencies to the business partners are managed by this service.

Below is a sequence diagram showing the generic flow for single sign on using the Access Control service. The terms used in the diagram maps to our example as:

Client – the client in our domain or our business partner’s domain.

Identity Provider – our Active Directory + AD FS2 or our business partner’s STS.

Relying party – our application running in Windows Azure

Sequence diagram login ACS

The above diagram shows the flow when the application is a web application and the client is a web browser client (also known as a ‘passive client’). If the application would expose web services that a locally installed smart client (an ‘active client’) would consume, for example WCF services consumed by a WPF client – the first step in the sequence would be to directly login to the identity provider – instead of being redirected to a login page.

Federation with public Identity Providers

Windows Azure Access Control also let you use some of the largest public Internet services as Identity Providers. Out of the box there is built in support for using Windows Live ID, Facebook, Yahoo and Google as identity providers. The Access Control service handles all protocol transitions between the different providers, including Open ID 2.0 for Google and Yahoo, Facebook Graph for Facebook, and WS-Federation for Windows Live ID. The service then delivers a single SAML 1.1, SAML 2.0, or SWT token to your web application using the WS-Federation protocol once a user is signed in.

This is of course a really interesting feature when you are building public facing consumer oriented services, but could also be really useful in business to business scenarios. If for example you are building a SAAS solution, using the public identity providers like Facebook and Windows Live ID could be the option for smaller businesses while your enterprise customers could use their own STS for federation.

Here are some recommended resources if you want to dig deeper into the subject.

Category: sso, azure, english

Single Sign On and Federated Security in the cloud – part 4

WIF and ADFS for Azure based solution

In the last blog post we looked at how we could accomplish Single Sign On with WIF and AD FS 2.0 when moving on premise solutions to Windows Azure:

Claims Based Identity with WIF and AD FS for an application running in the cloud

This approach is all well as long as the users can be authenticated against the Domain Controller.

But what happens when a business partner need to access the same application running in Windows Azure?

One solution would be to set up new accounts for the partner in Active Directory and install a AD FS 2.0 Proxy in the DMZ. The business partner would then access the Proxy, authenticate to the Proxy with their credentials and that way get a valid SAML token that would grant them access to the application.

There are however a couple of serious disadvantages to that approach:

  • You now have to administrate users that don’t belong to your domain which leads to increased costs and challenges keeping the accounts up to date. This could possibly have security implications as well (how do you get alerted when a certain user is no longer employed by the business partner for example).
  • There is no single sign on for the business partner as they have to sign in through the AD FS proxy. That means that they have to handle a separate username and password to be able to connect to your application, which of course has security implications as well (i.e. keeping the username and password on little yellow stickers on the screen)

A much nicer scenario would be to set up Identity Federation between your organization and the business partner. One way to do that could be to let the application running in Windows Azure trust a Security Token Service located at the business partner. This however is not a good option when you have several applications that you want to federate. You would then have to create many point to point trusts (between each application and each business partner) which would become a real challenge to manage over time.

A better option would be to set up the federation between your STS and the partners STS. Your partners would be redirected to their own STS what would provide a SAML token that your STS would exchange for a token valid for the application running in Windows Azure:
Federation in Azure with multiple business partners
Federated Identity with many business partners

In this case your application running in the cloud still only has one point of trust – to your own STS in the form of AD FS 2.0.

Your business partners now have single sign on from their domain to your application and you do not have to administrate their users. However – your AD FS 2.0 proxy now becomes a business critical single point of failure in your architecture. If there would be a failure in the proxy server, or firewall or the network that connects it to the domain, no business partners would be able to log in to the application. You could of course set up redundancy with duplicated hardware and servers. But what if there would be a way to get rid of the need for a proxy altogether? What if you could utilize an existing cloud solution that provides a scalable and redundant service for handling federated security?

In the next blog post we will look at Windows Azure AppFabric Access Control – a service that provides exactly that functionality.

Category: sso, azure, english

Presentation från SWAG: federerad säkerhet med Azure Access Control Service

Igår medverkade jag på Swedish Windows Azure Usergroup och SWENUGs julavslutning. Sergio Molero och Marcus Söderberg körde en intressant (och läskig!) presentation om säkerhet på Internet. Jag höll en dragning om federad säkerhet mha Windows Azure Service Bus.

Stor eloge till Alan Smith och ConcreteIT för ett mycket bra arrangemang och en trivsam kväll!

Mina bilder från presentationen om federad säkerhet i Azure.

Category: azure, sso, swag