Windows Azure Active Directory Graph Overview
Windows Azure AD Graph provides programmatic access to Windows Azure Active Directory (AD) through REST API endpoints. Using Windows Azure AD Graph developers can execute create, read, update, and delete (CRUD) operations on Windows Azure AD objects such as users and groups. In the on-premise world, you would usually programmatically access Windows Server Active Directory by using ADSI or ADO.NET libraries. In the cloud, you programmatically access Windows Azure AD using Windows Azure AD Graph.
Windows Azure AD Graph offers the following set of features that enable several scenarios (the scenarios are discussed in the next section):
REST API endpoints. Windows Azure AD Graph exposes REST endpoints so that developers can consume it in their applications. Windows Azure AD Graph conforms to OData v3 protocol, which makes it possible to consume from any modern development platform and application architecture, ranging from mobile devices to Office 365 extensions. Read more in the Windows Azure AD Graph REST API Reference.
Windows Azure AD Authentication. In order to execute any of the operations available through Windows Azure Graph, the client needs to be authenticated first. Windows Azure AD Graph relies on Windows Azure AD for authentication. Windows Azure AD federates with Windows Azure Active Directory and serves as a Security Token Service (STS) for client requests. Read more in Windows Azure AD Graph Authentication.
Role-Based Authorization. Client access permissions are managed using Role-Based Access Control (RBAC). Client applications can be assigned different administrator roles that enable privileges such as read and write. Roles are managed using the Windows Azure Management Portal, or alternatively using the Windows Azure AD PowerShell Cmdlets and scripts. Read more in Windows Azure AD Graph and Role-Based Access Control.
Windows Azure AD Graph enables two key scenarios:
Line of Business Applications (LOB). In this scenario, you are an enterprise developer and your organization purchased a subscription that includes Windows Azure AD (for example, Office 365 or Windows Intune). The Office 365 functionally mainly fulfills your organization’s needs, but there are some needs that are not present in the service. As an enterprise developer, you need to extend the functionality of Office 365. This may require access to Windows Azure AD objects.
Multi-Tenant Applications That Require Windows Azure AD Access. In this scenario, you are building a multi-tenant application that requires access to a tenant’s directory data (very similar to an on-premises application that use LDAP to query the local directory). Directory access for reading or writing data is done by calling the Graph API. Typical use cases include people pickers, validating a user’s security group membership, updating group membership, provisioning new users and groups, resetting users’ passwords, and validating a tenant or users’ licensing information.
Creating Reusable Features That Require Windows Azure AD Access. In this scenario, you are an independent software vendor (ISV) that specializes in creating and selling reusable features that extend the functionality of cloud applications. As an ISV you want to offer to your customers reusable features that require access to Windows Azure AD objects.
Explore the Guidance
You can explore Windows Azure AD Graph guidance further in the following sections: