Much of the value of an identity management system derives from the ability to glue together a lot of people, devices, and applications, and to enable applications and administrators to understand and manage all these connections. So in many ways, this value is proportional to the number of “things” that are connected through the directory. The more applications that are connected the more value there is to the people who use the directory. And the more people who connect with the directory the more sense it makes to connect applications to the directory.
Now look at the opportunity that the cloud brings to this equation. While identity management solutions like Active Directory have been pretty successful managing things within organizations, now the cloud is opening the door to connect beyond the organization. The cloud is ushering in explosive growth in the number of applications available to organizations and in the collection of people and devices that can interact with these applications. Ubiquitous connectivity means that people and organizations could potentially use any application anywhere. And any application could potentially be used by anyone—people within the organization, partners, or customers. The “available market” for connecting to an organization’s directory is huge.
This increased scope is a profound change in potential value of the identity management system. But to take advantage of this potential, organizations must be able to function in a world where most of the connections will be to things that are no longer under their direct control. Applications will be running in the cloud and managed by software vendors, cloud platform providers, or other third parties—not within the organization’s data centers. The people won’t be managed by the organization; they will be customers and partners all operating with their own identity providers. And many of the people will be using mobile phones, tablets, and other consumer-oriented devices not issued by the organization.
So if organizations want to take advantage of the emerging opportunity to connect their identity management and applications to this growing number of external applications and people, they will need to make it easy to connect to their directory, enable new ways to create connections, and have new kinds of workflows, policies, and governance that can deal safely with external connections.
Let’s look at some of ways that we have been reimagining Active Directory to help organizations “connect” in this new world.
Windows Azure Active Directory Developer Preview
On June 7, as part of the spring release of Windows Azure, we announced the developer preview for Windows Azure Active Directory. The developer preview adds two major capabilities to the Windows Azure Active Directory service that we described in Part 1 of this post. First, it enables developers to connect to and use information in the directory through an easy-to-use REST interface. Second, it allows developers to connect to the organizational single-sign-on (SSO) capabilities of Windows Azure Active Directory—the same capabilities that are currently used by Microsoft Office 365, Windows Intune, and other Microsoft products.
The developer preview, which will be available soon, builds on capabilities that Windows Azure Active Directory is already providing to customers. These include support for integration with consumer-oriented Internet identity providers such as Google and Facebook, and the ability to support Active Directory in deployments that span the cloud and enterprise through synchronization technology.
Together, the existing and new capabilities mean a developer can easily create applications that offer an experience that is connected with other directory-integrated applications. Users get SSO across third-party and Microsoft applications, and information such as organizational contacts, groups, and roles is shared across the applications. From an administrative perspective, Windows Azure Active Directory provides a foundation to manage the life cycle of identities and policy across applications.
Let’s look at the new capabilities in more detail.
Connecting applications to information in the directory
In the Windows Azure Active Directory developer preview, we added a new way for applications to easily connect to the directory through the use of REST/HTTP interfaces.
An authorized application can operate on information in Windows Azure Active Directory through a URL such as:
https://directory.windows.net/contoso.com/Users(‘Ed@Contoso.com’)
Such a URL provides direct access to objects in the directory. For example, an HTTP GET to this URL will provide the following JSON response (abbreviated for readability):
{ “d”: {
“Manager”: { “uri”:
“https://directory.windows.net/contoso.com/Users(‘User…’)/Manager” },
“MemberOf”: { “uri”:
“https://directory.windows.net/contoso.com/Users(‘User…’)/MemberOf” },
“ObjectId”: “90ef7131-9d01-4177-b5c6-fa2eb873ef19”,
“ObjectReference”: “User_90ef7131-9d01-4177-b5c6-fa2eb873ef19”,
“ObjectType”: “User”,
“AccountEnabled”: true,
“DisplayName”: “Ed Blanton”,
“GivenName”: “Ed”,
“Surname”: “Blanton”,
“UserPrincipalName”: “Ed@contoso.com”,
“Mail”: “Ed@contoso.com”,
“JobTitle”: “Vice President”,
“Department”: “Operations”,
“TelephoneNumber”: “4258828080”,
“Mobile”: “2069417891”,
“StreetAddress”: “One Main Street”,
“PhysicalDeliveryOfficeName”: “Building 2”,
“City”: “Redmond”,
“State”: “WA”,
“Country”: “US”,
“PostalCode”: “98007” } }
This kind of Internet-friendly interface makes it easy for developers—building on any platform—to integrate their applications and Windows Azure Active Directory. Using standard HTTP requests, a developer can access any “thing” in the directory (for instance, users), and they can access relationships between things. Continuing with the example above, we can see that it is easy to access a user’s groups by using the URL:
https://directory.windows.net/contoso.com/Users(‘Ed@Contoso.com’)/MemberOf
Sending an HTTP GET to this URL would return the following JSON response (abbreviated for readability) that provides a list of groups for Ed:
…
“results”: [
{ “__metadata”: { … }
“ObjectId”: “30a041bf-e43f-42d6-bec4-a24ce33d5d42”,
“ObjectReference”: “Group_30a041bf-e43f-42d6-bec4-a24ce33d5d42”,
“ObjectType”: “Group”,
“DisplayName”: “Vice Presidents”,
“Mail”: null
},
{ “__metadata”: { … }
“ObjectId”: “451758b1-a66e-4d74-b6ce-03c7ec2fee7e”,
“ObjectReference”: “Group_451758b1-a66e-4d74-b6ce-03c7ec2fee7e”,
“ObjectType”: “Group”,
“DisplayName”: “All Users”,
“Mail”: null
},
…
Because the directory interfaces are built using standard REST semantics, no special protocols or libraries are necessary to use the directory. The approach of using standard REST interfaces to operate over a graph containing entities (nodes) and relationships (arcs) between entities—often referred to as a graph interface—is very common on the Internet. For example, much of the information in Facebook is available in such a manner.
Last week at Microsoft TechEd North America 2012, Edward Wu discussed the directory graph interface. He talked about how, as the applications using the directory become more sophisticated, developers can build on this simple direct URL-based access to take advantage of the sophisticated filtering and metadata operations that are available via Open Data Protocol (OData) version 3.
Ed also noted that, in this early version of the preview, a few critical capabilities are missing. We recognize that developers will need write capabilities, notifications when data in the directory changes, and support for provisioning operations, and we are actively discussing with developers the best ways to provide these capabilities using REST semantics.
Thanks to the new directory graph interface, developers will find it straightforward to write applications that integrate with Windows Azure Active Directory and with other cloud solutions that operate with graph interfaces. For example, BuiltSteady has used the graph interfaces available in both Windows Azure Active Directory and Facebook to improve its application’s ability to intelligently assist users in task management scenarios that span work and personal experiences.
Connecting users to the directory
Above we discussed how the use of web technologies like REST/HTTP is making it much easier to connect applications to the directory. The cloud also provides an opportunity to make it easier to connect new people to the directory. The second major capability we are adding with the developer preview is providing developers the ability to connect their applications to same directory, and information about people, that is used by Office 365 and other Microsoft applications.
To put this new capability in context is useful to see that application developers building cloud-based applications are facing the same many-to-many dilemma that existed before the advent of directories—where each application essentially had to provide a custom application-specific system for identity management—except now the challenge is integrating the application with a variety of identity providers. This situation is depicted in the diagram below.
By using a shared directory, and having the directory directly support these identity providers, developers and administrators can reduce this challenge to a one-to-one integration. This approach is shown here.
Having a shared directory that enables this integration provides many benefits to developers, administrators, and users. If an application integrates with a shared directory just once—for one corporate customer, for example—in most respects no additional work needs to be done to have that integration apply to other organizations that use Windows Azure Active Directory. For an independent software vendor (ISV), this is a big change from the situation where each time a new customer acquires an application a custom integration needs to be done with the customer’s directory. With the addition of Facebook, Google, and the Microsoft account services, that one integration potentially brings a billion or more identities into the mix. The increase in the scope of applicability is profound.
One of the key technologies that Windows Azure Active Directory uses to connect to external identity providers is identity federation. Windows Azure Active Directory supports a range of different kinds of identity providers, including both consumer-oriented and enterprise-oriented identity providers.
To connect to consumer identities, Windows Azure Active Directory already integrates with Facebook, OpenID-based identity providers such as Yahoo! and Google, and the Microsoft account service that Chris Jones and Steven Sinofsky described in their recent post on the Building Windows 8 blog. Chris described “Microsoft account” as “our identity service for individuals who use Microsoft products and services.”
With the Windows Azure Active Directory developer preview, developers can enable SSO with Office 365 and other Microsoft applications. At TechEd last week Stuart Kwan talked about this in A Lap Around Windows Azure Active Directory. As Stuart describes we currently support WS-Federation to enable SSO between the application and the directory. We also see the SAML/P, OAuth 2, and OpenID Connect protocols as a strategic focus and will be increasing support for these protocols. Because integration with applications occurs over standard protocols, this SSO capability is available to any application running on any technology stack. In addition to Stuart’s talk, Vittorio Bertocci provided an in-depth presentation showing how to connect applications to the developer preview using Windows Identity Foundation.
Because Windows Azure Active Directory integrates with both consumer-focused and enterprise-focused identity providers, developers can easily support many new scenarios—such as managing customer or partner access to information—all using the same Active Directory–based approach that traditionally has been used for organizations’ internal identities. For example, in our discussions, developers in the pharmaceutical industry indicate they plan to use Windows Azure Active Directory to enable physicians to use a personal identity (for example, a Facebook or Google identity) when signing up to run clinical trials.
Connecting SaaS applications to the directory
In the diagram shown above, there are multiple directories involved in the relationship between the users and applications. The ability to connect together directories through federation is very powerful. Let’s look at how software developers can use this capability to build multi-tenant software-as-a-service (SaaS) applications.
As an example, let’s imagine that an ISV is building a customer relationship management (CRM) solution. As described above, this ISV can use Windows Azure Active Directory to help build the application. By using Windows Azure Active Directory Access Control, the ISV can create a common consistent view of users, rules, and other information across a range of identity providers including Facebook, Google, and Microsoft, as well as corporate customers running their own directories
The ISV’s customers can use a number of different directory solutions. Their directory could be Windows Server Active Directory with federation provided by Active Directory Federation Services. Or it could be a directory using PingFederate from Ping Identity to connect to the application.
Other customers might choose to use the Windows Azure Active Directory service as way to manage their users or to connect it to existing directory deployments. With the developer preview, an organization that is using Windows Azure Active Directory as part of it’s identity management solution can now grant permission to ISV’s application. This enables both single sign-on and the REST directory access described above.
In this case, notice that Windows Azure Active Directory can be used simultaneous by both the ISV—to help build the applications—and by the customers—to provide a cloud-based identity management solution for their organization.
In his TechEd presentation Vittorio Bertocci described how ISVs can build SaaS applications that can connect to multiple customers each using Windows Azure Active Directory. Specifically he showed how to use Window Identity Foundation extensibility to connect applications dynamically to the customers’ Windows Azure Active Directory deployment.
The opportunity for developers
The rapidly growing number of organizations using Windows Azure Active Directory and the large number of associated users who are available through the directory create opportunities for developers.
Integrating an application with Windows Azure Active Directory connects the application to the growing collection of applications that are already connected and to the large and growing collection of potential users. For users, this integration results in common experiences like single sign-on and shared context without the need to set up and maintain these connections. For the administrators of an organization, this translates to lower operating costs; consistent management of applications, including using the directory to define roles or disable an identity; and reduced risks. For software developers, these advantages make an application more relevant and valuable to users and administrators.
The combination of Windows Azure Active Directory enhancements to access the directory through new Internet-friendly protocols and integrate with both enterprise- and consumer-oriented identities will empower developers to use Windows Azure Active Directory to address new scenarios that go well beyond the “behind the firewall” role that identity management has historically played. We are excited to see how developers will take these new mechanisms and build new experiences and capabilities for organizations and users.
Because Windows Azure Active Directory supports industry-standard protocols, federation with it is no different from identity federation directly with an on-premises directory. Because applications interact with Windows Azure Active Directory through standard protocols, the applications can be cross-platform. Applications can run on the Windows operating system, Amazon Web Services, Google App Engine, iOS, and Android, and developers have their choice of many programming languages and runtimes.
In discussions with us, developers say integrating and keeping their applications federated with many different customer directories is one of their biggest challenges. Windows Azure Active Directory helps transform the application-to-directory federation challenge from a many-to-many problem for both customers and developers to a one-to-one integration. Windows Azure Active Directory provides a consistent, high-availability point of integration that reduces or eliminates many of the typical loose ends and anomalies that comes from one-off customer integrations. This results in substantially less work and testing for everyone, and much higher rates of successful deployment.
Where we are today and what’s next
In Part 1 of this post, we focused on how Microsoft is reimagining Active Directory as a cloud service. We discussed how the application of cloud architecture and economics is making it possible to bring the power of identity management to organizations of any size, with great ease of use, low cost, and high availability. As identity management becomes more available as a service, many more organizations will be able to take advantage of it.
Here in Part 2 of this post, we looked at how we are reimagining Active Directory and enabling new ways to connect to people, devices, and applications. The Windows Azure Active Directory developer preview offers new capabilities that enable integration with next-generation applications, mobile devices, consumer identities, and social networks.
The combination of widespread adoption and improved connectivity that identity management as a service offers will enable developers and organizations to tackle existing and emerging challenges. It will be an exciting time for the identity industry. We look forward to playing our part and working with others in shaping what this new world looks like.
Please look for Alex Simon’s blog post announcing availability of the developer preview soon.
– John Shewchuk, Microsoft Technical Fellow