DEV Community: Dennis Tretyakov

ID Token validation in dotnet

Dennis Tretyakov — Wed, 24 Aug 2022 11:17:23 +0000

Today I've got a challenge.
On one of the projects I'm working on, by business reasons we don't want users to login user 3rd IDP's.
However, we have a requirement to validate user's identity with BankID via criipto.com
which provides integration via OpenID.

What means that user should authenticate with our authority registered in criipto.com
and pass issued ID-Token to the backend as a proof of identity.
There are many tools that adds OpenID support to dotnet authentication pipeline,
however it took me a while to find tools to specifically validate ID-Token.

If that's what u happened to need, below will be an example, with some explanations after.

TLDR

You'll need IdentityModel.OidcClient.IdentityTokenValidator package.

using System.Net.Http;
using System.Threading.Tasks;
using IdentityModel.Client;
using IdentityModel.OidcClient;
using Xunit;

namespace IdTokenValidation;

public class ValidateTokenExample
{
    // Obviously constant values must be replaced for test to pass

    const string Authority = "AUTHORITY";
    const string ClientId = "CLIENT-ID";

    const string IdToken = "ID-TOKEN";

    [Fact]
    public async Task Validate()
    {
        // GetDiscoveryDocumentAsync extension comes from IdentityModel.OidcClient namespace
        // from IdentityModel.OidcClient package.
        DiscoveryDocumentResponse? doc = await new HttpClient().GetDiscoveryDocumentAsync(Authority);
        Assert.False(doc!.IsError);

        var validator = new JwtHandlerIdentityTokenValidator();
        var options = new OidcClientOptions
        {
            ClientId = ClientId,
            ProviderInformation = new ProviderInformation
            {
                IssuerName = doc.Issuer,
                KeySet = doc.KeySet
            }
        };

        IdentityTokenValidationResult? result = await validator.ValidateAsync(IdToken, options);

        Assert.False(result.IsError);
    }
}

Just a small note here: normally you would cache discovery documents, here it's not done for the sake of simplicity.

Caveats

Even tho ValidateAsync method has async signature,
I was assuming giving it an authority in OidcClientOptions would be enough.
I assumed it will fetch discovery document and will take a key from there.
Unfortunately, despite async signature it doesn't do so.
It performs synchronous validation based on data passed in,
therefore you need to fetch document yourself like and pass KeySet in to provider information,
like on the example above.

Endpoint is on a different host than authority

