Modul 3 – Authentifizierung und Autorisierung

Auf dieser Seite

 Modulübersicht
 Zielsetzung
 Betrifft
 Verwendung dieses Moduls
 Vorbereitung
 Entwerfen einer Authentifizierungs- und Autorisierungsstrategie
 Autorisierungsansätze
 Übertragen der Identität
 Rollenbasierte Autorisierung
 Auswählen eines Authentifizierungsmechanismus
 Zusammenfassung

Modulübersicht

Das Entwerfen der Authentifizierungs- und Autorisierungsmechanismen für eine verteilte Webanwendung ist eine anspruchsvolle Aufgabe – Sie müssen zahlreiche Entscheidungen treffen, die sich auf nahezu jeder Komponente der von Ihnen entwickelten Anwendung auswirken. Durch die Ausarbeitung eines geeigneten Authentifizierungs- und Autorisierungsentwurfs lassen sich viele der größten Sicherheitsrisiken minimieren. Wenn der jeweilige Entwurf in der Anfangsphase der Anwendungsentwicklung implementiert wird, gestaltet sich der Vorgang deutlich einfacher als beim Versuch, eine Lösung im Nachhinein an eine vorhandene oder teilweise erstellte Anwendung anzupassen.

In diesem Modul werden die Authentifizierungs- und Autorisierungsmechanismen erläutert, die bei der Entwicklung verteilter ASP.NET-Webanwendungen zur Verfügung stehen. Außerdem wird der Vorgang beschrieben, der Sie bei der Auswahl der am besten geeigneten Authentifizierungs- und Autorisierungsmechanismen unterstützt.

 

Zielsetzung

Themenbereiche:

• Kennenlernen der unterschiedlichen Optionen zur Weitergabe einer Identität über mehrere Anwendungsebenen hinweg

• Ermitteln der geeigneten Authentifizierungs- und Autorisierungsmechanismen zur Verwendung in Ihrer verteilten Webanwendung

• Vergleichen und Gegenüberstellen der Modelle "Identitätswechsel/Delegierung" (auch als "ursprünglicher Aufrufer" bezeichnet) und "vertrauenswürdiges Subsystem" für Authentifizierungs- und Autorisierungszwecke in Ihren verteilten .NET Web-Anwendungen

• Vergleichen und Gegenüberstellen der rollenbasierten und der ressourcenbasierten Autorisierung

 

Betrifft

Die Informationen in diesem Modul gelten für folgende Produkte und Technologien:

• Windows XP oder Windows 2000 Server (mit Service Pack 3) und höhere Betriebssysteme

• Microsoft Internetinformationsdienste (IIS) 5.0 und höher

• Microsoft Active Directory

• .NET Framework Version 1.0 (mit Service Pack 2) und höhere Versionen

• SQL Server 2000 (mit Service Pack 2) und höhere Versionen

 

Verwendung dieses Moduls

In diesem Modul wird beschrieben, wie sich die geeigneten Authentifizierungs- und Autorisierungsmechanismen für Ihre verteilte Webanwendung ermitteln lassen. Je früher Sie die Authentifizierungs- und Autorisierungsanforderungen Ihrer Anwendung in Betracht ziehen, desto einfacher lassen sich die Mechanismen implementieren und desto höher ist voraussichtlich der Sicherheitsgrad Ihrer Anwendung. Empfehlungen für eine erfolgreiche Arbeit mit diesem Modul:

• Lesen Sie Modul 1, "Einführung". Hier werden die Begriffe "Authentifizierung" und "Autorisierung" bei verteilten Webanwendungen erläutert.

• Lesen Sie Modul 2, "Sicherheitsmodell für ASP.NET-Anwendungen". Hier erhalten Sie einen Überblick über die Architektur und Technologien, die bei der Erstellung verteilter ASP.NET-Webanwendungen zum Einsatz kommen. Das Modul enthält eine Einführung in die Authentifizierungs- und Autorisierungsmechanismen sowie eine Definition von Gates und Gatekeepern, die bei der Autorisierung eine zentrale Rolle spielen.

• Lesen Sie sich folgende Module durch, in denen die Implementierung der in diesem Modul erläuterten Authentifizierungs- und Autorisierungstechniken demonstriert wird:

  • "Vorgehensweise: Erstellen eines benutzerdefinierten Kontos zur Ausführung von ASP.NET".

  • "Vorgehensweise: Verwenden der Formularauthentifizierung mit Active Directory".

  • "Vorgehensweise: Verwenden der Formularauthentifizierung mit SQL Server 2000".

  • "Vorgehensweise: Erstellen von GenericPrincipal-Objekten bei der Formularauthentifizierung".

  • "Vorgehensweise: Implementieren der Kerberos-Delegierung unter Windows 2000".

  • "Vorgehensweise: Implementieren von IPrincipal".

  • "Vorgehensweise: Verwenden von rollenbasierter Sicherheit mit Enterprise Services".

  • "Vorgehensweise: Aufrufen eines Webdienstes mit Clientzertifikaten von ASP.NET".

  • "Vorgehensweise: Einrichten von Clientzertifikaten".

 

Vorbereitung

Das Entwerfen einer Authentifizierungs- und Autorisierungsstrategie für verteilte Webanwendungen ist eine anspruchsvolle Aufgabe. Der Vorteil liegt darin, dass sich durch die Ausarbeitung eines geeigneten Authentifizierungs- und Autorisierungsentwurfs in der Anfangsphase der Anwendungsentwicklung viele der größten Sicherheitsrisiken minimieren lassen.

Dieses Modul hilft Ihnen dabei, eine für Ihre Anwendung geeignete Autorisierungsstrategie auszuarbeiten und außerdem folgende Schlüsselfragen zu beantworten:

• Wo soll die Autorisierung vorgenommen und welche Mechanismen sollen verwendet werden?

• Welche Authentifizierungsmechanismen sollen verwendet werden?

• Wird zur Authentifizierung der Active Directory®-Verzeichnisdienst verwendet oder werden Anmeldeinformationen anhand eines benutzerdefinierten Datenspeichers überprüft?

• Welche Auswirkungen gelten in Bezug auf heterogene und homogene Plattformen, und welche Entwurfsaspekte sollen beachtet werden?

• Wie sollen Benutzer, die nicht mit dem Microsoft® Windows®-Betriebssystem arbeiten, in meiner Anwendung dargestellt werden?

• Wie soll die Übertragung von Benutzeridentitäten über die Ebenen meiner Anwendung hinweg erfolgen? In welchen Fällen empfehlen sich Identitätswechsel/Delegierung auf Betriebssystemebene?

Wenn Sie sich mit Aspekten der Autorisierung befassen, müssen Sie dies auch mit Aspekten der Authentifizierung tun. Die beiden Prozesse sind aus zwei Gründen miteinander verbunden:

• Zunächst sind für jede sinnvolle Autorisierungsrichtlinie authentifizierte Benutzer erforderlich.

• Zweitens wird durch die Art der Authentifizierung von Benutzern (und insbesondere der Art der Identität authentifizierter Benutzer in Ihrer Anwendung) bestimmt, welche Gatekeeper Ihnen zur Verfügung stehen.
  Für Gatekeeper wie ASP.NET-Dateiautorisierung, Enterprise Services-(COM+-)Rollen und Windows-ACLs (Access Control Lists) ist eine authentifizierte Windows-Identität erforderlich (in Form eines WindowsIdentity-Objekts, das ein Windows-Zugriffstoken einkapselt, durch das wiederum der Sicherheitskontext des jeweiligen Aufrufers definiert wird). Für andere Gatekeeper wie ASP.NET-URL-Autorisierung und .NET-Rollen ist dies keine Voraussetzung. Für sie ist lediglich eine authentifizierte Identität erforderlich, die nicht zwangsweise durch ein Windows-Zugriffstoken dargestellt wird.

 

Entwerfen einer Authentifizierungs- und Autorisierungsstrategie

In den nachfolgenden Schritten wird ein Prozess beschrieben, der Ihnen bei der Ausarbeitung einer Authentifizierungs- und Autorisierungsstrategie für Ihre Anwendung behilflich ist:

1. Ressourcen identifizieren

2. Autorisierungsstrategie auswählen

3. Für den Ressourcenzugriff verwendete Identitäten auswählen

4. Aspekte bei der Identitätsübertragung berücksichtigen

5. Authentifizierungsansatz auswählen

6. Art der Identitätsübertragung festlegen

Ressourcen identifizieren

Identifizieren Sie die Ressourcen, die Ihre Anwendung für Clients bereitstellen muss. Zu typischen Ressourcen zählen:

• Webserver-Ressourcen wie Webseiten, Webdienste, statische Ressourcen (HTML-Seiten und Bilder)

• Datenbankressourcen wie auf individuelle Benutzer oder die gesamte Anwendung bezogene Daten

