Freigeben über

Sichern von .NET Microservices und Webanwendungen

Tipp

Dieser Inhalt ist ein Auszug aus dem eBook .NET Microservices Architecture for Containerized .NET Applications, verfügbar auf .NET Docs oder als kostenlose herunterladbare PDF, die offline gelesen werden kann.

PDF herunterladen

.NET-Mikroservices-Architektur für containerisierte .NET-Anwendungen eBook-Cover-Miniaturansicht.

Es gibt so viele Aspekte der Sicherheit in Microservices und Webanwendungen, dass das Thema problemlos mehrere Bücher wie diese nehmen könnte. In diesem Abschnitt konzentrieren wir uns also auf Authentifizierung, Autorisierung und Anwendungsgeheimnisse.

Implementieren der Authentifizierung in .NET Microservices und Webanwendungen

Es ist häufig erforderlich, dass Ressourcen und APIs, die von einem Dienst veröffentlicht werden, auf bestimmte vertrauenswürdige Benutzer oder Clients beschränkt werden. Der erste Schritt zum Treffen dieser Arten von Vertrauensentscheidungen auf API-Ebene ist die Authentifizierung. Die Authentifizierung ist der Prozess der zuverlässigen Überprüfung der Identität eines Benutzers.

Die Authentifizierung wird in Microserviceszenarien in der Regel zentral vorgenommen. Wenn Sie ein API-Gateway verwenden, ist das Gateway ein guter Ort für die Authentifizierung, wie in Abbildung 9-1 dargestellt. Wenn Sie diesen Ansatz verwenden, stellen Sie sicher, dass die einzelnen Microservices nicht direkt (ohne DAS API-Gateway) erreicht werden können, es sei denn, zusätzliche Sicherheit ist vorhanden, um Nachrichten zu authentifizieren, unabhängig davon, ob sie vom Gateway stammen oder nicht.

Diagramm, das zeigt, wie die mobile Client-App mit dem Back-End interagiert.

Abbildung 9-1. Zentralisierte Authentifizierung mit einem API-Gateway

Wenn das API-Gateway die Authentifizierung zentralisiert, werden Beim Weiterleiten von Anforderungen an die Microservices Benutzerinformationen hinzugefügt. Wenn direkt auf Dienste zugegriffen werden kann, kann ein Authentifizierungsdienst wie Azure Active Directory oder ein dedizierter Authentifizierungs-Microservice, der als Sicherheitstokendienst (SECURITY Token Service, STS) fungiert, verwendet werden, um Benutzer zu authentifizieren. Vertrauensentscheidungen werden zwischen Diensten mit Sicherheitstoken oder Cookies geteilt. (Diese Token können bei Bedarf zwischen ASP.NET Core-Anwendungen gemeinsam genutzt werden, indem die Cookiefreigabe implementiert wird.) Dieses Muster ist in Abbildung 9-2 dargestellt.

Diagramm, das die Authentifizierung über Back-End-Microservices zeigt.

Abbildung 9-2. Authentifizierung durch einen Identitäts-Mikroservice; Vertrauen wird über ein Zugriffstoken geteilt.

Wenn auf Microservices direkt zugegriffen wird, wird das Vertrauen, das Authentifizierung und Autorisierung umfasst, durch ein Sicherheitstoken geregelt, das von einem dedizierten Microservice ausgestellt und zwischen den Microservices geteilt wird.

Authentifizieren mit ASP.NET Core Identity

Der primäre Mechanismus in ASP.NET Core zum Identifizieren der Benutzer einer Anwendung ist das ASP.NET Core Identity-Mitgliedschaftssystem . ASP.NET Core Identity speichert Benutzerinformationen (einschließlich Anmeldeinformationen, Rollen und Ansprüche) in einem vom Entwickler konfigurierten Datenspeicher. In der Regel ist der ASP.NET Core Identitätsdatenspeicher ein Entity Framework-Speicher, der im Microsoft.AspNetCore.Identity.EntityFrameworkCore-Paket bereitgestellt wird. Benutzerdefinierte Speicher oder andere Drittanbieterpakete können jedoch verwendet werden, um Identitätsinformationen in Azure Table Storage, CosmosDB oder anderen Speicherorten zu speichern.

