Mekansime for å matche authentication scheme for token issuer

[elsand]

Det er ingen smart matching mellom innkommed requests og hvilket authentication scheme som velges, så alle kjøres gjennom til én matcher. Det innebærer at hvis en f.eks. gjør en request med et Altinn-token, og konfigurasjonen WebApi:Authentication:JwtBearerTokenSchemas består av (i denne rekkefølgen) Maskinporten, MaskinportenAuxillary, Altinn vil det kastes to exceptions for de to Maskinporten-schemene som feiler, før det treffer Altinn-schemaet hvor tokenet aksepteres.

På min maskin med release-build og Serilog__MinimumLevel__Default satt til Error måles ca 15% økning i RPS på min PC hvis det treffer på første scheme vs treff på siste scheme. Målt med tests\k6\run.ps1 -ApiEnvironment localdev -ApiVersion v1 -TokenGeneratorUsername *** -TokenGeneratorPassword ** -FilePath tests\k6\tests\serviceowner\dialogSearch.js --vus 10 --duration 30s

Antagelsen er at overheaden kommer av at det kastes exceptions, som er forholdsvis dyrt. Dette vil også potensielt skape støy i application insights (som tracker alt av exceptions).

En potensiell optimalisering her er:

1. Ved startup, eller i en singleton service, konstruerer en map mellom issuers og schemas, noe ala:

Dictionary<string, string> issuerToSchemeMap = new Dictionary<string, string>();

foreach (var schema in jwtTokenSchemas)
{
    var configManager = new ConfigurationManager<OpenIdConnectConfiguration>(
        schema.WellKnown, new OpenIdConnectConfigurationRetriever());
    var config = await configManager.GetConfigurationAsync();
    issuerToSchemeMap[config.Issuer] = schema.Name;
}

2. Introdusere en mellomvare som per request parser token, finner issuer, og lagrer matchet schema i context, noe ala:

public async Task Invoke(HttpContext context)
{
    if (context.Request.Headers.ContainsKey("Authorization"))
    {
        var authHeader = context.Request.Headers["Authorization"].ToString();
        var token = authHeader.Replace("Bearer ", string.Empty);
        var jwtToken = new JwtSecurityTokenHandler().ReadJwtToken(token);
        var issuer = jwtToken.Issuer;

        if (issuerToSchemeMap.TryGetValue(issuer, out var scheme))
        {
            context.Items["CurrentScheme"] = scheme;
        }
    }

    await _next(context);
}

3. Bruke en eventhandler per scheme som sjekker CurrentScheme matcher før den i det hele tatt prøver:

foreach (var schema in jwtTokenSchemas)
{
    authenticationBuilder.AddJwtBearer(schema.Name, options =>
    {
        options.MetadataAddress = schema.WellKnown;
        options.TokenValidationParameters = ....


        options.Events = new JwtBearerEvents
        {
            OnMessageReceived = context =>
            {
                if ((string)context.HttpContext.Items["CurrentScheme"] != schema.Name)
                {
                    context.NoResult(); // Skip the current authentication scheme
                    return Task.CompletedTask;
                }

                // If the scheme matches, it will continue to validate the token for this scheme.
                return Task.CompletedTask;
            }
        };

    });
}

Antagelsen er at dette vil være raskere, siden det ikke vil kastes exceptions. Minuset er at ReadJwtToken alltid må gjøres to ganger, selv om det er treff på første scheme (en gang i mellomvaren og en gang i selve handleren).