• Netzwerkressourcen wie Daten eines Remotedateisystems und aus Verzeichnisspeichern wie Active Directory

Außerdem müssen Sie die Systemressourcen identifizieren, auf die Ihre Anwendung zugreifen muss. Dies ist nicht der Fall bei Ressourcen, die Clients zur Verfügung gestellt werden. Zu den Systemressourcen zählen beispielsweise die Registrierung, Ereignisprotokolle und Konfigurationsdateien.

Autorisierungsstrategie auswählen

Es gibt zwei grundlegenden Autorisierungsstrategien:

• Rollenbasierte Autorisierung. Der Zugriff auf Operationen (normalerweise Methoden) wird basierend auf der Rollenmitgliedschaft des Aufrufers gesichert. Rollen werden verwendet, um die Benutzerbasis Ihrer Anwendung in Gruppen mit Benutzern zu unterteilen, die innerhalb der Anwendung über dieselben Sicherheitsberechtigungen verfügen, beispielsweise "Senior Manager", "Manager" und "Mitarbeiter". Benutzer werden Rollen zugeordnet. Wenn der jeweilige Benutzer zur Durchführung der angeforderten Operation autorisiert ist, verwendet die Anwendung feste Identitäten, über die der Zugriff auf Ressourcen erfolgt. Der jeweilige Ressourcen-Manager vertraut diesen Identitäten (z. B. Datenbanken, dem Dateisystem usw.).

• Ressourcenbasierte Autorisierung. Einzelne Ressourcen werden über Windows-ACLs gesichert. Da die Anwendung vor dem Zugriff auf Ressourcen die Identität des Aufrufers annimmt, kann das Betriebssystem standardmäßige Zugriffsüberprüfungen starten. Jeglicher Ressourcenzugriff wird mithilfe des Sicherheitskontexts des ursprünglichen Aufrufers durchgeführt. Dieser Identitätswechselansatz beeinträchtigt die Anwendungsskalierbarkeit nachhaltig, da man dadurch das Verbindungspooling in der mittleren Ebene der Anwendung nicht effizient einsetzen kann.

Da bei den meisten .NET-Webanwendungen die Skalierbarkeit ein bedeutender Faktor ist, empfiehlt sich bei der Autorisierung ein rollenbasierter Ansatz. Für bestimmte Intranetanwendungen, die auf einzelne Benutzer bezogene Inhalte aus Ressourcen (z. B. Dateien) bereitstellen und über Windows-ACLs vor bestimmten Benutzern geschützt werden können, ist möglicherweise ein ressourcenbasierter Ansatz empfehlenswert.

Das empfohlene und gängige Muster für die rollenbasierte Autorisierung gestaltet sich folgendermaßen:

• Authentifizierung von Benutzern in der Front-End-Webanwendung.

• Zuweisen von Rollen zu Benutzern.

• Autorisieren des Zugriffs auf Operationen (nicht direkt auf Ressourcen) basierend auf der Rollenmitgliedschaft.

• Zugriff auf die benötigten Back-End-Ressourcen (zur Unterstützung der angeforderten und autorisierten Operationen) über feste Dienstidentitäten. Die Back-End-Ressourcen-Manager (z. B. Datenbanken) vertrauen der Anwendung hinsichtlich der Autorisierung von Aufrufern und sind bereit, den vertrauenswürdigen Dienstidentitäten Berechtigungen zu gewähren.

  Ein Datenbankadministrator kann beispielsweise Zugriffsberechtigungen exklusiv für eine spezifische HR-Anwendung gewähren (jedoch nicht für einzelne Benutzer).

Hinweis: Für den rollenbasierten Autorisierungsansatz auf Anwendungsebene ist weiterhin die ressourcenbasierte Autorisierung zur Sicherung von Ressourcen auf Systemebene, beispielsweise Konfigurationsdateien, Registrierungsschlüssel usw. erforderlich.

Weitere Informationen

• Weitere Informationen zu den beiden Autorisierungsansätzen finden Sie unter "Autorisierungsansätze" weiter unten in diesem Modul.

• Weitere Informationen über die rollenbasierte Autorisierung und die unterschiedlichen Rollentypen finden Sie unter "Rollenbasierte Autorisierung" weiter unten in diesem Modul.

Für den Ressourcenzugriff verwendete Identitäten auswählen

Beantworten Sie die Frage, wer für den Zugriff auf Ressourcen vorgesehen ist.

Wählen Sie die Identitäten aus, die für den ebenenübergreifenden Ressourcenzugriff in Ihrer Anwendung verwendet werden sollen. Hierzu zählen Ressourcen, über die von webbasierten Anwendungen und optional von Webdiensten von Enterprise Services und .NET Remoting-Komponenten aus zugegriffen wird. In sämtlichen Fällen kann es sich bei der für den Ressourcenzugriff verwendeten Identität um Folgendes handeln:

• Identität des ursprünglichen Aufrufers. Hierbei wird von einem Identitätswechsel-/Delegierungsmodell ausgegangen, bei dem die Identität des ursprünglichen Aufrufers abgerufen und dann in sämtliche Ebenen Ihres Systems übertragen werden kann. Der Delegierungsfaktor ist ein Schlüsselkriterium zur Bestimmung Ihres Authentifizierungsmechanismus.

• Prozessidentität. Dies ist der Standardfall (ohne spezifischen Identitätswechsel). Der Zugriff auf lokale Ressourcen sowie Downstream-Aufrufe erfolgen mithilfe der aktuellen Prozessidentität. Die Realisierung dieses Ansatzes ist von der Grenze abhängig, die überschritten wird, da die Prozessidentität vom Zielsystem erkannt werden muss.

  Hierbei wird davon ausgegangen, dass Aufrufe auf eine der nachfolgenden Arten erfolgen:

  • Innerhalb derselben Windows-Sicherheitsdomäne

  • Über Windows-Sicherheitsdomänen hinweg (unter Verwendung von Vertrauens- und Domänenkonten bzw. von duplizierten Benutzernamen und Kennwörtern, wenn keine Vertrauensstellung besteht)

• Dienstkonto. Bei diesem Ansatz kommt ein (festes) Dienstkonto zum Einsatz. Beispiel:

  • Für den Datenbankzugriff handelt es sich hierbei möglicherweise um einen festen SQL-Benutzernamen und das entsprechende Kennwort, die durch die Komponente dargestellt werden, die die Datenbankverbindung herstellt.

  • Wenn eine feste Windows-Identität erforderlich ist, verwenden Sie eine Enterprise Services-Serveranwendung.

• Benutzerdefinierte Identität. Wenn Ihnen keine Windows-Konten zur Verfügung stehen, können Sie eigene Identitäten erstellen (mithilfe von IPrincipal- und IIdentity-Implementierungen), die auf Ihren spezifischen Sicherheitskontext bezogene Details enthalten. Hierzu zählen beispielsweise Rollenlisten, eindeutige Kennungen bzw. jegliche Art benutzerdefinierter Informationen.
  Wenn Sie Ihre benutzerdefinierte Identität mit IPrincipal und IIdentity implementieren und sie im aktuellen Webkontext platzieren (mit HttpContext.User), profitieren Sie umgehend von integrierten Gatekeepern wie .NET-Rollen und PrincipalPermission-Forderungen.

Aspekte bei der Identitätsübertragung berücksichtigen

Damit die Einzelbenutzerautorisierung, die Überwachung sowie die auf einzelne Benutzer bezogene Datenabfrage unterstützt werden, müssen Sie die Identität des ursprünglichen Aufrufers möglicherweise über mehrere Anwendungsebenen und mehrere Computergrenzen hinweg übertragen. Wenn beispielsweise ein Back-End-Ressourcen-Manager eine Einzelaufruferautorisierung vornehmen muss, muss die Identität des Aufrufers an diesen Ressourcen-Manager übertragen werden.

Basierend auf den Anforderungen Ihres Systems hinsichtlich Ressourcen-Manager-Autorisierung und Überwachung identifizieren Sie, welche Identitäten über Ihre Anwendung übertragen werden müssen.

Authentifizierungsansatz auswählen

Die beiden Schlüsselfaktoren, die sich auf Ihre Auswahl des Authentifizierungsansatzes auswirken, sind in erster Linie die Beschaffenheit der Benutzerbasis Ihrer Anwendung (welche Browsertypen verwendet werden und ob Windows-Konten vorhanden sind) und in zweiter Linie die Anforderungen Ihrer Anwendung hinsichtlich Identitätswechsel/Delegierung.

Weitere Informationen

Detailliertere Überlegungen, die Ihnen bei der Auswahl eines Authentifizierungsmechanismus für Ihre Anwendung behilflich sind, finden Sie unter "Auswählen eines Authentifizierungsmechanismus" weiter unten in diesem Modul.

Festlegen der Art der Identitätsübertragung