Tipp

ASP.NET Core 2.1 und höher stellt ASP.NET Core Identity als Razor-Klassenbibliothek bereit, sodass Sie nicht viel des erforderlichen Codes in Ihrem Projekt sehen, wie es bei früheren Versionen der Fall war. Ausführliche Informationen zum Anpassen des Identitätscodes an Ihre Anforderungen finden Sie unter Scaffold Identity in ASP.NET Core-Projekten.

Der folgende Code stammt aus der ASP.NET Core Web Application MVC-Projektvorlage, wobei die Authentifizierung einzelner Benutzerkonten ausgewählt ist. Es zeigt, wie ASP.NET Core Identity mithilfe von Entity Framework Core in der Program.cs-Datei konfiguriert wird.

//...
builder.Services.AddDbContext<ApplicationDbContext>(options =>
    options.UseSqlServer(
        builder.Configuration.GetConnectionString("DefaultConnection")));

builder.Services.AddDefaultIdentity<IdentityUser>(options =>
    options.SignIn.RequireConfirmedAccount = true)
        .AddEntityFrameworkStores<ApplicationDbContext>();

builder.Services.AddRazorPages();
//...

Nachdem ASP.NET Core Identity konfiguriert wurde, aktivieren Sie sie, indem Sie den app.UseAuthentication()endpoints.MapRazorPages() folgenden Code in der Program.cs-Datei des Diensts hinzufügen:

//...
app.UseRouting();

app.UseAuthentication();
app.UseAuthorization();

app.UseEndpoints(endpoints =>
{
    endpoints.MapRazorPages();
});
//...

Von Bedeutung

Die Zeilen im vorherigen Code MÜSSEN IN DER ANGEGEBENEN REIHENFOLGE SEIN, damit Identity korrekt funktioniert.

Die Verwendung von ASP.NET Core Identity ermöglicht mehrere Szenarien:

  • Erstellen Neuer Benutzerinformationen mithilfe des UserManager-Typs (userManager.CreateAsync).

  • Authentifizieren von Benutzern mithilfe des SignInManager-Typs. Sie können signInManager.SignInAsync direkt zum Anmelden verwenden oder signInManager.PasswordSignInAsync, um zu bestätigen, dass das Kennwort des Benutzers korrekt ist, und diesen dann anmelden.

  • Identifizieren Sie einen Benutzer basierend auf Informationen, die in einem Cookie gespeichert sind (das von ASP.NET Core Identity Middleware gelesen wird), sodass nachfolgende Anforderungen eines Browsers die Identität und Ansprüche eines angemeldeten Benutzers enthalten.

ASP.NET Core Identity unterstützt auch die zweistufige Authentifizierung.

Für Authentifizierungsszenarien, die einen lokalen Benutzerdatenspeicher verwenden und die Identität zwischen Anforderungen mithilfe von Cookies beibehalten (wie für MVC-Webanwendungen typisch), ist ASP.NET Core Identity eine empfohlene Lösung.

Authentifizieren bei externen Anbietern

ASP.NET Core unterstützt auch die Verwendung externer Authentifizierungsanbieter , um Benutzern die Anmeldung über OAuth 2.0-Flüsse zu ermöglichen. Dies bedeutet, dass sich Benutzer mit vorhandenen Authentifizierungsprozessen von Anbietern wie Microsoft, Google, Facebook oder Twitter anmelden und diese Identitäten einer ASP.NET Core-Identität in Ihrer Anwendung zuordnen können.

Um die externe Authentifizierung zu verwenden, müssen Sie neben der zuvor erwähnten Authentifizierungs-Middleware auch den app.UseAuthentication() externen Anbieter in Program.cs registrieren, wie im folgenden Beispiel gezeigt:

//...
services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
    .AddEntityFrameworkStores<ApplicationDbContext>();

services.AddAuthentication()
    .AddMicrosoftAccount(microsoftOptions =>
    {
        microsoftOptions.ClientId = builder.Configuration["Authentication:Microsoft:ClientId"];
        microsoftOptions.ClientSecret = builder.Configuration["Authentication:Microsoft:ClientSecret"];
    })
    .AddGoogle(googleOptions => { ... })
    .AddTwitter(twitterOptions => { ... })
    .AddFacebook(facebookOptions => { ... });
