Skip to main content

2 posts tagged with "azure"

View All Tags

ASP.NET, Serilog and Application Insights

If you're deploying an ASP.NET application to Azure App Services, there's a decent chance you'll also be using the fantastic Serilog and will want to plug it into Azure's Application Insights.

This post will show you how it's done, and it'll also build upon the build info work from our previous post. In what way? Great question. Well logs are a tremendous diagnostic tool. If you have logs which display some curious behaviour, and you'd like to replicate that in another environment, you really want to take exactly that version of the codebase out to play. Our last post introduced build info into our application in the form of our AppVersionInfo class that looks something like this:

{
"buildNumber": "20210130.1",
"buildId": "123456",
"branchName": "main",
"commitHash": "7089620222c30c1ad88e4b556c0a7908ddd34a8e"
}

We'd initially exposed an endpoint in our application which surfaced up this information. Now we're going to take that self same information and bake it into our log messages by making use of Serilog's enrichment functionality. Build info and Serilog's enrichment are the double act your logging has been waiting for.

Let's plug it together#

We're going to need a number of Serilog dependencies added to our .csproj:

<PackageReference Include="Serilog.AspNetCore" Version="3.4.0" />
<PackageReference Include="Serilog.Enrichers.Environment" Version="2.1.3" />
<PackageReference Include="Serilog.Enrichers.Thread" Version="3.1.0" />
<PackageReference Include="Serilog.Sinks.ApplicationInsights" Version="3.1.0" />
<PackageReference Include="Serilog.Sinks.Async" Version="1.4.0" />

The earlier in your application lifetime you get logging wired up, the happier you will be. Earlier, means more information when you're diagnosing issues. So we want to start in our Program.cs; Startup.cs would be just way too late.

public class Program {
const string APP_NAME = "MyAmazingApp";
public static int Main(string[] args) {
AppVersionInfo.InitialiseBuildInfoGivenPath(Directory.GetCurrentDirectory());
LoggerConfigurationExtensions.SetupLoggerConfiguration(APP_NAME, AppVersionInfo.GetBuildInfo());
try
{
Log.Information("Starting web host");
CreateHostBuilder(args).Build().Run();
return 0;
}
catch (Exception ex)
{
Log.Fatal(ex, "Host terminated unexpectedly");
return 1;
}
finally
{
Log.CloseAndFlush();
}
}
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.UseSerilog((hostBuilderContext, services, loggerConfiguration) => {
loggerConfiguration.ConfigureBaseLogging(APP_NAME, AppVersionInfo.GetBuildInfo());
loggerConfiguration.AddApplicationInsightsLogging(services, hostBuilderContext.Configuration);
})
.ConfigureWebHostDefaults(webBuilder => {
webBuilder
.UseStartup<Startup>();
});
}

If you look at the code above you'll see that the first line of code that executes is AppVersionInfo.InitialiseBuildInfoGivenPath. This initialises our AppVersionInfo so we have meaningful build info to pump into our logs. The next thing we do is to configure Serilog with LoggerConfigurationExtensions.SetupLoggerConfiguration. This provides us with a configured logger so we are free to log any issues that take place during startup. (Incidentally, after startup you'll likely inject an ILogger into your classes rather than using the static Log directly.)

Finally, we call CreateHostBuilder which in turn calls UseSerilog to plug Serilog into ASP.NET. If you take a look inside the body of UserSerilog you'll see we configure the logging of ASP.NET (in the same we did for Serilog) and we hook into Application Insights as well. There's been a number of references to LoggerConfigurationExtensions. Let's take a look at it:

internal static class LoggerConfigurationExtensions {
internal static void SetupLoggerConfiguration(string appName, BuildInfo buildInfo) {
Log.Logger = new LoggerConfiguration()
.ConfigureBaseLogging(appName, buildInfo)
.CreateLogger();
}
internal static LoggerConfiguration ConfigureBaseLogging(
this LoggerConfiguration loggerConfiguration,
string appName,
BuildInfo buildInfo
) {
loggerConfiguration
.MinimumLevel.Debug()
.MinimumLevel.Override("Microsoft", LogEventLevel.Information)
// AMAZING COLOURS IN THE CONSOLE!!!!
.WriteTo.Async(a => a.Console(theme: AnsiConsoleTheme.Code))
.Enrich.FromLogContext()
.Enrich.WithMachineName()
.Enrich.WithThreadId()
// Build information as custom properties
.Enrich.WithProperty(nameof(buildInfo.BuildId), buildInfo.BuildId)
.Enrich.WithProperty(nameof(buildInfo.BuildNumber), buildInfo.BuildNumber)
.Enrich.WithProperty(nameof(buildInfo.BranchName), buildInfo.BranchName)
.Enrich.WithProperty(nameof(buildInfo.CommitHash), buildInfo.CommitHash)
.Enrich.WithProperty("ApplicationName", appName);
return loggerConfiguration;
}
internal static LoggerConfiguration AddApplicationInsightsLogging(this LoggerConfiguration loggerConfiguration, IServiceProvider services, IConfiguration configuration)
{
if (!string.IsNullOrWhiteSpace(configuration.GetValue<string>("APPINSIGHTS_INSTRUMENTATIONKEY")))
{
loggerConfiguration.WriteTo.ApplicationInsights(
services.GetRequiredService<TelemetryConfiguration>(),
TelemetryConverter.Traces);
}
return loggerConfiguration;
}
}

If we take a look at the ConfigureBaseLogging method above, we can see that our logs are being enriched with the build info, property by property. We're also giving ourselves a beautifully coloured console thanks to Serilog's glorious theme support:

Take a moment to admire the salmon pinks. Is it not lovely?

Finally we come to the main act. Plugging in Application Insights is as simple as dropping in loggerConfiguration.WriteTo.ApplicationInsights into our configuration. You'll note that this depends upon the existence of an application setting of APPINSIGHTS_INSTRUMENTATIONKEY - this is the secret sauce that we need to be in place so we can pipe logs merrily to Application Insights. So you'll need this configuration in place so this works.

As you can see, we now have the likes of BuildNumber, CommitHash and friends visible on each log. Happy diagnostic days!

I'm indebted to the marvellous Marcel Michau who showed me how to get the fiddlier parts of how to get Application Insights plugged in the right way. Thanks chap!

Azure Easy Auth and Roles with .NET (and .NET Core)

If this post is interesting to you, you may also want to look at this one where we try to use Microsoft.Identity.Web for the same purpose.

Azure has a feature which is intended to allow Authentication and Authorization to be applied outside of your application code. It's called "Easy Auth". Unfortunately, in the context of App Services it doesn't work with .NET Core and .NET. Perhaps it would be better to say: of the various .NETs, it supports .NET Framework. To quote the docs:

At this time, ASP.NET Core does not currently support populating the current user with the Authentication/Authorization feature. However, some 3rd party, open source middleware components do exist to help fill this gap.

Thanks to Maxime Rouiller there's a way forward here. However, as I was taking this for a spin today, I discovered another issue.

Where are our roles?#

Consider the following .NET controller:

[Authorize(Roles = "Administrator,Reader")]
[HttpGet("api/admin-reader")]
public string GetWithAdminOrReader() =>
"this is a secure endpoint that users with the Administrator or Reader role can access";
[Authorize(Roles = "Administrator")]
[HttpGet("api/admin")]
public string GetWithAdmin() =>
"this is a secure endpoint that users with the Administrator role can access";
[Authorize(Roles = "Reader")]
[HttpGet("api/reader")]
public string GetWithReader() =>
"this is a secure endpoint that users with the Reader role can access";

The three endpoints above restrict access based upon roles. However, even with Maxime's marvellous shim in the mix, authorization doesn't work when deployed to an Azure App Service. Why? Well, it comes down to how roles are mapped to claims.

Let's back up a bit. First of all we've added a dependency to our project:

dotnet add package MaximeRouiller.Azure.AppService.EasyAuth

