Axel Heer

Exclusive CA trust with Kestrel

Möchte man neben Server-Zertifikaten auch Client-Zertifikate einsetzen, so wird einem bei Kestrel genauso geholfen. Wie von anderen Webservern gewohnt, können diese akzeptiert oder sogar verlangt werden. Kestrel führt dabei gleich eine Validierung mit Bordmitteln durch, um sicher zu stellen, dass sich die Anwendung nicht um jeden Mist kümmern muss bzw. diesen mangels entsprechender Voraussicht sogar akzeptiert.

Jedoch genügt es oft nicht, dass ein Client-Zertifikat grundsätzlich gültig ist. Ein gültiges Zertifikat ist ja nicht so schwer zu bekommen (hier Seitenhieb einbauen), die Anwendung vertraut vielleicht nur einem ganz bestimmten Zertifikat-Issuer, was sich aus dem Root-Zertifikat oder einer Zwischenstelle der Zertifikatskette ableiten lässt. Beispielsweise wird ein zusätzlicher Token übermittelt, der nur gelesen wird, sollte die Verbindung von einem vertrauenswürdigen Client aufgebaut worden sein. Oder es werden Felder aus dem Zertifikat für eine Authentifizierung bzw. Autorisierung herangezogen, welche genauso gut anderswo zu bekommen wären…

Früher noch, zumindest unter Windows, wurden eigene Zertifkat-Stores definiert, die eben jene besonders vertrauenswürdigen Issuer beinhalten sollen. Und das nur, um die SChannel-Geschichte mit dem passenden ClientAuthTrustMode zu konfigurieren, um dann mittels netsh die entsprechenden „SSL-Bindings“ zu erstellen, welche schlussendlich von z.B. einem IIS verwendet werden konnten. Das war natürlich viel einfacher als die CTLs davor (hier zweiten Seitenhieb einbauen). Wenn man schließlich alles richtig gemacht hat, wurde nur mehr den „richtigen“ Zertifikaten vertraut. Wenn nicht, dann eben auch anderen oder sogar gar keinen.

Zurück zu Kestrel: ist ein Client-Zertifikat gewünscht und sollte in der Zertifikat-Kette ein bestimmter Issuer vorkommen, so lässt sich ein einfacher Mechanismus mittels ConfigureHttpsDefaults für alle https Verbindungen konfigurieren.

public static IWebHostBuilder UseClientAuthIssuer(this IWebHostBuilder builder)
{
    if (builder == null)
        throw new ArgumentNullException(nameof(builder));

    return builder.ConfigureServices((context, services) =>
    {
        var exclusive = BuildExclusiveTrust("ClientAuthIssuer");

        services.Configure<KestrelServerOptions>(options =>
        {
            options.ConfigureHttpsDefaults(defaults =>
            {
                defaults.ClientCertificateMode = ClientCertificateMode.RequireCertificate;
                defaults.ClientCertificateValidation = (client, chain, errors) =>
                    errors == SslPolicyErrors.None && exclusive(chain);
            });
        });
    });
}

Achtung: im Gegensatz zu anderen Webservern ist eine gewöhnliche http Verbindung damit noch nicht untersagt! Darum muss man sich separat kümmern! (weiterleiten, gar nicht erst zulassen, …)

Wir verlangen lediglich, dass die „Kette“ einwandfrei ist und fügen ein zusätzliches „Trust-Kriterium“ hinzu.

private static Func<X509Chain, bool> BuildExclusiveTrust(string storeName)
{
    X509Certificate2[] trust;

    using (var store = new X509Store(storeName, StoreLocation.LocalMachine))
    {
        store.Open(OpenFlags.ReadOnly);

        trust = store.Certificates.Cast<X509Certificate2>().ToArray();

        store.Close();
    }

    return chain => chain.ChainElements.Cast<X509ChainElement>().Select(e => e.Certificate).Intersect(trust).Any();
}

Wie genau dieses Kriterium auszusehen hat, ist hier natürlich flexibler als die fixen ClientAuthTrustMode Varianten.

2018-07-29

• #Development
• #MVC
• #IIS
• #CSharp
• #Security

Central Certificates with Kestrel

