Freigeben über

Modul 9 – Enterprise Services-Sicherheit

  • Artikel

* * *

Auf dieser Seite

Modulübersicht Modulübersicht
Zielsetzung Zielsetzung
Betrifft Betrifft
Verwendung dieses Moduls Verwendung dieses Moduls
Sicherheitsarchitektur Sicherheitsarchitektur
Sicherheit für Server- und Bibliotheksanwendungen Sicherheit für Server- und Bibliotheksanwendungen
Sicherheitsanforderungen für den Codezugriff Sicherheitsanforderungen für den Codezugriff
Sicherheitskonfiguration Sicherheitskonfiguration
Konfigurieren einer ASP.NET-Clientanwendung Konfigurieren einer ASP.NET-Clientanwendung
Konfigurieren von Identitätswechselebenen für eine Enterprise Services-Anwendung Konfigurieren von Identitätswechselebenen für eine Enterprise Services-Anwendung
Sicherheitsprogrammierung Sicherheitsprogrammierung
Auswählen einer Prozessidentität Auswählen einer Prozessidentität
Zugriff auf Netzwerkressourcen Zugriff auf Netzwerkressourcen
Übermitteln des ursprünglichen Benutzers Übermitteln des ursprünglichen Benutzers
RPC-Verschlüsselung RPC-Verschlüsselung
Erstellen von Serviced Components Erstellen von Serviced Components
DCOM und Firewalls DCOM und Firewalls
Aufrufen von Serviced Components über ASP.NET Aufrufen von Serviced Components über ASP.NET
Sicherheitskonzepte Sicherheitskonzepte
Zusammenfassung Zusammenfassung

Modulübersicht

Traditionelle COM+-Dienste einschließlich verteilter Transaktionen, Just-in-Time-Aktivierung, Objektpooling und Konkurrenzmanagement sind für .NET-Komponenten verfügbar. In .NET werden diese Dienste als Enterprise Services bezeichnet. Die Komponenten, die im Kontext von Enterprise Service-Anwendungen ausgeführt werden, werden als Serviced Components bezeichnet. Serviced Components, die Sie mithilfe der .NET-Standardsprachen und Entwicklungstools erstellen, sind ein wesentliches Element beim Erreichen der Funktionalität, die von zahlreichen verteilten Webanwendungen benötigt wird.

In diesem Modul werden die Vorteile erörtert, die Serviced Components als Teil einer verteilten Webanwendung bieten. Es wird das von Enterprise Services bereitgestellte allgemeine Sicherheitsframework beschrieben, und es wird erläutert, wie mit diesem Framework sichere Serviced Components erstellt und implementiert werden können. Außerdem zeigt dieses Modul die Integration von Serviced Components in die verteilte Webanwendung. Sie sehen dabei, wie Sie eine Serviced Component aus einer ASP.NET-Clientanwendung aufrufen.

 

Zielsetzung

Themenbereiche:

  • Sichern der Enterprise Services-Lösung

  • Erstellen sicherer Serviced Components

  • Kennenlernen des von Enterprise Services bereitgestellten Sicherheitsframeworks und Ermitteln der von der Enterprise Services-Laufzeit bereitgestellten Gatekeeper

  • Konfigurieren der Sicherheit für eine Serviced Component mithilfe einer Kombination aus .NET-Attributen während der Entwicklung und mithilfe von Windows-Verwaltungsprogrammen während der Bereitstellung

  • Weiterleitung von Clientanmeldeinformationen mit Aufrufen an Serviced Components und Übertragen der Identität eines ursprünglichen Benutzers für Downstream-Systeme

  • Sichern der Serviced Component-Kommunikation durch RPC-Verschlüsselung

  • Aufrufen einer Serviced Component aus einer ASP.NET-Clientanwendung

 

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

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

  • Visual C# .NET

 

Verwendung dieses Moduls

Empfehlungen für eine erfolgreiche Arbeit mit diesem Modul:

  • Sie müssen über Erfahrung in der Programmierung mit Visual C# .NET verfügen.

  • Sie sollten über Erfahrung in der Entwicklung und Konfiguration von ASP.NET-Webanwendungen verfügen.

  • Sie müssen über Erfahrung bei der Konfiguration von Windows-Sicherheit mit den Windows-Verwaltungsprogrammen verfügen.

  • Sie müssen über Erfahrung bei der Entwicklung und Konfiguration von Enterprise Services-(COM+-)Anwendungen verfügen.

  • Lesen Sie Modul 1, "Einführung". Hier wird die Bedeutung von Authentifizierung, Autorisierung und sicherer Kommunikation für verteilte Webanwendungen erläutert.

  • Lesen Sie Modul 2, "Sicherheitsmodell für .NET-Anwendungen". Hier finden Sie eine Übersicht der Architektur und Technologien, die bei der Erstellung verteilter ASP.NET-Webanwendungen zum Einsatz kommen. Außerdem wird hervorgehoben, wo Sie Authentifizierung, Autorisierung und sicherer Kommunikation in diese Architektur integrieren können.

  • Lesen Sie Modul 3, "Authentifizierung und Autorisierung". Dort finden Sie eine detaillierte Einführung in die Authentifizierungs- und Autorisierungsmechanismen, die für verteilte Webanwendungen zur Verfügung stehen. Außerdem werden die Begriffe Identitätswechsel, Delegierung und Identitätsweitergabe erörtert – Verfahren, die für die Implementierung sicherer Enterprise Services-Lösungen wichtig sind.

  • Lesen Sie Modul 4, "Sichere Kommunikation". Dadurch wird die RPC-Verschlüsselung eingeführt, ein sicheres Kommunikationsprotokoll, das Sie häufig bei der Kommunikation zwischen Clients und Serviced Components verwenden werden.

  • Lesen Sie das Modul "Vorgehensweise: Verwenden von rollenbasierter Sicherheit mit Enterprise Services", in dem dargestellt wird, wie C# zur Implementierung rollenbasierter Sicherheit bei einer Serviced Component zu nutzen ist.

 

Sicherheitsarchitektur

Die von Enterprise Services-Anwendungen unterstützten Funktionen zur Authentifizierung, Autorisierung und sicheren Kommunikation werden in Abbildung 9.1 gezeigt. Bei der Clientanwendung in Abbildung 9.1 handelt es sich um eine ASP.NET-Webanwendung.

Enterprise Services – rollenbasierte Sicherheitsarchitektur

Abbildung 9.1
Enterprise Services – rollenbasierte Sicherheitsarchitektur

Funktionen für Authentifizierung und sichere Kommunikation werden vom RPC-Transportmechanismus bereitgestellt, der von Distributed COM (DCOM) verwendet wird. Die Autorisierung erfolgt durch Enterprise Services-(COM+--)Rollen.

Im Folgenden sind die Hauptelemente der Enterprise Services-Sicherheitsarchitektur zusammengefasst:

  • Enterprise Services-Anwendungen verwenden RPC für die Authentifizierung von Benutzern. Solange Sie die Authentifizierung nicht explizit deaktiviert haben, wird daher der Benutzer über Kerberos oder NTLM authentifiziert.

  • Die Autorisierung erfolgt über Enterprise Services-(COM+-)Rollen, die Gruppen- oder Benutzerkonten des Betriebssystems Microsoft® Windows® enthalten können. Die Rollenmitgliedschaft ist im COM+-Katalog definiert und wird mithilfe des Tools für Komponentendienste verwaltet.

    Hinweis: Wenn die Enterprise Services-Anwendung Identitätswechsel verwendet, ist außerdem eine Benutzerautorisierung über Windows ACLs bei gesicherten Ressourcen verfügbar.

  • Wenn ein Client (z. B. eine ASP.NET-Webanwendung) eine Methode für eine Serviced Component aufruft, greift die Enterprise Services-Abfangschicht auf den COM+-Katalog zu, um die Rollenmitgliedschaft des Clients zu ermitteln. Anschließend wird überprüft, ob die Mitgliedschaft der Rolle(n) autorisierten Zugriff auf die aktuelle Anwendung, Komponente, Schnittstelle und Methode erlaubt.

  • Wenn die Rollenmitgliedschaft des Kunden Zugriff erlaubt, wird die Methode aufgerufen. Wenn der Client nicht zu einer geeigneten Rolle gehört, wird der Aufruf zurückgewiesen, und optional wird ein Sicherheitsereignis für den fehlgeschlagenen Zugriffsversuch erstellt.

    Wichtig: Um eine sinnvolle rollenbasierte Autorisierung innerhalb einer von einer ASP.NET-Webanwendung aufgerufenen Enterprise Services-Anwendung implementieren zu können, müssen in der ASP.NET-Webanwendung Windows-Authentifizierung und Identitätswechsel verwendet werden, um sicherzustellen, dass der Sicherheitskontext des ursprünglichen Benutzers an die Serviced Component weitergeleitet wird.

  • Um die DCOM-Kommunikationsverbindung zwischen der Client- und der Serveranwendung zu sichern, kann entweder die Authentifizierungsebene RPC-Paketintegrität (zur Gewährleistung von Nachrichtenintegrität) oder die Authentifizierungsebene RPC-Paketdatensicherheit (zur Gewährleistung von Nachrichtenvertraulichkeit) verwendet werden.

Gatekeeper und Gates

Die Enterprise Services-Laufzeit dient als Gatekeeper für Serviced Components. Die einzelnen Gates (Autorisierungspunkte) innerhalb einer Enterprise Services-Anwendung finden Sie in Abbildung 9.2. Sie können diese Gates mithilfe der Enterprise Services-Rollen konfigurieren. Sie müssen dazu die Rollen mit den entsprechenden Windows-Gruppen- und -Benutzerkonten ausfüllen.

Hinweis: Außerdem müssen Sie sicherstellen, dass die Zugriffsüberprüfung (rollenbasierte Sicherheit) für Ihre Enterprise Services-Anwendung aktiviert ist und die geeignete Authentifizierungsebene verwendet wird. Weitere Informationen zur Konfiguration der Sicherheit finden Sie unter "Sicherheitskonfiguration" weiter unten in diesem Modul.

Gatekeeper innerhalb einer Enterprise Services-Anwendung

Abbildung 9.2
Gatekeeper innerhalb einer Enterprise Services-Anwendung

