Welcome to my third post about the recently announced Windows Azure Active Directory (AKA the hilariously-acronymed “WAAD”), and how to make WAAD work with your infrastructure. In the first post, we looked at Microsoft’s entry into the IDaaS market, and in the second post we explored the issues around deploying WAAD in a Microsoft-only environment—chiefly, the fact that in order to create a flat view of a single forest to send to WAAD, you must first normalize the data contained within all those domains. (And let’s be honest, who among us has followed Microsoft’s direction to centralize this data in a global enterprise domain???)
It should come as no surprise that I proposed a solution to this scenario: using a federated identity service to build a global, normalized list of all your users. Such a service integrates all those often overlapping identities into a clean list with no duplicates, packaging them up along with all the attributes that WAAD expects (usually a subset of all the attributes within your domains). Once done, you can use DirSync to upload this carefully cleaned and crafted identity to the cloud—and whenever there’s a change to any of those underlying identities, the update is synchronized across all relevant sources and handed off to DirSync for propagation to WAAD. Such an infrastructure is flexible, extensible, and fully cloud-enabled (more on that later…). Sounds great, right? But what about environments where there are multiple forests—or even diverse data types, such as SQL and LDAP?
Bless this Mess: A Federated Solution for Cleaning Up ALL Your Identity
So far, we’ve talked about normalizing identities coming from different domains in a given forest, but the same virtualization layer that allow us to easily query and reverse-engineer existing data, then remap it to meet the needs of a new target, such as WAAD, is not limited to a single forest and its domains. This same process also allows you to reorganize many domains belonging to many different forests. In fact, this approach would be a great way to meet that elusive target of creating a global enterprise domain out of your current fragmentation.
But while you’re federating and normalizing your AD layer, why stop there? Why not extend SaaS access via WAAD to the parts of your identity that are not stored within AD? What about all those contractors, consultants, and partners stored in your aging Sun/Oracle directories? Or those identities trapped in legacy Novell or mainframe systems? And what about essential user attributes that might be captured in one of these non-AD sources?
As you can see below, all these identities and their attributes can be virtualized, transformed, integrated, then shipped off to the cloud, giving every user easy and secure access to the web and SaaS apps they need.
Creating a Global Image of all Your Identities
Credentials: Sometimes, What Happens On-Premises Should Stay On-Premises
So we’ve seen how we can get to the attributes related to identities from many different silos and turn them into a cloud-ready image. But there’s still one very important piece that we’ve left out of the picture. What about credentials? They’re always the hardest part—should we sync all those &#@$ passwords, along with every &%!?# password change, over the Internet? If you’re a sizable enterprise integrating an array of SaaS applications, that’s a recipe for security breaches and hack attacks.
But fortunately, within Microsoft’s hybrid computing strategy, we can now manage our identities on-premises, while WAAD interfaces with cloud apps and delegates the credential-checking back to the right domain in the right forest via our good friend ADFS. Plus, ADFS even automatically converts the Kerberos ticket to a SAML token (well, it’s a bit more complex than that, but that’s all you need to know for today’s story).
The bottom line here is that you’ve already given WAAD the clean list of users, as well as the information it needs to route the credential-checking back to your enterprise AD infrastructure, using ADFS. So WAAD acts as a global federated identity service, while delegating the low-level authentication back to where it can be managed best: securely inside your domains and forests. (And I’m happy to say that we’ve been preaching the gospel of on-premises credential checks for years now, so it’s great to see mighty Microsoft join the choir. 😉 )
While this is very exciting, we still face the issue of all those identities not managed by Microsoft ADFS. While I explained above how a federated identity layer based on virtualization can help you normalize all your identities for use by WAAD, there’s still one missing link in the chain: how does WAAD send those identities back to their database or Sun/Oracle directory for the credential checking phase? After all, ADFS is built to talk to AD—not SQL or LDAP. Luckily, federation standards allow you to securely extend this delegation to any other trusted identity source. So if you have a non-MS source of identities in your enterprise and you can wrap them through a federation layer so they work as an IdP/secure token service, you’re in business. Extend the trust from ADFS to your non-AD subsystem through an STS and—bingo—WAAD now covers all your identity, giving your entire infrastructure secure access to the cloud.
How WAAD, ADFS, and RadiantOne CFS Work Together
We call this component “CFS” within our RadiantOne architecture, and with CFS and our VDS, you have a complete solution for living a happy, tidy, and secure life in the hybrid world newly ordained by Microsoft…(cue the choir of angels, then give us a call if you’d like to discuss how we can make this happen within your infrastructure…). 🙂
Thanks, as always, for reading my thoughts on these matters. And feel free to share yours in the comments below.