Um nicht bei jeder Website bzw. bei jeder Instanz eines Webservers der Website ein Server-Zertifikat für https einspielen zu müssen, bietet der IIS bereits seit längerer Zeit (Version 8.0) den sogenannten Central Certificate Store (kurz CCS). Man legt einfach alle Zertifikate auf einem File-Share ab und der IIS schnappt sich automatisch das Richtige, das Einhalten einer gewissen Namenskonvention vorausgesetzt. Einzige Einschränkung: alle Zertifikate müssen mit demselben Passwort geschützt werden, was bei Verwendung eines gewöhnlichen Zertifikat-Stores unter Windows im Prinzip nicht anders ist.

Wird nun bei einer .NET Core Anwendung auf den IIS verzichtet, um Kestrel mehr oder weniger direkt zu verwenden (Stichwort: Container), so musste bis zur aktuellen Version 2.1. die Konfiguration des https Endpunkts komplett im Code mittels UseHttps erfolgen. Bis vor Kurzem wurde auch empfohlen Kestrel nur innerhalb eines „richtigen“ Webservers zu betreiben, weswegen das sowieso kein sonderlich spannendes Thema war. Wie auch immer, in der Version 2.1. ist eine https Konfiguration über die bereits sehr flexiblen .NET Core Mechanismen wie z.B. appsettings.json möglich, und diese wollen wir analog CCS nutzen!

Nachteil: für jede Anwendung muss entweder explizit auf einen Zertifikat-Store verwiesen werden, was den „pre-CCS“ Zeiten entspricht, oder der Pfad zu einem .pfx-File inkl. Passwort im Klartext angegeben werden, was auch zu einer sehr verstreuten Geschichte führt. Das muss besser gehen.

Überlegung: sollten wir den Hostnamen der Anwendung bereits vorab wissen (ev. aufgrund einer kanonischen Schreibweise), so können die CCS Konventionen direkt beim Start angewendet werden, um das passende Zertifikat zu finden. Das Passwort könnte auch über einen hübscheren Mechanismus (z.B. Docker Secrets) geladen werden, was sicher auch keine schlechte Idee sein sollte. Mit den beiden Informationen in der Hand lässt sich Kestrel über simple .NET Core Mechanismen konfigurieren und alles wird gut.

public static IWebHostBuilder UseCentralCertificateStore(this IWebHostBuilder builder)
{
    if (builder == null)
        throw new ArgumentNullException(nameof(builder));

    return builder.ConfigureServices((context, services) =>
    {
        var certs = context.Configuration["Whatever:CertsPath"];
        var host = context.Configuration["Whatever:CanonicalHost"];

        if (!string.IsNullOrEmpty(certs) && !string.IsNullOrEmpty(host))
        {
            var fileName = SelectFile(certs, host);
            var password = LoadPassword(context.Configuration);

            services.Configure<KestrelServerOptions>(options =>
            {
                var settings = new Dictionary<string, string>()
                {
                    ["Certificates:Default:Path"] = fileName,
                    ["Certificates:Default:Password"] = password
                };

                var configuration = new ConfigurationBuilder()
                    .AddInMemoryCollection(settings)
                    .Build();

                options.Configure(configuration);
            });
        }
    });
}

Die KestrelServerOptions haben praktischerweise eine Methode Configure, um eine zusätzliche Konfiguration durchzuführen.

Zum Vergleich: der CCS sucht zuerst nach einer .pfx-Datei mit dem Hostnamen. Sollte diese nicht existieren, wird damit begonnen den ersten Teil durch ein „_“ zu ersetzen. Also „mein.eigener.host.io.pfx“, dann „_.eigener.host.io.pfx“, dann „_.host.io.pfx“, und so weiter. Sollte er nicht fündig werden, passieren schlimme Dinge. Das können wir auch.

private static string SelectFile(string certs, string host)
{
    foreach (var fileName in FileNames(host))
    {
        var path = Path.Combine(certs, fileName + ".pfx");

        if (File.Exists(path))
        {
            return path;
        }
    }

    throw new InvalidOperationException($"No certificate for '{host}' found at '{certs}'.");
}

private static IEnumerable<string> FileNames(string host)
{
    yield return host;

    var index = host.IndexOf('.');

    while (index > 0)
    {
        yield return "_" + host.Substring(index);

        index = host.IndexOf('.', index + 1);
    }
}

