You get in to the office in the morning and hit CTRL-ALT-DEL to log in to your AD. SOme time later you click a desktop icon for a web-app running in your datacentre. You are taken straight to the application. No login. Why? The app is AD-integrated. It’s what enterprise users expect to happen. But what about when the web-app is running in the cloud, outside of your AD infrastructure?
Although it’s been possible since Active Directory Federation Services 2.0 was in Beta (then known as Geneva Server), the new Access Control Service (ACS) in AppFabricLabs has made things a lot easier.
What do you need?
- A web-based application running on Windows Azure and using the Windows Identity Foundation (WIF).
- A free account on AppFabricLabs in which you have configured ACS
- A Windows Server connected to your Active Directory, running Active Directory Federation Services 2.0 (ADFS2).
Look at the diagram above: the user at bottom left logs in to AD in the morning using CTRL-ALT-DEL in the way we are all familiar with. This process results in a successful authentication. Her machine now holds a kerberos ticket that proves she is known to AD.
Let’s imagine a couple of hours later, she clicks a desktop icon that takes her to your Windows Azure based WIF application. A long-winded dance causes her to be redirected back to ACS and from there to ADFS2. As she is already authenticated by AD, she is not prompted for credentials when she needs to retrieve a SAML token from the ADFS server.
The ADFS server sends the token (via her web-browser) to the ACS service running in AppFabricLabs. The token contains a set of claims about her. Perhaps her email address, first name, last name, phone number, department, job-role and so on.
The ACS service receives the token, validates it came from the AD it purports to have come from and then creates a brand new token. Its default rule is to simply copy the set of claims from the original token across to the new token. I’ll talk about a neat improvement to the ACS service in AppFabricLabs which is a new “manage” button which now allows you to make many of these changes in a point-and-click, web-based portal in the next blog post.
The new token from ACS is forwarded to the WIF application.
The WIF application simply trusts the token sent to it by ACS. This trust is set up by configuration held in ACS and in the WIF application. By inference, it also trusts (though not explicitly) the ADFS Server and the AD that initiated the whole process. WIF gives the developer a model for extracting the claims from the token without ever having to worry about the complicated plumbing such as decryption and signature validation.
Once your WIF application has extracted the claims it needs, it uses them in some interesting way. It might pop-up a “Welcome back Planky” message, but it might also use the department claim to grant or deny access to a particular part for the application.
The result: the Azure based WIF application knows who the user is and where she came from. She was never prompted for any credentials – she logged in to her own AD several hours before clicking the icon. The experience for her was just the same as when she clicks an icon for a local AD-integrated application. As a user, she probably has no idea the application is actually running in one of Microsoft’s cloud datacenters.
In the next post, I’ll talk about the part where people glaze over. It would seem as though the WIF application is making the access control decision, not this thing called the Access Control Service. It’s true - that is happening. If though, we imagine that the WIF application knows nothing of the claim “department”, but does understand “business unit”, then the WIF application simply makes an access control decision on that claim. If the application is used by a number of companies – one calls it department, another calls it business unit yet another calls it function, perhaps yet another calls it operational group – you can see how complicated the access control rules within the application would need to be to cater for all these options. The access control service allows you to create rules that, for example map all of those individual claim names in to the single name department. Yes, your application is still making a decision based on a claim, but the code is much simpler because of it.
The reason this is great? It’s mostly configuration, not code. There obviously is code, but to create an enterprise identity-integrated application running in the cloud can be achieved so much more quickly than to create a massive project to achieve the same thing.
More posts on this interesting concept to come…