Sie können eine Identitätsübertragung (zur Bereitstellung eines Sicherheitskontexts) auf Anwendungsebene vornehmen. Die Identität und der Sicherheitskontext können auch auf Betriebssystemebene übertragen werden.

Um die Identität auf Anwendungsebene zu übertragen, verwenden Sie Methodenparameter und gespeicherte Prozedurparameter. Durch die Identitätsübertragung auf Anwendungsebene wird Folgendes unterstützt:

• Auf einzelne Benutzer bezogene Datenabfrage über vertrauenswürdige Abfrageparameter

    SELECT x,y FROM SomeTable WHERE username="Bob"

• Benutzerdefinierte Überwachung innerhalb beliebiger Anwendungsebenen

Durch die Identitätsübertragung auf Betriebssystemebene wird Folgendes unterstützt:

• Überwachung auf Plattformebene (z. B. Windows-Überwachung und SQL Server-Überwachung)

• Einzelbenutzerautorisierung basierend auf Windows-Identitäten

Um die Identität auf Betriebssystemebene zu übertragen, können Sie das Modell mit Identitätswechsel/Delegierung verwenden. In einigen Fällen kann die Kerberos-Delegierung verwendet werden, in anderen (in denen die Systemumgebung Kerberos z. B. nicht unterstützt) müssen Sie möglicherweise andere Ansätze verwenden, beispielsweise die Standardauthentifizierung. Bei der Standardauthentifizierung stehen die Anmeldeinformationen des Benutzers der Serveranwendung zur Verfügung und sind für den Zugriff auf Downstream-Netzwerkressourcen zu verwenden.

Weitere Informationen

Weitere Informationen zur Identitätsübertragung und zum Abruf eines Identitätswechsel-Tokens mit Netzwerkanmeldeinformationen (also mit Delegierungsunterstützung) finden Sie unter "Übertragen der Identität" weiter unten in diesem Modul.

 

Autorisierungsansätze

Hinsichtlich der Autorisierung gibt es zwei grundlegende Ansätze:

• Rollenbasierte Autorisierung. Benutzer werden in anwendungsdefinierte logische Rollen unterteilt. Mitglieder einer bestimmten Rolle weisen in der jeweiligen Anwendung dieselben Berechtigungen auf. Der Zugriff auf Operationen (erfolgt normalerweise über Methodenaufrufe) wird basierend auf der Rollenmitgliedschaft des Aufrufers autorisiert.
  Auf Ressourcen wird über feste Identitäten (z. B. die Prozessidentität einer Webanwendung oder eines Webdienstes) zugegriffen. Die Ressourcen-Manager vertrauen der Anwendung hinsichtlich der ordnungsgemäßen Autorisierung von Benutzern und autorisieren die vertrauenswürdige Identität.

• Ressourcenbasierte Autorisierung. Einzelne Ressourcen werden über Windows-ACLs gesichert. Durch die ACL wird bestimmt, welche Benutzer auf die Ressource zugreifen dürfen und welche Operationen die einzelnen Benutzer durchführen dürfen (Lesen, Schreiben, Löschen usw.).
  Der Zugriff auf Ressourcen erfolgt über die Identität des ursprünglichen Aufrufers (durch Identitätswechsel).

Rollenbasierte Autorisierung

Wenn der Sicherheitsansatz rollen- oder operationsbasiert ist, wird der Zugriff auf Operationen (nicht auf Back-End-Ressourcen) basierend auf der Rollenmitgliedschaft des Aufrufers autorisiert. Rollen (die beim Entwurf der Anwendung analysiert und definiert wurden) werden als logische Container verwendet, in der Benutzer zusammengefasst werden, die innerhalb der Anwendung über dieselben Sicherheitsberechtigungen (oder -funktionen) verfügen. Die Benutzer werden in der Anwendung Rollen zugeordnet. Über die Rollenmitgliedschaft wird der Zugriff auf spezifische Operationen (Methoden) gesteuert, die die Anwendung bereitstellt.

An welcher Stelle in der Anwendung diese Rollenzuordnung vorgenommen wird, ist ein Schlüsselkriterium in der Entwurfsphase. Ein Beispiel:

• Im einen Extremfall wird die Rollenzuordnung in einem Back-End-Ressourcen-Manager vorgenommen, beispielsweise in einer Datenbank. Hierfür muss der Sicherheitskontext des ursprünglichen Aufrufers auf sämtliche Ebenen der Anwendung bis hin zur Back-End-Datenbank übertragen werden.

• Im anderen Extremfall wird die Rollenzuordnung möglicherweise in Ihrer Front-End-Webanwendung vorgenommen. Bei diesem Ansatz erfolgt der Zugriff auf Downstream-Ressourcen-Manager über die festen Identitäten, die von sämtlichen Ressourcen-Managern autorisiert werden und denen die Ressourcen-Manager vertrauen.

• Die dritte Möglichkeit besteht darin, die Rollenzuordnung an einer beliebigen Stelle zwischen Front-End- und Back-End-Ebenen durchzuführen, beispielsweise in einer Enterprise Services-Anwendung der mittleren Ebene.

In Webanwendungen mit mehreren Ebenen sind durch vertrauenswürdige Identitäten für den Zugriff auf Back-End-Ressourcen-Manager mehr Möglichkeiten hinsichtlich der Anwendungsskalierbarkeit verfügbar (dank Verbindungspooling). Außerdem muss bei der Verwendung vertrauenswürdiger Identitäten der Sicherheitskontext des ursprünglichen Aufrufers nicht unbedingt auf Betriebssystemebene übertragen werden, ein Vorgang, der in bestimmten Szenarios schwierig (wenn nicht sogar unmöglich) ist.

Ressourcenbasierte Autorisierung

Der ressourcenbasierte Autorisierungsansatz baut auf Windows-ACLs und den zugrunde liegenden Zugriffssteuerungsmechanismen des Betriebssystems auf. Die Anwendung nimmt die Identität des Aufrufers an und überlässt die Zugriffsüberprüfungen dem Betriebssystem und den spezifischen Ressourcen-Managern (Dateisystem, Datenbank usw.).

Dieser Ansatz eignet sich in der Regel am besten für Anwendungen, die Zugriff auf Ressourcen ermöglichen, die durch Windows-ACLs individuell gesichert werden können, beispielsweise Dateien. Beispiele hierfür sind eine FTP-(File Transfer Protocol-)Anwendung oder eine einfache datengesteuerte Webanwendung. Die Schwachstellen des Ansatzes zeigen sich, wenn die angeforderte Ressource aus Daten besteht, die von mehreren unterschiedlichen Quellen abgerufen und konsolidiert werden müssen, beispielsweise aus mehreren Datenbanken, Datenbanktabellen, externen Anwendungen oder Webdiensten.

Der ressourcenbasierte Ansatz basiert außerdem darauf, dass der Sicherheitskontext des ursprünglichen Aufrufers in der Anwendung bis zu den Back-End-Ressourcen-Managern übertragen wird. Hierfür sind möglicherweise komplexe Konfigurationsschritte erforderlich. Die Fähigkeit einer Anwendung mit mehreren Ebenen zur Skalierung einer großen Benutzeranzahl wird vermindert, da die effiziente Nutzung des Poolings (z. B. Datenbankverbindungspooling) in der mittleren Ebene der Anwendung verhindert wird.

Ressourcenzugriffsmodelle

Die beiden gegensätzlichen Ansätze hinsichtlich der Autorisierung werden anhand der beiden am häufigsten verwendeten Ressourcenzugriffs-Sicherheitsmodelle verdeutlicht, die von .NET-Webanwendungen (und verteilten Anwendungen mit mehreren Ebenen im Allgemeinen) verwendet werden. Nachfolgend die beiden Modelle:

• Modell der vertrauenswürdigen Subsysteme

• Modell mit Identitätswechsel/Delegierung

Jedes Modell hat sowohl in Bezug auf Sicherheit als auch in Bezug auf Skalierbarkeit Vor- und Nachteile. In den nachfolgenden Abschnitten werden diese Modelle erläutert.

Modell der vertrauenswürdigen Subsysteme

Bei diesem Modell verwendet der Dienst der mittleren Ebene eine feste Identität, um auf Downstream-Dienste und Ressourcen zuzugreifen. Der Sicherheitskontext des ursprünglichen Aufrufers wird auf Betriebssystemebene nicht für den gesamten Dienst übertragen, obwohl in der Anwendung die Möglichkeit besteht, die Identität des ursprünglichen Aufrufers auf Anwendungsebene zu übertragen. Dieser Schritt ist möglicherweise zur Unterstützung von Back-End-Überwachungsanforderungen bzw. zur Unterstützung des Einzelbenutzer-Datenzugriffs und der Einzelbenutzer-Autorisierung erforderlich.