Fehlt nur noch das Passwort: dieses wurde im CCS hinterlegt und von diesem vermutlich irgendwie sicher abgelegt, was wir von einem Passwort in einem .json-File nicht wirklich behaupten können. Docker beispielsweise hängt dazu ein eigenes File in den laufenden Container, aber wir können uns natürlich alle Optionen offen halten. Zumindest zwei weitere.

private static string LoadPassword(IConfiguration configuration)
{
    var password = configuration["CERTS_PASSWORD"];

    if (!string.IsNullOrEmpty(password))
    {
        return password;
    }

    var path = configuration["CERTS_PASSWORD_PATH"]
        ?? Environment.ExpandEnvironmentVariables(@"%ProgramData%\Docker\secrets\certs_password");

    if (File.Exists(path))
    {
        return File.ReadLines(path).First();
    }

    throw new InvalidOperationException($"No certificate secret found at '{path}'.");
}

Sollte sogar mehr als ein Hostname pro Anwendung notwendig sein, so lässt sich das mittels ServerCertificateSelector (auch seit Version 2.1) weiter spinnen.

2018-07-15

• #Development
• #MVC
• #IIS
• #CSharp
• #Security

Handy-Signatur with ASP.NET Core using OpenID Connect

Steht man vor der Herausforderung, ein eher proprietäres Mittel zur Authentifikation – nämlich die österreichische Handy-Signatur – für eine Anwendung einzubinden, die mit einem relativ jungen und somit vermeintlich modernen Framework wie ASP.NET Core geschrieben wird, so halten sich die Aussichten auf Erfolg einmal in Grenzen. Stichwort: Erfolgssteigerung durch Erwartungsreduktion. Zwischen diesen beiden Welten wird es wohl kaum eine gemeinsame Schnittmenge geben, oder? Und es gibt sie doch: OpenID Connect. :tada:

Während mittlerweile in Bezug auf Authentifizierung sowie Autorisierung „eh fast alles“ auf OAuth aufzubauen scheint – sogar OpenID mit ihrer „Connect“ Variante – dürften derartig standardisierte Mechanismen auch vom E-Government Innovation Center implementiert und demonstriert werden. Das trifft sich natürlich ausgezeichnet, schließlich bietet ASP.NET Core zahlreiche Möglichkeiten externe Dienste einzubinden, die in der Regel auf genau diese Techniken setzen. Neben sehr spezifischen Implementierungen für z.B. Twitter stellt ASP.NET eine allgemeine OpenID Connect Middleware zur Verfügung, die im Folgenden für eine Anbindung der Handy-Signatur verwendet werden soll.

Die schlechte Nachricht zuerst: ein OpenID Connect Discovery wird nicht unterstützt. Damit wären gerade einmal zwei oder drei Parameter – Authority sowie ClientID und ev. ein Secret – notwendig und es würde einfach so funktionieren. Um diese „Experience“ auszuprobieren, kann beispielsweise ein Azure AD herangezogen werden…

Und die gute Nachricht: wir können die Middleware händisch nach Dokumentation konfigurieren – die Discovery ist „nur“ ein optionaler Teil der Spezifikation. Wieso also Aufwand in ein Service stecken, wenn man diesen den Clients aufbürden kann?

1. Das Zertifikat für die Validierung der ausgestellten Tokens ist zwingend (!) notwendig

    var issuerSigningCert = new X509Certificate2("...");
   

2. Die obligatorischen Parameter ID + Secret (wären auch bei einer Discovery anzugeben)

    var options = new OpenIdConnectOptions
    {
        ClientId = "...",
        ClientSecret = "...",
   
        /* ... */
    }
   

3. Endpunkte für AuthCode- sowie AccessToken-Requests

    {
        /* ... */
   
        Configuration = new OpenIdConnectConfiguration
        {
            AuthorizationEndpoint = "...",
            TokenEndpoint = "..."
        },
   
        /* ... */
    }
   

4. Mode sowie Type weicht von den .NET Core Defaults ab

    {
        /* ... */
   
        ResponseMode = OpenIdConnectResponseMode.Query,
        ResponseType = OpenIdConnectResponseType.Code,
   
        /* ... */
    }
   