Es werden drei getrennte Zugriffsüberprüfungen vorgenommen, wenn ein Client einen Methodenaufruf auf einer Serviced Component durchgeführt hat. Diese Überprüfungen werden in Abbildung 9.2 dargestellt und im Folgenden erläutert.

  1. Eine erste Zugriffsüberprüfung wird von dem Subsystem durchgeführt, das für die Aktivierung der Enterprise Services-Anwendungen zuständig ist, nämlich dem COM Service Control Manager (SCM), wenn ein Aufruf für eine Serviced Component zu einer Aktivierungsanforderung (und zur Erstellung einer neuen Instanz des COM+-Stellvertreterprozesses, Dllhost.exe) führt.

    Um diese Zugriffsüberprüfung bestehen zu können, muss der Benutzer Mitglied mindestens einer Rolle sein, die innerhalb der Anwendung definiert ist.

  2. Eine zweite Zugriffsüberprüfung wird durchgeführt, wenn der Aufruf des Clients in die Dllhost.exe-Prozessinstanz eintritt.
    Auch hier wird die Zugriffsüberprüfung bestanden, wenn der Benutzer Mitglied mindestens einer Rolle ist, die innerhalb der Anwendung definiert ist.

  3. Die abschließende Zugriffsüberprüfung wird durchgeführt, wenn der Aufruf des Clients entweder in eine Server- oder in eine Bibliotheksanwendung eintritt.

    Um diese Zugriffsüberprüfung bestehen zu können, muss der Benutzer Mitglied einer Rolle sein, die entweder der Schnittstellenklasse oder der Methode zugeordnet ist, die das Ziel des Clientaufrufs ist.

Wichtig: Nachdem ein Aufruf eine Methode für eine Serviced Component gestartet hat, werden keine weiteren Zugriffsüberprüfungen vorgenommen, wenn die Komponente mit anderen Komponenten in derselben Anwendung kommuniziert. Zugriffsüberprüfungen treten jedoch auf, wenn eine Komponente eine andere Komponente in einer anderen Anwendung (Bibliothek oder Server) aufruft.

Verwenden von Serveranwendungen für erhöhte Sicherheit

Wenn Ihre Anwendung eine Authentifizierungsebene erzwingen muss, sollten Sie eine Serveranwendung verwenden. Das ist der Fall, wenn sie Verschlüsselung benötigt, um sicherzustellen, dass die an eine Serviced Component gesendeten Daten vertraulich und manipulationssicher bleiben, während sie über das Netzwerk gesendet werden.

Die Authentifizierungsebene kann für eine Serveranwendung erzwungen werden. Im Gegensatz dazu erben Bibliotheksanwendungen ihre Authentifizierungsstufe vom Hostprozess.

Um den Aktivierungstyp einer Enterprise Services-Anwendung zu konfigurieren, verwenden Sie das Attribut ApplicationActivation der Anwendungsebene, wie unten dargestellt.

[assembly: ApplicationActivation(ActivationOption.Server)]

Dies entspricht der Festlegung von Serveranwendung als Aktivierungstyp auf der Seite Aktivierung im Dialogfeld Eigenschaften der Anwendung in den Komponentendiensten.

 

Sicherheit für Server- und Bibliotheksanwendungen

Die rollenbasierte Sicherheit funktioniert ähnlich für In-Process-Bibliotheksanwendungen und Out-of-Process-Serveranwendungen.

Beachten Sie folgende Unterschiede für Bibliotheksanwendungen:

  • Rechte. Die Rechte einer Bibliotheksanwendung hängen von den Rechten des Client-(Host-)Prozesses ab. Wenn der Clientprozess beispielsweise mit Administratorrechten ausgeführt wird, verfügt auch die Datenbankanwendung über Administratorrechte.

  • Identitätswechsel. Die Identitätswechselebene einer Bibliotheksanwendung wird vom Clientprozess geerbt und kann nicht explizit festgelegt werden.

  • Authentifizierung. Die Authentifizierungsebene einer Bibliotheksanwendung wird vom Clientprozess geerbt. Bei Bibliotheksanwendungen können Sie die Authentifizierungsebene explizit aktivieren oder deaktivieren. Diese Option ist auf der Seite Sicherheit im Dialogfeld Eigenschaften der Bibliotheksanwendung verfügbar.

    Diese Option dient normalerweise zur Unterstützung nicht authentifizierter Rückrufe von anderen Out-of-Process-COM-Komponenten.

Zuweisen von Rollen zu Klassen, Schnittstellen oder Methoden

Bei Bibliotheksanwendungen sollten Sie immer Rollen auf der Klassen-, Schnittstellen- oder Methodenebene zuweisen. Dies ist auch die empfohlene Vorgehensweise für Serveranwendungen.

Benutzer, die innerhalb von Bibliotheksanwendungsregeln definiert sind, können nicht zur Sicherheitsbeschreibung des Clientprozesses hinzugefügt werden. Dies bedeutet, dass mindestens Sicherheit auf Klassenebene erforderlich ist, damit eine Bibliotheksanwendung rollenbasierte Autorisierung durchführen kann.

 

Sicherheitsanforderungen für den Codezugriff

Für Codezugriffssicherheit (Code Access Security, CAS) muss der Code über bestimmte Berechtigungen verfügen, um bestimmte Operationen ausführen und auf beschränkte Ressourcen zugreifen zu können. CAS ist am sinnvollsten in einer Clientumgebung, in der Code aus dem Internet heruntergeladen wird. Bei solchen Situationen ist es unwahrscheinlich, dass der Code für vollständig vertrauenswürdig gehalten wird.

Normalerweise werden Anwendungen, die Serviced Component verwenden, für vollständig vertrauenswürdig gehalten. Daher ist der Einsatzbereich von CAS begrenzt. Enterprise Services fordert jedoch, dass der aufrufende Code über die erforderlichen Berechtigungen zum Aufrufen von unverwaltetem Code verfügt. Dies hat folgende Auswirkungen:

  • Eine Berechtigung für unverwalteten Code ist für die Aktivierung und Durchführung von kontextübergreifenden Aufrufen bei Serviced Components erforderlich.

  • Wenn es sich beim Client einer Serviced Component um eine ASP.NET-Webanwendung handelt, muss diese Anwendung über eine Berechtigung für unverwalteten Code verfügen.

  • Wenn eine Referenz auf eine Serviced Component an nicht vertrauenswürdigen Code weitergegeben wird, können die in der Serviced Component definierten Methoden nicht vom nicht vertrauenswürdigen Code aufgerufen werden.

 

Sicherheitskonfiguration

In diesem Abschnitt erfahren Sie, wie Sie Sicherheit für folgende Elemente konfigurieren können:

  • Serviced Components, die in einer (Out-of-Process-)Anwendung des Enterprise Services-Servers ausgeführt werden

  • Clients der ASP.NET-Webanwendung

Konfigurieren von Serveranwendungen

Die einzelnen Schritte für die Konfiguration einer Enterprise Services-Serveranwendung finden Sie in Abbildung 9.3.

Konfigurieren der Enterprise Services-Sicherheit

Abbildung 9.3
Konfigurieren der Enterprise Services-Sicherheit

Konfiguration zum Zeitpunkt der Entwicklung bzw. der Bereitstellung

Sie können die meisten Sicherheitseinstellungen im COM+-Katalog während der Entwicklungszeit konfigurieren, indem Sie .NET-Attribute innerhalb der Assembly verwenden, die die Serviced Component enthält. Diese Attribute werden zum Ausfüllen des COM+-Katalogs genutzt, wenn die Serviced Component unter Verwendung des Tools Regsvcs.exe bei COM+ registriert wird.

Weitere Konfigurationsschritte, wie beispielsweise das Ausfüllen von Rollen mit Windows-Gruppen- und -Benutzerkonten und das Konfigurieren als "Ausführen als"-Identität für die Serveranwendung (Dllhost.exe-Instanz), müssen zum Zeitpunkt der Bereitstellung mithilfe des Verwaltungstools der Komponentendienste (oder programmatisch über ein Skript) konfiguriert werden.

Konfigurieren der Authentifizierung

Um die Authentifizierungsebene der Anwendung deklarativ festzulegen, müssen Sie das Assemblyebenenattribut ApplicationAccessControl verwenden, wie unten dargestellt.

[assembly: ApplicationAccessControl(
              Authentication = AuthenticationOption.Call)]

Dies entspricht der Festlegung des Wertes Authentifizierungsebene für Aufrufe auf der Seite Sicherheit im Dialogfeld Eigenschaften der Anwendung in den Komponentendiensten.

Hinweis: Die Authentifizierungsebene des Clients wirkt sich auch auf die von der Enterprise Services-Anwendung verwendete Authentifizierungsebene aus, da ein Vorgang zur Aushandlung von Obergrenzen durchgeführt wird, der dazu führt, dass immer die höhere der beiden Einstellungen verwendet wird.

Weitere Informationen zur Konfiguration der von einer ASP.NET-Clientanwendung verwendeten DCOM-Authentifizierungsebene finden Sie unter "Konfigurieren einer ASP.NET-Clientanwendung" weiter unten in diesem Abschnitt.

Weitere Informationen zu den DCOM-Authentifizierungsebenen und zur Konfiguration von Dienstkomponenten finden Sie im Abschnitt "Sicherheitskonzepte" in diesem Modul.

Konfigurieren von Autorisierung (Zugriffsüberprüfungen auf Komponentenebene)