Der Modellname ist auf die Tatsache zurückzuführen, dass der Downstream-Dienst (möglicherweise eine Datenbank) dem Upstream-Dienst hinsichtlich der Autorisierung von Aufrufern vertraut. In Abbildung 3.1 ist dieses Modell dargestellt. Achten Sie besonders auf die Vertrauensgrenze. In diesem Beispiel vertraut die Datenbank der mittleren Ebene hinsichtlich der Autorisierung von Aufrufern und dahin gehend, dass nur autorisierten Aufrufern über die vertrauenswürdige Identität auf die Datenbank zugreifen.

Abbildung 3.1
Modell der vertrauenswürdigen Subsysteme

Das Muster für den Ressourcenzugriff auf das Modell der vertrauenswürdigen Subsysteme gestaltet sich wie folgt:

• Authentifizierung von Benutzern durchführen

• Benutzern Rollen zuweisen

• Autorisierung basierend auf Rollenmitgliedschaft durchführen

• Über eine feste Identität auf den Downstream-Ressourcen-Manager zugreifen

Feste Identitäten

Die feste Identität, die für den Zugriff auf Downstream-Systeme und -Ressourcen-Manager verwendet wird, wird häufig von einem vorkonfigurierten Windows-Konto bereitgestellt, das als Dienstkonto bezeichnet wird. Bei einem Ressourcen-Manager von Microsoft SQL Server™ bedeutet dies die Windows-Authentifizierung.

In einigen Anwendungen kommt für den Zugriff auf SQL Server alternativ ein nominiertes SQL-Konto (durch Angabe eines Benutzernamens und eines Kennworts in einer Verbindungszeichenfolge) zum Einsatz. In diesem Szenario muss die Datenbank für die SQL-Authentifizierung konfiguriert werden.

Weitere Informationen zu den Vorzügen der Windows- und SQL-Authentifizierung bei der Kommunikation mit SQL Server finden Sie in Modul 12, "Datenzugriffssicherheit".

Arbeiten mit mehreren vertrauenswürdigen Identitäten

Einige Ressourcen-Manager müssen die Möglichkeit haben, eine etwas differenziertere Autorisierung durchzuführen, basierend auf der Rollenmitgliedschaft des Aufrufers. Ihnen stehen beispielsweise zwei Benutzergruppen zur Verfügung, von denen eine zur Durchführung von Lese-/Schreiboperationen und die andere für schreibgeschützte Operationen autorisiert werden soll.

Ziehen Sie folgenden Ansatz mit SQL Server in Betracht:

• Erstellen Sie zwei Windows-Konten, eines für Leseoperationen und eines für Lese-/Schreiboperationen.
  Allgemeiner ausgedrückt verfügen Sie über zwei separate Konten, die die anwendungsspezifischen Rollen widerspiegeln. So möchten Sie beispielsweise ein Konto für Internetbenutzer und das andere für interne Operatoren und/oder Administratoren nutzen.

• Jedes Konto einer benutzerdefinierten SQL Server-Datenbankrolle zuordnen und die erforderlichen Datenbankberechtigungen für jede Rolle einrichten.

• Benutzer in Ihrer Anwendung Rollen zuordnen und anhand der Rollenmitgliedschaft vor dem Verbindungsaufbau mit der Datenbank ermitteln, die Identität welchen Kontos angenommen werden soll.

Dieser Ansatz ist in Abbildung 3.2 dargestellt.

Abbildung 3.2
Differenziertere Autorisierung durch Verwendung mehrerer Identitäten für den Datenbankzugriff

Modell mit Identitätswechsel/Delegierung

Bei diesem Modell nimmt ein Dienst oder eine Komponente (üblicherweise auf der Ebene für logische Geschäftsdienste) die Identität des Clients an (durch Identitätswechsel auf Betriebssystemebene), bevor der Zugriff auf den nachfolgenden Downstream-Dienst erfolgt. Wenn sich der nachfolgende Dienst auf demselben Computer befindet, ist der Identitätswechsel ausreichend. Die Delegierung wird erforderlich, wenn sich der Downstream-Dienst auf einem Remotecomputer befindet.

Als Folge der Delegierung handelt es sich beim für den Zugriff auf Downstream-Ressourcen verwendeten Sicherheitskontext um den des Clients. Dieses Modell wird normalerweise aus folgenden Gründen verwendet:

• Es ermöglicht dem Downstream-Dienst die Einzelbenutzer-Autorisierung über die Identität des ursprünglichen Aufrufers.

• Es ermöglicht dem Downstream-Dienst die Verwendung der Überwachungsfunktionen auf Betriebssystemebene.

In einem konkreten Beispiel dieser Technik nimmt eine Enterprise Services-Komponente der mittleren Ebene die Identität des Aufrufers an, bevor der Zugriff auf eine Datenbank erfolgt. Der Zugriff auf die Datenbank erfolgt über eine Datenbankverbindung, die an den Sicherheitskontext des ursprünglichen Aufrufers gebunden ist. Bei diesem Modell authentifiziert die Datenbank jeden einzelnen Aufrufer und trifft Autorisierungsentscheidungen basierend auf den Berechtigungen, die der Identität des jeweiligen Aufrufers zugewiesen wurden (bzw. basierend auf der Windows-Gruppenmitgliedschaft des Aufrufers). Das Modell mit Identitätswechsel/Delegierung wird in Abbildung 3.3 dargestellt.

Abbildung 3.3
Modell mit Identitätswechsel/Delegierung

Auswählen eines Ressourcenzugriffsmodells

Das Modell der vertrauenswürdigen Subsysteme kommt in den meisten Internetanwendungen und umfassenden Intranetanwendungen zum Einsatz, hauptsächlich aus Gründen der Skalierbarkeit. Das Modell mit Identitätswechsel kommt häufiger in weniger umfangreichen Anwendungen zum Einsatz, in denen die Skalierbarkeit nicht oberste Priorität hat, sowie in Anwendungen, in denen die Überwachung (aus Gründen der Unleugbarkeit) von essenzieller Bedeutung ist.

Vorteil des Modells mit Identitätswechsel/Delegierung

Der größte Vorteil des Modells mit Identitätswechsel/Delegierung ist die Überwachung (nahe an den Daten). Mithilfe der Überwachung können Administratoren verfolgen, welche Benutzer versucht haben, auf spezifische Ressourcen zuzugreifen. Im Allgemeinen gilt der autorisierende Grad der Überwachung dann als am höchsten, wenn die Überwachungen zum genauen Zeitpunkt des Ressourcenzugriffs generiert werden und durch die Routinen, die auf die Ressource zugreifen.

Das Modell mit Identitätswechsel/Delegierung unterstützt diesen Vorgang durch die Verwaltung des Sicherheitskontextes des Benutzers hinsichtlich des Downstream-Ressourcenzugriffs. Hierdurch kann das Back-End-System den Benutzer und den angeforderten Zugriff autorisierend protokollieren.

Nachteile des Modells mit Identitätswechsel/Delegierung

Zu den Nachteilen im Zusammenhang mit dem Modell mit Identitätswechsel/Delegierung zählen:

• Technologische Herausforderungen. Der Großteil der Anbieter von Sicherheitsdiensten unterstützt die Delegierung nicht. Kerberos ist hier als einzige Ausnahme zu nennen.
  Für Prozesse, die Identitätswechsel vornehmen, sind höhere Sicherheitsberechtigungen erforderlich (insbesondere die Berechtigung Einsetzen als Teil des Betriebssystems). (Diese Einschränkung gilt für Windows 2000, wird sich jedoch nicht auf Windows 2003 Server auswirken.)

• Skalierbarkeit. Beim Modell mit Identitätswechsel/Delegierung kann das Datenbankverbindungspooling nicht effektiv eingesetzt werden, da der Datenbankzugriff über Verbindungen erfolgt, die an die jeweiligen Sicherheitskontexte der ursprünglichen Aufrufer gebunden sind. Hierdurch wird die Fähigkeit der Anwendung zur Skalierung großer Benutzerzahlen nachhaltig beeinträchtigt.

• Größerer Verwaltungsaufwand. ACLs müssen in Back-End-Ressourcen so verwaltet werden, dass jedem Benutzer die richtige Zugriffsstufe gewährt wird. Wenn sich die Anzahl der Back-End-Ressourcen (und die Anzahl der Benutzer) erhöht, ist für die Verwaltung von ACLs ein sehr großer Verwaltungsaufwand erforderlich.

Vorteile des Modells der vertrauenswürdigen Subsysteme

Das Modell der vertrauenswürdigen Subsysteme weist folgende Vorteile auf:

• Skalierbarkeit. Das Modell der vertrauenswürdigen Subsysteme unterstützt das Verbindungspooling, das für die Anwendungsskalierbarkeit essenziell ist. Durch das Verbindungspooling können Clients in einem Pool zusammengefasste Verbindungen erneut verwenden. Dies ist bei diesem Modell möglich, da bei jeglichem Back-End-Ressourcenzugriff der Sicherheitskontext des Dienstkontos verwendet wird, ungeachtet der Identität des Aufrufers.