5. Nonce Artifakte werden (noch?) nicht unterstützt (siehe Doku)

    {
        /* ... */
   
        ProtocolValidator = new OpenIdConnectProtocolValidator
        {
            RequireNonce = false,
            RequireStateValidation = false
        },
   
        /* ... */
    }
   

6. Die ausgestellten Tokens wollen unbedingt validiert werden

    {
        /* ... */
   
        TokenValidationParameters = new TokenValidationParameters
        {
            IssuerSigningKey = new X509SecurityKey(issuerSigningCert)
            {
                KeyId = "..."
            },
            ValidIssuer = "..."
        },
   
        /* ... */
    }
   

7. Zu guter Letzt können Fehler abgefangen werden (optional)

    {
        /* ... */
   
        Events = new OpenIdConnectEvents
        {
            OnMessageReceived = context =>
            {
                if (!string.IsNullOrWhiteSpace(context.ProtocolMessage.Error))
                {
                    var remoteError = WebUtility.UrlEncode(context.ProtocolMessage.ErrorDescription);
                    context.Response.Redirect("/error?remoteError=" + remoteError);
                    context.HandleResponse();
                }
   
                return Task.CompletedTask;
            }
        }
    }
   

Unter der Annahme alles richtig konfiguriert zu haben, kann schlussendlich die OpenID Connect Middleware analog zu allen anderen registriert werden; jedenfalls vor MVC oder ähnlichem. Ansonsten würde die Authentifizierung nach dem Aufruf der eigentlichen Anwendung stattfinden, was nicht funktionieren kann…

public void Configure(IApplicationBuilder app)
{
    /* ... */

    app.UseOpenIdConnectAuthentication(options);

    app.UseMvc();
}

Und die beste Nachricht: das harmoniert mit ASP.NET Identity & Co.

2017-07-15

• #Development
• #MVC
• #CSharp
• #Security

Canonical host names with ASP.NET Core

Seit Version 1.1 bietet ASP.NET Core eine URL Rewriting Middleware, um unabhängig vom eingesetzten Webserver – und vielleicht ein wenig komfortabler – Regeln zu definieren, die ein Umschreiben eingehender URLs bewirken sollen. Das kann sinnvoll sein, um legacy Adressen weiter zu unterstützen, ein wenig SEO zu betreiben, oder einfach nur HTTPS freundlich aber doch zu erzwingen.

Nachdem es sich um eine gewöhnliche .NET Core Komponente handelt, lassen sich Regeln nicht nur in „spezieller“ IIS- oder Apache-Syntax formulieren, sondern auch (!) direkt mittels C# implementieren und einbinden; oder einer anderen .NET tauglichen Sprache, versteht sich. Eine oft übliche Regel, nämlich die Normalisierung des Host Names, kann so relativ simpel umgesetzt werden: es ist lediglich das Interface IRule anzuwenden.

public class CanonicalHostRule : IRule
{
    public HostString Host { get; set; }

    public int StatusCode { get; set; }

    public void ApplyRule(RewriteContext context)
    {
        if (context == null)
            throw new ArgumentNullException(nameof(context));

        if (context.HttpContext.Request.Host != Host)
        {
            var request = context.HttpContext.Request;
            var newUrl = new StringBuilder()
                .Append(request.Scheme)
                .Append("://")
                .Append(Host)
                .Append(request.PathBase)
                .Append(request.Path)
                .Append(request.QueryString);

            var response = context.HttpContext.Response;
            response.StatusCode = StatusCode;
            response.Headers[HeaderNames.Location] = newUrl.ToString();

            context.Result = RuleResult.EndResponse;
        }
    }
}

Entspricht der Host des Request nicht der gewünschten „normalisierten“ Schreibweise, so wird direkt eine angepasste URL generiert und mit dem konfigurierten Status Code an den Client zurückgeschickt. That‘s it.

Für die Registrierung eben dieser Regel kann man noch mittels Extension Method der aktuellen Mode entsprechen:

public static class CanonicalHostExtensions
{
    public static RewriteOptions AddCanonicalHost(this RewriteOptions options, string host, int statusCode = StatusCodes.Status302Found)
    {
        if (options == null)
            throw new ArgumentNullException(nameof(options));

        return AddCanonicalHost(options, new HostString(host), statusCode);
    }

