Problem

T

Preferred architecture

Here is the configuration in Azure app configuration:

Solution

We’ll use RBAC and managed identity to set up authorization for our function to access the configuration and secret. This involves adding the role of App configuration data reader to Azure app configuration and Key vault secret user to Key vault. This setup works perfectly for a System Assigned Managed Identity. However, for a User Assigned Managed Identity, we need to specify which identity the application should use. This is done by adjusting the function’s keyVaultReferenceIdentity property to the resource ID of the user-assigned identity.

userAssignedIdentityResourceId=$(az identity show -g functions-secret-config-demo -n function-identity --query id -o tsv)
az functionapp update --resource-group functions-secret-config-demo --name function-secrets-demo --set keyVaultReferenceIdentity=${userAssignedIdentityResourceId}

Conclusion

And there we have it – our values are now successfully loaded in the application, and we’ve securely moved our secrets to the ideal spot: Azure Key Vault. You’ll notice the Source column pointing to the App configuration reference. A green tick icon is your sign of success, showing that we’ve successfully retrieved the value.

Cloud services make it easy to create and host your applications. But these benefits come with a cost. For instance underlying hardware is often shared between customers. This brings the cost down but on the other hand, you loose some control over your environment. This is necessary because otherwise other users could disrupt run of your application.

The problem

Today I encounter a problem, where I need to create C# API, which will get results from Powershell library and return these results to the user. API is hosted as Azure app service web app and the library is published on PowerShell Gallery. I am running Powershell inside my C# code using System.Management.Automation NuGet package.

First thing that comes to my mind is install the module to my runspace using command Install-Module <module name>. This requires administrator rights and it just doesn’t work. I don’t like the idea downloading the powershell module from gallery each time anyway.

The solution

Every module published in PowerShell Gallery can also be downloaded. You can use some kind of package manager tool or do it manually. In general I like the idea of having specific tested version of the module packed with my application. After the download we ended up with package.nupkg file. But how can we integrate it into our Powershell runspace? The .nupkg filetype is nothing more than an archive. You can extract it with anything that can extract ZIP like archives. The result is shown on image bellow.

Cool! Now we ended up having familiar .psd1 file, which can be easily imported into the runspace. In short to use third party powershell module in Azure app service you have to take care of its download, extract it and then import it into your session.

using (Runspace runspace = RunspaceFactory.CreateRunspace())
{
    runspace.Open();
    PowerShell powershell = PowerShell.Create();
    powershell.Runspace = runspace;

    powershell.Commands.AddCommand("Set-ExecutionPolicy")
        .AddParameter("Scope", "Process")
        .AddParameter("ExecutionPolicy", "RemoteSigned");
    powershell.Invoke();
    powershell.Commands.Clear();

    powershell.Commands.AddCommand("Import-Module")
        .AddArgument(@".\PS\ExchangeOnlineManagement.psd1");
    powershell.Invoke();
    powershell.Commands.Clear();
    
    //you can use imported module now
}

Modern applications consist of lots of independent components. Microservice architecture brings great benefits but it also has its downsides. Developers must take care of communication between various parts of the system and make it secure and authenticated. One of the preferred ways is to give your component identity from Azure Active Directory (AAD) and utilize the use of AAD tokens. This demo shows various ways how to retrieve identity from application context using a single line of code and get sample secrets from the Azure Key Vault. This all is done with the help of DefaultAzureCredential class from Azure.Identity NuGet package.

The whole demo can be cloned from my GitHub repo.

Prerequisites

We will create an instance of the Azure Key vault. As the second step, we insert the value `supersecurevalue` as a secret with the key `mylittlesecret`. This all is done with the help of Azure CLI.

az keyvault create --location westeurope --name azureidentityvault --resource-group identitytest  
az keyvault secret set --name mylittlesecret --value supersecurevalue --vault-name azureidentityvault

DefaultAzureCredential

