This is the first post of a little series on secure Azure Functions working with Office 365. This first one is about “simple” credential (user/password or ID/secret) access. Next we are going to use an additional certificate while accessing SharePoint Online.
- Secure Azure Functions Part 1 – Use Azure KeyVault Secrets when accessing Microsoft Graph
- Secure Azure Functions Part 2 – Handle certificates with Azure KeyVault when accessing SharePoint Online
When secure access to APIs is needed from Azure Functions the challenge is to securely store access credentials or secrets. To access Microsoft Graph for instance for the OAuth authentication you need a ClientID and a secret. The question is now where to store this. Is it a good idea to store this in your code or AppSettings? Most likely not!
In this post I want to show you a simple scenario to access Microsoft Graph from an Azure function and retrieving the ClientID and AppSecret from Azure KeyVault.
Accessing Microsoft Graph in this case is only an example for an API access where a secret is needed.
The architecture scenario
Our architectural scenario is an Azure function that is securely called, for instance from a SharePoint Framework (SPFx) component via the new AADHttpClient. Nevertheless we will omit the UI part in this post and fully concentrate on the backend side:
So there we have our Azure function which will securely retrieve access credentials from Azure Key vault. Having that it will securely authenticate against our backend Api, that is Microsoft Graph in our example.
At first we will start creating the “credentials” for our backend Api. In our case this is an Azure Active Directory app registration.
App registration to access Microsoft Graph
There are two versions for Azure App registrations. V1 and V2. For a detailed overview on the differences refer to here. But as we want to access Microsoft Graph and this is possible with V2 we will now use that one. In a later scenario we will access SharePoint Online which was only possible till recent past with V1 and then we will have a look at that variant.
For accessing V2 we open the Url https://apps.dev.microsoft.com/ and register a new converged application. We will need to
- Enter a name
- Copy the application Id (we can do this later as well)
- Create a new secret and copy it (Attention, we CAN’T do this later as well, we only can create a new one if we forget)
- Add the platform Web-Api
- As we want to access Office 365 Groups and its owners:
Add Application permission Group.Read.All and Directory.Read.All
- You can uncheck Live SDK support
To manage V2 app registrations from Azure Portal as well is currently under preview at the time of writing (end of 2018). To use it, simply log in to https://portal.azure.com/, go to "Azure Active Directory" and then "App registrations (preview)". The steps then are quite the same then mentioned above but slightly simpler. We will have a look at this in a later scenario as through this way it is now also possible to handle SharePoint Online Api permissions.
Once you have registered your app you need to consent it. Use the following Url template:
The tenant can be your GUID our the full name ( .onmicrosoft.com ).
The redirect_uri is obsolete as it might not be reached after everything went fine so ignore the 404 error afterwards.
In the new app registration preview this step can be done directly from the app registration by one click (make sure you are logged in as tenant admin that has adequate permissions to grant them to all users).
Establish Azure KeyVault
Creating an Azure KeyVault is also straightforward with some small but important steps to notice. First we switch to “Key vaults” in the Azure portal and create a new one:
A unique name is necessary as well as the subscription and the ressource group. The rest we can keep as is for now.
Next we will add our created AppID and Secret to the Key vault:
We do this twice. Once for the ID (debatable, you might also put this only to the AppSettings but …) and once for the Secret (not debatable 😉 )
Before leaving the key vault for a moment we might note down it’s Url which we need for access from our code later:
That’s it for the moment. Once we are going to retrieve them from our Azure function we will come back to establish access to the key vault.
Configure the Azure Function App
For the Azure Function App we basically don’t need something special. For those of you new to the topic pay attention to create the Function App via “App Services”:
Additionally (for instance when consuming your Azure function from SharePoint Framework (SPFx)) you might need tp
- Configure CORS settings
- Configure Authentication
Both is described here.
Managed Service Identity (MSI)
For sure the access to the recently established Azure key vault is not “anonymous” but also secured. The trick to not having to handle another credential/secret is the “Managed Service Identity”.
We can simply extend our Azure function app to register with Active Directory. In a next step we allow access for that AAD registration (think of an AD account for that app which auto-authenticates against the key vault later on) to our Azure key vault.
In your function app select “Platform settings” and there “Managed Service Identity”
Next you simply turn MSI on and save it
That’s it. After a short while you can switch back to your Azure key vault. There you choose “Access policies” and “+ Add new”.
Under “Principal” search for the recently created app function name. It can be easily detected by the special icon logo. For permissions select “Get” and “List” at least for “Secret Permissions” (for a later scenario I already added the same for key and certificate…)
Retrieve Key Vault Secret
The first thing we need are our app credentials (ID / secret) to access Microsoft Graph afterwards. The retrieval is quite simple as we need no explicit authentication. It is handled implicitly by MSI.
The async task will return the secret for a given name. First we build the Uri for it, constructed by our base Url we noted above when establishisng our key vault and now retrieving it from the ConfigurationManager. The Url is something like:
Then with that Uri we finally retrieve the secretValue asynchronously and return it back.
Access Microsoft Graph
To access Micrsoft Graph we use the MSAL library which is represented by the NuGet package “Microsoft.Identity.Client”. This library is designed to handle Azure AD V2 endpoint access with AccessTokens. It is still a pre-release as time of writing (end of 2018) but it is declared “production ready”. You could also use the ADAL library for this scenario (you find an alternative example in the source code) and will use this in a later scenario for V1 access. Further explanation you can find here.
We extract our Graph stuff to a separate controller. At first we need some basic values which we can either hardcode or retrieve from ConfigurationManager.
But on top we need our registered values from above which we included both in Azure KeyVault. We will provide them within our constructor.
Next thing is to establish a GraphServiceClient. Therefore we retrieve an AccessToken via MSAL and on behalf of our client app registration values.
Finally we have our Task to retrieve the data. In our small example case we want to check if a given user account is owner of a given Office365 Group ID.
The Azure Function – Putting it all together
The magic is already shown but now we simply put it alltogther inside our Azure function.
For our simple demo scenario we expect an Office 365 GroupID and a user login from query parameters.
Next we retrieve our application ID and our application secret from Azure Key vault by using our static KeyVaultAccess class.
Having those values we instantiate our GraphAccess class.
Once we have it we finally call the isValid method to evaluate if the given login is owner of the given group. The method retrieves the login and group id but before it needs a “GraphServiceClient”. I showed you two methods (ADAL and MSAL version) inside the GraphAccess class and here the MSAL version is called. That’s it.
You could now call this function from a SPFx solution for instance but might also say: Hey, why not directly call the Graph from SPFx?
You are right but this is an example that can be simply adapted to your own API call (that is, not MSGraph but also needs a ID/Secret or user/password access). Furthermore you might not provide a privileged access to your users by admit WebApiPermissions. Or you need Graph access in combination with other backend code for instance?
An even better scenario for this is elevating SharePoint permissions. Therefore I am going to write another post establishing access to SharePoint Online from Azure function by using Azure Key vault. Here we will need a certificate on top. So stay tuned.