Automating the Provisioning of Selective Teams with Guest Access: Part 1 — Azure AD App Registrations

Series Contents

• Introduction
• History & Background
• Part 1: Application Authentication — Azure AD Application Registrations (you are here)
• Part 2: Request Storage — SharePoint
• Part 3: Request Process Automation — Microsoft Power Automate & Microsoft Graph
• Part 3.5: Flow Enhancements
• Part 4: Enhanced User Interface — PowerApps & Teams
• Part 4.1: Governing the ‘Viral’ Creation of Teams
• Part 5: Next Steps — Security

As you’ve read in the opening “how did we get here” post, we landed on a combination of a number of Microsoft cloud services that allow us to pull this off. One of the major pieces required for all this stuff to work is that this process requires the proper level of access and permissions.

Enter Azure Active Directory Application Registrations.

Figure 1: Azure Active Directory App Registrations — Overview Pane

An AAD AppReg is a required item for this process. It is the plumbing that we’ll need for our flow to use, when calling the relevant operations in the Microsoft Graph. This App Reg can be tailored and scoped to do only specific operations, as well as secured so that a token is required for it to be used. More information on application registrations can be found here. But, let’s walk through setting up the one we need for our desired process.

Step 1: Create a New App Registration

This is the easy step. We’ll need to create this app reg first, and then tailor it with the relevant permission and security bits. So, from the Overview page (figure 1 above) select New Registration. A new pane will appear to enter some information in (figure 2 below).

Figure 2: Register an application

Enter the name that you’d like for this registration. As we’re only dealing with this process starting from within our tenant we’ll stick with the default account type of Single Tenant. For the Redirect URI enter https://localhost. After clicking Register you’ll see the following Overview pane for your brand new App Reg (figure 3). Note the IDs have been obscured to protect the innocent.

Figure 3: Overview pane for new app registration

Step 2: Set Up API Permissions

To provide a wee bit more security, as well as scope the actual operation(s) that our process will utilize, we need to grant it the relevant permissions to the APIs that it needs to use. To do this we click View API Permissions. This results in a blade that shows what permissions this registration currently has (Figure 4 below).

Figure 4: App Registration Permissions

Basically, this area allows us to assign the relevant permissions that our process will use in this registration. How do we do this? Well, we start with clicking +Add a permission. This surfaces to us the various APIs we can utilize. For our process here we’re all about the Microsoft Graph. So that’s what we select (Figure 5: API Permissions).

Figure 5: Request API Permissions

Because we’re utilizing Flow for this, and want our process to execute, we select Application permission type (Figure 6).

Figure 6: Permission Type

After selecting the type we need to select the specific permissions we want this registration to govern. Because we like following least-privilege, we’ll only want to give this registration the minimum required permissions to execute our process. Per the Microsoft Graph documentation we only need 2 permissions for the Create Team operation and the Update Group Setting operation. Select these two, and click Add Permissions (Figure 7).

Figure 7: API Permission Settings

After adding the relevant permissions you’ll be returned to the API permissions page and it should look something akin to the below (figure 8).

Figure 8: API Permissions After Adding

Again, in the spirit of least-privilege, we want to be using only the permissions required by this operation. So, we should remove the User.Read permission from this area. Select that permission, then select Remove Permission from the flyout that appears.

Figure 9: Remove Permission

After removing the permission, we need to proactively grant consent to the tenant, so that our users who want to request teams can do so through our process. We can do so by clicking the Grant admin consent for Contoso button. This action grants consent for the entire tenant, so the organization’s users won’t see a consent page for the application.

Figure 10: Grant Admin Consent

The end result is a permission set for this registration that looks like the below (figure 11). The registration has now been set up with the correct permissions. But now we need to lock it down further.

Figure 11: Completed API Permission

Step 3: Create a Client Secret

In order for us to properly secure this registration, so that only those that have the proper credentials can call it, we need to set up a Client Secret. This secret will allow us to request a token that can be used for this call. To start, click on +New client secret.

Figure 12: Client Secret

Secrets can expire in 1 year, 2 years, or never expire. Enter the name of it (in the Description field), pick an expiration, then click Add.

Figure 13: Add a client secret

Note that after you add the client secret you are shown its value. It is *extremely* important you copy/paste this for later as after you leave/sign out, signing back in will not give you access to the actual value. We will need this when we get to our flow, so store this in a safe place.

Figure 14: Copy secret value

Conclusion

At this point you’ve created a new AAD App Registration for us to use in our process going forward. In our next article we’ll spin up a SharePoint Online site and list to hold our Team requests.