There are various identities we want to use for our application during different stages of the development cycle. For example, one for development, one for integration testing, and one for production. For sure we don’t want to have a separate code section for each environment. Azure.Identity NuGet package makes retrieving identity unified. The following example retrieves our secret from the created Key vault (uses C# 9 and top-level statements). 

using System;  
using Azure.Identity;  
using Azure.Security.KeyVault.Secrets;  
  
const string keyvaultName = "azureidentityvault";  
const string secretKey = "mylittlesecret";  
  
var credential = new DefaultAzureCredential();  
  
var client = new SecretClient(new Uri($"https://{keyvaultName}.vault.azure.net/"), credential);  
KeyVaultSecret secret = client.GetSecret(secretKey);  
Console.WriteLine(secret.Value);

var credential = new InteractiveBrowserCredential();

var credential = new DefaultAzureCredential(includeInteractiveCredentials: true);

var credential = new AzureCliCredential();

VisualStudioCodeCredential

var credential = new new VisualStudioCodeCredential();

Azure Visual studio extensions required you to be logged in to show your Azure resources. You need an Azure account extension for this purpose. It providers various commands on how to perform sign-in. Just hit F1 and start typing “Azure Sign In”. VisualStudioCodeCredential takes this identity and uses it for the identity of our application during runtime.

VisualStudioCredential

var credential = new new VisualStudioCredential();

This option is very similar to the previous one. It differs only in the IDE and the way of providing credentials to it. In the “big” Visual studio you find the login form in Tools > Options > Azure service authentication.

SharedTokenCacheCredential

var credential = new new SharedTokenCacheCredential();

Many Microsoft applications use Azure single sign-on. This class uses identity, that was already stored in the local cache by one of them.

ManagedIdentityCredential

var credential = new ManagedIdentityCredential();  

az storage account create --name identityfunctionstorage --resource-group identitytest  
az functionapp create --name identityfunctiondemo --resource-group identitytest --storage-account identityfunctionstorage --consumption-plan-location westeurope

az functionapp identity assign --name identityfunctiondemo --resource-group mirotest

{  
  "principalId": "3fedf722-7c5d-426f-9d35-d985d3eb59bc",  
  "tenantId": "8d099a24-312e-4bb5-8fe4-aed67b7c4921",  
  "type": "SystemAssigned",  
  "userAssignedIdentities": null  
}

az keyvault set-policy --name azureidentityvault --object-id 3fedf722-7c5d-426f-9d35-d985d3eb59bc --secret-permission get

func azure functionapp publish identityfunctiondemo  
  
Microsoft (R) Build Engine version 16.8.0+126527ff1 for .NET  
Copyright (C) Microsoft Corporation. All rights reserved.  
  
  Determining projects to restore...  
  All projects are up-to-date for restore.  
  Azure_Identity_Demo_Function -> D:\working\Azure.Identity.Demo.Function\bin\publish\bin\Azure_Identity_Demo_Function.dll  
  
Build succeeded.  
    0 Warning(s)  
    0 Error(s)  
  
Time Elapsed 00:00:02.22  
  
  
Getting site publishing info...  
Creating archive for current directory...  
Uploading 4,06 MB [###############################################################################]  
Upload completed successfully.  
Deployment completed successfully.  
Syncing triggers...  
Functions in identityfunctiondemo:  
    IdentityHttpFunction - [httpTrigger]  
        Invoke url: https://identityfunctiondemo.azurewebsites.net/api/identityhttpfunction?code=QOLVCOC0FNtMIgN5bRur4sQSoEXkGraUovGmcsnULKPBiHuJXVKQwg==

var credential = new EnvironmentCredential();

Conclusion

DefaultAzureCredential class makes the everyday life of developers much easier. By typing a single line of code, we can provide a unified solution for providing identity. It adapts well to various environments starting from local debugging in IDE, continuing with build runners, and ending up in production cloud hosting.

Business websites use AD groups as authentication mechanism quite often. Before cloud era, ASP.NET translated AD groups into roles out of the box. This is no longer possible with Azure AD. At least not so simple. Now there are 2 ways you can check group membership:

• Set Azure AD to include security groups membership information into JWT token.
• Query Graph API for user groups.

There are many tutorials describing the first approach. It is easy and effective, however it has its limitations. If the user is member of a lot of groups, size of the token will grow. There is limit 200 group ids in one JWT token. Error message appears, that points you to Graph API, if you try to request token for user with more than 200 groups. This sample demonstrates how to obtain users AD groups from Graph API and assign ASP.NET roles based on these groups. Roles are then stored in cookie, so only first request queries Graph API.

The whole sample can be cloned from my GitHub repo.

How to run this sample

You need access to Azure AD to register your application and check ids of groups.

Register Azure AD application

1. Create new Azure AD application and set its reply URL. I won’t cover this in detail.
2. Set up a secret in Certificates & secrets tab.
3. In API permissions tab, add permission Microsoft Graph -> GroupMember.Read.All. User.Read is present by default. Don’t forget to grant admin consent.

Fill in information about your app into AzureAD section of appsettings.json file.

"AzureAD": {
    "Instance": "https://login.microsoftonline.com/",
    "Domain": "<your domain>",
    "TenantId": "<your tenant id>",
    "ClientId": "<your client id>",
    "ClientSecret": "<your client secret>"
  },

You would want to place your secret somewhere safer in production application.

Assign ASP.NET roles to your Azure AD groups

Find guid of your Azure AD groups. In the AuthorizationGroups section of appsettings.json file replace key-value pairs with group id as key and target role as value. You can add as many as you want.

"AuthorizationGroups": {
  "5b99527f-947b-4e8d-aad5-404f8d39008c": "examplerole1",
  "2bd89580-1d95-4a9a-98c2-a7a150168cba": "examplerole2"
},

Set up endpoints authorization and run the application

There are 3 endpoints:

• / Default endpoint. Requires only to be logged in.
• /roletest Requires role to grant access.
• /accessdenied Redirect destination in case of failed authorization.

In Startup.cs modify { Roles = "examplerole1" } to match one of roles specified in previous step.

app.UseEndpoints(endpoints =>
  {
      endpoints.MapGet("/", async context =>
      {
          await context.Response.WriteAsync("Im authorized (no required role).");
      }).RequireAuthorization();

      endpoints.MapGet("/roletest", async context =>
      {
          await context.Response.WriteAsync("You passed the role test!");
      }).RequireAuthorization(new AuthorizeAttribute() { Roles = "examplerole1" });

      endpoints.MapGet("/accessdenied", async context =>
      {
          await context.Response.WriteAsync("Access denied!");
      });
  });

Run the application.

How does it work

Azure AD authentication

I used Microsoft.AspNetCore.Authentication.AzureAD.UI NuGet package. Startup.cs file changes:

services.AddAuthentication(AzureADDefaults.AuthenticationScheme)
    .AddAzureAD(options => Configuration.Bind("AzureAD", options));

app.UseAuthentication();
app.UseAuthorization();

This package takes care of setting up Open Id Connect and Cookies.

Graph API

Class GraphService.cs takes care of all operations against Graph API. Method CheckMemberGroupsAsync gets collection of group ids and returns only ids, that user is member of. This is done by CheckMemberGroups Graph API method.

public async Task<IEnumerable<string>> CheckMemberGroupsAsync(IEnumerable<string> groupIds)
{
    //You can check up to a maximum of 20 groups per request (see graph api doc).
    var batchSize = 20;

    var tasks = new List<Task<IDirectoryObjectCheckMemberGroupsCollectionPage>>();
    foreach (var groupsBatch in groupIds.Batch(batchSize))
    {
        tasks.Add(_client.Me.CheckMemberGroups(groupsBatch).Request().PostAsync());
    }
    await Task.WhenAll(tasks);

    return tasks.SelectMany(x => x.Result.ToList());
}

Information about which user groups to check is taken from user context. That’s why GraphServiceClient must be created on behalf of user with it’s token. I’ve create factory method CreateOnBehalfOfUserAsync for this purpose.

public static async Task<GraphService> CreateOnBehalfOfUserAsync(string userToken, IConfiguration configuration)
{
    var clientApp = ConfidentialClientApplicationBuilder
        .Create(configuration["AzureAD:ClientId"])
        .WithTenantId(configuration["AzureAD:TenantId"])
        .WithClientSecret(configuration["AzureAD:ClientSecret"])
        .Build();

    var authResult = await clientApp
        .AcquireTokenOnBehalfOf(new[] { "User.Read", "GroupMember.Read.All" }, new UserAssertion(userToken))
        .ExecuteAsync();

    GraphServiceClient graphClient = new GraphServiceClient(
        "https://graph.microsoft.com/v1.0",
        new DelegateAuthenticationProvider(async (requestMessage) =>
        {
            requestMessage.Headers.Authorization = new AuthenticationHeaderValue("bearer", authResult.AccessToken);
        }));

    return new GraphService(graphClient);
}

Intercepting authentication flow and adding custom claims

OpenId exposes OnTokenValidated event. We can use returned token before authentication is finished. It is needed to create Graph API client, that will act on behalf of actual user.

• Load key-value pairs of group ids and target roles from section AuthorizationGroups of configuration.
• Create Grap API service on behalf of actual user.
• Check which groups from configuration is user member of.
• Create role claims from returned entries.
• Add these claims to current user.

Added claims are stored in cookie, so other requests do not trigger this event.

services.Configure<OpenIdConnectOptions>(AzureADDefaults.OpenIdScheme, options =>
    {
        options.Events = new OpenIdConnectEvents
        {
            OnTokenValidated = async ctx =>
            {
                var roleGroups = new Dictionary<string, string>();
                Configuration.Bind("AuthorizationGroups", roleGroups);

                var graphService = await GraphService.CreateOnBehalfOfUserAsync(ctx.SecurityToken.RawData, Configuration);
                var memberGroups = await graphService.CheckMemberGroupsAsync(roleGroups.Keys);

                var claims = memberGroups.Select(groupGuid => new Claim(ClaimTypes.Role, roleGroups[groupGuid]));
                var appIdentity = new ClaimsIdentity(claims);
                ctx.Principal.AddIdentity(appIdentity);
            }
        };
    });