//...

Beliebte externe Authentifizierungsanbieter und die zugehörigen NuGet-Pakete sind in der folgenden Tabelle dargestellt:

Anbieter Paket
Microsoft Microsoft.AspNetCore.Authentication.MicrosoftAccount
Googeln Microsoft.AspNetCore.Authentication.Google
Facebook Microsoft.AspNetCore.Authentication.Facebook
Zwitschern Microsoft.AspNetCore.Authentication.Twitter

In allen Fällen müssen Sie ein Antragsregistrierungsverfahren abschließen, das vom Anbieter abhängig ist und in der Regel folgendes umfasst:

  1. Abrufen einer Clientanwendungs-ID.
  2. Abrufen eines Client-Anwendungsgeheimnisses.
  3. Konfigurieren einer Umleitungs-URL, die von der Autorisierungs-Middleware und dem registrierten Anbieter behandelt wird
  4. Optional können Sie eine Abmelde-URL so konfigurieren, dass die Abmeldung in einem SSO-Szenario (Single Sign On) ordnungsgemäß verarbeitet wird.

Ausführliche Informationen zum Konfigurieren Ihrer App für einen externen Anbieter finden Sie in der ASP.NET Core-Dokumentation zur Authentifizierung des externen Anbieters).

Tipp

Alle Details werden von der zuvor erwähnten Autorisierungs-Middleware und -diensten behandelt. Sie müssen also nur die Authentifizierungsoption "Individuelles Benutzerkonto " auswählen, wenn Sie das ASP.NET Core-Webanwendungsprojekt in Visual Studio erstellen, wie in Abbildung 9-3 dargestellt, neben der Registrierung der zuvor erwähnten Authentifizierungsanbieter.

Screenshot des Dialogfelds

Abbildung 9-3. Auswählen der Option "Einzelne Benutzerkonten" für die Verwendung der externen Authentifizierung beim Erstellen eines Webanwendungsprojekts in Visual Studio 2019.

Zusätzlich zu den zuvor aufgeführten externen Authentifizierungsanbietern stehen Drittanbieterpakete zur Verfügung, die Middleware für die Verwendung vieler weiterer externer Authentifizierungsanbieter bereitstellen. Eine Liste finden Sie im AspNet.Security.OAuth.Providers-Repository auf GitHub.

Sie können auch ihre eigene externe Authentifizierungs-Middleware erstellen, um einige besondere Notwendigkeiten zu lösen.

Authentifizieren mit Bearertoken

Die Authentifizierung mit ASP.NET Core Identity (oder Identity plus externen Authentifizierungsanbietern) eignet sich gut für viele Webanwendungsszenarien, in denen das Speichern von Benutzerinformationen in einem Cookie geeignet ist. In anderen Szenarien sind Cookies jedoch kein natürliches Mittel zum Speichern und Übertragen von Daten.

Beispielsweise in einer ASP.NET Core Web API, die RESTful-Endpunkte verfügbar macht, auf die von Single Page Applications (SPAs), von systemeigenen Clients oder sogar von anderen Web-APIs zugegriffen werden kann, sollten Sie stattdessen die Bearertokenauthentifizierung verwenden. Diese Arten von Anwendungen arbeiten nicht mit Cookies, können aber problemlos ein Bearer-Token abrufen und es in den Autorisierungsheader der folgenden Anfragen einschließen. Um die Tokenauthentifizierung zu aktivieren, unterstützt ASP.NET Core mehrere Optionen für die Verwendung von OAuth 2.0 und OpenID Connect.

Authentifizieren mit einem OpenID Connect- oder OAuth 2.0-Identitätsanbieter

Wenn Benutzerinformationen in Azure Active Directory oder einer anderen Identitätslösung gespeichert werden, die OpenID Connect oder OAuth 2.0 unterstützt, können Sie das Microsoft.AspNetCore.Authentication.OpenIdConnect-Paket verwenden, um sich mit dem OpenID Connect-Workflow zu authentifizieren. Um sich beispielsweise beim Identity.Api microservice in eShopOnContainers zu authentifizieren, kann eine ASP.NET Core-Webanwendung Middleware aus diesem Paket verwenden, wie im folgenden vereinfachten Beispiel in Program.cs gezeigt:

// Program.cs

var identityUrl = builder.Configuration.GetValue<string>("IdentityUrl");
var callBackUrl = builder.Configuration.GetValue<string>("CallBackUrl");
var sessionCookieLifetime = builder.Configuration.GetValue("SessionCookieLifetimeMinutes", 60);

// Add Authentication services

services.AddAuthentication(options =>
{
    options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
})
.AddCookie(setup => setup.ExpireTimeSpan = TimeSpan.FromMinutes(sessionCookieLifetime))
.AddOpenIdConnect(options =>
{
    options.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    options.Authority = identityUrl.ToString();
    options.SignedOutRedirectUri = callBackUrl.ToString();
    options.ClientId = useLoadTest ? "mvctest" : "mvc";
    options.ClientSecret = "secret";
    options.ResponseType = useLoadTest ? "code id_token token" : "code id_token";
    options.SaveTokens = true;
    options.GetClaimsFromUserInfoEndpoint = true;
    options.RequireHttpsMetadata = false;
    options.Scope.Add("openid");
    options.Scope.Add("profile");
    options.Scope.Add("orders");
    options.Scope.Add("basket");
    options.Scope.Add("marketing");
    options.Scope.Add("locations");
    options.Scope.Add("webshoppingagg");
    options.Scope.Add("orders.signalrhub");
});

// Build the app
//…
app.UseAuthentication();
//…
app.UseEndpoints(endpoints =>
{
    //...
});

Wenn Sie diesen Workflow verwenden, ist die ASP.NET Core Identity Middleware nicht erforderlich, da alle Benutzerinformationsspeicher und -Authentifizierung vom Identitätsdienst verarbeitet werden.

Ausstellen von Sicherheitstoken aus einem ASP.NET Core-Dienst

Wenn Sie Sicherheitstoken für lokale ASP.NET Core Identity-Benutzer ausgeben möchten, anstatt einen externen Identitätsanbieter zu verwenden, können Sie einige gute Drittanbieterbibliotheken nutzen.

IdentityServer4 und OpenIddict sind OpenID Connect-Anbieter, die problemlos in ASP.NET Core Identity integriert werden können, damit Sie Sicherheitstoken aus einem ASP.NET Core-Dienst ausstellen können. Die IdentityServer4-Dokumentation enthält ausführliche Anweisungen zur Verwendung der Bibliothek. Die grundlegenden Schritte zur Verwendung von IdentityServer4 zum Ausgeben von Token sind jedoch wie folgt.

  1. Sie konfigurieren IdentityServer4 in Program.cs , indem Sie einen Generator aufrufen. Services.AddIdentityServer.

  2. Sie rufen app.UseIdentityServer in Program.cs auf, um IdentityServer4 zur HTTP-Anforderungsverarbeitungspipeline der Anwendung hinzuzufügen. Auf diese Weise kann die Bibliothek Anforderungen an OpenID Connect- und OAuth2-Endpunkte wie /connect/token bereitstellen.

  3. Sie konfigurieren den Identitätsserver, indem Sie die folgenden Daten festlegen:

    • Die zum Signieren zu verwendenden Anmeldeinformationen .

    • Die Identitäts- und API-Ressourcen , auf die Benutzer möglicherweise Zugriff anfordern können:

      • API-Ressourcen stellen geschützte Daten oder Funktionen dar, auf die ein Benutzer mit einem Zugriffstoken zugreifen kann. Ein Beispiel für eine API-Ressource wäre eine Web-API (oder eine Gruppe von APIs), die eine Autorisierung erfordert.

      • Identitätsressourcen stellen Informationen (Ansprüche) dar, die einem Client zur Identifizierung eines Benutzers übergeben werden. Die Ansprüche können den Benutzernamen, die E-Mail-Adresse usw. enthalten.

    • Die Klienten, die eine Verbindung herstellen, um Token anzufordern.

    • Der Speichermechanismus für Benutzerinformationen, z. B. ASP.NET Core Identity oder eine Alternative.