• Minimaler Verwaltungsaufwand bei Back-End-ACLs. Nur das Dienstkonto greift auf Back-End-Ressourcen (z. B. Datenbanken) zu. ACLs werden anhand dieser einen Identität konfiguriert.

• Benutzer können nicht direkt auf Daten zugreifen. Im Modell mit vertrauenswürdigen Subsystemen wird nur dem Dienstkonto der mittleren Ebene der Zugriff auf die Back-End-Ressourcen gewährt. Folglich können Benutzer nicht direkt auf Back-End-Daten zugreifen. Sie müssen über die Anwendung darauf zugreifen und die Anwendungsautorisierung durchlaufen.

Nachteile des Modells der vertrauenswürdigen Subsysteme

Das Modell der vertrauenswürdigen Subsysteme hat einige Nachteile:

• Überwachung. Um die Überwachung am Back-End durchzuführen, können Sie (auf Anwendungsebene) die Identität des ursprünglichen Aufrufers explizit an das Back-End übertragen und die Überwachung dort durchführen. Wahlweise können Sie in der mittleren Ebene eine Überwachungsliste generieren und sie dann in Wechselbeziehung mit Back-End-Überwachungslisten setzen (Voraussetzung hierfür ist, dass die Serveruhren synchron laufen).

• Höheres Risiko durch Servergefährdung. Im Modell mit vertrauenswürdigen Subsystemen wird dem Dienst der mittleren Ebene umfassender Zugriff auf Back-End-Ressourcen gewährt. Folglich kann ein Angreifer durch einen gefährdeten Dienst der mittleren Ebene einfacher umfassenden Zugriff auf Back-End-Ressourcen erlangen.

 

Übertragen der Identität

Verteilte Anwendungen sind in mehrere sichere Subsysteme zu unterteilen. So stellen beispielsweise eine Front-End-Webanwendung, ein Webdienst der mittleren Schicht, eine Remotekomponente und eine Datenbank vier unterschiedliche Sicherheitssubsysteme dar. In jedem werden Authentifizierung und Autorisierung vorgenommen.

Sie müssen die Subsysteme identifizieren, die die Identität des Aufrufers (und den zugehörigen Sicherheitskontext) an das nachfolgende Downstream-Subsystem übertragen müssen, damit die Autorisierung anhand des ursprünglichen Aufrufers unterstützt wird.

Identitätsübertragung auf Anwendungsebene im Vergleich zur Identitätsübertragung auf Betriebssystemebene

Zu den Strategien für die Identitätsübertragung zählen die Verwendung der Delegierungsfunktionen des Betriebssystems bzw. das Übermitteln von Tickets und/oder Anmeldeinformationen auf Anwendungsebene. Beispiel:

• Um die Identität auf Anwendungsebene zu übertragen, werden normalerweise Anmeldeinformationen (oder Tickets) mithilfe von Methodenparametern und gespeicherten Prozedurparametern übermittelt.

  Hinweis: GenericPrincipal-Objekte, die die Identität des authentifizierten Aufrufers beinhalten, werden nicht automatisch prozessübergreifend übertragen. Hierfür ist benutzerdefinierter Code erforderlich.

  Sie können Parameter an gespeicherte Prozeduren übermitteln, die das Abrufen und Verarbeiten benutzerspezifischer Daten ermöglichen. Beispiel:

  SELECT CreditLimit From Table Where UserName="Bob"
  

  Dieser Ansatz wird in einigen Fällen als Ansatz mit vertrauenswürdigen Abfrageparametern bezeichnet.

• Für die Identitätsübertragung auf Betriebssystemebene ist die Delegierung als erweiterte Form des Identitätswechsels erforderlich.

Identitätswechsel und Delegierung

Im Normalfall werden Threads innerhalb einer Serveranwendung mithilfe des Sicherheitskontextes des Serverprozesses ausgeführt. Die Attribute mit dem Sicherheitskontext des Prozesses werden durch die Anmeldesitzung des Prozesses verwaltet und durch das Windows-Zugriffstoken auf Prozessebene bereitgestellt. Jeglicher lokale Ressourcenzugriff und jeglicher Remote-Ressourcenzugriff wird mithilfe des Sicherheitskontextes auf Prozessebene durchgeführt, den das Windows-Konto bestimmt, über das der Serverprozess ausgeführt wird.

Identitätswechsel

Wenn eine Serveranwendung für den Identitätswechsel konfiguriert ist, wird ein Identitätswechsel-Token an den Thread angehängt, der zur Verarbeitung einer Anforderung dient. Das Identitätswechsel-Token stellt den Sicherheitskontext des authentifizierten Aufrufers (bzw. des anonymen Benutzers) dar. Jeglicher lokale Ressourcenzugriff erfolgt durch den Thread des Identitätswechsel-Tokens, der sich aus der Verwendung des Sicherheitskontextes des Aufrufers ergibt.

Delegierung

Wenn ein Serveranwendungsthread auf eine Remoteressource zuzugreifen versucht, ist die Delegierung erforderlich. Insbesondere muss das Token des Aufrufers mit der gewechselten Identität über Netzwerkanmeldeinformationen verfügen. Andernfalls erfolgt jeglicher Remote-Zugriff als anonymer Benutzer (AUHORITY\ANONYMOUS-ANMELDUNG).

Es gibt einige Faktoren, durch die bestimmt wird, ob die Delegierung eines Sicherheitskontextes möglich ist. In Tabelle 3.1 werden die unterschiedlichen IIS-Authentifizierungstypen aufgeführt, und es wird jeweils angegeben, ob der Sicherheitskontext des authentifizierten Aufrufers delegiert werden kann.

Tabelle 3.1: IIS- Authentifizierungstypen

Authentifizierungstyp	Delegierung möglich	Hinweise
Anonym	Vom Einzelfall abhängig	Wenn das anonyme Konto (standardmäßig IUSR_MACHINE) in IIS als lokales Konto konfiguriert wurde, ist die Delegierung nur möglich, wenn der lokale Computer (Webserver) und der Remotecomputer über identische lokale Konten (mit übereinstimmenden Benutzernamen und Kennwörtern) verfügen. Wenn das anonyme Konto ein Domänenkonto ist, kann es delegiert werden.
Standard	Ja	Wird die Standardauthentifizierung mit lokalen Konten verwendet, ist die Delegierung möglich, wenn die lokalen Konten auf den lokalen Computern und den Remotecomputern identisch sind. Domänenkonten können ebenfalls delegiert werden.
Digest	Nein
In Windows integriert	Vom Einzelfall abhängig	Die integrierte Windows-Authentifizierung führt entweder zu NTLM oder Kerberos (abhängig von der Betriebssystemversion auf Client- und Servercomputer). NTLM unterstützt die Delegierung nicht. Kerberos unterstützt die Delegierung mit einer entsprechend konfigurierten Systemumgebung. Weitere Informationen finden Sie unter "Vorgehensweise: Implementieren der Kerberos-Delegierung unter Windows 2000" in diesem Handbuch.
Clientzertifikate	Vom Einzelfall abhängig	Können delegiert werden, wenn sie gemeinsam mit der IIS-Zertifikatszuordnung verwendet werden und das Zertifikat einem lokalen Konto zugeordnet ist, das auf dem Remotecomputer dupliziert oder einem Domänenkonto zugeordnet ist. Dies ist möglich, da die Anmeldeinformationen für das zugeordnete Konto auf dem lokalen Server gespeichert und zur Erstellung einer interaktiven Anmeldesitzung (mit Netzwerkanmeldeinformationen) verwendet werden. Von der Active Directory-Zertifikatszuordnung wird die Delegierung nicht unterstützt.

Wichtig: Hinsichtlich der Kerberos-Delegierung unter Windows 2000 gibt es keinerlei Einschränkungen. Folglich ist es einem Benutzer möglich, über mehrere Remotecomputer hinweg mehrere Netzwerkhops durchzuführen. Um dieses potenzielle Sicherheitsrisiko zu eliminieren, sollten Sie die Reichweite des Domänenkontos einschränken, indem Sie das Konto aus der Gruppe "Domänenbenutzer" entfernen und festlegen, dass das Konto nur zur Anmeldung bei bestimmten Computern verwendet werden darf.

 

Rollenbasierte Autorisierung

In den meisten .NET-Webanwendungen wird hinsichtlich der Autorisierung ein rollenbasierter Ansatz verwendet. Sie müssen die unterschiedlichen Rollentypen in Betracht ziehen und diejenigen auswählen, die für Ihr Anwendungsszenario am besten geeignet sind. Folgende Optionen stehen zur Wahl:

• .NET-Rollen

• Enterprise Services (COM+)-Rollen