    public static RewriteOptions AddCanonicalHost(this RewriteOptions options, HostString host, int statusCode = StatusCodes.Status302Found)
    {
        if (options == null)
            throw new ArgumentNullException(nameof(options));

        options.Rules.Add(new CanonicalHostRule
        {
            Host = host,
            StatusCode = statusCode
        });

        return options;
    }
}

Eine praktikable Konfiguration, die beispielsweise HTTPS sowie einen kanonischen Host „erzwingt“, kann nun in der globalen Startup.cs mittels Rewrite Middleware eingebunden werden:

var options = new RewriteOptions()
    .AddRedirectToHttps(StatusCodes.Status303SeeOther)
    .AddCanonicalHost("axel.heer.eu", StatusCodes.Status303SeeOther);

app.UseRewriter(options);

Ob das jetzt einfacher oder zumindest klarer als eine äquivalente Apache- oder IIS-Konfiguration sein soll, bleibt dem guten Geschmack überlassen. Jedenfalls wird eine ASP.NET Core Anwendung damit eine Spur unabhängiger vom Webserver, welcher auch immer das dann im produktiven Einsatz sein möge.

2017-06-25

• #Development
• #MVC
• #CSharp

Asserting Collections with Collections using xUnit

Werden im Assert Abschnitt eines Unit Tests ganze Collections überprüft, so bietet xUnit out-of-the-box ein paar elegante Möglichkeiten diese zu validieren. Insbesondere im Fehlerfall hilft der Output oft den kaputten Datensatz direkt zu identifizieren, wobei das mit der Ursache natürlich eine andere Geschichte ist…

Beispiel:

[Fact]
public void ShouldDoIt()
{
    var actual = ...

    Assert.Collection(actual,
    a =>
    {
        Assert.Equal("Narf", a.Name);
        Assert.True(a.Active);
    },
    a =>
    {
        Assert.Equal("Asdf", a.Name);
        Assert.False(a.Active);
    });
}

Passt ein Wert des zweiten Elements nicht, so bekommt man das in der Regel relativ detailliert mitgeteilt:

Error Message:
 Assert.Collection() Failure
Collection: [{ Name = Narf, Active = True }, { Name = Asdf, Active = True }]
Error during comparison of item at index 1
Inner exception: Assert.False() Failure
        Expected: False
        Actual:   True

Hat man das gewünschte Ergebnis auch in Form einer Collection zur Verfügung, so hilft einem wie gewohnt Assert.Equal weiter, das nicht nur mit einfachen Objekten, sondern genauso mit Collections umgehen kann. Sogar eine Überladung für einen mehr oder weniger speziellen IEqualityComparer steht zur Verfügung.

[Fact]
public void ShouldDoIt()
{
    var expected = ...

    var actual = ...

    Assert.Equal(expected, actual);
}

Handelt es sich jedoch um inkompatible Strukturen – werden beispielsweise Models mit View Models verglichen –, so wird oft in der einen oder anderen Art und Weise iteriert, wodurch neben einer gewissen Eleganz eben jene Zusatzinfos im Fehlerfall verloren gehen. Ohne das Anwerfen eines Debuggers ist es dann nicht mehr wirklich nachvollziehbar, welches Element auf einmal Mist beinhaltet.

Dabei lässt sich Assert.Collection mit einem einfachen Trick auch dafür benutzen.

public static class TestExtensions
{
    public static void AssertWith<TExpected, TActual>(this IEnumerable<TActual> actual, IEnumerable<TExpected> expected, Action<TExpected, TActual> inspector)
    {
        Assert.Collection(actual, expected.Select(e => (Action<TActual>)(a => inspector(e, a))).ToArray());
    }
}

Mittels LINQ bzw. ein wenig funktionaler Programmierung wird das „expected“ gemeinsam mit einem allgemein gültigen „Inspector“ in ein mit Assert.Collection kompatibles Inspector-Array umgewandelt, was sich wie folgt anwenden lässt.

[Fact]
public void ShouldDoIt()
{
    var expected = ...

    var actual = ...

    actual.AssertWith(expected, (e, a) =>
    {
        Assert.Equal(e.Name, a.Name);
        Assert.Equal(e..., a.Active);
    });
}

Bei Bedarf kann das sogar beliebig verschachtelt werden.

2017-03-12

• #Development
• #CSharp