We’ve got a bunch of new preview technologies under development to share with you over the coming days and weeks. That’s going to be exciting, but I thought it would be interesting to start with a short blog post talking about one of the things we thought a lot about when building Windows Azure Active Directory.
It has always struck me (and others I suspect), both when I was using Active Directory to secure access to critical Windows documents and source code and now that I’m part of the team building Active directory, as strange that directories have little or no concept of a applications. Why is that?
One of the primary things organizations use directories for is to manage access to applications, but in most directories, including Active Directory, there’s no representation of an “application”. You can find users and PC’s and of course you’ll find many of the servers that you run applications on in your Active Directory. But there’s no place you can go look for an application, especially not a composite application that runs across multiple servers or a cloud based multi-tenant SAAS app run completely outside your data center. And yet everyone in the industry knows that one most compelling uses of directories and other IAM technologies is to provision& de-provision users in applications and to provide those users with an SSO experience for those applications (and thus avoid multiple username/password combinations and the ensuing helpdesk calls).
In fact many people (even people inside the AD team) argue that for most organizations the choice of which directory to use is based on the applications that integrate with it rather than the features and capabilities of the directory itself. I’ve talked with lots of customers with lots of different directory use cases so I’m pretty confident that is an over simplification, however it’s undeniable that application access management is always one of the top 2-3 directory and IAM scenarios.
So with Windows Azure Active Directory, we decided to make applications – both composite single tenant type and the multi-tenant SAAS apps first class citizens in the directory. Applications can now be easy registered with your Azure AD tenant and granted access rights to access that tenant. And if your are a developer or a cloud ISV, you can register a multi-tenant SAAS app you’ve created in your Azure AD tenant and with one click make it available for use by any other Azure AD customer. With one click, those customers can now add your application to their own tenant giving it a clearly called out set of privileges. They get the benefit of using Azure AD to administer access to your application with one click, you get the benefit of offering world class enterprise directory capabilities that can be easily connected to your customers existing Windows Server Active Directory.
Compared to what was previously required to make this work (a directory, an identity management service, custom configuration, custom connector development, workflow modeling, schema matching and more) this is a HUGE simplification and one we’re pretty excited about. If you want to learn about how it works under the covers, head over to Vittorio’s blog post on the topic. He’s done a nice job of explaining exactly how it works: http://aka.ms/gj3xzy
Over the coming months we’ll be building on this simplification adding increasing levels of capability. I hope you are going to like what you see!