Windows Azure: App Fabric ACS -- Explained clearly.

AppFab:ACS

I’m going to assume you understand a little of the basics of federation for this part of the post. If you don’t - read my federation primer to get yourself up to speed.

When you place an instance in Azure and you “protect” it using AppFab:ACS, you are typically crossing an organisational boundary. There are reasons you might not be doing that – which we’ll come to in a moment. For now, let’s assume you are say, a SaaS service provider. You have written the most fantastic expense submission application and everybody wants to use it.

You don’t want to go to the trouble of having to manage the users. You want to provide the service. So you set up federation trusts with those companies that want to use your service. They create the users, set their passwords, determine if the accounts are enabled or disabled. They delete the accounts when they are no longer relevant, they set password complexity policy, expiration policy and so on. If a user forgets their password they go to their own company’s helpdesk to get it reset, not yours.

They do this by configuring a service that sits on top of their Active Directory called Active Directory Federation Services 2.0 (ADFS 2.0). You in your turn configure the Windows Azure Application Fabric’s Access Control Service (AppFab:ACS) with details of your application and vice versa, you configure your application with details of your partition of AppFab:ACS.

You then set up a federation trust with any company that wants to access your application. This involves the exchange of URLs and certificates between their ADFS2 server and your partition of AppFab:ACS. There are metadata endpoints to simplify this process. Of course, you could set this up between your own company’s ADFS2 server and your own instance of AppFab:ACS, as shown below:

Now, when a user from your application wants to use the application you have deployed to the cloud, it will be as if the application lives inside your AD. It doesn’t, but the experience they would have is like this:

It’s 09:00, Fred comes in to the office, hits CTRL-ALT-DEL and enters his AD credentials to log in to the domain.
It’s 10:00 and he now needs to enter his expenses. He clicks a desktop icon which is a URL shortcut to the application in the cloud.
The application opens, says “Welcome back Fred” and he uses the application to submit his expenses.

He was never prompted for credentials because of the way the dance works with federation/ADFS2 and Active Directory. The dance is explained in my federation primer, but what essentially happens is this:

Fred clicks the icon and his browser takes him to the application
The application redirects his browser to your partition of AppFab:ACS
AppFab:ACS sees that Fred has come from its federation partner and redirects Fred's browser to his own ADFS2 server.
On trying to reach the ADFS2 server, an authentication takes place. It’s all built-in to Windows and done through Kerberos. It’s entirely invisible to Fred as a user, the same as when he goes to a domain-joined IIS machine using Windows authentication. The authentication just works under the covers.
On successful authentication, the ADFS2 server pushes Fred back to AppFab:ACS and appends a SAML token which it encrypts and digitally signs. If you need to understand encryption and signatures, read my crypto primer.
AppFab:ACS receives the token, decrypts it and checks the digital signature. It is now assured the token has been issued by its federation partner.
AppFab:ACS creates a new token and copies the claims in the original token in to the new token. At this point it might also do something called claims transformation. If you need to understand this – again, read the federation primer.
It digitally signs and encrypts the token (optional) and redirects Fred’s browser back to the application it started appending the new SAML token.
The application decrypts the token and checks the signature. It verifies the token was definitely issued by your partition of AppFab:ACS and grants access to Fred. Fred never had to enter a password, other than the password he entered when he logged on to AD at 09:00 when he started work.