"mailEnabled": false, "provisioningErrors": [], "proxyAddresses": [], "securityEnabled": true }, … ] } Because Azure AD Graph API is built using standard REST semantics, NO special protocols or libraries are necessary to access your directory tenant information. HTTP is enough. Furthermore, Azure AD Graph API supports differential query requests. A differential query request returns all changes made to specified entities during the time between two consecutive requests. For example, if you make a differential query request an hour after the previous differential query request, only the changes made during that hour will be returned. This functionality is especially useful when synchronizing directory tenant data with an application’s data store. A differential query request URL is created by appending deltaLink in the query string to the tenant-specific endpoint: https://graph.windows.net/<tenant domain name>/<entity>?api-version=<version>&deltaLink= Such as: The deltaLink parameter with no assigned value indicates that this is an initial differential query request. Differential query paged responses contain all changes that occurred on the tenant until last page of changes is returned: { "odata.metadata": "", "aad.nextLink": "... [Truncated]", "value": [ { "odata.type": "Microsoft.WindowsAzure.ActiveDirectory.User", "objectType": "User", "objectId": "dca803ab-bf26-4753-bf20-e1c56a9c34e2", "accountEnabled": true, "displayName": "John Smith", "givenName": "John", "mailNickname": "johnsmith", "passwordPolicies": "None", "surname": "Smith", "usageLocation": "US", "userPrincipalName": "" } ] } The aad.nextLink property indicates that there are more changes on the tenant and that the application should perform subsequent differential query request right away and pass aad.nextLink property value from the response as deltaLink parameter value: [Truncated]
Note For more information, see the Microsoft TechNet article . Granting access with the consent experience prior to March 12, 2014 The "legacy" consent experience allows you to only grant the following permissions: Sign on users from their organization. Sign on users and read the their organization’s directory data (as the application only) Sign on users and read and write their organization’s directory data (as the application only) In order to be effective, this implies to: Prepare the application’s project to handle multiple tenants Add sign-up capabilities to the application The article outlines how to build a multi-tenant web ASP.NET MVC 4 application that can be used by organizations that have Azure AD. Important note This illustration will be removed soon. A sample code that addresses a similar scenario is available . The rest of this chapter illustrates the two above steps for the legacy consent experience. Preparing the application’s project to handle multiple tenants (legacy) Adjusting the web single sign-on (and single sign-out) protocol coordinates in the configuration As previously mentioned, in lieu of the tenant-specific endpoints https://login.windows.net/<tenant domain name>/<protocol>, the tenant-independent endpoints https://login.windows.net/common/<protocol> enables the application to know which tenant the user is in during sign-in. Azure AD signs the user in and figures out their tenant, handling this way for you the Home Real Discovery (HRD) or Where Are You From (WAYF). You should consequently adapt the endpoint(s) being used in your application accordingly. Likewise, the authentication response must be processed to check user is from a consented tenant. For that purpose, you must validate the audience that relates to the various consented tenant. Important note Azure AD will issue a token to a user only if the recipient application has been granted access within the user’s directory. Using the tenant-independent endpoint does not weaken the access constraints established at the directory level; it just adds generality to the sign-on process. A list of the consented tenant domain name should be typically maintained by the application as part of the sign-up process. (See below.) As far as the sign-out is concerned, it can use either the tenant-specific of the tenant-independent sign-out endpoints.
Adding a web API for Single Sign-On (SSO) Developing and calling a web API that leverages Azure AD basically entails for the following steps: Registering the web API in the directory tenant. Configuring the web API project for Azure AD. Defining the web API application roles and permissions. Enabling the client application to access the web API. Registering the web API in the directory tenant As before with a web application, the directory tenant administrator creates the service principal at behest of developer. To register a web API, proceed with the following steps: Sign into the Azure management portal as the administrator of the directory to configure. Click ACTIVE DIRECTORY on the left menu, and then click the name of the organization’s directory for which you want to register the web API. On the top menu, click APPLICATIONS. If no apps have been added to your directory, this page will only show the ADD AN APP link. Click on the link, or alternatively you can click ADD at the tray of the bottom. A What do you want do? dialog brings up. Click Add an application my organization is developing. On the Tell us about your application page, specify a user friendly name for your web API. This name will enable it to be easily identified when looking at registered client applications in your directory. Select WEB APPLICATION AND/OR WEB API. Click the arrow icon on the bottom-right hand corner of the page. On the App properties page, provide the information for the web API. Specify the address of the web API in APP URL, as well as in APP ID URI to logically identify the web API. Note With a web application, the address specified in APP URL is used to know to where the token representing successful authentication should be sent. In the case of a web API, however, the return URL is handled by the client of the web API. Hence, you can enter here whatever valid URL you like and that won’t have impact on the process. This said, this is usually a good idea to put the correct URL anyway, given that you never know how you’ll want to evolve this web API in the future... Click the check mark icon on the bottom-right hand corner of the page. You are redirected to the Quick Start page for the web API. At this point, your web API is now listed among the other registered applications of your directory. Let’s configure it for Azure AD.