By default GetDiscoveryDocumentAsync doesn't allow discovery document segments from domains that are not matching authority.
For example in case of google (Authority: https://accounts.google.com/)
opening discovery document root https://accounts.google.com/.well-known/openid-configuration you may see that some endpoints
have different domains. Like token_endpoint will be at https://oauth2.googleapis.com/token and jwks_uri will be at https://www.googleapis.com/oauth2/v3/certs

Therefore, there is an overload for GetDiscoveryDocumentAsync where you can specify validation policy,
and either whitelist allowed domains either disable endpoint validation at all, like on the examples below.

using System.Net.Http;
using System.Threading.Tasks;
using IdentityModel.Client;
using Xunit;

namespace IdTokenValidation;

public class FetchGoogleDocumentExample
{
    [Fact]
    public async Task UsingWhitelist()
    {
        var opt = new DiscoveryDocumentRequest
        {
            Address = "https://accounts.google.com/",
            Policy =
            {
                AdditionalEndpointBaseAddresses =
                {
                    "https://oauth2.googleapis.com/",
                    "https://www.googleapis.com/",
                    "https://openidconnect.googleapis.com/"
                }
            }
        };

        DiscoveryDocumentResponse? doc = await new HttpClient().GetDiscoveryDocumentAsync(opt);
        Assert.False(doc!.IsError);
    }

    [Fact]
    public async Task WithEndpointValidationDisabled()
    {
        var opt = new DiscoveryDocumentRequest
        {
            Address = "https://accounts.google.com/",
            Policy =
            {
                 ValidateEndpoints = false
            }
        };
        var http = new HttpClient();

        DiscoveryDocumentResponse? doc = await http.GetDiscoveryDocumentAsync(opt);
        Assert.False(doc!.IsError);
    }
}

In case of issues, you might want check example repository at https://github.com/tretyakov-d/playground-id-token-validation.

I hope it helped

A cleaner way for configuring DI container in dotnet with ServiceAnnotations

Dennis Tretyakov — Thu, 28 Jan 2021 18:56:45 +0000

DI is great, but managing the registry of dependencies might be not.
With project growing it becomes harder and harder to maintain DI registry.

Maintaining the registry manually is not just a pain in the ass:

it's a continuous time waste
it's a popular source of bugs
it's a great demotivator to create new small classes, but use the "I'll just stick it here" approach instead

The module approach -- in any form, whether it's framework-specific modules like Autofac.Module,
either using static methods like Microsoft's extension approach (eg. AddLogging, AddMvc),
doesn't solve the problem.
It's an attempt to hide the problem, by giving an illusionary structure, at the same time all the problems remain,
In addition to that we are getting logical conflicts with shared components.
In the end, the only benefit of "modularity"
-- is that it helps to build a bigger heap of code that requires continuous manual care.

Don't get me wrong here. There is nothing wrong with the modular approach for distributing cross-cutting components,
like the same logging or MVC mentioned above.
I'm talking specifically about services within a single application.

There is another popular approach -- "conventional".
In case you are not familiar with it -- it means scanning an assembly using reflection
and programmatically registering services based on naming conventions.

That solves the manual part - that's true, however:

it's not flexible enough.

Yes, typically it does cover, a significant percent of registrations,
but it leaves out lots of details, and as know "the devil hides in details"
the enforced naming pattern harms semantics, or will if it doesn't seem like that in the beginning
the convention's still something that must be continuously manually taken care of

Service Annotations

This is an approach I've come up with several years ago and it has proven itself on a variety of projects.
Finally, I’ve packed it and published it on Github and NuGet.
It has quite a minimalistic API, but sufficient to solve all the problems mentioned above.
It is designed for IServiceCollection so every modern IoC framework supports it.

It is based on assembly scanning but uses attributes not naming conventions and code to handle special cases.

Service Attribute

In a typical project, the attribute handles most of the registrations.
On a class level, you define how it should be registered.
It is required to specify a lifetime.
And optionally you can specify as what type the class should be registered, defaults to itself if not specified.

examples of Service attribute usage:

[Service(ServiceLifetime.Transient)]
public class MyService: IMyService { }

// will be registered with Transient lifetime
// will be registered as MyService
// equivalent to: services.AddTransient<MyService>();

[Service(ServiceLifetime.Singleton, typeof(IMySerivce))]
public class MyService: IMyService {}

// will be registered with Singleton lifetime
// will be registered as IMyService
// equivalent to: services.AddSingleton<IMySerivce, MyService>();

[Service(ServiceLifetime.Scoped, typeof(MyService), typeof(IMySerivce))]
public class MyService: IMyService { }

// will be registered with Scoped lifetime
// will be registered as MyService and as IMyService
// equivalent to: services.AddScoped<MyService>()
//    .AddScoped<IMySerivce>(serviceProvider => serviceProvider.GetService<MyService>());

ConfigureServices Attribute

So far we have seen the static part, but there is always a set of services that require custom resolvers,
or even access to configuration or some context data.
Therefore there is a ConfigureServices attribute.
The attributes invoke a specified static method
passing IServiceCollection instance to the method as a parameter.
Looks for a method named "ConfigureServices" if not other name is specified.

an example of ConfigureServices attribute usage:

[Service(ServiceLifetime.Transient), ConfigureServices(nameof(RegisterHttpClient))]
public class MyService {
  readonly HttpClient _httpContext;

  public MyService(HttpClient httpContext) => _httpClient = httpClient;

  static void RegisterHttpClient(IServiceCollection serviceCollection, IConfiguration configuration) {
    serviceCollection.AddHttpClient<MyService>(httpClient => {
      httpClient.BaseAddress = new Uri(configuration.GetConnectionString("myServiceEndpoint"));
    });
  }
}

// the Service attribute
// will be register service with Transient lifetime
// will be register service as MyService

// the ConfigureService attribute
// will invoke RegisterHttpClient method

ConfigureServices attribute could as well be used without Service attribute.
It can be applied to any class, the only requirements are:

that method (referred by that attribute) must be static and without overloads.
objects specified as parameters to be passed to a scanning context. (see Setup and configuration right below)

Setup and configuration

First, install NuGet package

dotnet add package ServiceAnnotations

Importing ServiceAnnotations namespace will add an extensions method AddAnnotatedServices to a IServiceCollection interface. Which has two parameters, both are optional.

An assembly to scan. Defaults to calling assembly, so typically don't need to be specified.
Action to configure scan context,
where we can pass objects that would be available
as parameters for ConfigureServices attribute referred methods.
Like in the example above where were using IConfiguration as a parameter to get a BaseAddress for an HttpClient.

You don't need to explicitly add IServiceCollection, it will be available by default

...
using ServiceAnnotations;

public class Startup {
  readonly IConfiguration _configuration;

  public Startup(IConfiguration configuration) => _configuration = configuration;

  public void ConfigureServices(IServiceCollection services) {
    services.AddAnnotatedServices(context =>
      context.Add<IConfiguration>(_configuration));
  }

  ...
}

ps

I hope it will help you to keep your code cleaners.

Don't hesitate to open issues and contribute on Github.

Setting up MSDeploy for CI/CD deployments to IIS

Dennis Tretyakov — Mon, 18 Jan 2021 21:18:44 +0000

Just a few months ago I was 100% sure I’ll never hear about Windows Server ever again, but not everyone is on Kubernetes or even dotnet core yet, so if you are as lucky as me, and have to setup deployment to the IIS server in 3rd decade of 21st century, here are the detailed instructions how to do it.

First Let me first clarify something. There is a product name called Web Deploy which provides 2 main components:

Command-line tool MSDeploy.exe what we use, to make a deployment to an IIS server.
A service that must be installed on a server running IIS, where we want to make deployments to.

Just a few tips in advance

You will need a user account with Admin privileges to perform deployment
You will need to install IIS Management Service
You will need to install Microsoft Web Deploy to the server
You will need NO restarts, quite a surprise for Windows 😁

Install IIS Management Service

Run (Win + R) -> appwiz.cpl
Click "Turn Windows features on or off"
On "Add Roles and Features Wizard" proceed to "Server Roles" (on non-server versions of windows you'll be taken to the same screen immediately)
Select "Management service"
Proceed to confirmation and press install (appears instead of Next button)

Step by step screenshots

Install Microsoft Web Deploy

This is a tool that should be installed on both the server (the machine running IIS) and the client (the machine making a deployment).

Getting it is is a bit tricky though. There are two actual versions of web deploy.

The latest version Microsoft offers to download via Download Center is Web Deploy 3.6 (which one is obsolete)
Visual Studio 2017+ comes with Web Deploy 4
As it doesn't make sense to install Visual Studio on production servers, as I found on the MS Developer Community forum
you can download a stand-alone .msi for Web Deploy 4 from https://download.visualstudio.microsoft.com/download/pr/e1828da1-907a-46fe-a3cf-f3b9ea1c485c/035860f3c0d2bab0458e634685648385/webdeploy_amd64_en-us.msi
if the link is broken, there is a backup copy on my OneDrive https://1drv.ms/u/s!Au6taQChFyJmge1TOscBDl0V2FMsJQ
c

The versions are not compatible. In other words, you cannot use Web Deploy 4 to deploy to the server with Web Deploy 3.6

Yet another important detail is that the "Typical" installation of MS Deploy doesn't include the server components.
Therefore installing MS Deploy choose either Complete install either Custom and ensure all the components will be installed.

Step by step screenshots

Things to verify

Windows services should be up and running

Open Services Manager. Run (Win + R) services.msc
Locate "Web Deployment Agent Service" and ensure it's started. (this is MSDeploy)
Locate "Web Management Service" and ensure it's started.

Step by step screenshots

Management service should be present in IIS configuration.

You might also want to adjust some settings

Open IIS Manager. Run (Win + R) inetmgr
Locate "Management Service" in the Management section of the Server Features view

If you want to change the settings you'll need to stop the service using the stop button on the right panel.
The interface might seem a bit confusing, but feel free to do so, it stops only the management service itself, not the IIS.

Step by step screenshots

The port should be open

As you could see on Management Service screen in IIS settings, by default it listens to port 8172.
The installer also opens the port in Firewall settings for all IP addresses.

Open Windows Defender Firewall with Advanced Security. Run (Win + R) wf.msc
Locate "Web Management Service (HTTP Traffic-In)" rule

Step by step screenshots

Pack and deploy legacy asp.net app to IIS

That deploy part is way easier or at least doesn't require clicks.

To make a package with msbuild

$proejctPath = '.\MyProject.csproj'

msbuild $projectPath `
  /p:OutDir=.\dist\ `
  /p:Configuration=Release `
  /p:GenerateSerializationAssemblies=False `
  /p:DeployOnBuild=true `
  /p:WebPublishMethod=Package `
  /p:PackageAsSingleFile=true `
  /p:IncludeSetAclProviderOnDestination=False `
  /p:AutoParameterizationWebConfigConnectionStrings=false

To deploy using msdeploy


$package = '.\dist\_PublishedWebsites\MyProject_Package\MyProject.zip'
$username = ''
$password = ''
$serverIpOrHostname = '127.0.0.1'
$msDeployPort = '8172'
$endpoint = "https://${serverIpOrHostname}:${msDeployPort}/MSDeploy.axd"
$iisWebsiteName = 'My Website'

# with -whatIf flag provided, msdeploy just shows what's gonna happen without
# remove the line with -whatIf flag to make real deployment
msdeploy -source:package=$package `
     -whatIf `
     -verb:sync `
     -allowUntrusted `
     -dest:auto,ComputerName=`"$endpoint`",UserName=`"$username`",Password=`"$password`",IncludeAcls=False,AuthType=Basic `
     -setParam:name=`"IIS Web Application Name`",value=`"$iisWebsiteName`" `
     -disableLink:AppPoolExtension `
     -disableLink:ContentExtension `
     -disableLink:CertificateExtension

where is msdeploy.exe

Typically it's: C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe and yet, no matter how rediculous it is, the Web Deploy 4 is going to be in the same directory :)

where is msbuild.exe

With visual studio installed it should be in C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\MSBuild.exe
Obviously the version number and edition might differ.

However you don't have to have to install Visual Studio, to have MSBuild on a build agent.
You can download and install Build Tools for Visual Studio 2019.

https://dennistretyakov.com/setting-up-msdeploy-for-ci-cd-deployments-to-iis#install-iis-management-service

One instance for various service types in Microsoft Extensions DI

Dennis Tretyakov — Mon, 13 Jul 2020 04:22:20 +0000

Recently moving away from Autofac to Microsoft Extensions DI I've faced a problem
that there is no API to register one service implementation instance (singleton, scoped) for various service types.

Autofac behaviour

[Fact]
public void Autofac_ReturnsSameInstance()
{
    var contaienrBuilder = new ContainerBuilder();
    contaienrBuilder.RegisterType<Service>()
        .AsSelf()
        .AsImplementedInterfaces()
        .SingleInstance();

    var container = contaienrBuilder.Build();

    var byInterface = container.Resolve<IService>();
    var byExactType = container.Resolve<Service>();

    Assert.Same(byInterface, byExactType);
}

Microsoft DI behaviour

[Fact]
public void DI_ReturnsDifferentInstances()
{
    var serviceProvider = new ServiceCollection()
        .AddSingleton<Service>()
        .AddSingleton<IService, Service>()
        .BuildServiceProvider();

    var byInterface = serviceProvider.GetRequiredService<IService>();
    var byExactType = serviceProvider.GetRequiredService<Service>();

    Assert.NotSame(byInterface, byExactType);
}

Achieving similar behaviour on Microsoft DI

Autofac allows multiple keys for the same implementation.
Microsoft DI is one to one map.
To achieve the same behaviour choose the type you will use as the primary key (Service in the example below).
For all other types (like IService in the example below) register resolvers that would resolve a service using primary key.

[Fact]
public void DI_ReturnsSameInstace_LikeAutofac()
{
    var serviceProvider = new ServiceCollection()
        .AddSingleton<Service>()
        .AddSingleton<IService>(sp => sp.GetRequiredService<Service>())
        .BuildServiceProvider();

    var byInterface = serviceProvider.GetRequiredService<IService>();
    var byExactType = serviceProvider.GetRequiredService<Service>();

    Assert.Same(byInterface, byExactType);
}

Code on GitHub.

My long and rocky road to TDD

Dennis Tretyakov — Wed, 27 May 2020 07:18:59 +0000

Internet is full of odes to TDD
competing over a longer list of benefits and providing basic examples, like how to test a Sum function of a Calc class.

Despite all of that the entry barrier for TDD is very high, at least for strongly typed languages like C#
where the compiler and good code-completion tools can provide a certain level of illusionary confidence of working software.

I switched to TDD about six years ago.
And here are the biggest struggles I've had,
when I just started
and I've had them for quite a long time.

The upside down

One of the most advertised perks of TDD is "better interfaces"
that is achieved by "first you use, then implement" approach.
Well, at least for me, it didn't work out as easy as it sounds.

The way I used to work before TDD, was to start each feature with deep and detailed analysis.
I'd try to compile a "big picture" in my head, typically with the help of a pen and paper.
I'd try to plan which components I'd reuse and which ones I'd need to create.

In the beginning, I haven't seen the contradiction with "first you use, then implement" in that,
so I'd start each new feature following the "big picture" approach,
which typically would be followed by one of two scenarios:

I'd start working on lower-level components (like repository) responsibly writing tests first, as the approach requires (pretending that I'm using that).
When the lower level was done, I'd go one level higher and would do the same until I'd reach the top.
I'd start implementing from the top, but still using the model I've planed imagining the "big picture".

Neither works! There was no effect, it was awkward, clumsy, and slow.
It would cost me lots of time and patience polishing and rewriting the tests again and again until some reasonable level of simplicity and more or less clear semantics were reached,
but even then, in certain cases, changing that wouldn't be an easy task.

Things changed a lot, when I've tried to give up the "big picture" approach an go the "dumb" way.

By that I mean — starting with the entry point of a use case and not stepping out of it,
defining dependency interfaces the way I need them here and now to make my test easy first.
And only after the test is done,
I'd go to implement the dependencies or eventually replace the exact matches with the existing ones.

Obviously the "big picture" part is still necessary,
but it should take place only after the feature is implemented in the simplest way possible!
Only then it's a time to revise the components and refactor the code to extract code duplications in separate components,
apply certain optimizations and etc.

So the proper name for the approach I called "dumb" should be an "iterative" or simply "agile".
This approach actually embraces the natural evolution of code and leads to TDD promised "better interfaces" and some other practical perks like:

As there is no need to change existing code, the features are being implemented faster and safer.
The post-factum emerged design solutions are better in a way as they put emphasis on use cases and their specifics, whereas thought ahead design emphasizes the common part and hides specifics.
Since the revision/refactoring can be done separately, apart from the KISS version, the efforts can be measured separately as well.

That's not cool

Technically the approach described above killed all the fun, or at least that's how I felt at the beginning.

Before switching to an "iterative" process (the one mentioned above), which was kinda forced by TDD,
one of the coolest parts of development was planning ahead.
Having lots of discussions with the dev team and business about long and short term plans,
especially with new projects (so-called green fields),
putting together all the knowledge, all speculations, all previous experience to design a perfect foundation... this time.

That felt like an extremely important and valuable thing to do.
The only thing that might have felt even better was occasionally stating:
"ah, that's already done!", "that will work out of the box", "that won't take much time, we thought it through back then (might be even years ago)"
while discussing new features and obviously getting credit for that.

Well, all of that was gone! No thinking ahead, no perfect solutions, no more feeling of self-importance — not cool at all.
Even more, sometimes it felt extremely "hacky", like knowing that I could do more, care more, but I didn't... It felt like something very unprofessional.

On top of that,
as planing ahead was gone, my very deep language knowledge (C# at that moment) had become almost useless, since there was no area to apply it.

In a while the pragmatism started paying back:

Refactoring test-driven code is way "easier" or in other words — faster and safer.
In comparison with speculative planning,
revising existing architecture allows to define exact and very granular goals with quite precise estimates.
This is also the point where deep language and framework knowledge kicks in, but in this case — to solve real problems.
In addition to more accurate estimates and metrics, as there are less ups and downs, the estimates become also more predictable for business
which adds more trust in the relationship between business and developers.

In the end, with TDD I've started spending much more time on application architecture than ever before
without having any doubts from the business side.

The personal doubts went away as well, as solving real problems in a short time feels and is
way more professional than wasting time on solving speculated problems no matter how realistic they might seem at the moment.

Am I doing it right?

The deeper I was going to TDD the more granular my code was becoming.
More classes, smaller classes, tons of classes with one public function.
All test-driven, therefore well tested, BUT will it work?
Yet again and again I didn't have confidence in that and had to retest it manually.
That was also adding more to the doubt pile about the value of so much time invested in tests.

Until one day it hit me! I don't need to do it manually.
For whatever I doubt, whatever I have to retest — I should write a test.
The fun part — sometimes it might be quite challenging to achieve.

For example, with .net core MVC application, having doubts if the app will start successfully I can write a test for it.
I might have forgotten to register one of the pipeline components for a feature I was working on — I can write a test to check that all controllers can be resolved.

The same applies to work with framework and other 3rd party components.
Whenever there are doubts about how exactly it behaves or there is uncertainty about behavior in future versions — just test it.

Some may argue these are not unit tests and this is not TDD.
I'm not going to debate the semantics.
The fact is — it works and it's efficient.
It allows to move on, being confident that the code is working.
The TDD doesn't prevent you from automating manual tests.
The one thing remains though, for TDD to go on, the tests should be fast.

The takeaways

There is no perfect design to be applied to any project.
The TDD embraces SOLID principles and allows refactoring on cheap.
Continuous refactoring is the way to keep the project architecture clean, to embrace the use cases and specifics.
Thinking ahead gives a very nice feeling of importance, but it comes with a huge price.
It makes testing and maintenance complicated (i.e. costly)
as well as emphasizes obviously common things and hides the import specifics of an application use cases.
The main purpose of testing is confidence in working software.
Whatever is doubted should be tested.

Would you ever go back to Angular from React?

Dennis Tretyakov — Sun, 26 Apr 2020 23:56:28 +0000

I'm not trying to start a holy war!
I can remember a few years ago while having only theoretical knowledge on React, I had lots of discussions about the pros and cons of React vs Angular2.
Now after using React for about 2 years, I can't imagine any reason ever to use Anguar2. Unfortunately, occasionally I have to and it's a pain.

So, what I'm trying to find out, did I've got too obsessed with React? or it's really that much superior over Angular (and I assume others too, except preact)