Um eine differenzierte Autorisierung auf der Komponenten-, Schnittstellen bzw. Methodenebene zu ermöglichen, müssen Sie folgende Schritte durchführen:

  • Aktivieren der Zugriffsüberprüfungen auf der Anwendungsebene. Verwenden Sie folgendes .NET-Attribut, um anwendungsweite Zugriffsüberprüfungen zuzulassen:

      [assembly: ApplicationAccessControl(true)]

    Dies entspricht der Aktivierung des Kontrollkästchens Zugriffsüberprüfung für diese Anwendung erzwingen auf der Seite Sicherheit im Dialogfeld Eigenschaften der Anwendung in den Komponentendiensten.

    Wichtig: Wenn dieses Attribut nicht festgelegt wird, werden keinerlei Zugriffsüberprüfungen durchgeführt.

  • Konfigurieren der Sicherheitsstufe der Anwendungen auf Prozess- und Komponentenebene.
    Um eine sinnvolle rollenbasierte Sicherheit zu erreichen, sollten Sie die Zugriffsüberprüfung auf der Prozess- und Komponentenebene mittels des folgenden .NET-Attributs aktivieren:

      [assembly: ApplicationAccessControl(AccessChecksLevel= 
                      AccessChecksLevelOption. ApplicationComponent)]

    Dies entspricht der Aktivierung des Kontrollkästchens Zugriffsüberprüfung auf Prozess- und Komponentenebene durchführen auf der Seite Sicherheit im Dialogfeld Eigenschaften der Anwendung in den Komponentendiensten.

    Hinweis: Für Bibliotheksanwendungen sollte die Zugriffsüberprüfung auf Prozess- und Komponentenebene aktiviert werden.

  • Aktivieren von Zugriffsüberprüfungen auf Komponentenebene Zur Aktivierung von Zugriffsüberprüfungen auf Komponentenebene müssen Sie das Klassenebenenattribut ComponentAccessControl verwenden, wie unten dargestellt.

      [ComponentAccessControl(true)]
  public class MyServicedComponent : ServicedComponent
  {
  }

    Dies entspricht der Aktivierung des Kontrollkästchens Zugriffsüberprüfung auf Komponentenebene erzwingen auf der Seite Sicherheit im Dialogfeld Eigenschaften der Komponente in den Komponentendiensten.

    Hinweis: Diese Einstellung ist nur wirksam, wenn Sie die Zugriffsüberprüfung auf Anwendungsebene aktiviert und Zugriffsüberprüfungen auf Prozess- und Komponentenebene konfiguriert haben (wie oben beschrieben).

Erstellen und Zuweisen von Rollen

Rollen können auf der Anwendungs-, Komponenten-(Klassen-), Schnittstellen- und Methodenebene erstellt und zugewiesen werden.

Hinzufügen von Rollen zu einer Anwendung
Um die Rollen zu einer Anwendung hinzuzufügen, müssen Sie das Assemblyebenenattribut SecurityRole verwenden, wie unten dargestellt.

  [assembly:SecurityRole("Mitarbeiter")]
  [assembly:SecurityRole("Manager")]

Dies entspricht dem Hinzufügen von Rollen zu einer Anwendung mit dem Tool der Komponentendienste.

Hinweis: Die Verwendung des SecurityRole-Attributs entspricht dem Hinzufügen von Rollen zur Anwendung, jedoch nicht ihrer Zuweisung zu einzelnen Komponenten, Schnittstellen bzw. Methoden. Die Folge ist, dass die Mitglieder dieser Rollen die Zusammensetzung der Sicherheitsbeschreibung für die Anwendung bestimmen. Dies wird ausschließlich verwendet, um zu bestimmen, wer berechtigt ist, auf die Anwendung zuzugreifen (und sie zu starten).

Um eine effektivere rollenbasierte Autorisierung zu erhalten, weisen Sie den Komponenten, Schnittstellen und Methoden Rollen zu wie unten beschrieben.

Hinzufügen von Rollen zu einer Komponente (Klasse)

Um die Rollen zu einer Komponente hinzuzufügen, müssen Sie das SecurityRole-Attribut über der Klassendefinition anwenden, wie unten dargestellt.

  [SecurityRole("Manager")]
  public class Transfer : ServicedComponent
  {
  }

Hinzufügen von Rollen zu einer Schnittstelle

Um Rollen auf der Schnittstellenebene hinzuzufügen, müssen Sie eine Schnittstellendefinition erstellen und sie anschließend in Ihrer Serviced Component-Klasse implementieren. Dann können Sie mit dem Attribut SecurityRole der Schnittstelle Rollen zuordnen.

Wichtig: Zum Zeitpunkt der Entwicklung müssen Sie außerdem der Klasse das Attribut SecureMethod zuordnen. Dadurch werden die Enterprise Services darüber informiert, dass sie Sicherheitsdienste auf Methodenebene verwenden können. Zum Zeitpunkt der Bereitstellung muss der Administrator außerdem Benutzer zur systemdefinierten Marshaler-Rolle hinzufügen, die automatisch im COM+-Katalog erstellt wird, wenn eine als SecureMethod gekennzeichnete Klasse bei den Komponentendiensten registriert wird.

Die Verwendung der Marshaler-Rolle wird im nächsten Abschnitt weiter erläutert.

Folgendes Beispiel zeigt, wie Sie die Manager-Rolle zu einer bestimmten Schnittstelle hinzufügen können.

  [SecurityRole("Manager")]
  public interface ISomeInterface
  {
    void Method1( string message );
    void Method2( int parm1, int parm2 );
    }

  [ComponentAccessControl]
  [SecureMethod]
  public class MyServicedComponent : ServicedComponent, ISomeInterface
  {
    public void Method1( string message )
    {
      // Implementierung
    }
    public void Method2( int parm1, int parm2 )
    {
      // Implementierung
    }
  }

Hinzufügen von Rollen zu einer Methode

Um sicherzustellen, dass die öffentlichen Methoden einer Klasse im COM+-Katalog angezeigt werden, müssen Sie explizit eine Schnittstelle implementieren, mit der die Methoden definiert werden. Um die Methoden zu sichern, müssen Sie anschließend das Attribut SecureMethod für die Klasse oder das Attribut SecureMethod oder SecurityRole auf der Methodenebene verwenden.

Hinweis: Die Attribute SecureMethod und SecurityRole müssen über der Methodenimplementierung erscheinen und nicht innerhalb der Schnittstellendefinition.

Um Sicherheit auf der Methodenebene zu aktivieren, führen Sie die folgenden Schritte durch:

a. Definieren Sie eine Schnittstelle, die die zu sichernden Methoden enthält. Beispiel:

  public interface ISomeInterface
  {
    void Method1( string message );
    void Method2( int parm1, int parm2 );
  }

b. Implementieren Sie die Schnittstelle in der Serviced Component-Klasse:

  [ComponentAccessControl]
  public class MyServicedComponent : ServicedComponent, ISomeInterface
  {
    public void Method1( string message )
    {
      // Implementierung
    }
    public void Method2( int parm1, int parm2 )
    {
      // Implementierung
    }
  }

c. Wenn Sie Rollen mit dem Tool der Komponentendienste administrativ konfigurieren möchten, müssen Sie die Klasse mit dem Attribut SecureMethod annotieren, wie unten dargestellt.

  [ComponentAccessControl]
  [SecureMethod]
  public class MyServicedComponent : ServicedComponent, ISomeInterface
  {
  }

d. Wenn Sie alternativ zum Zeitpunkt der Entwicklung mit den .NET-Attributen Rollen zu Methoden hinzufügen möchten, wenden Sie das Attribut SecurityRole auf der Methodenebene an. In diesem Fall müssen Sie das Attribut SecureMethod nicht auf der Klassenebene zuweisen (das Attribut ComponentAccessControl muss jedoch für die Konfiguration der Zugriffsüberprüfungen auf Komponentenebene vorhanden sein).
Im folgenden Beispiel können nur Mitglieder der Rolle Manager Method1 aufrufen, und Mitglieder der Rollen Manager und Mitarbeiter können Method2 aufrufen.

  [ComponentAccessControl]
public class MyServicedComponent : ServicedComponent, ISomeInterface
{
  [SecurityRole("Manager")]
  public void Method1( string message )
  {
    // Implementierung
  }
  [SecurityRole("Manager")]
  [SecurityRole("Mitarbeiter")]
  public void Method2( int parm1, int parm2 )
  {
    // Implementierung
  }
}

e. Zum Zeitpunkt der Bereitstellung muss der Administrator alle Benutzer hinzufügen, die Zugriff auf Methoden oder Schnittstellen der Klasse für die vordefinierte Marshaler-Rolle benötigen.

Hinweis: Die Enterprise Services-Infrastruktur verwendet eine Reihe von Schnittstellen auf Systemebene, die von allen Serviced Components bereitgestellt werden. Hierzu gehören IManagedObject, IDisposable und IServiceComponentInfo. Wenn Zugriffsüberprüfungen auf Schnittstellen- oder Methodenebene aktiviert sind, wird der Enterprise Services-Infrastruktur der Zugriff auf diese Schnittstellen verweigert.

Dadurch erzeugen die Enterprise Services eine spezielle Rolle mit Namen Marshaler und verbindet diese Rolle mit den Schnittstellen. Sie können diese Rolle (und die zuvor erwähnten Schnittstellen) mit dem Tool der Komponentendienste anzeigen.

Zur Bereitstellungszeit muss der Anwendungsadministrator also alle Benutzer der Marshaler-Rolle hinzufügen, die Zugriff auf beliebige Methoden oder Schnittstellen dieser Klasse benötigen. Hierfür gibt es zwei unterschiedliche Automatisierungsmöglichkeiten:

  • Schreiben Sie ein Skript, das das Objektmodell der Komponentendienste zugrunde legt, um alle Benutzer aus anderen Rollen in die Marshaler-Rolle zu kopieren.

  • Schreiben Sie ein Skript, das alle anderen Rollen diesen drei speziellen Schnittstellen zuordnet, und löschen Sie die Marshaler-Rolle.

Registrieren von Serviced Components

Sie können Serviced Components an folgenden Orten registrieren:

  • Globaler Assemblycache. Im Gegensatz zu Bibliotheksanwendungen MÜSSEN Serviced Components, für die COM+-Serveranwendungen als Host fungieren, im globalen Assemblycache installiert werden.
    Um eine Serviced Component im globalen Assemblycache zu registrieren, müssen Sie das Befehlszeilendienstprogramm Gacutil.exe ausführen. Um eine Assembly mit dem Namen MyServicedComponent.dll im globalen Assemblycache zu registrieren, führen Sie folgenden Befehl aus.

      gacutil -i MyServicedComponent.dll

    Hinweis: Außerdem können Sie mit dem Microsoft .NET Framework-Konfigurationstool aus der Programmgruppe Verwaltung den Inhalt des globalen Assemblycache anzeigen und bearbeiten.

  • COM+-Katalog. Um eine Assembly mit dem Namen MyServicedComponent.dll im globalen COM+-Katalog zu registrieren, führen Sie folgenden Befehl aus.

      regsvcs.exe MyServicedComponent.dll

    Dieser Befehl führt zur Erstellung einer COM+-Anwendung. Die in der Assembly vorhandenen .NET-Attribute werden zum Ausfüllen des COM+-Katalogs verwendet.

Füllen von Rollen

Das Ausfüllen von Rollen mit dem Tool der Komponentendienste oder durch Verwendung eines Skripts zur Programmierung des COM+-Katalogs mit den COM+Verwaltungsobjekten.