• Benutzerdefinierte Datenbankrollen in SQL Server

• SQL Server-Anwendungsrollen

.NET-Rollen

.NET-Rollen sind äußerst flexibel und drehen sich um IPrincipal-Objekte, die die Liste der Rollen enthalten, der eine authentifizierte Identität angehört. .NET-Rollen können in Webanwendungen, Webdiensten oder Remotekomponenten verwendet werden, für die ASP.NET als Host fungiert (und auf die über den HTTP-Kanal zugegriffen wird).

Die Autorisierung kann mit .NET-Rollen entweder deklarativ über PrincipalPermission-Forderungen oder programmatisch in Code durchgeführt werden, wobei imperative PrincipalPermission-Forderungen verwendet werden (oder die IPrincipal.IsInRole-Methode).

.NET-Rollen bei Windows-Authentifizierung

Verwendet Ihre Anwendung die Windows-Authentifizierung, erstellt ASP.NET automatisch ein WindowsPrincipal-Objekt, das an den Kontext der aktuellen Webanforderung angehängt wird (über HttpContext.User). Nachdem der Authentifizierungsprozess abgeschlossen ist und ASP.NET das Objekt an die aktuelle Anforderung angehängt hat, wird es für alle nachfolgenden rollenbasierten Autorisierungsvorgängen in .NET verwendet.

Mithilfe der Windows-Gruppenmitgliedschaft des authentifizierten Aufrufers wird die Rollenliste ermittelt. Bei der Windows-Authentifizierung stimmen .NET-Rollen und Windows-Gruppen überein.

.NET-Rollen bei nicht unter Windows durchgeführter Authentifizierung

Wenn in Ihrer Anwendung ein nicht unter Windows durchgeführter Authentifizierungsmechanismus verwendet wird, beispielsweise die Formular- oder Passport-Authentifizierung, müssen Sie Code verfassen, um ein GenericPrincipal-Objekt (oder ein benutzerdefiniertes IPrincipal-Objekt) zu erstellen. Dieses müssen Sie im Anschluss mit einer Rollenliste füllen, die aus einem benutzerdefinierten Authentifizierungsdatenspeicher, beispielsweise einer SQL Server-Datenbank, abgerufen wurde.

Benutzerdefinierte IPrincipal-Objekte

Der rollenbasierte Sicherheitsmechanismus in .NET ist erweiterungsfähig. Sie können eigene Klassen erstellen, die IPrincipal und IIdentity implementieren und Ihre persönliche erweiterte rollenbasierte Autorisierungfunktionalität zur Verfügung stellen.

Solange das benutzerdefinierte IPrincipal-Objekt (das die aus einem benutzerdefinierten Datenspeicher abgerufenen Rollen enthält) an den aktuellen Anforderungskontext angehängt ist (über HttpContext.User), ist die grundlegende Funktionalität zur Rollenüberprüfung gewährleistet.

Durch Implementierung der IPrincipal-Schnittstelle stellen Sie sicher, dass sowohl deklarative als auch imperative Formen von PrincipalPermission-Forderungen mit Ihrer benutzerdefinierten Identität verwendet werden können. Des Weiteren können Sie erweiterte Rollensemantik implementieren, indem Sie eine zusätzliche Methode bereitstellen, beispielsweise IsInMultipleRoles( string [] roles ) , die es Ihnen ermöglicht, Test und Assertion hinsichtlich der Mitgliedschaft mehrerer Rollen durchzuführen.

Weitere Informationen

• Weitere Informationen zur rollenbasierten Autorisierung in .NET finden Sie in Modul 8, "ASP.NET-Sicherheit".

• Weitere Informationen zur Erstellung von GenericPrincipal-Objekten finden Sie unter "Vorgehensweise: Erstellen von GenericPrincipal-Objekten bei der Formularauthentifizierung" in diesem Handbuch.

Enterprise Services-(COM+-)Rollen

Wenn Enterprise Services-(COM+-)Rollen verwendet werden, wird die Durchführung von Zugriffsüberprüfungen auf die mittlere Ebene übertragen. Dabei können Sie bei der Verbindungsherstellung mit Back-End-Datenbanken das Datenbankverbindungspooling nutzen. Für die sinnvolle rollenbasierte Autorisierung in Enterprise Services (COM+) muss jedoch Ihre Front-End-Webanwendung die Identität des ursprünglichen Aufrufers annehmen und sie (mithilfe eines Windows-Zugriffstokens) an die Enterprise Services-Anwendung übertragen. Hierzu müssen die nachfolgenden Einträge in die Datei Web.config der Webanwendung aufgenommen werden.

<authentication mode="Windows" />
<identity impersonate="true" />

Wenn die Verwendung deklarativer Überprüfungen auf Methodenebene ausreichend ist (um herauszufinden, welche Benutzer welche Methoden aufrufen können), können Sie über das Verwaltungstool der Komponentendienste Ihre Anwendung bereitstellen und die Rollenmitgliedschaft aktualisieren.

Wenn programmatische Überprüfungen im Methodencode erforderlich sind, gehen einige der verwaltungs- und bereitstellungsbezogenen Vorteile von Enterprise Services-(COM+-)Rollen verloren, da die Rollenlogik hartcodiert ist.

Benutzerdefinierte Datenbankrollen in SQL Server

Bei diesem Ansatz erstellen Sie Rollen in der Datenbank, weisen basierend auf den Rollen Berechtigungen zu und ordnen den Rollen Windows-Gruppen- und Benutzerkonten zu. Bei diesem Ansatz muss die Identität des Aufrufers an das Back-End übertragen werden (wenn die bevorzugte Windows-Authentifizierung bei SQL Server verwendet wird).

SQL Server-Anwendungsrollen

Bei diesem Ansatz werden den Rollen in der Datenbank Berechtigungen erteilt, SQL Server-Anwendungsrollen umfassen jedoch keine Benutzer- oder Gruppenkonten. Folglich geht die Granularität des ursprünglichen Aufrufers verloren.

Über Anwendungsrollen autorisieren Sie den Zugriff auf eine spezifische Anwendung (nicht auf eine Gruppe von Benutzern). Die Anwendung aktiviert die Rolle über eine integrierte gespeicherte Prozedur, die einen Rollennamen und ein Kennwort akzeptiert. Einer der größten Nachteile dieses Ansatzes liegt darin, dass die sichere Verwaltung von Anmeldeinformationen (Rollenname und zugehöriges Kennwort) durch die Anwendung erforderlich ist.

Weitere Informationen

Weitere Informationen zu benutzerdefinierten Datenbankrollen und Anwendungsrollen in SQL Server finden Sie in Modul 12, "Datenzugriffssicherheit."

.NET-Rollen im Vergleich zu Enterprise Services-(COM+-)Rollen

In der nachfolgenden Tabelle werden die Funktionen von .NET-Rollen und Enterprise Services-(COM+-)Rollen verglichen.

Tabelle 3.2: Vergleich von Enterprise Services-Rollen und .NET-Rollen

Funktion	Enterprise Services-Rollen	.NET-Rollen
Verwaltung	Verwaltungstool der Komponentendienste	Benutzerdefiniert
Datenspeicher	COM+-Katalog	Benutzerdefinierter Datenspeicher (z. B. SQL Server oder Active Directory)
Deklarativ	Ja [SecurityRole("Manager")]	Ja [PrincipalPermission (SecurityAction.Demand,Role="Manager")]
Imperativ	Ja ContextUtil.IsCallerInRole()	Ja IPrincipal.IsInRole
Granularität auf Klassen-, Schnittstellen- und Methodenebene	Ja	Ja
Erweiterbar	Nein	Ja (über benutzerdefinierte IPrincipal-Implementierung)
Für alle .NET-Komponenten verfügbar	Nur für von der ServicedComponent-Basisklasse abgeleitete Komponenten	Ja
Rollenmitgliedschaft	Rollen umfassen Windows-Gruppen- oder Benutzerkonten	Bei der Verwendung von WindowsPrincipals SIND Rollen Windows-Gruppen – keine zusätzliche Abstraktionsebene
Erfordert explizite Schnittstellenimplementierung	Ja Zur Ermöglichung der Autorisierung auf Methodenebene muss eine Schnittstelle explizit definiert und implementiert werden	Nein

Arbeiten mit .NET-Rollen

Folgende Elemente können durch .NET-Rollen gesichert werden:

• Dateien

• Ordner

• Webseiten (.aspx-Dateien)

• Webdienste (.asmx-Dateien)

• Objekte

• Methoden und Eigenschaften

• Codeblöcke in Methoden

Da Sie mit .NET-Rollen Operationen (die von Methoden und Eigenschaften durchgeführt werden) sowie spezifische Codeblocks schützen können, können Sie den Zugriff auf lokale Ressourcen und Remoteressourcen durch Ihre Anwendung schützen.