Next we've updated our Startup.cs``ConfigureServices such that it looks like this:

if (Env.IsDevelopment()) {
services.AddMicrosoftIdentityWebAppAuthentication(Configuration);
else
services.AddAuthentication("EasyAuth").AddEasyAuthAuthentication((o) => { });

With the above in place, either the Microsoft Identity platform will directly be used for authentication, or Maxime's package will be used as the default authentication scheme. The driver for this is Env which is an IHostEnvironment that was injected to the Startup.cs. Running locally, both authentication and authorization will work. However, deployed to an Azure App Service, only authentication will work.

It turns out that directly using the Microsoft Identity platform, we see roles claims coming through like so:

[
// ...
{
"type": "http://schemas.microsoft.com/ws/2008/06/identity/claims/role",
"value": "Administrator"
},
{
"type": "http://schemas.microsoft.com/ws/2008/06/identity/claims/role",
"value": "Reader"
},
// ...
]

But in Azure we see roles claims showing up with a different type:

[
// ...
{
"type": "roles",
"value": "Administrator"
},
{
"type": "roles",
"value": "Reader"
},
// ...
]

This is the crux of the problem; .NET and .NET Core are looking in a different place for roles.

Role up, role up!#

There wasn't an obvious way to make this work with Maxime's package. So we ended up lifting the source code of Maxime's package and tweaking it. Take a look:

using Microsoft.AspNetCore.Authentication;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Options;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Security.Claims;
using System.Text.Encodings.Web;
using System.Text.Json;
using System.Text.Json.Serialization;
using System.Threading.Tasks;
/// <summary>
/// Based on https://github.com/MaximRouiller/MaximeRouiller.Azure.AppService.EasyAuth
/// Essentially EasyAuth only supports .NET Framework: https://docs.microsoft.com/en-us/azure/app-service/app-service-authentication-how-to#access-user-claims
/// This allows us to get support for Authentication and Authorization (using roles) with .NET
/// </summary>
namespace EasyAuth {
public static class EasyAuthAuthenticationBuilderExtensions {
public static AuthenticationBuilder AddEasyAuthAuthentication(
this IServiceCollection services) =>
services.AddAuthentication("EasyAuth").AddEasyAuthAuthenticationScheme(o => { });
public static AuthenticationBuilder AddEasyAuthAuthenticationScheme(
this AuthenticationBuilder builder,
Action<EasyAuthAuthenticationOptions> configure) =>
builder.AddScheme<EasyAuthAuthenticationOptions, EasyAuthAuthenticationHandler>(
"EasyAuth",
"EasyAuth",
configure);
}
public class EasyAuthAuthenticationOptions : AuthenticationSchemeOptions {
public EasyAuthAuthenticationOptions() {
Events = new object();
}
}
public class EasyAuthAuthenticationHandler : AuthenticationHandler<EasyAuthAuthenticationOptions> {
public EasyAuthAuthenticationHandler(
IOptionsMonitor<EasyAuthAuthenticationOptions> options,
ILoggerFactory logger,
UrlEncoder encoder,
ISystemClock clock)
: base(options, logger, encoder, clock) {
}
protected override Task<AuthenticateResult> HandleAuthenticateAsync() {
try {
var easyAuthEnabled = string.Equals(Environment.GetEnvironmentVariable("WEBSITE_AUTH_ENABLED", EnvironmentVariableTarget.Process), "True", StringComparison.InvariantCultureIgnoreCase);
if (!easyAuthEnabled) return Task.FromResult(AuthenticateResult.NoResult());
var easyAuthProvider = Context.Request.Headers["X-MS-CLIENT-PRINCIPAL-IDP"].FirstOrDefault();
var msClientPrincipalEncoded = Context.Request.Headers["X-MS-CLIENT-PRINCIPAL"].FirstOrDefault();
if (string.IsNullOrWhiteSpace(easyAuthProvider) ||
string.IsNullOrWhiteSpace(msClientPrincipalEncoded))
return Task.FromResult(AuthenticateResult.NoResult());
var decodedBytes = Convert.FromBase64String(msClientPrincipalEncoded);
var msClientPrincipalDecoded = System.Text.Encoding.Default.GetString(decodedBytes);
var clientPrincipal = JsonSerializer.Deserialize<MsClientPrincipal>(msClientPrincipalDecoded);
if (clientPrincipal == null) return Task.FromResult(AuthenticateResult.NoResult());
var mappedRolesClaims = clientPrincipal.Claims
.Where(claim => claim.Type == "roles")
.Select(claim => new Claim(ClaimTypes.Role, claim.Value))
.ToList();
var claims = clientPrincipal.Claims.Select(claim => new Claim(claim.Type, claim.Value)).ToList();
claims.AddRange(mappedRolesClaims);
var principal = new ClaimsPrincipal();
principal.AddIdentity(new ClaimsIdentity(claims, clientPrincipal.AuthenticationType, clientPrincipal.NameType, clientPrincipal.RoleType));
var ticket = new AuthenticationTicket(principal, easyAuthProvider);
var success = AuthenticateResult.Success(ticket);
Context.User = principal;
return Task.FromResult(success);
} catch (Exception ex) {
return Task.FromResult(AuthenticateResult.Fail(ex));
}
}
}
public class MsClientPrincipal {
[JsonPropertyName("auth_typ")]
public string? AuthenticationType { get; set; }
[JsonPropertyName("claims")]
public IEnumerable<UserClaim> Claims { get; set; } = Array.Empty<UserClaim>();
[JsonPropertyName("name_typ")]
public string? NameType { get; set; }
[JsonPropertyName("role_typ")]
public string? RoleType { get; set; }
}
public class UserClaim {
[JsonPropertyName("typ")]
public string Type { get; set; } = string.Empty;
[JsonPropertyName("val")]
public string Value { get; set; } = string.Empty;
}
}

There's a number of changes in the above code to Maxime's package. Three changes that are not significant and one that is. First the insignificant changes:

  1. It uses System.Text.Json in place of JSON.NET
  2. It uses C#s nullable reference types
  3. It changes the extension method signature such that instead of entering services.AddAuthentication().AddEasyAuthAuthentication((o) =&gt; { }) we now need only enter services.AddEasyAuthAuthentication()

Now the significant change:

Where the middleware encounters claims in the X-MS-CLIENT-PRINCIPAL header with the Type of "roles" it creates brand new claims for each, with the same Value but with the official Type supplied by ClaimsTypes.Role of "http://schemas.microsoft.com/ws/2008/06/identity/claims/role". The upshot of this, is that when the processed claims are inspected in Azure they now look more like this:

[
// ...
{
"type": "roles",
"value": "Administrator"
},
{
"type": "roles",
"value": "Reader"
},
// ...
{
"type": "http://schemas.microsoft.com/ws/2008/06/identity/claims/role",
"value": "Administrator"
},
{
"type": "http://schemas.microsoft.com/ws/2008/06/identity/claims/role",
"value": "Reader"
}
]

As you can see, we now have both the originally supplied roles as well as roles of the type that .NET and .NET Core expect. Consequently, roles based behaviour starts to work. Thanks to Maxime for his fine work on the initial solution. It would be tremendous if neither the code in this blog post nor Maxime's shim were required. Still, until that glorious day!

Update: Potential ways forward#

When I was tweeting this post, Maxime was good enough to respond and suggest that this may be resolved within Azure itself in future:

Oh, so that's why they removed the name? ๐Ÿ˜ฒ๐Ÿ˜œ Jokes aside, we hope that this package won't be necessary for the future. I know that @mattchenderson is part of a working group to update Easy Auth. Might want to make sure you follow him as well. ๐Ÿ˜

โ€” Maxime Rouiller (@MaximRouiller) January 14, 2021

There's a prospective PR that would add an event to Maxime's API. If something along these lines was merged, then my workaround would no longer be necessary. Follow the PR here.