Verwenden von Windows-Gruppen

Fügen Sie Windows 2000-Gruppenkonten zu den Enterprise Services-Rollen hinzu, um größtmögliche Flexibilität zu erzielen. Durch die Verwendung von Windows-Gruppen können Sie effektiv mit einem einzigen Verwaltungstool (dem Verwaltungstool für Benutzer und Computer) sowohl die Windows- als auch die Enterprise Services-Sicherheit verwalten.

  • Erstellen Sie eine Windows-Gruppe für jede Rolle in der Enterprise Services-Anwendung.

  • Weisen Sie jede Gruppe ihrer jeweiligen Rolle zu.
    Wenn Sie über eine Rolle namens Manager verfügen, erstellen Sie eine Windows-Gruppe namens Managers. Weisen Sie die Gruppe Managers der Rolle Manager zu.

  • Wenn Sie den Rollen Gruppen zugewiesen haben, fügen Sie mit dem Tool für die Verwaltung von Benutzern und Computern die Benutzer in den einzelnen Gruppen hinzu bzw. entfernen Sie sie.
    Wenn Sie beispielsweise ein Windows 2000-Benutzerkonto namens David zur Windows 2000-Gruppe "Manager" hinzufügen, wird David effektiv zur Rolle Manager hinzugefügt.

  • So fügen Sie mit den Komponentendiensten Windows-Gruppen zu Enterprise Services-Rollen hinzu

    1. Erweitern Sie mit dem Tool der Komponentendienste die Anwendung, die die Rollen enthält, die zu den Windows 2000-Gruppen hinzugefügt werden sollen.

    2. Erweitern Sie den Ordner Rollen und die Rolle, die Sie den Windows-Gruppen zuweisen möchten.

    3. Wählen Sie den Ordner Benutzer unter der speziellen Rolle aus.

    4. Klicken Sie mit der rechten Maustaste auf den Ordner, zeigen Sie auf Neu und klicken Sie anschließend auf Benutzer.

    5. Fügen Sie im Dialogfeld Benutzer oder Gruppen auswählen Gruppen (oder Benutzer) zur Rolle hinzu.

Weitere Informationen

Weitere Informationen zur Programmierung des COM+-Katalogs unter Verwendung der COM+-Verwaltungsobjekte finden Sie unter Automating COM+ Administration" im Abschnitt zur Komponentenentwicklung der MSDN Library (englischsprachig).

Konfigurieren der Identität

Verwenden Sie das Tool der Komponentendienste (oder ein Skript), um die Identität der Enterprise Services-Anwendung zu konfigurieren. Die Identitätseigenschaft bestimmt, welches Konto für die Ausführung der Instanz von Dllhost.exe verwendet wird, die als Host für die Anwendung fungiert.

  • So konfigurieren Sie Identität

    1. Wählen Sie mit dem Tool für die Komponentendienste die entsprechende Anwendung aus.

    2. Klicken Sie mit der rechten Maustaste auf den Namen der Anwendung und dann auf Eigenschaften.

    3. Klicken Sie auf die Registerkarte Identität.

    4. Klicken Sie auf Dieser Benutzer und geben Sie das konfigurierte Dienstkonto an, das für die Ausführung der Anwendung verwendet wird.

Weitere Informationen

Weitere Informationen zur Auswahl einer geeigneten Identität für die Ausführung einer Enterprise Services-Anwendung finden Sie unter "Auswählen einer Prozessidentität" weiter unten in diesem Modul.

 

Konfigurieren einer ASP.NET-Clientanwendung

Sie müssen die DCOM-Authentifizierungsebene und die Identitätswechselebenen konfigurieren, die von den Clientanwendungen bei der Kommunikation mit Serviced Components über DCOM verwendet werden.

Konfigurieren der Authentifizierung

Um die standardmäßige Authentifizierungsebene zu konfigurieren, die von ASP.NET-Webanwendungen bei der Kommunikation mit einer Serviced Component verwendet wird, müssen Sie das Attribut comAuthenticationLevel im <processModel>-Element in Machine.config bearbeiten.

Die Datei machine.config befindet sich in folgendem Ordner:

  %windir%\Microsoft.NET\Framework\v1.0.3705\CONFIG

Legen Sie für das Attribut comAuthenticationLevel einen der folgenden Werte fest:

  comAuthenticationLevel=
              "[Default|None|Connect|Call|Pkt|PktIntegrity|PktPrivacy]"

Weitere Informationen

Weitere Informationen zu den DCOM-Authentifizierungsebenen finden Sie unter "Authentifizierung" im Abschnitt "Sicherheitskonzepte" weiter unten in diesem Modul.

Konfigurieren des Identitätswechsels

Die vom Client festgelegte Identitätswechselebene bestimmt die Möglichkeiten des Servers in Bezug auf Identitätswechselebenen. Um die standardmäßige Identitätswechselebene zu konfigurieren, die von einer webbasierten Anwendung bei der Kommunikation mit einer Serviced Component verwendet wird, müssen Sie das Attribut comImpersonationLevel im <processModel>-Element in Machine.config bearbeiten. Legen Sie dafür einen der folgenden Werte fest:

  comImpersonationLevel="[Standard|Anonym|Identifizieren|Identität annehmen|Delegieren]"

Weitere Informationen

Weitere Informationen zu den DCOM-Identitätswechselebenen finden Sie unter "Identitätswechsel" im Abschnitt "Sicherheitskonzepte" weiter unten in diesem Modul.

 

Konfigurieren von Identitätswechselebenen für eine Enterprise Services-Anwendung

Wenn eine Serviced Component in einer Anwendung eine Serviced Component in einer zweiten (Server-)Anwendung aufrufen muss, müssen Sie möglicherweise die Identitätswechselebene für die Clientanwendung konfigurieren.

Wichtig: Die für eine Enterprise Services-Anwendung (auf der Seite Sicherheit im Dialogfeld Eigenschaften) konfigurierte Identitätswechselebene ist die Identitätswechselebene, die von den ausgehenden Gesprächen verwendet wird, die die Komponenten innerhalb der Anwendung vornehmen. Sie hat keine Auswirkungen darauf, ob Serviced Components innerhalb der Anwendung Identitätswechsel durchführen. Um einen Identitätswechsel bei Clients innerhalb einer Serviced Component durchzuführen, müssen Sie programmatische Identitätswechseltechniken verwenden, wie unter "Übermitteln des ursprünglichen Benutzers" weiter unten in diesem Modul beschrieben.

Um die Identitätswechselebene der Anwendung deklarativ festzulegen, müssen Sie das Assemblyebenenattribut ApplicationAccessControl verwenden, wie unten dargestellt.

  [assembly: ApplicationAccessControl(
                  ImpersonationLevel=ImpersonationLevelOption.Identify)]

Dies entspricht der Festlegung des Wertes Identitätswechselebene auf der Seite Sicherheit im Dialogfeld Eigenschaften der Anwendung in den Komponentendiensten.

 

Sicherheitsprogrammierung

Die Enterprise Services-Sicherheitsfunktionen sind für .NET-Komponenten verfügbar, die die Klassen ContextUtil, SecurityCallContext und SecurityIdentity verwenden.

Programmatische rollenbasierte Sicherheit