Hinweis: Die ersten vier Elemente in obiger Liste (Dateien, Ordner, Webseiten und Webdienste) werden über das UrlAuthorizationModule geschützt, das mithilfe der Rollenmitgliedschaft des Aufrufers (und seiner Identität) Autorisierungsentscheidungen treffen kann.

Die Windows-Authentifizierung nimmt Ihnen ein Großteil der Schritte ab, die für die Verwendung von .NET-Rollen durchzuführen sind. ASP.NET erstellt ein WindowsPrincipal-Objekt, und durch die Windows-Gruppenmitgliedschaft des Benutzers wird die zugehörige Rollenliste bestimmt.

Zur Verwendung von .NET-Rollen mit einem Nicht-Windows-Authentifizierungsmechanismus muss Code für folgende Zwecke geschrieben werden:

• Erfassung der Anmeldeinformationen des Benutzers

• Überprüfung der Anmeldeinformationen des Benutzers anhand eines benutzerdefinierten Datenspeichers, beispielsweise einer SQL Server-Datenbank

• Abrufen einer Rollenliste, Erstellen eines GenericPrincipal-Objekts sowie Verknüpfen dieses Objekts mit der aktuellen Webanforderung
  Das GenericPrincipal-Objekt stellt den authentifizierten Benutzer dar und wird für nachfolgende .NET-Rollenüberprüfungen verwendet, beispielsweise deklarative PrincipalPermission-Forderungen und programmatische IPrincipal.IsInRole-Überprüfungen.

Weitere Informationen

Weitere Informationen über den Prozess der Erstellung eines GenericPrincipal-Objekts für die Formularauthentifizierung finden Sie in Modul 8, "ASP.NET-Sicherheit".

Überprüfen der Rollenmitgliedschaft

Folgende Arten von .NET-Rollenüberprüfungen sind verfügbar:

Wichtig: Die .NET-Rollenüberprüfung basiert darauf, dass ein IPrincipal-Objekt (das den authentifizierten Benutzer darstellt) mit der aktuellen Anforderung verknüpft wird. Bei ASP.NET-Webanwendungen muss das IPrincipal-Objekt an HttpContext.User angehängt werden. Bei Windows Formularanwendungen ist das IPrincipal-Objekt an den Thread.CurrentPrincipal anzuhängen.

• Manuelle Rollenüberprüfungen. Für die differenzierte Autorisierung können Sie die IPrincipal.IsInRole-Methode aufrufen, um den Zugriff auf spezifische Codeblöcke über die Rollenmitgliedschaft des Aufrufers zu autorisieren. Bei der Überprüfung der Rollenmitgliedschaft können die logischen Operatoren AND und OR verwendet werden.

• Deklarative Rollenüberprüfungen (Gates zu Ihren Methoden). Sie können Methoden mit der PrincipalPermissionAttribute-Klasse (die auf PrincipalPermission verkürzt werden kann) mit Anmerkungen versehen, um die Rollenmitgliedschaft deklarativ zu fordern. Hierbei wird nur die OR-Logik unterstützt. Sie können beispielsweise fordern, dass ein Aufrufer mindestens eine spezifische Rolle aufweist, also beispielsweise "Kassierer" oder "Manager" ist. Bei deklarativen Überprüfungen kann man nicht festlegen, dass ein Aufrufer Manager und Kassierer sein muss.

• Imperative Rollenüberprüfungen (Überprüfungen in Ihren Methoden). Sie können PrincipalPermission.Demand innerhalb von Code aufrufen, um eine differenziertere Autorisierungslogik anzuwenden. Logische AND- und OR-Operationen werden unterstützt.

Beispiele für die Rollenüberprüfung

In den nachfolgenden Codefragmenten sind Beispiele für Rollenüberprüfungen mit programmatischen, deklarativen und imperativen Techniken dargestellt.

Autorisieren von Bob zur Durchführung einer Operation:

Hinweis: Obwohl die Autorisierung einzelner Benutzer möglich ist, sollte die Autorisierung auf der Rollenmitgliedschaft basieren, da Sie auf diese Weise Gruppen von Benutzern autorisieren können, die in Ihrer Anwendung über dieselben Berechtigungen verfügen.

• Direkte Benutzernamenüberprüfung

  GenericIdentity userIdentity = new GenericIdentity("Bob");
  if (userIdentity.Name=="Bob")
  {
  }
  

• Deklarative Überprüfung

  [PrincipalPermissionAttribute(SecurityAction.Demand, User="Bob")]
  public void DoPrivilegedMethod()
  {
  }
  

• Imperative Überprüfung

  PrincipalPermission permCheckUser = new PrincipalPermission(
                                                 "Bob", null);
  permCheckUser.Demand();
  

Autorisieren von Kassierern zur Durchführung einer Operation:

• Direkte Rollennamenüberprüfung

  GenericIdentity userIdentity = new GenericIdentity("Bob");
  // Rollennamen werden ggf. aus einem benutzerdefinierten Datenspeicher abgerufen
  string[] roles = new String[]{"Manager", "Kassierer"};
  GenericPrincipal userPrincipal = new GenericPrincipal(userIdentity, 
                                                        roles);
  if (userPrincipal.IsInRole("Kassierer"))
  {
  }
  

• Deklarative Überprüfung

  [PrincipalPermissionAttribute(SecurityAction.Demand, Role="Kassierer")]
  void SomeTellerOnlyMethod()
  {
  }
  

• Imperative Überprüfung

  public SomeMethod()
  {
    PrincipalPermission permCheck = new PrincipalPermission(
                                                 null,"Kassierer");
    permCheck.Demand();
    // Nur Kassierer können den nachfolgenden Code ausführen
    // Bei Benutzern, die keine Kassierer sind, wird eine Sicherheitsausnahmebedingung erzeugt
    . . .
  }
  

Autorisieren von Managern ODER Kassierern zur Durchführung einer Operation:

• Direkte Rollennamenüberprüfung

  if (Thread.CurrentPrincipal.IsInRole("Kassierer") ||
      Thread.CurrentPrincipal.IsInRole("Manager"))
  {
    // Durchführung privilegierter Operationen
  }
  

• Deklarative Überprüfung

  [PrincipalPermissionAttribute(SecurityAction.Demand, Role="Kassierer"),
   PrincipalPermissionAttribute(SecurityAction.Demand, Role="Manager")]
  public void DoPrivilegedMethod()
  {
  ...
  }
  

• Imperative Überprüfung

  PrincipalPermission permCheckTellers = new PrincipalPermission( 
                                                     null,"Kassierer");
  PrincipalPermission permCheckManagers = new PrincipalPermission(
                                                     null,"Manager");
  

(permCheckTellers.Union(permCheckManagers)).Demand();

Autorisieren ausschließlich der Personen, die Manager UND Kassierer sind, zur Durchführung einer Operation:

• Direkte Rollennamenüberprüfung

  if (Thread.CurrentPrincipal.IsInRole("Kassierer") &&
      Thread.CurrentPrincipal.IsInRole("Manager"))
  {
    // Durchführung privilegierter Operation
  }
  

• Deklarative Überprüfung

  Es ist nicht möglich, mit .NET-Rollen deklarative AND-Überprüfungen durchzuführen. Wenn PrincipalPermission-Forderungen zu einem Stapel zusammengefasst werden, führt dies zu einer logischen OR-Operation.

• Imperative Überprüfung

  PrincipalPermission permCheckTellers = new PrincipalPermission(
                                                   null,"Kassierer");
  permCheckTellers.Demand();  
  PrincipalPermission permCheckManagers = new PrincipalPermission(
                                                   null, "Manager");
  permCheckManagers.Demand();
  

 

Auswählen eines Authentifizierungsmechanismus

In diesem Abschnitt finden Sie Anhaltspunkte, die Sie bei der Auswahl eines geeigneten Authentifizierungsmechanismus für gängige Anwendungsszenarios unterstützen. Zunächst sollten Sie folgende Punkte in Betracht ziehen:

• Identitäten. Ein Windows-Authentifizierungsmechanismus eignet sich nur, wenn die Benutzer Ihrer Anwendung über Windows-Konten verfügen, die über eine vertrauenswürdige Autorität zu authentifizieren sind, auf die man über den Webserver Ihrer Anwendung zugreifen kann.

• Verwaltung von Anmeldeinformationen. Einer der größten Vorteile der Windows-Authentifizierung ist es, die Verwaltung von Anmeldeinformationen dem Betriebssystem überlassen zu können. Bei Nicht-Windows-Ansätzen, beispielsweise bei der Formularauthentifizierung, müssen Sie sorgfältig erwägen, wo und wie Sie Benutzeranmeldeinformationen speichern. Bei den beiden gängigsten Ansätzen wird Folgendes verwendet:

  • SQL Server-Datenbanken

  • Benutzerobjekte innerhalb Active Directory

  Weitere Informationen zu den Sicherheitsaspekten bei der Verwendung von SQL Server als Speicher für Anmeldeinformationen finden Sie in Modul 12, "Datenzugriffssicherheit".

  Weitere Informationen zur Formularauthentifizierung für benutzerdefinierte Datenspeicher (einschließlich Active Directory) finden Sie in Modul 8, "ASP.NET-Sicherheit".

