Editor’s note: The following post was written by Office 365 MVP Martina Gromand Client Development MVP Toni Pohl. This is the third of a 4 part series. Read part 1and part 2. 

Identity in Your Own Apps with Windows Azure Active Directory

Part 3: See behind the scenes with GraphExplorer

We´re using the Windows Azure Portal in part 2 (link) to manage Windows Azure Active Directory (WAAD). Existing Office 365 AD´s can be connected with your Windows Azure account as global administrator. From that point on all objects like users, groups, apps and settings within our AD can be managed in the Azure portal. Developers can use a second mechanism: The GraphAPI (http://bit.ly/1eNLLnG ). This interface is used in code and delivers the same functionality as the Azure or Office 365 portal.

Before we look into the details of GraphAPI we want to point out a very helpful tool made by the Windows Azure Active directory product group: The GraphExplorer. You find it online at https://graphexplorer.cloudapp.net/ .

As you see by its URL GraphExplorer is a website living itself on Windows Azure. For exploring WAAD we can use a built-in Demo Company AD – or our own. So click Sign In and login with your Office 365 domain administrator. Guess what… GraphExplorer uses the same functionality as our web app we created in part 1 in combination with GraphAPI.

After the login let´s experiment with the already filled out API call against our own AD. When clicking the Get-button we get a JSON formatted return for our call: the name and a collections of services for this WAAD. The request goes online to https://graph.windows.net/<active directory domain>/ . The API (a cloud service) reads the request and sends back the informations for that method.

What a great tool! Again, without programing anything we can use an online tool for reading object-data of any AD we have administrator-credentials. Let´s explore this a little bit!

/users delivers all users in our AD. With these service methods we get all data stored in the user containers, much more than in the Azure or Office 365 portals, we can access all objects with all public properties.

If we look at use object of Martina we created in the Azure portal in part 2 this is what we get: an user object in a collection of users in JavaScript Object Notation format (JSON):

{

      "odata.type": "Microsoft.WindowsAzure.ActiveDirectory.User",

      "objectType": "User",

      "objectId": "2d6d1e86-b93c-421a-a4c6-0032bc15e32a",

      "accountEnabled": true,

      "assignedLicenses": [],

      "assignedPlans": [],

      "city": null,

      "country": null,

      "department": null,

      "dirSyncEnabled": null,

      "displayName": "Martina Grom",

      "facsimileTelephoneNumber": null,

      "givenName": "Martina",

      "jobTitle": null,

      "lastDirSyncTime": null,

      "mail": null,

      "mailNickname": "martina",

      "mobile": null,

      "otherMails": [

        "mg@atwork.at"

      ],

      "passwordPolicies": "None",

      "passwordProfile": null,

      "physicalDeliveryOfficeName": null,

      "postalCode": null,

      "preferredLanguage": null,

      "provisionedPlans": [],

      "provisioningErrors": [],

      "proxyAddresses": [],

      "state": null,

      "streetAddress": null,

      "surname": "Grom",

      "telephoneNumber": null,

      "usageLocation": null,

      "userPrincipalName": "martina@mvpdemo2014.onmicrosoft.com"

    },

The good news: This is exactly what we need to do in our own code when working against the GraphAPI. Accessing the API with a special request and reading the returned data.

The same method works with groups. Go back in the browser and try the link to the /groups call. In our AD we have two groups: Redmond and Vienna. We also see that these groups are not synced with a local AD but live in the cloud, they are not mail enabled and so on.

If you want to get the members of one specific group go deeper with a call like this: Use /groups/<object-Id of the group>/members, f.e.: https://graph.windows.net/mvpdemo2014.onmicrosoft.com/groups/524785a0-b416-4f1b-b4b7-aa1c6a55bcaa/members .

This is the complete output (return) for that call. We get one user-object, in that case user Martina.

In the Azure portal we also saw the app IDs. Of course, they also can be requested with GraphAPI. When opening the link /applications we see all apps as in the portal before.

Does this look familiar to you? Sure, it´s all the values we have in our web.config in part 1 when Visual Studio created our ASP.NET MVC app for us. Here´s the counterpart in WAAD, all values are stored in the /applications node of our AD-tree. In WAAD there exist some more metadata including the time frame for the app secret.

Of course, the app secret is also stored in here, but you can´t get it. It´s only visible when creating a new key and never shown as result. You only can renew the secret – but then you have to do it in WAAD as well as in your app(s). It´s also very important to see that the app URI and the replyURLs are stored here. If you put your (web) app to production the URL https://localhost:44324/ of course will change. Then you have to modify the replyURL with the new one (the easiest way is to do this in the Azure portal). As you see there can be more than one replyURL– but in our tests it never worked with more than one URL. The redirection always used the first entry. Maybe this behavior will change in future depending on the address where the call comes from which was in our opinion the idea of this collection.

There´s another node we want to mention: /servicePrincipals (SPN). These object types can be used in applications too. The difference is that SPN´s have more privileges than apps, see more here.

When using Office 365 the call to /subscribedSkus can be helpful. Here you get all assigned license plans for that tenant.

The service plans are depending on your subscription. ServicePlan Yammer_Enterprise is always automatically included in the Office 365 plans E3 and E4. When you use a 30-day test tenant, you get full access to all Office 365 features.

Our conclusion and our recommendation here is to have a look into the GraphExplorer online-tool when working with WAAD. This tool is very cool to test requests against GraphAPI and see what results you get. For extending our own portal we´ll use GraphAPI in the next part 4.

About the authors

Toni Pohl has worked for nearly 20 years as an independent IT expert. Toni began his IT career in the early 1990s as a trainer. After working as a trainer, his emphasis changed to the field of consulting and developing software solutions using database systems. In 1999 Toni Pohl founded atwork information technology group along with Martina Grom. They share the business administration. He is responsible for new business development, technology, and quality assurance. Toni Pohl has been awarded in 2013 by Microsoft with the Most Valuable Professional Award (MVP) for his expertise in Client Development. Toni blogs about new technologies for the atwork-blog, in Microsoft-TechNet-Team-Austria Blog, in codefest.at, the Austrian MSDN Blog and in cloudusergroup and is writing technical articles for various magazines. You can connect with him on Twitter, Facebook, or Linkedin.

Martina Grom works as IT-Consultant & is co-founder and CEO of atwork information technology. atwork is located in Austria/Europe and is specialized in development of Online Solutions. Martina & Toni founded atwork in 1999, and she has worked in IT since 1995. Martina is recognized as an expert in Microsoft Office Online Services solutions and was worldwide one of the first 8 MVP’s awarded in 2011 for her expertise in Office 365. She writes numerous articles and blog posts. Her passion is Online & Social Media, cloud computing and Office 365. Martina consults companies on their way to the cloud. Martina has a master degree in international business administration of University of Vienna, You can connect with her on Twitter,Facebook, Linkedin or join her cloudusergroup. 

About MVP Monday

The MVP Monday Series is created by Melissa Travers. In this series we work to provide readers with a guest post from an MVP every Monday. Melissa is a Community Program Manager, formerly known as MVP Lead, for Messaging and Collaboration (Exchange, Lync, Office 365 and SharePoint) and Microsoft Dynamics in the US. She began her career at Microsoft as an Exchange Support Engineer and has been working with the technical community in some capacity for almost a decade. In her spare time she enjoys going to the gym, shopping for handbags, watching period and fantasy dramas, and spending time with her children and miniature Dachshund. Melissa lives in North Carolina and works out of the Microsoft Charlotte office.