Wenn Sie Clients und Ressourcen für den zu verwendenden IdentityServer4 angeben, können Sie eine IEnumerable<T> Sammlung des entsprechenden Typs an Methoden übergeben, die speicherinterne Client- oder Ressourcenspeicher verwenden. Oder für komplexere Szenarien können Sie Client- oder Ressourcenanbietertypen über Dependency Injection bereitstellen.

Eine Beispielkonfiguration für IdentityServer4 zur Verwendung von Speicherressourcen und Clients, die von einem benutzerdefinierten IClientStore-Typ bereitgestellt werden, kann wie im folgenden Beispiel aussehen:

// Program.cs

builder.Services.AddSingleton<IClientStore, CustomClientStore>();
builder.Services.AddIdentityServer()
    .AddSigningCredential("CN=sts")
    .AddInMemoryApiResources(MyApiResourceProvider.GetAllResources())
    .AddAspNetIdentity<ApplicationUser>();
//...

Verbrauch von Sicherheitstoken

Die Authentifizierung gegen einen OpenID Connect-Endpunkt oder das Ausstellen Ihrer eigenen Sicherheitstoken deckt einige Szenarien ab. Aber was ist mit einem Dienst, der einfach den Zugriff auf benutzer einschränken muss, die über gültige Sicherheitstoken verfügen, die von einem anderen Dienst bereitgestellt wurden?

Für dieses Szenario steht Authentifizierungs-Middleware, die JWT-Token verarbeitet, im Paket "Microsoft.AspNetCore.Authentication.JwtBearer " zur Verfügung. JWT steht für "JSON Web Token" und ist ein gängiges Sicherheitstokenformat (definiert durch RFC 7519) für die Kommunikation von Sicherheitsansprüchen. Ein vereinfachtes Beispiel für die Verwendung von Middleware zum Verwenden solcher Token könnte wie dieses Codefragment aussehen, das aus dem Order.Api microservice von eShopOnContainers stammt.

// Program.cs

var identityUrl = builder.Configuration.GetValue<string>("IdentityUrl");

// Add Authentication services

builder.Services.AddAuthentication(options =>
{
    options.DefaultAuthenticateScheme = AspNetCore.Authentication.JwtBearer.JwtBearerDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = AspNetCore.Authentication.JwtBearer.JwtBearerDefaults.AuthenticationScheme;

}).AddJwtBearer(options =>
{
    options.Authority = identityUrl;
    options.RequireHttpsMetadata = false;
    options.Audience = "orders";
});

// Build the app

app.UseAuthentication();
//…
app.UseEndpoints(endpoints =>
{
    //...
});

Die Parameter in dieser Verwendung sind:

  • Audience stellt den Empfänger des eingehenden Tokens oder der Ressource dar, auf die das Token Zugriff gewährt. Wenn der in diesem Parameter angegebene Wert nicht mit dem Parameter im Token übereinstimmt, wird das Token abgelehnt.

  • Authority ist die Adresse des Tokenausstellenden Authentifizierungsservers. Die JWT-Bearerauthentifizierungs-Middleware verwendet diesen URI, um den öffentlichen Schlüssel abzurufen, mit dem die Signatur des Tokens überprüft werden kann. Die Middleware bestätigt außerdem, dass der iss Parameter im Token mit diesem URI übereinstimmt.

Ein anderer Parameter ist für Testzwecke nützlich. Sie legen diesen Parameter auf "false" fest, sodass Sie in Umgebungen testen können, RequireHttpsMetadatain denen Keine Zertifikate vorhanden sind. In realen Bereitstellungen sollten JWT-Bearertoken immer nur über HTTPS übergeben werden.

Mit dieser Middleware werden JWT-Token automatisch aus Autorisierungsheadern extrahiert. Sie werden dann deserialisiert, überprüft (mithilfe der Werte in den Audience Und Authority Parametern) und als Benutzerinformationen gespeichert, auf die später von MVC-Aktionen oder Autorisierungsfiltern verwiesen werden soll.

Die JWT-Bearerauthentifizierungs-Middleware kann auch erweiterte Szenarien unterstützen, z. B. die Verwendung eines lokalen Zertifikats zum Überprüfen eines Tokens, wenn die Autorität nicht verfügbar ist. In diesem Szenario können Sie ein TokenValidationParameters Objekt im JwtBearerOptions Objekt angeben.

Weitere Ressourcen

ZurückWeiter