• Identitätsübertragung. Müssen Sie ein Modell mit Identitätswechsel/Delegierung implementieren und den Sicherheitskontext des ursprünglichen Aufrufers auf Systemebene ebenenübergreifend übertragen, beispielsweise, um die Unterstützung für Überwachung bzw. Einzelbenutzer-Autorisierung (differenzierte Autorisierung) bereitzustellen? In diesem Fall müssen Sie in der Lage sein, die Identität des Aufrufers anzunehmen und seinen Sicherheitskontext an das nachfolgende Downstream-Subsystem delegieren wie unter "Delegierung" im Abschnitt "Übertragen der Identität" weiter oben in diesem Modul beschrieben.

• Browsertyp. Verfügen alle Ihre Benutzer über Internet Explorer oder müssen Sie eine Benutzerbasis mit unterschiedlichen Browsertypen unterstützen? Aus Tabelle 3.3 geht hervor, für welche Authentifizierungsmechanismen Internet Explorer-Browser erforderlich ist, und welche eine Vielzahl gängiger Browsertypen unterstützen.

Tabelle 3.3: Browseranforderungen für die Authentifizierung

Authentifizierungstyp	Erfordert Internet Explorer	Hinweise
Formulare	Nein
Passport	Nein
Integrierte Windows-Authentifizierung (Kerberos oder NTLM)	Ja	Für Kerberos müssen außerdem auf den Client- und Servercomputern mindestens Windows 2000 vorhanden und Konten für die Delegierung konfiguriert sein. Weitere Informationen finden Sie unter "Vorgehensweise: Implementieren der Kerberos-Delegierung unter Windows 2000" in diesem Handbuch.
Standard	Nein	Die Standardauthentifizierung ist Bestandteil des HTTP 1.1-Protokolls, das von nahezu allen Browsern unterstützt wird.
Digest	Ja
Zertifikat	Nein	Für Clients sind X.509-Zertifikate erforderlich.

Internetszenarios

Die grundlegenden Annahmen hinsichtlich Internetszenarios sind:

• Die Benutzer verfügen in der Domäne des Servers bzw. in einer vertrauenswürdigen Domäne, auf die der Server zugreifen kann, nicht über Windows-Konten.

• Die Benutzer verfügen nicht über Clientzertifikate.

In Abbildung 3.4 wird ein Entscheidungsdiagramm zur Auswahl eines Authentifizierungsmechanismus für Internetszenarios dargestellt.

Abbildung 3.4
Auswählen eines Authentifizierungsmechanismus für Internetanwendungen

Weitere Informationen zur Webdienstesicherheit und der WS-Sicherheitsspezifikation, die Bestandteil der Global XML Architecture-(GXA-)Initiative ist, finden Sie in Modul 10, "Webdienstesicherheit".

Vergleich: Formulare/Passport

In diesem Abschnitt werden die Vorzüge der Formular- und der Passport-Authentifizierung zusammengefasst.

Vorteile der Formularauthentifizierung

• Unterstützt die Authentifizierung anhand eines benutzerdefinierten Datenspeichers; normalerweise handelt es sich hier um eine SQL Server-Datenbank oder Active Directory.

• Unterstützt die rollenbasierte Autorisierung mit Rollensuche in einem Datenspeicher.

• Nahtlose Integration in die Webbenutzeroberfläche.

• ASP.NET stellt einen Großteil der Infrastruktur bereit. Im Vergleich zu klassischem ASP ist verhältnismäßig wenig benutzerdefinierter Code erforderlich.

Vorteile der Passport-Authentifizierung

• Passport ist eine zentralisierte Lösung.

• Hierdurch werden Aspekte der Anmeldeinformationsverwaltung aus der Anwendung entfernt.

• Die Passport-Authentifizierung kann mit rollenbasierten Autorisierungsschemata verwendet werden.

• Sie ist ausgesprochen sicher, da sie auf Kryptografietechnologien aufbaut.

Weitere Informationen

• Weitere Informationen zu Ansätzen der Webdienstauthentifizierung finden Sie in Modul 10, "Webdienstesicherheit".

• Weitere Informationen zur Formularauthentifizierung mit SQL Server finden Sie unter "Vorgehensweise: Verwenden der Formularauthentifizierung mit SQL Server 2000" in diesem Handbuch.

Intranet-/Extranetszenarios

In Abbildung 3.5 ist ein Entscheidungsdiagramm dargestellt, das Ihnen bei der Auswahl eines Authentifizierungsmechanismus für Szenarios mit Intranet- und Extranetanwendungen behilflich ist.

Abbildung 3.5
Auswählen eines Authentifizierungsmechanismus für Intranet- und Extranetanwendungen

Vergleich von Authentifizierungsmechanismen

In der nachfolgenden Tabelle werden die verfügbaren Authentifizierungsmechanismen miteinander verglichen.

Tabelle 3.4: Verfügbare Authentifizierungsmethoden

	Standard	Digest	NTLM	Kerberos	Certs	Formulare	Passport
Benutzer benötigen Windows-Konten in der Domäne des Servers	Ja	Ja	Ja	Ja	Nein	Nein	Nein
Unterstützt die Delegierung*	Ja	Nein	Nein	Ja	Vom Einzelfall abhängig	Ja	Ja
Win2K-Clients und -Server erforderlich	Nein	Ja	Nein	Ja	Nein	Nein	Nein
Anmeldeinformationen werden als Klartext übermittelt (hierfür ist SSL erforderlich)	Ja	Nein	Nein	Nein	Nein	Ja	Nein
Unterstützt Nicht-IE-Browser	Ja	Nein	Nein	Nein	Ja	Ja	Ja

* Details finden Sie unter "Delegierung" im Abschnitt "Übertragen der Identität" weiter oben in diesem Modul.

 

Zusammenfassung

Das Entwerfen eines Authentifizierungs- und Autorisierungsansatzes für verteilte Anwendungen ist eine anspruchsvolle Aufgabe. Durch die Ausarbeitung eines geeigneten Authentifizierungs- und Autorisierungsentwurfs in der frühen Entwurfsphase Ihrer Anwendungsentwicklung lassen sich viele der größten Sicherheitsrisiken minimieren. Nachfolgend sind die in diesem Modul enthaltenen Informationen zusammengefasst:

• Verwenden Sie das Modell der vertrauenswürdigen Subsysteme für den Ressourcenzugriff, um von den Vorteilen des Datenbankverbindungspoolings zu profitieren.

• Wenn in Ihrer Anwendung keine Windows-Authentifizierung verwendet wird, stellen Sie die Autorisierungsaspekte über die .NET-Rollenüberprüfung bereit. Überprüfen Sie Anmeldeinformationen anhand eines benutzerdefinierten Datenspeichers, rufen Sie eine Rollenliste ab, und erstellen Sie ein GenericPrincipal-Objekt. Verknüpfen Sie es mit der aktuellen Webanforderung (HttpContext.User).

• Wenn in Ihrer Anwendung die Windows-Authentifizierung verwendet wird und nicht die Enterprise Services, verwenden Sie .NET-Rollen. Bedenken Sie, dass bei der Windows-Authentifizierung .NET-Rollen Windows-Gruppen sind.

• Wenn in Ihrer Anwendung sowohl die Windows-Authentifizierung als auch Enterprise Services verwendet werden, sollten Sie Enterprise Services-(COM+-)Rollen verwenden.

• Für die sinnvolle rollenbasierte Autorisierung mit Enterprise Services-(COM+-)Rollen muss die Identität des ursprünglichen Aufrufers an die Enterprise Services-Anwendung übertragen werden. Wenn die Enterprise Services-Anwendung von einer ASP.NET-Webanwendung aus aufgerufen wird, muss die Webanwendung die Windows-Authentifizierung verwenden und für den Identitätswechsel konfiguriert sein.

• Versehen Sie Methoden mit dem PrincipalPermission-Attribut, um die Rollenmitgliedschaft deklarativ zu fordern. Diese Methode wird nicht aufgerufen, wenn der Aufrufer nicht die angegebene Rolle aufweist und eine Sicherheitsausnahmebedingung erzeugt wird.

• Rufen Sie PrincipalPermission.Demand im Methodencode auf (oder verwenden Sie IPrincipal.IsInRole), um differenzierte Autorisierungsentscheidungen treffen zu können.

• Ziehen Sie die Implementierung eines benutzerdefinierten IPrincipal-Objekts in Betracht, um die Semantik für die Rollenüberprüfung zu erweitern.