Für differenzierte Autorisierungsentscheidungen können Sie die Rollenmitgliedschaft programmatisch mit der Methode IsCallerInRole der Klasse ContextUtil testen. Bevor Sie diese Methode aufrufen, sollten Sie überprüfen, dass Zugriffsüberprüfungen auf Komponentenebene aktiviert sind, wie im folgenden Codefragment gezeigt. Wenn die Sicherheit deaktiviert ist, gibt IsCallerInRole immer den Wert "true" zurück.

  public void Transfer(string fromAccount, string toAccount, double amount)
  {
    // Stellen Sie sicher, dass die Sicherheitsfunktion aktiviert ist
    if (ContextUtil.IsSecurityEnabled) 
    {
      // Nur Manager dürfen Summen von über $ 1000 transferieren
      if (amount > 1000)
      {
        if (ContextUtil.IsCallerInRole("Manager"))
        {
          // Benutzer ist autorisiert
        }
        else
        {
          // Benutzer ist nicht autorisiert
        }
      }
  }

Identifizieren von Benutzern

Folgendes Beispiel zeigt, wie alle Upstream-Benutzer aus einer Serviced Component identifiziert werden können.

  [ComponentAccessControl]
  public class MyServicedComponent : ServicedComponent
  {
    public void ShowCallers()
    {
      SecurityCallContext context = SecurityCallContext.CurrentCall;
      SecurityCallers callers = context.Callers;
      foreach(SecurityIdentity id in callers)
      {
        Console.WriteLine(id.AccountName);
      }
    }
  }

Hinweis: Die Identität des ursprünglichen Benutzers ist über die Eigenschaft SecurityCallContext.OriginalCaller verfügbar.

 

Auswählen einer Prozessidentität

Serveraktivierte Enterprise Services-Anwendungen werden innerhalb einer Instanz des Dllhost.exe-Prozesses ausgeführt. Sie müssen das für die Ausführung des Prozesses im COM+-Katalog verwendete Konto mithilfe des Tools der Komponentendienste konfigurieren.

Hinweis: Sie können die Ausführung nicht mittels eines .NET-Attributs als Identität angeben.

Vermeiden Sie die Ausführung als interaktiver Benutzer

Führen Sie Serveranwendungen nicht mit der Identität des interaktiv angemeldeten Benutzers aus (dies ist die Standardeinstellung). Es gibt zwei Hauptgründe dafür, dies zu vermeiden:

  • Die Berechtigungen und Zugriffsrechte der Anwendung variieren und hängen davon ab, wer jeweils interaktiv beim Server angemeldet ist. Wenn zufällig ein Administrator angemeldet ist, verfügt die Anwendung über Administratorrechte.

  • Wenn die Anwendung gestartet wird, während ein Benutzer interaktiv angemeldet ist, und sich der Benutzer dann abmeldet, wird die Serveranmeldung beendet. Sie kann erst neu gestartet werden, wenn sich wieder ein Benutzer interaktiv anmeldet.

Die Einstellung für interaktive Benutzer wurde für Entwickler zum Zeitpunkt der Entwicklung entworfen und sollte nicht als Einstellung für die Bereitstellungsphase betrachtet werden.

Verwenden Sie ein benutzerdefiniertes Konto mit minimalen Rechten

Erstellen Sie ein Konto mit minimalen Rechten, um die potenzielle Bedrohung durch Prozessbeeinträchtigungen abzuschwächen. Wenn ein entschlossener Angreifer es schafft, den Serverprozess zu beeinträchtigen, kann dieser Angreifer problemlos die dem Prozesskonto zugewiesenen Berechtigungen und Zugriffsrechte übernehmen. Ein mit minimalen Rechten konfiguriertes Konto begrenzt den möglichen Schaden.

Wenn Sie mit dem Prozesskonto auf Netzwerkressourcen zugreifen müssen, muss der Remotecomputer in der Lage sein, das Prozesskonto zu authentifizieren. In diesem Szenario haben Sie zwei Optionen:

  • Sie können ein Domänenkonto verwenden, wenn sich die beiden Computer in derselben Domäne oder in vertrauenswürdigen Domänen befinden.

  • Sie können ein lokales Konto verwenden und anschließend ein doppeltes Konto (mit demselben Benutzernamen und Kennwort) auf dem Remotecomputer erstellen. Bei dieser Option müssen Sie sicherstellen, dass die Kennwörter der beiden Kontos synchronisiert bleiben.
    Sie sind möglicherweise gezwungen, den Ansatz mit einem duplizierten lokalen Konto zu verwenden, wenn der Remotecomputer sich in einer gesonderten Domäne (ohne Vertrauensstellung) oder hinter einer Firewall (bei der aufgrund geschlossener Anschlüsse keine Windows-Authentifizierung möglich ist) befindet.

 

Zugriff auf Netzwerkressourcen

Die Serviced Components benötigen möglicherweise Zugriff auf Remoteressourcen. Sie müssen in der Lage sein, folgende Elemente zu identifizieren:

  • Die Ressourcen, auf die die Komponenten zugreifen müssen. Dabei kann es sich beispielsweise um Dateien in Datenfreigaben, Datenbanken, andere DCOM-Server, Active Directory®-Verzeichnisobjekte usw. handeln.

  • Die für die Durchführung des Ressourcenzugriffs verwendete Identität. Wenn Ihre Serviced Component auf Remoteressourcen zugreift, muss die verwendete Identität (standardmäßig die Prozessidentität) vom Remotecomputer authentifiziert werden.

Hinweis: Weitere Informationen speziell zum Zugriff auf Datenbanken von SQL-Remoteservern finden Sie in Modul 12, "Datenzugriffssicherheit".

Sie können auf Remoteressourcen von einer Komponente innerhalb einer Enterprise Services-Anwendung zugreifen, indem Sie eine der folgenden Identitäten verwenden:

  • Ursprünglicher Benutzer (falls Sie explizit Identitätswechsel über CoImpersonateClient durchführen)

  • Aktuelle Prozessidentität (im COM+-Katalog für Serveranwendungen konfiguriert)

  • Ein spezielles Dienstkonto

Verwenden des ursprünglichen Benutzers

Um die Identität des ursprünglichen Benutzers für den Zugriff auf Remoteressourcen verwenden zu können, muss Folgendes gegeben sein:

  • Sie müssen einen programmgesteuerten Identitätswechsel für den ursprünglichen Benutzer durchführen, indem Sie CoImpersonateClient aufrufen.

  • Sie müssen in der Lage sein, den Sicherheitskontext des Benutzers vom Anwendungsserver, der als Host für die Enterprise Services-Anwendung fungiert, zum Remotecomputer zu delegieren. Dies setzt voraus, dass Sie Kerberos-Authentifizierung zwischen der Enterprise Services-Anwendung und der Clientanwendung verwenden.

Skalierbarkeitswarnung: Wenn Sie auf die Datendienstebene Ihrer Anwendung mit der angenommenen Identität des ursprünglichen Benutzers zugreifen, beeinträchtigen Sie extrem die Skalierbarkeit der Anwendung, da Sie verhindern, dass das Datenbankverbindungspooling effizient eingesetzt werden kann. Das Pooling arbeitet nicht effizient, da der Sicherheitskontext der jeweiligen Datenbankverbindung an zu viele einzelne Benutzer gebunden ist.

Weitere Informationen

Weitere Informationen zum Identitätswechsel bei Benutzern finden Sie unter "Übermitteln des ursprünglichen Benutzers" weiter unten in diesem Modul.

Verwenden der aktuellen Prozessidentität

Wenn Ihre Anwendung als Serveranwendung konfiguriert ist, können Sie die konfigurierte Prozessidentität für den Zugriff auf Remoteressourcen verwenden (Standardfall).

Wenn Sie das Serverprozesskonto für den Zugriff auf Remoteressourcen verwenden möchten, müssen Sie einen der folgenden Vorgänge durchführen:

  • Ausführen der Serveranwendung mithilfe eines Domänenkontos mit minimalen Rechten. Dies setzt voraus, dass sich Client- und Servercomputer in derselben Domäne oder in vertrauenswürdigen Domänen befinden.

  • Duplizieren Sie das Prozesskonto mithilfe desselben Benutzernamens und desselben Kennworts auf dem Remotecomputer.

Wenn Ihr Hauptanliegen eine einfache Verwaltung ist, sollten Sie ein Domänenkonto mit minimalen Rechten verwenden.

Wenn Ihre Anwendung für die Ausführung als Bibliotheksanwendung konfiguriert ist, wird die Prozessidentität vom Hostprozess (häufig eine webbasierte Anwendung) geerbt. Weitere Informationen zur Verwendung der ASP.NET-Prozessidentität für den Zugriff auf Remoteressourcen finden Sie in Modul 8, "ASP.NET-Sicherheit".

Verwenden eines speziellen Dienstkontos

Ihre Enterprise Services-Anwendung könnte über ein speziell konfiguriertes Dienstkonto (also ein von Windows unabhängiges Dienstkonto) auf die Remoteressourcen zugreifen. Diese Vorgehensweise wird jedoch bei Windows 2000 nicht empfohlen, da dafür die LogonUser-API aufgerufen werden muss. Außerdem bringt sie für die Anwendung ein Problem bei der Verwaltung von Anmeldeinformationen mit sich, da die Kontoanmeldeinformationen auf sichere Weise gespeichert werden müssen.

Die Verwendung von LogonUser sollte bei Windows 2000 vermieden werden, da Sie dadurch gezwungen sind, dem Enterprise Services-Prozesskonto das starke Recht zum Agieren als Teil des Betriebssystems zuzuweisen.

Hinweis: Bei Microsoft Windows .NET Server 2003 wird diese Einschränkung aufgehoben.

 

Übermitteln des ursprünglichen Benutzers

Standardmäßig erfolgen ausgehende Aufrufe durch Serviced Components (z. B. für den Zugriff auf lokale Ressourcen oder Remoteressourcen) über den vom Hostprozess erhaltenen Sicherheitskontext. Für Serveranwendungen ist dies die konfigurierte "Ausführen als"-Identität. Bei Bibliotheksanwendungen ist dies die Identität des (Host-)Client-Prozesses (z. B. Aspnet_wp.exe, wenn die ASP.NET-Webanwendung der Client ist).

  • So übermitteln Sie den Kontext des ursprünglichen Benutzers über eine Enterprise Services-Anwendung

    1. Rufen Sie CoImpersonateClient auf.

      Dadurch wird dem aktuellen Thread ein Thread-Identitätswechsel-Token zugewiesen.

    2. Führen Sie die Operation aus (Zugriff auf lokale oder Remoteressource).
      Wenn der Identitätswechsel aktiviert ist, erfolgt der ausgehende Aufruf mithilfe des Sicherheitskontexts des Clients (durch das Identitätswechsel-Token definiert).

      Wenn auf die lokalen Ressourcen zugegriffen wurde, muss der Benutzer (Clientprozess) einen Identitätswechsel mindestens auf der Ebene "Identität annehmen" angeben. Wenn auf die lokalen Ressourcen zugegriffen wurde, muss der Benutzer (Clientprozess) einen Identitätswechsel mindestens auf der Ebene "Identität annehmen" angeben.

      Wenn es sich bei dem Benutzer um eine ASP.NET-Webanwendung handelt, ist die Standardebene für den Identitätswechsel für den ASP.NET-Workerprozess "Identität annehmen". Daher ist es für die Übermittlung des ursprünglichen Benutzers an einen Downstream-Remotecomputer erforderlich, diesen Standard in "Delegieren" zu ändern (im Element <processModel> der Datei Machine.config auf dem Clientcomputer).

      Hinweis: Um den Sicherheitskontext des ursprünglichen Benutzers für den Zugriff auf Remoteressourcen verwenden zu können, müssen Sie Kerberos-Authentifizierung verwenden, und zwar mit für das Delegieren konfigurierten Konten. Das für die Ausführung der Enterprise Services-Serveranwendung verwendete Konto muss auch in Active Directory als "Für Delegierungszwecke vertraut" gekennzeichnet werden.

    3. Beenden Sie den Identitätswechsel durch Aufrufen von CoRevertToSelf.
      Dadurch wird das Identitätswechsel-Token entfernt. Bei allen weiteren Aufrufen über die aktuelle Methode wird der Prozesssicherheitskontext verwendet. Wenn Sie CoRevertToSelf nicht aufrufen, wird der Vorgang implizit aufgerufen, wenn die Methode beendet wird.

Hinweis: Die Identität des ursprünglichen Benutzers wird automatisch an eine Enterprise Services-Anwendung übermittelt und ist über SecurityCallContext.OriginalCaller verfügbar. Dies kann für Überwachungszwecke sinnvoll sein.

Aufrufen von CoImpersonateClient

CoImpersonateClient (und CoRevertToSelf) befinden sich in OLE32.dll. Sie müssen die zugehörigen Definitionen über das Attribut DllImport importieren, um sie über P/Invoke aufrufen zu können. Dies wird im nachfolgenden Codefragment veranschaulicht.

  class COMSec 
  { 
    [DllImport("OLE32.DLL", CharSet=CharSet.Auto)] 
    public static extern uint CoImpersonateClient(); 

    [DllImport("OLE32.DLL", CharSet=CharSet.Auto)] 
    public static extern uint CoRevertToSelf(); 
  } 
  . . .
  void SomeMethod()
  {
    // Wenn Sie den Sicherheitskontext des ursprünglichen Benutzers übermitteln und ihn für den Zugriff auf lokale Ressourcen
    // oder Remoteressourcen verwenden möchten, beginnen Sie mit dem Identitätswechsel 
    COMSec.CoImpersonateClient(); 
    // Führen Sie Operationen als Benutzers durch
    // In diesem Fall verwendet der Code den Kontext des Benutzers, nicht den Kontext des Prozesses 
    . . .
    COMSec.CoRevertToSelf();
    // In diesem Fall verwendet der Code hier wieder den Prozesskontext
  }
Weitere Informationen

Weitere Informationen zum Konfigurieren eines vollständigen Kerberos-Delegierungsszenarios, das die Übermittlung des Sicherheitskontexts des ursprünglichen Benutzers über eine ASP.NET-Webanwendung, eine Enterprise Services-Anwendung und eine Datenbank veranschaulicht, finden Sie im Abschnitt "Übermitteln des ursprünglichen Benutzers an die Datenbank" in Modul 5, "Intranetsicherheit".

 

RPC-Verschlüsselung

Verwenden Sie zwischen Client und Server die Authentifizierungsebene für RPC-Paketdatensicherheit, um die von einer Clientanwendung über DCOM an eine Remote-Serviced Component gesendeten Daten zu sichern. Dadurch wird die Vertraulichkeit und Integrität für Nachrichten gewährleistet.

Sie müssen die Authentifizierungsebene auf dem Client und dem Server konfigurieren.

Um ASP.NET zu konfigurieren (mit einer ASP.NET-Webanwendung als Client), legen Sie für das comAuthenticationLevel-Attribut des Elements <processModel> in der Datei machine.config den Wert PktPrivacy fest.

Um eine Enterprise Services-Serveranwendung zu konfigurieren, legen Sie die Authentifizierungsebene für die Anwendungsebene entweder mithilfe des Tools für Komponentendienste oder über das folgende .NET-Attribut innerhalb der Serviced Component-Assembly fest.

  [assembly: ApplicationAccessControl(
                Authentication = AuthenticationOption.Privacy)]

Weitere Informationen

  • Weitere Informationen zum Konfigurieren der Sicherheit (einschließlich der Authentifizierungsebenen) finden Sie unter "Sicherheitskonfiguration" weiter oben in diesem Modul.

  • Weitere Informationen zu RPC/DCOM-Authentifizierungsebenen finden Sie unter "Sicherheitskonzepte" weiter unten in diesem Modul.

  • Weitere Informationen zur Verhandlung auf der Authentifizierungsebene finden Sie unter "Sicherheitskonzepte" weiter unten in diesem Modul.

 

Erstellen von Serviced Components

Eine schrittweise Anleitung zum Erstellen einer Serviced Component finden Sie in diesem Handbuch unter "Vorgehensweise: Verwenden von rollenbasierter Sicherheit mit Enterprise Services".

Probleme beim Sperren von DLLs

Führen Sie die folgenden Schritte beim erneuten Erstellen einer Serviced Component durch, wenn die DLL gesperrt ist:

  • Verwenden Sie die Komponentendienste, um die COM+-Serveranwendung herunterzufahren.

  • Wenn Sie eine Bibliotheksanwendung erstellen, ist die Anwendung möglicherweise weiterhin im Prozess Aspnet_wp.exe geladen. Führen Sie IISReset über eine Eingabeaufforderung aus, oder verwenden Sie den Task-Manager, um den Prozess Aspnet_wp.exe anzuhalten.

  • Verwenden Sie das Tool FileMon.exe von https://technet.microsoft.com/sysinternals/default.aspx, um Probleme beim Sperren von Dateien zu beheben.

Versionserstellung

Das AssemblyVersion-Standardattribut, das von der Entwicklungsumgebung Microsoft Visual Studio® .NET beim Erstellen eines neuen Projekts generiert wird, ist nachfolgend dargestellt.

  [assembly: AssemblyVersion("1.0.*")]

Bei jedem erneuten Erstellen des Projekts wird eine neue Assemblyversion generiert. Dies führt auch zum Generieren eines neuen Klassenbezeichners (CLSID), um die Serviced Component-Klassen zu kennzeichnen. Wenn Sie die Assembly wiederholt mit den Komponentendiensten unter Verwendung der Datei Regsvcs.exe registrieren, werden duplizierte Komponenten (genau genommen Klassen) mit unterschiedlichen CLSIDs unter dem Ordner Komponenten angezeigt.

Dies entspricht zwar der strengen Semantik der COM-Versionserstellung und verhindert Probleme bei vorhandenen verwalteten sowie nicht verwalteten Clients, kann sich jedoch während der Entwicklung als störend erweisen.

Während der Tests und der Entwicklung sollten Sie erwägen, eine explizite Version unter Verwendung des AssemblyVersion-Attributs der Assemblyebene festzulegen wie nachfolgend gezeigt:

  [assembly: AssemblyVersion("1.0.0.1")]

Diese Einstellung verhindert, dass bei jeder nachfolgenden Projekterstellung eine neue CLSID generiert wird. Sie können auch das Problem für die Schnittstellenbezeichner (Interface Identifiers, IIDs) beheben. Wenn Ihre Klasse explizite Schnittstellen implementiert, können Sie die IID für eine gegebene Schnittstelle wie nachfolgend gezeigt mithilfe des GUID-Attributs ändern.

  [Guid("E1FBF27E-9F11-474d-8DF6-58916F798E9D")]
  public interface IMyInterface
  {
  }

  • So generieren Sie neue GUIDs

    1. Klicken Sie im Menü Extras von Visual Studio .NET auf GUID erstellen.

    2. Klicken Sie auf Registrierungsformat.

    3. Klicken Sie auf Neue GUID.

    4. Klicken Sie auf Kopieren.

    5. Fügen Sie die GUID aus der Zwischenablage in den Quellcode ein.

Wichtig: Vor dem Bereitstellen Ihrer Serviced Component-Assembly zum Testen und Produzieren müssen Sie alle geänderten GUIDs entfernen und zu einem automatisierten Versionserstellungsmechanismus zurückkehren (z. B. durch Verwenden von "1.0.*"). Wenn Sie diesen Vorgang nicht durchführen, erhöht sich die Wahrscheinlichkeit, dass eine neue Version Ihrer Komponente zu Problemen bei vorhandenen Clients führt.

Weitere Informationen

Weitere Informationen zur Versionserstellung für die Bereitstellung finden Sie in MSDN unter Understanding Enterprise Services (COM+) in .NET (englischsprachig).

QueryInterface-Ausnahmen

Wenn ein Aufruf von QueryInterface für die Schnittstelle IRoleSecurity fehlschlägt, zeigt dies an, dass Sie eine Schnittstellendefinition innerhalb Ihrer Assembly aktualisiert, die Assembly jedoch nicht mit den Komponentendiensten via Regsvcs.exe erneut registriert haben.

Wichtig: Bei jeder Ausführung von Regsvcs.exe müssen Sie die "Ausführen-als"-Identität einer Serveranwendung erneut konfigurieren und die Benutzer wieder zu Gruppen hinzufügen. Sie können ein einfaches Skript erstellen, um diese Aufgabe zu automatisieren.

 

DCOM und Firewalls

Windows 2000 (SP3 oder QFE 18.1) oder Windows .NET Server 2003 ermöglichen die Konfiguration von Enterprise Services-Anwendungen für die Verwendung eines statischen Endpunktes. Wenn eine Firewall den Client vom Server trennt, müssen Sie in der Firewall nur zwei Anschlüsse öffnen. Insbesondere muss Anschluss 135 für Remoteprozeduraufrufe (RPC) und ein Anschluss für die Enterprise Services-Anwendung geöffnet werden.

Wahlweise können Sie Ihre Enterprise Services-Anwendung als Webdienst offen legen. Dadurch können Sie Serviced Components unter Verwendung von SOAP über Anschluss 80 aktivieren und aufrufen. Das Hauptproblem bei diesem Ansatz besteht darin, dass er es Ihnen nicht ermöglicht, den Transaktionskontext vom Client an den Server zu übermitteln. Sie müssen Ihre Transaktion bei der Remote-Serviced Component starten.

Weitere Informationen

Weitere Informationen finden Sie in den folgenden Knowledge Base-Artikeln:

 

Aufrufen von Serviced Components über ASP.NET

In diesem Abschnitt werden die Hauptprobleme beschrieben, die auftreten können, wenn eine ASP.NET-Anwendung eine Serviced Component aufruft.

Benutzeridentität

Wenn Sie eine Serviced Component über eine ASP.NET-Anwendung aufrufen, wird die Sicherheitsidentität von der Win32®-Threadidentität der Anwendung abgerufen. Wenn die Webanwendung für den Identitätswechsel des Benutzers konfiguriert ist, handelt es sich hierbei um die Identität des Benutzers. Andernfalls ist es die ASP.NET-Prozessidentität (standardmäßig ASPNET).

Bei einer ASP.NET-Anwendung können Sie die aktuelle Win32-Threadidentität durch Aufrufen von WindowsIdentity.GetCurrent() abrufen.

Bei einer Serviced Component können Sie die Identität des ursprünglichen Benutzers durch die Verwendung von SecurityCallContext.OriginalCaller abrufen.

Verwenden der Windows-Authentifizierung und des Identitätswechsels innerhalb der webbasierten Anwendung

Um eine sinnvolle, rollenbasierte Sicherheit in Ihrer Enterprise Services-Anwendung zu ermöglichen, müssen Sie die Windows-Authentifizierung verwenden und den Identitätswechsel aktivieren. Dadurch wird sichergestellt, dass die Serviced Components die ursprünglichen Benutzer authentifizieren und Autorisierungsentscheidungen auf Basis der Identität des ursprünglichen Benutzers treffen können.

Konfigurieren der Authentifizierung und des Identitätswechsels in Machine.config

Die DCOM-Authentifizierungsebenen werden zwischen dem Client (z. B. einer webbasierten Anwendung) und dem Server (der Enterprise Services-Anwendung) verhandelt. Dabei wird die höhere der beiden Sicherheitseinstellungen verwendet.

Konfigurieren Sie die ASP.NET-Authentifizierungsebenen über das comAuthentication-Attribut des Elements <processModel> in der Datei Machine.config.

Die Identitätswechselebenen werden vom Client gesteuert (z. B. eine webbasierte Anwendung). Der Client kann den Grad für den Identitätswechsel bestimmen, den der Server verwenden darf.

Konfigurieren Sie die ASP.NET-Identitätswechselebenen (für alle ausgehenden DCOM-Aufrufe) über das comImpersonationLevel-Attribut des Elements <processModel> in der Datei Machine.config.

Konfigurieren von Schnittstellenproxys

Die für einzelne Schnittstellenproxys geltenden Sicherheitseinstellungen werden von den Standardsicherheitseinstellungen für die Prozessebene abgerufen. Bei ASP.NET werden die Standardsicherheitseinstellungen (wie die Identitätswechselebene und die Authentifizierungsebene) in der Datei Machine.config konfiguriert, wie bereits zuvor beschrieben.

Bei Bedarf können Sie die von einem einzelnen Schnittstellenproxy verwendeten Sicherheitseinstellungen ändern. Wenn Ihre ASP.NET-Anwendung beispielsweise mit einer Serviced Component kommuniziert, die zwei Schnittstellen offen legt, wobei aber nur über eine Schnittstelle vertrauliche Daten übertragen werden, können Sie die Verschlüsselungsunterstützung, die von der Authentifizierungsebene für Paketdatensicherheit bereitgestellt wird, nur für die Schnittstelle mit den vertraulichen Daten verwenden, während Sie für die andere Schnittstelle z. B. die Paketauthentifizierung nutzen. Dadurch vermeiden Sie den Leistungseinbruch, der bei einer Verschlüsselung bei beiden Schnittstellen auftritt.

Zusammengenommen wird die Gruppe der Sicherheitseinstellungen, die für einen Schnittstellenproxy gelten, als Sicherheitsblanket bezeichnet. COM stellt die folgenden Funktionen bereit, die Ihnen das Abfragen und Ändern von Sicherheitsblanketeinstellungen für einen einzelnen Schnittstellenproxy ermöglichen:

  • CoQueryProxyBlanket

  • CoSetProxyBlanket

  • CoCopyProxy

Sie müssen P/Invoke zum Aufrufen dieser Funktionen über eine ASP.NET-Webanwendung (DCOM-Client) verwenden. Der folgende Code veranschaulicht, wie eine bestimmte Schnittstelle für die Verwendung der Authentifizierungsebene für Paketdatensicherheit (die die Verschlüsselung ermöglicht) konfiguriert wird. Dieser Code kann von einer ASP.NET-Webanwendung verwendet werden, die mit einer Remote-Serviced Component kommuniziert.

  // Definieren Sie eine Wrapper-Klasse für den P/Invoke-Aufruf von "CoSetProxyBlanket"
  class COMSec 
  { 
    // Konstanten erforderlich für den Aufruf von "CoSetProxyBlanket"
    public const uint RPC_C_AUTHN_DEFAULT           = 0xFFFFFFFF;
    public const uint RPC_C_AUTHZ_DEFAULT           = 0xFFFFFFFF;
    public const uint RPC_C_AUTHN_LEVEL_PKT_PRIVACY = 6;
    public const uint RPC_C_IMP_LEVEL_DEFAULT       = 0;
    public const uint COLE_DEFAULT_AUTHINFO         = 0xFFFFFFFF;
    public const uint COLE_DEFAULT_PRINCIPAL        = 0;
    public const uint EOAC_DEFAULT                  = 0x800;

    // HRESULT  CoSetProxyBlanket( IUnknown * pProxy,
    //                             DWORD dwAuthnSvc,
    //                             DWORD dwAuthzSvc,
    //                             WCHAR * pServerPrincName, 
    //                             DWORD dwAuthnLevel,
    //                             DWORD dwImpLevel,
    //                             RPC_AUTH_IDENTITY_HANDLE pAuthInfo,
    //                             DWORD dwCapabilities ); 
  [DllImport("OLE32.DLL", CharSet=CharSet.Auto)] 
  public unsafe static extern uint CoSetProxyBlanket( 
                                        IntPtr pProxy,
                                        uint dwAuthnSvc,
                                        uint dwAuthzSvc,
                                        IntPtr pServerPrincName,
                                        uint dwAuthnLevel,
                                        uint dwImpLevel,
                                        IntPtr pAuthInfo,
                                        uint dwCapababilities);
  } // Klasse "COMSec" beenden


  // Code to call CoSetProxyBlanket
  void CallComponent()
  {
    // Dies ist die zu konfigurierende Schnittstelle
    Guid IID_ISecureInterface = new Guid("c720ff19-bec1-352c-bb4b-e2de10b858ba");
    IntPtr pISecureInterface;

    // Instanziieren Sie die Serviced Component
    CreditCardComponent comp = new CreditCardComponent();
    // Rufen Sie den zugehörigen IUnknown-Zeiger ab
    IntPtr pIUnk = Marshal.GetIUnknownForObject(comp);
    // Rufen Sie die zu konfigurierende Schnittstelle ab
    Marshal.QueryInterface(pIUnk, ref IID_ISecureInterface, 
                          out pISecureInterface);
    try
    {
      // Konfigurieren Sie den Schnittstellenproxy, und legen Sie die Paketsicherheit-Authentifizierung fest
      uint hr = COMSec.CoSetProxyBlanket( pISecureInterface, 
                                          COMSec.RPC_C_AUTHN_DEFAULT,
                                          COMSec.RPC_C_AUTHZ_DEFAULT,
                                          IntPtr.Zero,
                                          COMSec.RPC_C_AUTHN_LEVEL_PKT_PRIVACY,
                                          COMSec.RPC_C_IMP_LEVEL_DEFAULT,
                                          IntPtr.Zero,
                                          COMSec.EOAC_DEFAULT );
      ISecureInterface secure = (ISecureInterface)comp;
      // Der nachfolgende Aufruf wird als "ISecureInterface" verschlüsselt und ist
      // für die Paketsicherheit-Authentifizierung konfiguriert. Andere Schnittstellen verwenden die Prozessebenen- 
      // Standardwerte (üblicherweise handelt es sich hier um die Paketauthentifizierung).
      secure.ValidateCreditCard("123456789");
    }
    catch (Exception ex)
    {
    }
  }

Weitere Informationen

  • Weitere Informationen zum Konfigurieren einer ASP.NET-Clientanwendung für das Aufrufen von Serviced Components finden Sie unter "Konfigurieren einer ASP.NET-Clientanwendung" weiter oben in diesem Modul.

  • Weitere Informationen zu DCOM-Authentifizierungsebenen finden Sie unter "Authentifizierung" weiter unten in diesem Modul.

  • Weitere Informationen zu DCOM-Identitätswechselebenen finden Sie unter "Identitätswechsel" weiter unten in diesem Modul.

  • Weitere Informationen zur Verwendung der Windows-Authentifizierung und der Aktivierung des Identitätswechsels innerhalb einer webbasierten Anwendung finden Sie in Modul 8, "ASP.NET-Sicherheit".

 

Sicherheitskonzepte

Dieser Abschnitt bietet eine kurze Übersicht über die Sicherheitskonzepte der Enterprise Services. Viele Konzepte werden Ihnen bekannt sein, wenn Sie bereits Erfahrungen mit COM+ haben.

Hintergrundinformationen zu Enterprise Services finden Sie im MSDN-Artikel "Understanding Enterprise Services (COM+) in .NET" (englischsprachig).

Nachfolgend werden einige wichtige Sicherheitskonzepte zusammengefasst, die Ihnen vertraut sein sollten:

  • Sicherheitseinstellungen für Serviced Components und Enterprise Services-Anwendungen werden im COM+-Katalog verwaltet. Die meisten Einstellungen können mithilfe der .NET-Attribute konfiguriert werden. Alle Einstellungen können unter Verwendung des Verwaltungsprogramms für Komponentendienste oder des Entwicklungssystemskripts von Microsoft Visual Basic® Scripting Edition konfiguriert werden.

  • Die Autorisierung erfolgt über Enterprise Services-(COM+-)Rollen, die Gruppen- oder Benutzerkonten von Windows enthalten können. Hierbei handelt es sich nicht um .NET-Rollen.

    • Die rollenbasierte Sicherheit kann auf Anwendungs-, Schnittstellen-, Klassen- und Methodenebene zugeordnet werden.

    • Für differenzierte Autorisierungsentscheidungen können Sie die Rollenmitgliedschaft programmatisch mit der Methode IsCallerInRole der Klasse ContextUtil testen.

  • Für eine effektive rollenbasierte Autorisierung innerhalb einer Enterprise Services-Anwendung muss eine Windows-Identität zum Aufrufen der Serviced Components verwendet werden.

    • Dazu müssen Sie möglicherweise Windows-Authentifizierung zusammen mit dem Identitätswechsel innerhalb einer ASP.NET-Webanwendung durchführen – sofern die Webanwendung Serviced Components aufruft, die von Enterprise Services-(COM+-)Rollen abhängen.

    • Wenn Sie eine Serviced Component über eine ASP.NET-Webanwendung oder einen Webdienst aufrufen, wird die für den ausgehenden DCOM-Aufruf verwendete Identität durch die Win32-Threadidentität bestimmt, wie von WindowsIdentity.GetCurrent() definiert.

  • Serviced Components können in Server- oder Bibliotheksanwendungen ausgeführt werden.

    • Serveranwendungen werden in separaten Instanzen der Datei Dllhost.exe ausgeführt.

    • Bibliotheksanwendungen werden im Prozessadressraum des Clients ausgeführt.

    • Die rollenbasierte Autorisierung funktioniert für Server- und Bibliotheksanwendungen ähnlich, obwohl es hinsichtlich der Sicherheit einige geringfügige Unterschiede zwischen Bibliotheks- und Serveranwendungen gibt. Weitere Informationen finden Sie unter "Sicherheit für Server- und Bibliotheksanwendungen" weiter oben in diesem Modul.

  • Die Authentifizierung wird von den DCOM- und RPC-Diensten bereitgestellt. Mit der Kombination der Authentifizierungsebene des Clients und des Servers wird die sich ergebende Authentifizierungsebene bestimmt, die für die Kommunikation mit der Serviced Component verwendet wird.

  • Der Identitätswechsel wird innerhalb der Clientanwendung konfiguriert. Er bestimmt die Möglichkeiten des Servers für den Identitätswechsel.

Enterprise Services-(COM+-)Rollen und .NET-Rollen

Enterprise Services-(COM+-)Rollen werden zum Darstellen allgemeiner Kategorien von Benutzern verwendet, die dieselben Sicherheitsrechte in einer Anwendung gemeinsam nutzen. Während sie konzeptuell den .NET-Rollen ähneln, sind sie doch völlig eigenständig.

Enterprise Services-(COM+-)Rollen enthalten Windows-Benutzerkonten und -Gruppenkonten (anders als .NET-Rollen, die beliebige Nicht-Windows-Benutzeridentitäten enthalten können). Daher stellen Enterprise Services-(COM+-)Rollen nur einen effektiven Autorisierungsmechanismus für Anwendungen dar, die die Windows-Authentifizierung und den Identitätswechsel (zur Übermittlung des Sicherheitskontexts des Benutzers an die Enterprise Services-Anwendung) verwenden.

Tabelle 9.1: Vergleich von Enterprise Services-(COM+-)Rollen und .NET-Rollen

Funktion

Enterprise Services-(COM+-)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

Authentifizierung

Da Enterprise Services von der zugrunde liegenden Infrastruktur abhängen, die von COM+ und DCOM/RPC bereitgestellt wird, handelt es sich bei den für Enterprise Services-Anwendungen verfügbaren Einstellungen der Authentifizierungsebene um die von RPC definierten (und von DCOM verwendeten) Einstellungen.

Tabelle 9.2: Authentifizierungseinstellungen für Enterprise Services-Anwendungen

Authentifizierungsebene

Beschreibung

Standard

Auswählen der Authentifizierungsebene unter Verwendung normaler Verhandlungsregeln

Keine

Keine Authentifizierung

Verbinden

Anmeldeinformationen nur authentifizieren, wenn der Client die erste Verbindung zum Server herstellt

Aufruf

Authentifizierung zu Beginn jedes Remoteprozeduraufrufs

Paket

Authentifizierung aller vom Client erhaltenen Daten

Paketintegrität

Authentifizierung aller Daten und Überprüfung, dass keine übertragenen Daten geändert wurden

Paketdatensicherheit

Authentifizierung aller Daten und Verschlüsselung des Parameterstatus für jeden Remoteprozeduraufruf
Heraufstufen der Authentifizierungsebene

Sie sollten sich bewusst sein, dass bestimmte Authentifizierungsebenen automatisch heraufgestuft werden. Beispiel:

  • Bei Verwendung des UDP-Datagrammtransports werden die Ebenen "Verbinden" und "Aufruf" zu "Paket" heraufgestuft, da die zuvor erwähnten Authentifizierungsebenen nur über einen verbindungsorientierten Transport wie TCP sinnvoll sind.

    Hinweis: Windows 2000 verwendet für die DCOM-Kommunikation standardmäßig RPC über TCP.

  • Für prozessübergreifende Aufrufe auf einem einzelnen Computer werden alle Authentifizierungsebenen immer zu "Paketdatensicherheit" heraufgestuft. In einem Szenario mit einem einzelnen Computer erfolgt jedoch keine Datenverschlüsselung aus Vertraulichkeitsgründen (da diese Daten nicht über das Netzwerk übertragen werden).

Verhandeln der Authentifizierungsebene

Die von Enterprise Services zum Authentifizieren eines Clients verwendete Authentifizierungsebene wird durch zwei Einstellungen bestimmt:

  • Authentifizierungsebene für die Prozessebene. Bei einer durch Server aktivierten Anwendung (wird innerhalb von Dllhost.exe ausgeführt) wird die Authentifizierungsebene innerhalb des COM+-Katalogs konfiguriert.

  • Clientauthentifizierungsebene. Die konfigurierte Authentifizierungsebene des Clientprozesses, der mit der Serviced Component kommuniziert, hat auch Auswirkungen auf die verwendete Authentifizierungsebene.

    Die Standardauthentifizierungsebene für eine ASP.NET-Webanwendung wird in der Datei Machine.config durch das comAuthenticationLevel-Attribut des Elements <processModel> konfiguriert.

Es wird immer die höherwertige der beiden Authentifizierungsebenen (Client und Server) verwendet. Dies wird in Abbildung 9.4 veranschaulicht.

Verhandeln der Authentifizierungsebene

Abbildung 9.4
Verhandeln der Authentifizierungsebene

Weitere Informationen

Weitere Informationen zum Konfigurieren der Authentifizierungsebenen für eine Enterprise Services-Anwendung finden Sie unter "Sicherheitskonfiguration" weiter oben in diesem Modul.

Identitätswechsel

Die für eine Enterprise Services-Anwendung definierte Identitätswechselebene bestimmt die für alle ausgehenden DCOM-Aufrufe verwendete Identitätswechselebene, die von Serviced Components innerhalb der Anwendung durchgeführt werden.

Wichtig: Sie bestimmt NICHT, ob Serviced Components in der Anwendung den Identitätswechsel für ihre Benutzer durchführen. Serviced Components führen standardmäßig keinen Identitätswechsel für Benutzer durch. Um dies zu tun, muss die Serviced Component CoImpersonateClient aufrufen, wie unter "Übermitteln des ursprünglichen Benutzers" weiter oben in diesem Modul beschrieben.

Der Identitätswechsel ist eine clientseitige Einstellung. Er bietet dem Client einen gewissen Grad an Schutz, da der Client damit die Möglichkeiten des Servers für den Identitätswechsel einschränken kann.

Tabelle 9.3: Verfügbare Identitätswechselebenen

Identitätswechselebene

Beschreibung

Identifizieren

Ermöglicht es dem Server, den Client zu identifizieren sowie Zugriffsüberprüfungen unter Verwendung des Zugriffstokens des Clients durchzuführen.

Identität annehmen

Ermöglicht es dem Server, unter Verwendung der Anmeldeinformationen des Clients auf lokale Ressourcen zuzugreifen.

Delegieren

Ermöglicht es dem Server, unter Verwendung der Anmeldeinformationen des Clients auf Remoteressourcen zuzugreifen (dies erfordert Kerberos und eine spezielle Kontokonfiguration).

Die Standardebene für den Identitätswechsel, die von webbasierten Anwendungen bei der Kommunikation mit Serviced Components (oder anderen Komponenten, die DCOM verwenden) verwendet wird, wird durch das Attribut comImpersonationLevel im <processModel>-Element in Machine.config bestimmt.

Cloaking

Das Cloaking bestimmt genau, wie die Clientidentität während des Identitätswechsels über einen COM-Objektproxy für einen Server dargestellt wird. Es gibt zwei Arten von Cloaking:

  • Dynamisches Cloaking. Enterprise Services-Serveranwendungen verwenden das dynamische Cloaking (nicht konfigurierbar). Für Bibliotheksanwendungen wird das Cloaking durch den Hostprozess bestimmt, beispielsweise durch den ASP.NET-Workerprozess (Aspnet_wp.exe). Webbasierte Anwendungen verwenden ebenfalls das dynamische Cloaking (auch dies ist nicht konfigurierbar).

    Das dynamische Cloaking führt dazu, dass das Identitätswechseltoken für den Thread während des Identitätswechsels zur Darstellung der Clientidentität verwendet wird. Das bedeutet, dass beim Aufrufen von CoImpersonateClient innerhalb einer Serviced Component die Identität des Clients für nachfolgende ausgehende Aufrufe angenommen wird, die von derselben Methode durchgeführt werden, bis entweder CoRevertToSelf aufgerufen wird oder die Methode endet (wobei CoRevertToSelf implizit aufgerufen wird).

  • Statisches Cloaking. Beim statischen Cloaking werden dem Server die Anmeldeinformationen angezeigt, die beim ersten Aufruf des Clients an den Server verwendet werden (unabhängig davon, ob ein Thread während eines ausgehenden Aufrufs einen Identitätswechsel durchführt).

Weitere Informationen

  • Weitere Informationen zum Konfigurieren der Identitätswechselebenen für Enterprise Services-Anwendungen finden Sie unter "Sicherheitskonfiguration" weiter oben in diesem Modul.

  • Weitere Informationen zum Cloaking finden Sie in MSDN bei den Informationen für das Plattform-SDK unter "Cloaking" (englischsprachig).

 

Zusammenfassung

In diesem Modul wurde beschrieben, wie sichere Serviced Components innerhalb einer Enterprise Services-Anwendung erstellt werden. Es wurde außerdem gezeigt, wie eine webbasierte ASP.NET-Clientanwendung konfiguriert wird, die Serviced Components aufruft. Zusammengefasst:

  • Verwenden Sie durch Server aktivierte Enterprise Services-Anwendungen, um die Sicherheit zu erhöhen. Zusätzliche Prozesshops erhöhen ebenfalls die Sicherheit.

  • Verwenden Sie zum Ausführen von Serveranwendungen lokale Konten mit minimalen Rechten.

  • Verwenden Sie die Authentifizierung auf der Ebene der Paketdatensicherheit (die auf dem Server und dem Client konfiguriert werden muss), wenn Sie die Daten sichern müssen, die zwischen einer Serviced Component und einer Clientanwendung über ein Netzwerk übertragen werden.

  • Aktivieren Sie Zugriffsüberprüfungen auf Komponentenebene, um eine sinnvolle, rollenbasierte Sicherheitsimplementierung zu erreichen.

  • Verwenden Sie in einer ASP.NET-Webanwendung die Windows-Authentifizierung und aktivieren Sie den Identitätswechsel, bevor Sie eine Komponente in einer Enterprise Services-Anwendung aufrufen, die von der rollenbasierten Sicherheit abhängt.

  • Verwenden Sie gesicherte Gatewayklassen als Einstiegspunkte in Enterprise Services-Anwendungen.

    Indem Sie die Anzahl der Gatewayklassen verringern, die für Clients Einstiegspunkte in Ihre Enterprise Services-Anwendungen bereitstellen, reduzieren Sie die Anzahl der Klassen, denen Rollen zugeordnet werden müssen. Für andere interne Hilfsklassen sollten rollenbasierte Überprüfungen aktiviert, diesen aber keine Rollen zugeordnet werden. Das bedeutet, dass externe Clients diese nicht direkt aufrufen können, während die Gatewayklassen in derselben Anwendung über direkten Zugriff verfügen.

  • Rufen Sie IsSecurityEnabled unmittelbar vor dem Überprüfen der Rollenmitgliedschaft programmatisch auf.

  • Vermeiden Sie einen Identitätswechsel auf der mittleren Ebene, da dies ein effektives Datenbankverbindungspooling verhindert und die Skalierbarkeit Ihrer Anwendung drastisch einschränkt.

  • Fügen Sie Windows-Gruppen zu Enterprise Services-(COM+-)Rollen hinzu, um die Flexibilität zu erhöhen und die Verwaltung zu vereinfachen.