This course teaches you how to manage application and network services in the Azure ecosystem.
By the end of this course, you'll have gained a firm understanding of the key components that comprise the Azure application and network services ecosystem. Ideally, you will achieve the following learning objectives:
- How to use Active Directory.
- How to understand networking strategies for Azure and communication services.
- How to use Redis cache.
This course is intended for individuals who wish to pursue the Azure 70-532 certification.
You should have work experience with Azure and general cloud computing knowledge.
This Course Includes
- 1 hour and 10 minutes of high-definition video.
- Expert-led instruction and exploration of important concepts surrounding Azure application and network services.
What You Will Learn
- How to utilize Azure Active Directory.
- How to implement Azure communication strategies.
- How to take advantage of Redis caching.
About the Author
Isaac has been using Microsoft Azure for several years now, working across the various aspects of the service for a variety of customers and systems. He’s a Microsoft MVP and a Microsoft Azure Insider, as well as a proponent of functional programming, in particular F#. As a software developer by trade, he’s a big fan of platform services that allow developers to focus on delivering business value.
Hello and welcome back. Let's get started with Azure Active Directory. In this section we'll cover user management, we'll take a look at integration endpoints and how these tie into application integration and we'll look at some of the Graph API examples.
So, what is Azure Active Directory? Fundamentally, Azure Active Directory or AD provides three key features. Firstly, identity management for application authentication allowing applications to authenticate users against the directory. Secondly, user management, being able to create, update, and delete users as well as create and manage groups. And lastly, enabling single sign-on functionality allowing users to authenticate against multiple applications using their one identity.
So why should we use AD? We can answer that with a few key points. Firstly, Azure AD inherits from a long line of Windows Active Directory releases with Windows server over the years and it has benefited from years of testing and refinement. Secondly, Azure AD is simple to use as we'll see in the demos to follow. Thirdly, Azure AD is integrated into many popular apps and infrastructure allowing you to configure and deploy an integrated solution quickly and with ease. And lastly, Azure AD can be cost effective, removing the burden associated with building and maintaining infrastructure.
Let's look at the question of when should we consider using Active Directory? Active Directory can be useful in a variety of scenarios. Starting simply you can use it as an Azure hosted standalone user directory. Software as a service or SaaS, the application to support it can use Active Directory for authentication. Today this includes thousands of applications including Office 365, Salesforce, Dropbox, and Concur as well as many others. The AD directory can also be synchronized with many other directories including on-premises directories allowing for a common identity for your users between your existing applications and any software as a service applications that support AD. We can use AD to provide single sign-on or SSO between internal and software as a service applications. AD can also enable integration between applications such as different software as a service apps or when integrating an on-premises application. And lastly, the Graph API provides a programmatic way to manage users and groups.
Let's go through the key points again. Azure Active Directory can be synchronized with on-premises directories and can be maintained through the Graph API. We can use Active Directory on our on-premises applications if required. Naturally we'd make use of Active Directory in our Cloud hosted applications and we can configure our software as a service applications to use our AD instance when the software as a service applications supports it. And lastly, we can integrate our own Cloud apps, software as a service apps, and on-premises applications using Azure AD.
Let's take a look at the short video on how to create an Active Directory in the Azure portal. So I'll see ya there shortly. I'm here in Azure, the classic portal, let's start this section by creating a new directory by going down to the New button at the bottom left of the screen. So we've clicked New, I'm gonna go to App Services, and we're gonna select from this list down the bottom Active Directory and then Directory and then we're gonna click Custom Create which will bring up the wizard and we'll create a new directory and we'll call this one CaTestDir and we'll say CA test directory and we can select our country or region. In my case I'm gonna select United Kingdom and we click Add. And we'll come back in a second once this has finished loading up and we'll see how we can start managing users.
Now this is ready let's click on CaTestDir. Now this is loaded, let's click Manage Access, the button at the top and we're gonna add a new user. We're gonna add the new user in our organization and we're gonna call this one standard user and then we'll click Next and we'll give it a display name of Standard User and there are many roles we can choose from here but we'll go ahead and choose the Normal User role. We'll ignore the Multifactoral Authentication for now and we just click Create. And we'll give it the new generated password and now we've got a new user. Let's create a new group. So we'll add a new group and we'll say this one is the Test CA Group and again we've got two options here but we'll just stick with the basics for this one and we'll just click the tick and there we go. And that's our group here and we can add a member and we're gonna add the standard user that we created just now and click tick and now we've got our new user in the group. And that's done, we've created a user, created a group, and we've assigned that user to our new group.
Let's now have a look at each of the endpoint types we've mentioned. Azure Active Directory supports WS-Federation 1.2 as per the Web Services Federation Version 1.2 Specification. Simply speaking, WS-Federation is an identity protocol for browser applications. WS-Federation provides separate endpoints, one for metadata and one for logging in and logging out of a service.
Let's have a look at a simple example explaining the interaction between the client and the WS-Federation endpoint. Keeping in mind that this is a simplified example, let's go through the steps for a typical user login. The user goes to the web app, the application redirects the user to AD providing a special URL that identifies the application that the user wishes to log into. This is the key point, the endpoint URL. Active Directory responds with a login form that can be customized for the application. Unless the user already has a valid logged in cookie we'll assume that the user is not already logged in. The user fills out a form and submits it. Assuming the login details were correct Active Directory responds with a SAML token. The login form then redirects the user by submitting a HTTP post with the token to the application. The application can then validate the token, the details of which we won't go into here. And at this point the application logs the user in and completes the process.
SAML-P is the SAML 2.0 protocol. This protocol support authentication for browser applications similarly to WS-Federation. However, SAML-P libraries are not part of the .NET framework. If we want to use SAML-P we would need to acquire a third party library. Typically you would use SAML-P when the third party application you're trying to integrate with does not support WS-Federation. The interaction between the user and the Azure AD is almost identical to the WS-Federation example we just covered so we won't look at it in detail here.
OAuth 2.0 is a protocol that can allow access to user accounts that are accessible over an HTTP service. This protocol is used to authorize third party services to access the user's account. A typical OAuth request contains the client identifier and a pregenerated secret to allow our application to issue the OAuth request. We won't be looking at OAuth in depth but let's just have a look at how we can generate the secret key for application. So let's go to the Azure portal now.
So let's go to the classic Azure portal now and take a look at how this can work in practice. I'm here in the Azure portal. I've opening up our CA Test directory and we're gonna add a webpage that we wanna give OAuth access to. So to do that we click on the Applications tab at the top, so now we can click out of the bottom of the page and we'll create a new fake app and we'll give it some fake details. So we'll give this one signon.com and we can give it a unique URI for app ID. And let's give it the same name again of signon.com. Having created our application we can now go to the Configure tab and now we scroll down to the bottom of the page to the Keys section and we can see there are no keys so let's go ahead and add some keys. And there we've got one key and it says, "The key will be displayed after you save it." So let's create the key and save. And now we can see our secret key. Let's now have a quick look at the endpoint detail for our directory.
So I'm back at the Test Directory, the CA Test Directory. We're gonna click on our fake app. At the bottom of the page we can click on View Endpoints. We can now see the endpoints for the various protocols listed with the specific URLs for our app. We can see WS-Federation, SAML-P, OAuth, as well as the Graph API URL that we'll look at shortly.
Finally, let's have a look at the AD Graph API. In many scenarios managing users and groups manually through the portal is not practical. The Graph API allows you to manage AD data programmatically. Using the Graph API we can manage users, groups, and other data. We can check user roles and group memberships as well as manage application permissions. In order to manage AD through the Graph API we'll first need to allow our application to access Active Directory. Similarly to the demos we've just seen we can find the settings to do that under the Configure tab when we select one of the applications when managing our AD instance in the classic portal. We can grant read only or read and write permissions as per this example.
Here I have some example code and I wanna walk through it with you to demonstrate how we can connect and query the Graph API for our directory. So we have all the using statements at the top of the page. We've included the Microsoft Azure Active Directory Graph client and the Microsoft Identity client's Active Directory using statement also. Let's take a closer look at the program. We specify a number of URLs to connect ourselves to the various services for the Graph service and for our AD account that we want to use as well as the tenant ID and the client ID as well as the client secret which will be different depending on which AD you are using.
We'll start by creating an Active Directory client on line 23. This is the client that we'll be using so we can issue queries against the directory. We initialized the client providing it a root URL which is a combination of the Graph URL which we've specified up here with the tenant ID also. And the second argument provides the authentication token as you can see highlighted here.
The method for getting the authentication token named GetAuthToken calls acquire a token async to get the token after setting up the query of the login URL unique to Active Directory and the client ID to identify our app as well as the client's secret. Once the client reference is ready we can query the directory. In our case, we have a constructor with a simple query to find all users where the user's country property equals UK and then takes the first two results. We execute the query and return the results as a list as you can see here on line 30 and the link expression that we can see. This has been a fairly simple query example. The API also allows us to query directories in a similar way along with a wide variety of other operations and this brings us to the end of this section.
In this section we outlined Azure Active Directory, its purpose, and use cases. We looked at the endpoints AD office for application integration as well as the supported protocols including WS-Federation, SAML-P, and OAuth 2.0. We finally looked at Graph API and its purpose along with a simple example.
Stay tuned, 'cause in the next section we'll dive into the topic of virtual networks and we hope to see you there.