The art of simplicity

In my previous post I used the allatclaims scope to get all claims in the ID token. That works, but there’s a catch: every claim you add makes the token bigger. With a lot of group memberships, the token grows quickly, and it gets sent along with every request that carries it. The alternative is to keep the ID token small and ask ADFS for the extra claims when you need them. That’s what the userinfo endpoint is for. How does it work? The userinfo endpoint is part of the OpenID Connect standard. Your application sends the access token as a bearer token, and ADFS returns the claims for that user as JSON. In ADFS the endpoint lives here: https://<adfs-server>/adfs/userinfo You can find it in the discovery document as well: https://<adfs-server>/adfs/.well-known/openid-configuration There is one important detail. ADFS treats userinfo as a resource of its own, with the identifier urn:microsoft:userinfo . The access token you send to the endpoint must be issued ...

Recently I ran into a puzzling issue while connecting an application to ADFS using its built-in OpenID Connect support. The login worked fine, the user got authenticated, but the ID token contained almost nothing I needed. No group claims, no custom attributes, just the basics. The claim rules were configured correctly. So where were my claims? Where did my claims go? ADFS keeps a strict separation between the two tokens. The claims you define through the issuance transform rules end up in the access token. The ID token gets a much smaller set by default. If your application reads the ID token to get user information, you have two options: Call the userinfo endpoint with the access token Ask ADFS to copy the access token claims into the ID token This is where the allatclaims scope comes in. What does allatclaims do? When the authorization request includes scope=allatclaims , ADFS customizes the ID token so it includes the claims from the access token, based on ...

Coding agents are good at explaining things. They are also good at explaining them in five verbose paragraphs when a ten-line tree would have done the job. You would almost think that output tokens are free! Recently I came across the show-me skill from HumanLayer . It’s a small skill with one purpose: when you ask your agent to explain something, it answers with a visual representation instead of a wall of text. What does it do? The whole skill is a short set of instructions. It tells the agent to skip the preamble, keep the prose brief and pick the smallest view that makes the point clear. Sounds simple? Because the idea is indeed. For each kind of explanation, the skill names the view to use: Logic or an algorithm → pseudocode Runtime control flow → a call tree UI structure → a component tree, including the state and module boundaries that matter File responsibility or a broad refactor → a shallow file tree Component interaction or data flow → a Me...

In my post yesterday, I showed how to configure rolling and retention so a runaway log file no longer fills your disk. That solves the problem, but it leaves a question open: what if you want to do something with those files before they disappear? Note: This post is a follow-up on Cleaning up old log files with Serilog . Maybe you want to compress the files to save space. Maybe compliance requires you to archive them first. Serilog.Sinks.File has an extension point for this: FileLifecycleHooks . What are FileLifecycleHooks? A lifecycle hook lets you run your own code at specific moments in the life of a log file. You inherit from the abstract class FileLifecycleHooks and override one or both of these methods: OnFileOpened : called when the sink opens a new log file. You receive the underlying stream and can return your own stream that wraps it. OnFileDeleting : called just before a file is deleted by the retention policy. Both have a default implementation that do...

We got an alert from our ops team: the disk of one of our servers was filling up. The culprit was a log file that grew so fast it ate all the available space. The dev team didn't configured any cleanup, so the file just kept growing. The application was already using Serilog . Let's have a look what options we have available to limit the amount of log data. The default config The simplest way to write a log file with Serilog looks like this: Log.Logger = new LoggerConfiguration() .WriteTo.File("logs/log.txt") .CreateLogger(); This works, but it writes everything to one single file. By default, no rolling happens and nothing gets deleted. Remark: This isn’t entirely true. The file sink has a default fileSizeLimitBytes of 1 GB. When the file reaches that limit, Serilog silently stops writing log events. So you don’t fill your disk, but you lose your logs. That’s not much better. Rolling files The first step is to start a new file at regular int...

After deploying a new application to production, we noticed that a lot of extra log messages where written to the EventLog. As we didn't configure the EventLog logging provider in our application, we did not expect this. Turns out that when you create a new ASP.NET Core application with WebApplication.CreateBuilder , you get a set of logging providers activated out-of-the-box. So the question becomes: which providers are enabled, and how do you get rid of the ones you don’t need? Which providers are enabled by default? The default builder registers the following providers: Console Debug EventSource EventLog (Windows only) You can verify this yourself by looking at the registered ILoggerProvider services: var builder = WebApplication.CreateBuilder(args); var app = builder.Build(); var providers = app.Services.GetServices<ILoggerProvider>(); foreach (var provider in providers) { Console.WriteLine(provider.GetType().Name); } On Windows this pr...