Modul 11 – .NET Remoting-Sicherheit

Auf dieser Seite

 Modulübersicht
 Zielsetzung
 Betrifft
 Verwendung dieses Moduls
 .NET Remoting-Architektur
 .NET Remoting-Gatekeeper
 Authentifizierung
 Autorisierung
 Authentifizierungs- und Autorisierungsstrategien
 Zugriff auf Systemressourcen
 Zugriff auf Netzwerkressourcen
 Übergeben von Anmeldeinformationen an Remoteobjekte zur Authentifizierung
 Übermitteln des ursprünglichen Benutzers
 Vertrauenswürdiges Subsystem
 Sichere Kommunikation
 Auswählen eines Hostprozesses
 Remoting im Vergleich zu Webdiensten
 Zusammenfassung

Modulübersicht

Das .NET Framework bietet eine Remoting-Infrastruktur, die Clients die Kommunikation mit Objekten ermöglicht, die in Remoteanwendungsdomänen und -prozessen bzw. auf Remotecomputern gehostet sind. In verteilten Webanwendungen können .NET Komponenten der Präsentationsebene via .NET Remoting auf Geschäftslogikkomponenten zugreifen, die sich in der mittleren Ebene befinden.

In diesem Modul wird erläutert, wie Sie Authentifizierung, Autorisierung und sichere Kommunikation in verteilten Webanwendungen implementieren, die .NET Remoting verwenden.

Zielsetzung

Themenbereiche:

• Sichern der .NET Remoting-Lösung

• Erstellen sicherer Remotekomponenten

• Kennenlernen der Architektur und der Funktionen verteilter Anwendungen, die .NET Remoting verwenden, und Einarbeiten in die Erweiterungsfunktionen von .NET Remoting

• Auswählen eines geeigneten Hostprozesses

• Identifizieren und Verwenden der von .NET Remoting bereitgestellten Gatekeeper

• Übermitteln von Clientanmeldeinformationen mit Aufrufen an Remoteobjekte

• Übertragen der Identität eines ursprünglichen Benutzers von einer Remotekomponente auf Downstream-Systeme

• Einsatzmöglichkeiten für .NET Remoting bzw. für Webdienste als Teil Ihrer verteilten Webanwendung

• Ausarbeiten geeigneter Mechanismen hinsichtlich Authentifizierung, Autorisierung und sicherer Kommunikation für Ihre .NET Remoting-Lösung

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

• Visual C# .NET

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

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 SQL Server-Sicherheit, IIS-Sicherheit, Windows-Sicherheit und Active Directory 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 ASP.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 sichere 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 Ihnen bei der Arbeit mit .NET Remoting zur Verfügung stehen.

• Lesen Sie Modul 4, "Sichere Kommunikation". Hier finden Sie eine Einführung in Secure Sockets Layer (SSL) und IPSec, die häufig verwendet werden, um Kommunikationskanäle zwischen Clients und Remoteobjekten zu sichern.

• Lesen Sie Modul 8, "ASP.NET-Sicherheit". Hier werden mit ASP.NET in Verbindung stehende Sicherheitsaspekte erläutert, von denen viele relevant sind, wenn Sie das Hosting von Remoteobjekten in ASP.NET durchführen (der empfohlene Ansatz).

• Lesen Sie sich folgende Module durch, aus denen hervorgeht, wie ein Großteil der in diesem Modul erläuterten Techniken implementiert wird:

  • "Vorgehensweise: Erstellen eines benutzerdefinierten Kontos zum Ausführen von ASP.NET"

  • "Vorgehensweise: Verwenden eines Windows-Dienstes als Host für ein Remoteobjekt"

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

  • "Vorgehensweise: Einrichten von SSL auf einem Webserver"

  • "Vorgehensweise: Verwenden von IPSec zum Sichern der Kommunikation zwischen zwei Servern"

  • "Vorgehensweise: Verwenden von SSL zum Sichern der Kommunikation mit SQL Server 2000"

.NET Remoting-Architektur

Aus Abbildung 11.1 geht hervor, wie die grundlegende .NET Remoting-Architektur aussieht, wenn Sie ein Remoteobjekt in ASP.NET hosten. Ein ASP.NET-Host gemeinsam mit dem HyperText Transfer Protocol-(HTTP-)Kanal für Kommunikationszwecke zu empfehlen, wenn das Hauptaugenmerk auf der Sicherheit liegt, da das Remoteobjekt hierdurch die Sicherheitsdienste von ASP.NET und IIS verwenden kann.

Weitere Informationen zu verfügbaren Host- und Kanaltypen sowie vergleichsbezogene Informationen finden Sie unter "Auswählen eines Hostprozesses" weiter unten in diesem Modul.

Abbildung 11.1
.NET Remoting-Architektur

Der Client kommuniziert mit einem In-Process-Proxyobjekt. Anmeldeinformationen für die Authentifizierung (z. B. Benutzernamen, Kennwörter, Zertifikate usw.) können Sie über den Proxy des Remoteobjekts festlegen. Der Methodenaufruf durchläuft eine Kette mit Datensenken (Sie können eigene benutzerdefinierte Datensenken implementieren, zum Beispiel, um die Datenverschlüsselung vorzunehmen) und wird auf die Transportdatensenke übertragen, die für das Senden von Daten innerhalb des Netzwerks zuständig ist. Auf der Serverseite durchläuft der Aufruf dieselbe Pipeline und wird dann an das Objekt gesendet.

Hinweis: Der Begriff Proxy, der im gesamten Modul verwendet wird, bezieht sich auf das clientseitige In-Process-Proxyobjekt, über das Clients mit dem Remoteobjekt kommunizieren. Achtung: Proxy darf nicht mit dem Begriff Proxyserver verwechselt werden.

Remoting-Datensenken

In .NET Remoting kommen Datensenken von Transportkanälen, benutzerdefinierten Kanälen und Formatierungskanälen zum Einsatz, wenn ein Client einen Methodenaufruf für ein Remoteobjekt initiiert.

Datensenken von Transportkanälen

Datensenken von Transportkanälen übertragen Methodenaufrufe im gesamten Netzwerk zwischen dem Client und dem Server. In .NET werden die Klassen HttpChannel und TcpChannel bereitgestellt, obwohl die Architektur vollständig erweiterbar ist und Sie Ihre eigenen benutzerdefinierten Implementierungen integrieren können.

• HttpChannel. Dieser Kanal ist zu verwenden, wenn Sie das Hosting eines Remoteobjekts in ASP.NET durchführen. Dieser Kanal nutzt das HTTP-Protokoll, um Meldungen zwischen Client und Server zu übertragen.

• TcpChannel. Dieser Kanal kommt zum Einsatz, wenn Sie das Hosting eines Remoteobjekts in einem Dienst des Microsoft® Windows®-Betriebssystems oder einer anderen ausführbaren Datei durchführen. Dieser Kanal nutzt TCP-Sockets, um Meldungen zwischen Client und Server zu übermitteln.

• Benutzerdefinierte Kanäle. Ein benutzerdefinierter Transportkanal kann ein zugrunde liegendes Transportprotokoll verwenden, um Meldungen zwischen Client und Server zu übermitteln. Ein benutzerdefinierter Kanal nutzt beispielsweise Named Pipes oder Mailslots.

Vergleich von Transportkanal-Datensenken

In der nachfolgenden Tabelle werden die beiden wichtigsten Transportkanal-Datensenken miteinander verglichen.

Tabelle 11.1: Vergleich von "TcpChannel" und "HttpChannel"

Benutzerdefinierte Datensenken

Benutzerdefinierte Kanaldatensenken können Sie an unterschiedlichen Punkten der Kanaldatensenken-Pipeline einsetzen, um Meldungen zu ändern, die zwischen Client und Server übermittelt werden. Ein Beispiel für eine benutzerdefinierte Kanaldatensenke ist eine Kanaldatensenke, die Verschlüsselungs- und Entschlüsselungsfunktionen bereitstellt.

Formatierungssenken

Formatierungssenken serialisieren Methodenaufrufe in einen Strom, der netzwerkübergreifend übermittelt werden kann. In .NET werden zwei Formatierungssenken bereitgestellt:

• Binäre Formatierung. Sie verwendet die Klasse BinaryFormatter, um Methodenaufrufe in Paketform in einen serialisierten Binärstrom aufzunehmen, der anschließend (mithilfe von HTTP-POST) gesendet wird, um die Daten an den Server zu übermitteln. Bei der binären Formatierung wird der Inhaltstyp (content-type) in der HTTP-Anforderung auf "application/octet-stream" eingestellt.
  Die binäre Formatierung ist der Simple Object Access Protocol-(SOAP-)Formatierung klar überlegen.

• SOAP-Formatierung. Sie verwendet die Klasse SoapFormatter, um Methodenaufrufe in Paketform in eine SOAP-Meldung aufzunehmen. Der Inhaltstyp wird in der HTTP-Anforderung auf "text/xml" eingestellt und mit HTTP-POST an den Server übermittelt.

Anatomie einer Anforderung beim Hosting in ASP.NET

Endpunkte von Remoteobjekten werden von URLs adressiert, die mit der Dateinamenerweiterung REM bzw. SOAP enden, beispielsweise http://someserver/vDir/remoteobject.soap. Wenn eine Anforderung für ein Remoteobjekt (mit der Erweiterung REM oder SOAP) von IIS empfangen wird, wird sie (in IIS) der ASP.NET-ISAPI-Erweiterung zugeordnet (Aspnet_isapi.dll). Die ISAPI-Erweiterung leitet die Anforderung an eine Anwendungsdomäne im ASP.NET-Workerprozess (Aspnet_wp.exe) weiter. Die Abfolge der Ereignisse geht aus Abbildung 11.2 hervor.

Abbildung 11.2
Serverseitige Verarbeitung

Aus Abbildung 11.2 geht folgende Ereignisabfolge hervor:

1. Eine SOAP- oder REM-Anforderung geht über HTTP ein und wird einem spezifischen virtuellen Verzeichnis auf dem Webserver zugeordnet.

2. IIS überprüft die SOAP-/REM-Zuordnung und ordnet die Dateierweiterung der ASP.NET-ISAPI-Erweiterung Aspnet_isapi.dll zu.

3. Die ISAPI-Erweiterung überträgt die Anforderung an eine Anwendungsdomäne im ASP.NET-Workerprozess (Aspnet_wp.exe). Wenn es sich hierbei um die erste an diese Anwendung gerichtete Anforderung handelt, wird eine neue Anwendungsdomäne erstellt.

4. Der HttpRemotingHandlerFactory-Handler wird aufgerufen, und die Remoting-Infrastruktur liest den <system.runtime.remoting>-Abschnitt in Web.config, durch den die serverseitige Objektkonfiguration (z. B. Einzelaufruf- oder Singleton-Parameter) sowie Autorisierungsparameter (aus dem <authorization>-Element) gesteuert werden.

5. Die Remoting-Infrastruktur macht die Assembly ausfindig, die das Remoteobjekt enthält, und instanziiert sie.

6. Die Remoting-Infrastruktur liest die HTTP-Header und den Datenstrom und ruft dann die Methode im Remoteobjekt auf.

   Hinweis: Während dieses Prozesses ruft ASP.NET die übliche Abfolge von Ereignishandlern auf. Optional können einer oder mehrere hiervon in Global.asax implementiert werden, beispielsweise BeginRequest, AuthenticationRequest, AuthorizeRequest usw. Zu dem Zeitpunkt, zu dem die Anforderung die Remoteobjektmethode erreicht, wurde das IPrincipal-Objekt, das den authentifizierten Benutzer darstellt, in HttpContext.User (und Thread.CurrentPrincipal) gespeichert. Es steht für Autorisierungszwecke zur Verfügung. Hier kommen beispielsweise Hauptberechtigungen und programmatische Rollenüberprüfungen zum Einsatz.

ASP.NET und der HTTP-Kanal

Remoting verfügt nicht über ein eigenes Sicherheitsmodell. Authentifizierung und Autorisierung zwischen Client (Proxy) und Server (Remoteobjekt) werden durch den Kanal- und Hostprozess durchgeführt. Folgende Kombinationen von Hosts und Kanälen können Sie verwenden:

• Benutzerdefinierte ausführbare Datei und der TCP-Kanal. Bei dieser Kombination stehen keinerlei integrierte Sicherheitsfunktionen zur Verfügung.

• ASP.NET und der HTTP-Kanal. Bei dieser Kombination werden Authentifizierung und Autorisierung mithilfe der ASP.NET- und IIS-Sicherheitsfunktionen durchgeführt.

Objekte, deren Hosting in ASP.NET durchgeführt wird, profitieren von den Sicherheitsfunktionen von ASP.NET und IIS. Hierzu zählen:

• Authentifizierungsfunktionen. Die Windows-Authentifizierung wird in Web.config konfiguriert:

    <authentication mode="Windows"/>
  

  Über die Einstellungen in IIS wird gesteuert, welche Art von HTTP-Authentifizierung zum Einsatz kommt.

  Gängige HTTP-Header werden zur Authentifizierung von Anforderungen verwendet. Sie können Anmeldeinformationen für den Client zur Verfügung stellen, indem Sie den Remoteobjektproxy einsetzen. Sie können auch standardmäßige Anmeldeinformationen verwenden.

  Formular- bzw. Passport-Authentifizierung funktioniert hier nicht, da hierbei kein Zugriff des Clients auf Cookies möglich ist. Dies ist jedoch eine Voraussetzung für diese beiden Authentifizierungsmechanismen. Außerdem ist für Formulare und Passport eine Umleitung an eine Anmeldeseite erforderlich, was wiederum die Interaktion mit dem Client voraussetzt. Remoteobjekte auf der Serverseite wurden für die nicht interaktive Verwendung konzipiert.

• Autorisierungsfunktionen. Clients werden über standardmäßige ASP.NET-Autorisierungstechniken autorisiert.

  Zu den konfigurierbaren Autorisierungsoptionen zählen:

  • URL-Autorisierung.

  • Dateiautorisierung (hierfür ist eine spezifische Konfiguration erforderlich, wie unter "Arbeiten mit der Dateiautorisierung" weiter unten in diesem Modul erläutert).

  Zu den programmatischen Autorisierungsoptionen zählen:

  • Hauptberechtigungen (deklarativ und imperativ).

  • Explizite Rollenüberprüfungen mit IPrincipal.IsInRole.

• Funktionen für sichere Kommunikation. Für die Sicherung des Datentransports zwischen Client und Server wird SSL (und/oder IPSec) empfohlen.

Weitere Informationen

• Weitere Informationen zu den von ASP.NET und IIS bereitgestellten Authentifizierungs- und Autorisierungsfunktionen finden Sie in Modul 8, "ASP.NET-Sicherheit".

• Weitere Informationen zum Hosting eines Objekts in ASP.NET/IIS finden Sie im Artikel Q312107, "HOW TO: Host a Remote Object in Microsoft Internet Information Services", der Microsoft Knowledge Base (englischsprachig) .

.NET Remoting-Gatekeeper

Folgende Autorisierungspunkte (oder Gatekeeper) stehen für ein Remoteobjekt, dessen Hosting von ASP.NET durchgeführt wird, zur Verfügung:

• IIS. Wenn die anonyme Authentifizierung deaktiviert ist, lässt IIS nur Anforderungen von Benutzern zu, die sich entweder in der zugehörigen oder einer vertrauenswürdigen Domäne authentifizieren können. IIS bietet außerdem Filterfunktionen für IP-Adressen und DNS.

• ASP.NET

  • UrlAuthorizationModule. Sie können <authorization>-Elemente in der Datei Web.config Ihrer Anwendung konfigurieren, um zu steuern, welche Benutzer und Benutzergruppen auf die Anwendung zugreifen dürfen. Die Autorisierung basiert auf dem IPrincipal-Objekt, das in HttpContext.User gespeichert ist.

  • FileAuthorizationModule. Das FileAuthorizationModulesteht für Remotekomponenten zur Verfügung, obwohl hierfür eine spezifische Konfiguration erforderlich ist.

    Hinweis: Der Identitätswechsel ist für die ordnungsgemäße Funktion der Dateiautorisierung nicht erforderlich.

    Die Klasse FileAuthorizationModule führt nur für die angeforderte Datei bzw. den angeforderten URI (z. B. REM und SOAP) Zugriffsüberprüfungen durch, nicht für Dateien, auf die über Code innerhalb des Remoteobjekts zugegriffen wird.

• Hauptberechtigungen und explizite Rollenüberprüfungen. Zusätzlich zu den konfigurierbaren Gatekeepern von IIS und ASP.NET können Hauptberechtigungen (deklarativ oder imperativ) als zusätzliche Mechanismen für die differenzierte Zugriffssteuerung verwendet werden. Hauptberechtigungsüberprüfungen ermöglichen die Zugriffssteuerung für Klassen, Methoden oder einzelne Codeblöcke, basierend auf der Identität und Gruppenmitgliedschaft einzelner Benutzer. Die entsprechende Definition finden Sie im IPrincipal-Objekt, das an den aktuellen Thread angehängt ist.

  Hinweis: Zum Anfordern der Rollenmitgliedschaft verwendete Hauptberechtigungen unterscheiden sich vom Aufrufen von IPrincipal.IsInRole zum Testen der Rollenmitgliedschaft. Beim ersten Vorgang wird eine Ausnahmebedingung erzeugt, wenn der Benutzer nicht Mitglied der angegebenen Rolle ist, beim zweiten Vorgang wird hingegen lediglich ein Boole'scher Wert zurückgegeben, um die Rollenmitgliedschaft zu bestätigen.

  Bei der Windows-Authentifizierung hängt ASP.NET automatisch ein WindowsPrincipal-Objekt an, das den authentifizierten Benutzer für die aktuelle Webanforderung (unter Verwendung von HttpContext.User) darstellt.

Authentifizierung

Wenn Sie Remoting gemeinsam mit einem ASP.NET-Webanwendungsclient verwenden, erfolgt die Authentifizierung innerhalb der Webanwendung und auf dem Remoteobjekthost. Die verfügbaren Authentifizierungsoptionen für den Remoteobjekthost hängen vom Hosttyp ab.

Hosting in ASP.NET

Wenn das Hosting für Objekte in ASP.NET erfolgt, wird der HTTP-Kanal verwendet, um Methodenaufrufe zwischen dem clientseitigen Proxy und dem Server zu übertragen. Der HTTP-Kanal verwendet das HTTP-Protokoll, um den Remoteobjektproxy für den Server zu authentifizieren.

Die folgende Liste zeigt die Authentifizierungsoptionen, die beim Hosting in ASP.NET zur Verfügung stehen:

• IIS-Authentifizierungsoptionen. Anonyme Authentifizierung, Standardauthentifizierung, Digestauthentifizierung, integrierte Windows-Authentifizierung und Zertifikatsauthentifizierung.

• ASP.NET-Authentifizierungsoptionen. Windows-Authentifizierung oder Keine (für Implementierungen benutzerdefinierter Authentifizierungen)

  Hinweis: .NET Remoting kann ie Formular- und die Passport-Authentifizierung nicht direkt verwenden. An Remoteobjekte gerichtete Aufrufe wurden als "nicht interaktiv" konzipiert. Wenn es sich beim Client des Remoteobjekts um eine .NET-Webanwendung handelt, kann die Webanwendung die Formular- und Passport-Authentifizierung verwenden und Anmeldeinformationen explizit an das Remoteobjekt übergeben. Diese Art von Szenario wird unter "Übermitteln des ursprünglichen Benutzers" weiter unten in diesem Modul ausführlicher erläutert.

Hosting in einem Windows-Dienst

Wenn das Hosting für Objekte in einem Windows-Dienst erfolgt, wird der TCP-Kanal verwendet, um Methodenaufrufe zwischen dem Client und dem Server zu übertragen. Dieser verwendet Übertragungen, die auf Ursprungssockets (Raw Sockets) basieren. Da mit Sockets keine Authentifizierung bereitgestellt wird, gibt es für den Server keine Möglichkeit, den Client zu authentifizieren.

In diesem Szenario muss das Remoteobjekt die benutzerdefinierte Authentifizierung verwenden.

Benutzerdefinierte Authentifizierung

Bei der einfachen benutzerdefinierten Authentifizierung kann das Remoteobjekt eine Login-Methode bereitstellen, die einen Benutzernamen und ein Kennwort akzeptiert. Die Anmeldeinformationen können anhand eines Speichers, einer abgerufenen Rollenliste sowie anhand eines an den Client zurückgesendeten Tokens überprüft werden, das für nachfolgende Anforderungen verwendet werden soll. Wenn das Token auf dem Server abgerufen wird, erstellt es ein IPrincipal-Objekt (mit Rollen), das in Thread.CurrentPrincipal gespeichert wird, wo der Einsatz zu Autorisierungszwecken erfolgt.

Andere Beispiele für benutzerdefinierte Authentifizierungen umfassen das Erstellen einer benutzerdefinierten Transportkanal-Datensenke, die einen prozessübergreifenden Kommunikationskanal verwendet, der die Authentifizierung bereitstellt (z. B. Pipes), oder das Erstellen einer Kanaldatensenke, die die Authentifizierung anhand des Windows Security Service Provider Interface (SSPI) durchführt.

Weitere Informationen

• Weitere Informationen zum Hosting eines Objekts in einem Windows-Dienst finden Sie unter "Vorgehensweise: Verwenden eines Windows-Dienstes als Host für ein Remoteobjekt" in diesem Handbuch.

• Weitere Informationen zu Datensenken und Datensenkenketten finden Sie im Abschnitt zum .NET Framework unter "Sinks and Sink Chains" in der MSDN Library (englischsprachig).

• Weitere Informationen zum Erstellen einer benutzerdefinierten Authentifizierungslösung, die SSPI verwendet, finden Sie im MSDN-Artikel ".NET Remoting Security Solution, Part 1: Microsoft.Samples.Security.SSPI Assembly" (englischsprachig) unter https://msdn2.microsoft.com/library/ms973911.aspx.

  Hinweis: Die in diesem Artikel beschriebene Implementierung ist ein Beispiel und kein von Microsoft getestetes und unterstütztes Produkt.

Autorisierung

Wenn das Hosting von Objekten von ASP.NET durchgeführt und der HTTP-Kanal für die Kommunikation genutzt wird, kann der Client über folgende Mechanismen authentifiziert und autorisiert werden:

• URL-Autorisierung

• Dateiautorisierung

• Hauptberechtigungen (deklarativ und imperativ)

• IPrincipal.IsInRole-Überprüfungen im Code

Wenn das Hosting von Objekten in einem Windows-Dienst erfolgt, stellt der TCP-Kanal keinerlei Autorisierung bereit. Folglich müssen Sie die benutzerdefinierte Authentifizierung und anschließend die Autorisierung durchführen, indem Sie ein IPrincipal-Objekt erstellen und es in Thread.CurrentPrincipal speichern.

Sie können dann Ihre Methoden des Remoteobjekts über deklarative Überprüfungen von Hauptberechtigungen mit Anmerkungen versehen, wie nachfolgend dargestellt.

[PrincipalPermission(SecurityAction.Demand, 
                     Role="Manager")]
void SomeMethod()
{
}

Innerhalb des Codes der Methode Ihres Objekts können auch imperative Hauptberechtigungen und explizite Rollenüberprüfungen mithilfe von IPrincipal.IsInRole verwendet werden.

Arbeiten mit der Dateiautorisierung

Sie können die integrierte Windows-Zugriffssteuerung verwenden, um das Remoteobjekt als sicherungsfähige Windows-Ressource zu sichern. Ohne die Dateiautorisierung (unter Verwendung von Windows-ACLs) steht Ihnen nur die URL-Autorisierung zur Verfügung.

Sie müssen eine physische Datei mit der Dateierweiterung REM oder SOAP im virtuellen Verzeichnis der Anwendung erstellen, um FileAuthorizationModule zum Autorisieren des Zugriffes auf Remoteobjektendpunkte (gekennzeichnet durch REM- oder SOAP-URLs) zu verwenden.

Hinweis: Die Dateierweiterungen REM und SOAP werden von IIS verwendet, um Anforderungen für Objektendpunkte zur ASP.NET ISAPI-Erweiterung (aspnet_isapi.dll) zuzuordnen. Sie sind normalerweise nicht als physische Dateien vorhanden.

So konfigurieren Sie die Dateiautorisierung für .NET Remoting

1. Erstellen Sie eine Datei mit demselben Namen wie objectUri (z. B. RemoteMath.rem) im virtuellen Stammverzeichnis der Anwendung.

2. Fügen Sie am Anfang der Datei die folgende Zeile hinzu, und speichern Sie dann die Datei:

     <%@ webservice class="YourNamespace.YourClass" ... %>
   

3. Fügen Sie über Windows Explorer eine entsprechend konfigurierte ACL zur Datei hinzu.

   Hinweis: Sie können objectUri aus der Datei Web.config abrufen, die zum Konfigurieren des Remoteobjekts auf dem Server verwendet wird. Suchen Sie das Element <wellknown>, wie nachfolgend dargestellt.

     <wellknown mode="SingleCall" objectUri="RemoteMath.rem" 
     type="RemotingObjects.RemoteMath, RemotingObjects, Version=1.0.000.000 
     Culture=neutral, PublicKeyToken=4b5ae668c251b606"/>
   

Weitere Informationen

• Weitere Informationen zu diesen Autorisierungsmechanismen finden Sie in Modul 8, "ASP.NET-Sicherheit".

Authentifizierungs- und Autorisierungsstrategien

Viele Anwendungen, die .NET Remoting verwenden, nutzen die Remoteobjekte, um auf der mittleren Ebene der Anwendung Geschäftsfunktionen bereitzustellen; diese Funktionen werden dann von den ASP.NET-Webanwendungen aufgerufen. Diese Anordung ist in Abbildung 11.3 dargestellt.

Abbildung 11.3
Von einer ASP.NET-Webanwendung aufgerufene Remoteobjekte

In diesem Szenario werden die für die Webanwendung verfügbaren IIS- und ASP.NET-Gatekeeper verwendet, um den Zugriff auf den clientseitigen Proxy zu sichern. Die für den ASP.NET-Host auf dem Remoteanwendungsserver zur Verfügung stehenden IIS- und ASP.NET-Gatekeeper stehen zum Sichern des Zugriffs auf das Remoteobjekt bereit.

Es gibt im Wesentlichen zwei Authentifizierungs- und Autorisierungsstrategien für Remoteobjekte, auf die .NET-Webanwendungen zugreifen.

• Sie können Benutzer auf dem Webserver authentifizieren sowie autorisieren und dann den Sicherheitskontext des Benutzers unter Verwendung des Identitätswechsels an das Remoteobjekt übermitteln. Dies ist das Modell mit Identitätswechsel/Delegierung.
  Bei diesem Ansatz verwenden Sie einen IIS-Authentifizierungsmechanismus, der es erlaubt, den Sicherheitskontext des Benutzers zu delegieren, z. B. die Kerberos-, Standard- oder Formularauthentifizierung (wobei es die beiden letztgenannten Mechanismen ermöglichen, auf die Anmeldeinformationen des Benutzers zuzugreifen), und die Anmeldeinformationen explizit an das Remoteobjekt zu übermitteln, wobei der Proxy des Remoteobjekts verwendet wird.

  Die von ASP.NET konfigurierbaren und programmatischen Gatekeeper (einschließlich der URL-Autorisierung, der Dateiautorisierung, der Hauptberechtigungen und .NET-Rollen) stehen zum Autorisieren einzelner Benutzer innerhalb des Remoteobjekts zur Verfügung.

• Sie können Benutzer auf dem Webserver authentifizieren sowie autorisieren und dann eine vertrauenswürdige Identität verwenden, um mit dem Remoteobjekt zu kommunizieren. Dies ist das Modell der vertrauenswürdigen Subsysteme.
  Dieses Modell beruht darauf, dass die Webanwendung Benutzer authentifiziert und ordnungsgemäß autorisiert, bevor das Remoteobjekt aufgerufen wird. Sämtliche vom Remoteobjekt erhaltenen Anforderungen von der vertrauenswürdigen Identität, die von der Webanwendung geplant wurden, dürfen fortgesetzt werden.

Weitere Informationen

• Weitere Informationen zum Modell mit Identitätswechsel/Delegierung und zum Modell der vertrauenswürdigen Subsysteme finden Sie unter "Ressourcenzugriffsmodelle" im Abschnitt "Autorisierungsansätze" in Modul 3, "Authentifizierung und Autorisierung".

• Weitere Informationen zum Verwenden des Modells des ursprünglichen Benutzers mit Remoting finden Sie unter "Übermitteln des ursprünglichen Benutzers" weiter unten in diesem Modul.

• Weitere Informationen zum Verwenden des Modells der vertrauenswürdigen Subsysteme finden Sie unter "Vertrauenswürdiges Subsystem" weiter unten in diesem Modul.

Zugriff auf Systemressourcen

Weitere Informationen zum Zugriff auf Systemressourcen (z. B. auf das Ereignisprotokoll und die Registrierung) über ein Remoteobjekt, dessen Hosting ASP.NET durchführt, finden Sie unter "Zugreifen auf Systemressourcen" in Modul 8, "ASP.NET-Sicherheit". Die in Modul 8 erläuterten Ansätze und Einschränkungen gelten auch für Remoteobjekte, deren Hosting von ASP.NET durchgeführt wird.

Zugriff auf Netzwerkressourcen

Wenn Sie über ein Remoteobjekt auf Netzwerkressourcen zugreifen, müssen Sie die Art der Identität bedenken, die zum Antworten auf Netzwerk-Authentifizierungsanforderungen vom Remotecomputer verwendet wird. Drei Optionen stehen zur Wahl:

• Prozessidentität (Standardwert). Wenn das Hosting in ASP.NET erfolgt, bestimmt die zum Ausführen des ASP.NET-Workerprozesses verwendete und vom Element <processModel> in Machine.config definierte Identität den Sicherheitskontext, der für den Ressourcenzugriff verwendet wird.
  Wenn das Hosting in einem Windows-Dienst erfolgt, bestimmt die zum Ausführen des Dienstprozesses (mit dem MMC-Snap-In Dienste konfiguriert) verwendete Identität den Sicherheitskontext, der für den Ressourcenzugriff verwendet wird.

• Feste Dienstidentität. Beispiel: Eine Dienstidentität, die durch Aufrufen von LogonUser erstellt wurde.

  Hinweis: Verwechseln Sie diese Dienstidentität nicht mit der zum Ausführen des Windows-Dienstes verwendeten Identität. Eine feste Dienstidentität verweist auf ein Windows-Benutzerkonto, das speziell zum Zugreifen auf Ressourcen von einer Anwendung erstellt wurde.

• Identität des ursprünglichen Benutzers. Wenn ASP.NET für den Identitätswechsel konfiguriert ist oder der programmatische Identitätswechsel in einem Windows-Dienst verwendet wird.

Ausführliche Informationen zu den Vorzügen dieser Ansätze finden Sie zusammen mit Konfigurationsdetails unter "Zugreifen auf Netzwerkressourcen" in Modul 8, "ASP.NET-Sicherheit".

Übergeben von Anmeldeinformationen an Remoteobjekte zur Authentifizierung

Wenn ein Clientprozess ein Remoteobjekt aufruft, erfolgt dies über einen Proxy. Hierbei handelt es sich um ein lokales Objekt, das dieselbe Reihe von Methoden bereitstellt wie das Zielobjekt.

Angeben von Clientanmeldeinformationen

Wenn das Hosting des Remoteobjekts in ASP.NET erfolgt und es für die Windows-Authentifizierung konfiguriert ist, müssen Sie die zum Authentifizieren verwendeten Anmeldeinformationen mithilfe der Eigenschaft für die Anmeldeinformationen des Kanals angeben. Wenn Sie die Anmeldeinformationen nicht explizit festlegen, wird das Remoteobjekt ohne Anmeldeinformationen aufgerufen. Wenn die Windows-Authentifizierung erforderlich ist, führt dies zu einem HTTP-Status 401, d. h. zu einer Zugriffsverweigerungsmeldung.

Verwenden von "DefaultCredentials"

Wenn Sie die Anmeldeinformationen des Prozesses verwenden möchten, der das Hosting des Remoteobjektproxys durchführt (oder des aktuellen Threadtokens, wenn der Thread, der den Proxy aufruft, einen Identitätswechsel durchführt), sollten Sie die Eigenschaft für die Anmeldeinformationen des Kanals auf den Wert DefaultCredentials festlegen, der vom Anmeldeinformationscache des Prozesses verwaltet wird.

Sie können die Verwendung von DefaultCredentials entweder in einer Konfigurationsdatei oder programmgesteuert festlegen.

Explizite Konfiguration

In der Konfigurationsdatei der Clientanwendung (Web.config, wenn die Clientanwendung eine ASP.NET-Webanwendung ist) legen Sie für das useDefaultCredentials-Attribut des Elements <channel> den Wert true fest, um anzugeben, dass der Proxy DefaultCredentials verwenden soll, wenn er mit dem Remoteobjekt kommuniziert.

  <channel ref="http" useDefaultCredentials="true" />

Programmatische Konfiguration

Zur programmatischen Konfiguration verwenden Sie den folgenden Code, um DefaultCredentials programmatisch einzurichten.

  IDictionary channelProperties;
  channelProperties = ChannelServices.GetChannelSinkProperties(proxy);
  channelProperties ["Anmeldeinformationen"] = CredentialCache.DefaultCredentials;

Verwenden von bestimmten Anmeldeinformationen

Wenn Sie beim Aufrufen eines Remoteobjekts einen bestimmten Satz Anmeldeinformationen für die Authentifizierung verwenden möchten, deaktivieren Sie Standardanmeldeinformationen in der Konfigurationsdatei wie folgt:

  <channel ref="http" useDefaultCredentials="false" />

Hinweis: Die programmatischen Einstellungen setzen immer die Einstellungen in der Konfigurationsdatei außer Kraft.

Verwenden Sie dann den folgenden Code, um den Proxy für die Verwendung bestimmter Anmeldeinformationen zu konfigurieren:

  IDictionary channelProperties =  
                          ChannelServices.GetChannelSinkProperties(proxy);
  NetworkCredential credentials;
  credentials = new NetworkCredential("Benutzername", "Kennwort", "Domäne");
  ObjRef objectReference = RemotingServices.Marshal(proxy);
  Uri objectUri = new Uri(objectReference.URI);
  CredentialCache credCache = new CredentialCache();
  // "authenticationType" ersetzen durch "Aushandeln", "Standard", "Digest", 
  // "Kerberos" oder "NTLM"
  credCache.Add(objectUri, "authenticationType", credentials);
  channelProperties["Anmeldeinformationen"] = credCache;
  channelProperties["Vorauthentifizierung durchführen"] = true;

Immer einen bestimmten Authentifizierungstyp anfordern

Sie sollten immer einen bestimmten Authentifizierungstyp unter Verwendung der Methode CredentialCache.Add anfordern, wie oben dargestellt. Vermeiden Sie die direkte Verwendung der Klasse NetworkCredential, wie im nachfolgenden Code veranschaulicht wird.

  IDictionary providerData = ChannelServices.GetChannelSinkProperties(yourProxy);
  providerData["Anmeldeinformationen"] = new NetworkCredential(uid, pwd);

Dies sollte im Produktionscode vermieden werden, da Sie keine Kontrolle über den vom Remoteobjekthost verwendeten Authentifizierungsmechanismus haben. Somit haben Sie auch keine Kontrolle über die verwendeten Anmeldeinformationen.

Es könnte beispielsweise vorkommen, dass Sie eine Kerberos- oder NTLM-Authentifizierungsanforderung vom Server erwarten, jedoch stattdessen eine Standardanforderung erhalten. In diesem Fall werden der bereitgestellte Benutzername und das Kennwort unverschlüsselt im Klartext an den Server gesendet.

Festlegen der Eigenschaft "Vorauthentifizierung durchführen"

Die Eigenschaft Vorauthentifizierung durchführen des Proxys kann auf den Wert "true" (Wahr) oder "false" (Falsch) eingestellt werden. Legen Sie den Wert auf "true" fest (wie im o. a. Code dargestellt), um bestimmte Authentifizierungsanmeldeinformationen bereitzustellen. Diese führen dazu, dass mit der ersten Anforderung der HTTP-Header WWW-Authenticate übergeben wird. Dadurch muss der Webserver weder den Zugriff für die erste Anforderung ablehnen noch die Authentifizierung für die nachfolgende Anforderung durchführen.

Verwenden der Eigenschaft "connectiongroupname"

Wenn Sie über eine ASP.NET-Webanwendung verfügen, die eine Verbindung zu einer Remotekomponente (Hosting durch ASP.NET) herstellt und den Sicherheitskontext des ursprünglichen Benutzers übermittelt (durch Verwendung von DefaultCredentials und des Identitätswechsels oder durch Festlegen von expliziten Anmeldeinformationen, wie oben gezeigt), sollten Sie die Eigenschaft connectiongroupname des Kanals innerhalb der Webanwendung festlegen. Dadurch wird verhindert, dass ein neuer, nicht authentifizierter Client eine bestehende, authentifizierte TCP-Verbindung zur Remotekomponente wiederverwenden kann, die den Authentifizierungsanmeldeinformationen eines vorherigen Clients zugeordnet ist. Die Wiederverwendung von Verbindungen kann als Ergebnis von HTTP KeepAlives und der Authentifizierungspersistenz auftreten, die in IIS aus Leistungsgründen aktiviert ist.

Legen Sie für die Eigenschaft connectiongroupname einen Bezeichner fest (z. B. den Benutzernamen des Benutzers), der einen Benutzer vom nächsten unterscheidet.

  channelProperties["connectiongroupname"] = userName;

Hinweis: Wenn der Sicherheitskontext des ursprünglichen Benutzers nicht über die Webanwendung an die Remotekomponente übermittelt wird, sondern die Verbindung zur Remotekomponente mithilfe einer festen Identität (z. B. der ASP.NET-Prozessidentität der Webanwendung) herstellt, müssen Sie die Eigenschaft connectiongroupname nicht festlegen. In diesem Szenario bleibt der Sicherheitskontext der Verbindung beim Wechsel von einem Benutzer zum nächsten konstant.

Die nächste Version von .NET Framework unterstützt das Verbindungspooling auf Basis der SID des Threads, der das Proxyobjekt aufruft. Dadurch wird das oben beschriebene Problem behandelt, wenn die Webanwendung für den Benutzer einen Identitätswechsel durchführt. Das Pooling wird für .NET Remoting-Clients unterstützt, jedoch nicht für Webdienstclients.

Übermitteln des ursprünglichen Benutzers

In diesem Abschnitt wird beschrieben, wie Sie den Sicherheitskontext des ursprünglichen Benutzers über eine ASP.NET-Webanwendung an eine Remotekomponente übermitteln können, deren Hosting von ASP.NET auf einem Remoteanwendungsserver durchgeführt wird. Sie müssen dies möglicherweise durchführen, um die Einzelbenutzerautorisierung innerhalb des Remoteobjekts oder innerhalb von Downstream-Subsystemen (z. B. Datenbanken) zu unterstützen.

In Abbildung 11.4 wird der Sicherheitskontext des ursprünglichen Benutzers (Bob) über den Front-End-Webserver, der als Host für eine ASP.NET-Webanwendung fungiert, an das Remoteobjekt, dessen Hosting ASP.NET auf einem Remoteanwendungsserver durchführt, und abschließend an einen Back-End-Datenbankserver übermittelt.

Abbildung 11.4
Übermitteln des Sicherheitskontexts des ursprünglichen Benutzers

Damit die Anmeldeinformationen an ein Remoteobjekt übermittelt werden, muss der Remoteobjektclient (in diesem Szenario die ASP.NET-Webanwendung) den Proxy des Objekts konfigurieren und die Eigenschaft Anmeldeinformationen des Proxys explizit festlegen, wie unter "Übergeben von Anmeldeinformationen an Remoteobjekte zur Authentifizierung" weiter oben in diesem Modul beschrieben.

Hinweis: IPrincipal-Objekte werden nicht über .NET Remoting-Grenzen hinweg übermittelt.

Der Kontext des Benutzers kann auf zweierlei Arten übermittelt werden:

• Übergeben von Standardanmeldeinformationen und Verwenden der Kerberos-Authentifizierung (und -Delegierung). Dieser Ansatz erfordert, dass Sie innerhalb der ASP.NET-Webanwendung einen Identitätswechsel durchführen und den Remoteobjektproxy mitDefaultCredentials konfigurieren, das vom Sicherheitskontext des Benutzers nach dem Identitätswechsel abgerufen wird.

• Übergeben expliziter Anmeldeinformationen und Verwenden der Standard- oder Formularauthentifizierung. Dieser Ansatz erfordert keinen Identitätswechsel innerhalb der ASP.NET-Webanwendung. Stattdessen konfigurieren Sie den Remoteobjektproxy programmatisch mit expliziten Anmeldeinformationen, die entweder von Servervariablen (über die Standardauthentifizierung) oder von HTML-Formularfeldern (über die Formularauthentifizierung) abgerufen werden, die für die Webanwendung zur Verfügung stehen. Bei der Standard- oder Formularauthentifizierung stehen Benutzername und Kennwort für den Server im Klartext zur Verfügung.

Standardanmeldeinformationen mit Kerberos-Delegierung

Um die Kerberos-Delegierung verwenden zu können, muss auf allen Computern (Servern und Clients) Windows 2000 oder höher installiert sein. Zusätzlich müssen Clientkonten, die delegiert werden sollen, im Verzeichnisdienst Active Directory® gespeichert werden. Sie dürfen nicht als Konto ist vertraulich und kann nicht delegiert werden gekennzeichnet werden.

In den nachfolgenden Tabellen werden die Konfigurationsschritte aufgeführt, die auf dem Webserver und dem Anwendungsserver erforderlich sind.

Konfigurieren des Webservers

  
<authentication mode="Windows" />

 
<identity impersonate="true" />

<channel ref="http"  
	useDefaultCredentials="true" />
 

Konfigurieren des Remoteanwendungsservers

  <authentication mode="Windows" />

  <identity impersonate="true" />

Weitere Informationen

Weitere Informationen zur Kerberos-Delegierung finden Sie unter "Vorgehensweise: Implementieren der Kerberos-Delegierung unter Windows 2000" in diesem Handbuch.

Explizite Anmeldeinformationen bei der Standard- oder Formularauthentifizierung

Sie können als Alternative zur Kerberos-Delegierung die Standard- oder die Formularauthentifizierung für die Webanwendung verwenden, um die Anmeldeinformationen des Clients zu erfassen, und dann die Standardauthentifizierung (oder integrierte Windows-Authentifizierung) für das Remoteobjekt einsetzen.

Bei diesem Ansatz stehen die Klartext-Anmeldeinformationen des Clients für die Webanwendung zur Verfügung. Diese können über den Remoteobjektproxy an ein Remoteobjekt übergeben werden. Dazu müssen Sie Code in die Webanwendung einbeziehen, um die Anmeldeinformationen des Clients abzurufen und den Remoteobjektproxy zu konfigurieren.

Standardauthentifizierung

Bei der Standardauthentifizierung stehen die Anmeldeinformationen des ursprünglichen Benutzers für die Webanwendung in Servervariablen zur Verfügung. Aus dem nachfolgenden Code geht hervor, wie diese abgerufen werden und wie das Konfigurieren des Remoteobjektproxys erfolgt.

  // Clientanmeldeinformationen abrufen (verfügbar bei Standardauthentifizierung)
  string pwd = Request.ServerVariables["AUTH_PASSWORD"];
  string uid = Request.ServerVariables["AUTH_USER"];
  // Anmeldeinformationen dem Remoteobjektproxy zuordnen
  IDictionary channelProperties =  
                          ChannelServices.GetChannelSinkProperties(proxy);
  NetworkCredential credentials;
  credentials = new NetworkCredential(uid, pwd);
  ObjRef objectReference = RemotingServices.Marshal(proxy);
  Uri objectUri = new Uri(objectReference.URI);
  CredentialCache credCache = new CredentialCache();
  credCache.Add(objectUri, "Standard", credentials);
  channelProperties["Anmeldeinformationen"] = credCache;
  channelProperties["Vorauthentifizierung durchführen"] = true;

Hinweis: Der im oben angegebenen Code gezeigte NetworkCredential-Konstruktor wird mit der Benutzer-ID und dem Kennwort bereitgestellt. Es kann eine Standarddomäne auf dem Webserver in IIS beim Konfigurieren der Standardauthentifizierung konfiguriert werden, um die Hartcodierung des Domänennamens zu vermeiden.

Formularauthentifizierung

Bei der Formularauthentifizierung stehen die Anmeldeinformationen des ursprünglichen Benutzers für die Webanwendung in Formularfeldern (anstatt in Servervariablen) zur Verfügung. In diesem Fall verwenden Sie den folgenden Code:

  // Clientanmeldeinformationen aus Anmeldeformular abrufen
  string pwd = txtPassword.Text;
  string uid = txtUid.Text;
  // Anmeldeinformationen dem Remoteobjektproxy zuordnen
  IDictionary channelProperties =  
                          ChannelServices.GetChannelSinkProperties(proxy);
  NetworkCredential credentials;
  credentials = new NetworkCredential(uid, pwd);
  ObjRef objectReference = RemotingServices.Marshal(proxy);
  Uri objectUri = new Uri(objectReference.URI);
  CredentialCache credCache = new CredentialCache();
  credCache.Add(objectUri, "Standard", credentials);
  channelProperties["Anmeldeinformationen"] = credCache;
  channelProperties["Vorauthentifizierung durchführen"] = true;

In den nachfolgenden Tabellen werden die Konfigurationsschritte aufgeführt, die auf dem Webserver und dem Anwendungsserver erforderlich sind.

Konfigurieren des Webservers

  <authentication mode="Windows" />

  <authentication mode="Formulare" />

  <authentication mode="Formulare" />

  <identity impersonate="false" />

Konfigurieren des Anwendungsservers

  <authentication mode="Windows" />

  <identity impersonate="true" />

Vertrauenswürdiges Subsystem

Das Modell der vertrauenswürdigen Subsysteme bietet einen alternativen (und einfach zu implementierenden) Ansatz zum Übermitteln des Sicherheitskontexts des ursprünglichen Benutzers. In diesem Modell besteht zwischen dem Remoteobjekthost und der Webanwendung eine Vertrauensgrenze. Das Remoteobjekt vertraut der Webanwendung hinsichtlich der ordnungsgemäßen Authentifizierung und Autorisierung von Benutzern vor der Weiterleitung von Anforderungen an das Remoteobjekt. Im Remoteobjekthost wird keine Authentifizierung des ursprünglichen Benutzers durchgeführt. Der Remoteobjekthost authentifiziert die feste vertrauenswürdige Identität, die von der Webanwendung zum Kommunizieren mit dem Remoteobjekt verwendet wird. In den meisten Fällen ist dies die Prozessidentität der ASP.NET-Webanwendung.

Das Modell der vertrauenswürdigen Subsysteme wird in Abbildung 11.5 dargestellt. Aus diesem Diagramm gehen außerdem zwei der möglichen Konfigurationen hervor. Bei der ersten Möglichkeit werden der ASP.NET-Host und der HTTP-Kanal verwendet, bei der zweiten ein Windows-Diensthost und der TCP-Kanal.

Abbildung 11.5
Modell der vertrauenswürdigen Subsysteme

Übermitteln der Identität des Benutzers

Wenn Sie mit dem Modell der vertrauenswürdigen Subsysteme arbeiten, ist die Übertragung der Identität des ursprünglichen Benutzers (der Name, nicht der Sicherheitskontext) möglicherweise dennoch erforderlich, beispielsweise für Überwachungszwecke in der Datenbank.

Sie können die Identität auf Anwendungsebene übermitteln, indem Sie die Parameter von Methoden und gespeicherten Prozeduren verwenden, während Parameter von vertrauten Abfragen (wie im folgenden Beispiel gezeigt) zum Abrufen benutzerspezifischer Daten aus der Datenbank genutzt werden können.

  SELECT x,y,z FROM SomeTable WHERE UserName = "Bob"

Auswählen eines Hosts

Beim Modell der vertrauenswürdigen Subsysteme führt der Remoteobjekthost keine Authentifizierung der ursprünglichen Benutzer durch. Die Authentifizierung (und Autorisierung) seines unmittelbaren Clients (in diesem Szenario die ASP.NET-Webanwendung) ist jedoch weiterhin erforderlich, um zu verhindern, dass nicht autorisierte Anwendungen Anforderungen an das Remoteobjekt senden.

Wenn das Hosting in ASP.NET erfolgt und Sie den HTTP-Kanal einsetzen, können Sie die integrierte Windows-Authentifizierung verwenden, um die Prozessidentität der ASP.NET-Webanwendung zu authentifizieren.

Wenn das Hosting in einem Windows-Dienst erfolgt, können Sie den TCP-Kanal verwenden, der zwar hervorragende Leistung, aber keine Authentifizierungsmöglichkeiten bietet. In diesem Szenario können Sie zwischen dem Webserver und dem Anwendungsserver IPSec verwenden. Es kann eine IPSec-Richtlinie eingerichtet werden, die es nur dem Webserver ermöglicht, mit dem Anwendungsserver zu kommunizieren.

Konfigurationsschritte

In den nachfolgenden Tabellen werden die Konfigurationsschritte aufgeführt, die auf dem Webserver und dem Anwendungsserver erforderlich sind.

Konfigurieren des Webservers

  <authentication mode="Windows|Formulare|Passport" />

  <channel ref="http"  
    useDefaultCredentials="true" />

Konfigurieren des Anwendungsservers

<authentication mode="Windows" />

<identity impersonate="false" />

Verwenden eines Windows-Diensthosts

Wenn Sie einen Windows-Diensthostprozess verwenden, müssen Sie ein Windows-Konto zum Ausführen des Dienstes erstellen. Dieser Sicherheitskontext, der von diesem Konto bereitgestellt wird, wird vom Remoteobjekt für alle lokalen Ressourcenzugriffe und alle Remoteressourcenzugriffe eingesetzt.

Für den Zugriff auf eine Microsoft SQL Server™-Remotedatenbank (mit der Windows-Authentifizierung) können Sie ein Domänenkonto oder ein lokales Konto mit minimalen Rechten verwenden und dann ein dupliziertes Konto (mit demselben Benutzernamen und demselben Kennwort) auf dem Datenbankserver erstellen.

Sichere Kommunikation

Die sichere Kommunikation befasst sich mit der garantierten Integrität und Vertraulichkeit von Nachrichten, während diese über das Netzwerk übermittelt werden. Sie können einen plattformbasierten Ansatz verwenden, um die Kommunikation via SSL oder IPSec zu sichern, oder Sie verwenden einen Ansatz auf Nachrichtenebene und entwickeln eine benutzerdefinierte Verschlüsselungsdatensenke, um die gesamte Nachricht oder ausgewählte Teile einer Nachricht zu verschlüsseln.

Plattformebenenoptionen

Die beiden Optionen der Plattformebene, die zum Sichern der zwischen einem Client und einer Remotekomponente zu übertragenden Daten in Betracht gezogen werden, sind Folgende:

• SSL
• IPSec

Wenn Sie das Hosting von Remoteobjekten in ASP.NET durchführen, können Sie SSL zum Sichern des Kommunikationskanals zwischen Client und Server verwenden. Hierfür ist auf dem Computer, der das Hosting des Remoteobjekts durchführt, ein Serverauthentifizierungszertifikat erforderlich.

Wenn Sie das Hosting von Remoteobjekten in einem Windows-Dienst durchführen, können Sie IPSec zwischen den Client- und Hostcomputern (Server) verwenden oder eine benutzerdefinierte Verschlüsselungsdatensenke entwickeln.

Nachrichtenebenenoptionen

Da die .NET Remoting-Architektur erweitert werden kann, können Sie eigene benutzerdefinierte Datensenken entwickeln und sie in die Verarbeitungspipeline integrieren. Sie können eine benutzerdefinierte Datensenke entwickeln, die die Nachrichtendaten verschlüsselt und entschlüsselt, die vom oder an das Remoteobjekt gesendet werden, um die sichere Kommunikation bereitzustellen.

Der Vorteil dieses Ansatzes ist: Sie können damit ausgewählte Teile einer Nachricht verschlüsseln. Dies steht im Gegensatz zu den Ansätzen auf Plattformebene, die alle Daten verschlüsseln, die zwischen Client und Server gesendet werden.

Weitere Informationen

Weitere Informationen zu SSL und IPSec finden Sie in Modul 4, "Sichere Kommunikation".

Auswählen eines Hostprozesses

Objekte, auf die der Remotezugriff erfolgen soll, müssen in einer ausführbaren Hostdatei gestartet werden. Der Host achtet auf eingehende Anforderungen und sendet Aufrufe an Objekte. Der ausgewählte Hosttyp wirkt sich auf den Nachrichtentransportmechanismus aus, der als Kanal bezeichnet wird. Der von Ihnen ausgewählte Kanal wirkt sich auf die Authentifizierung, die Autorisierung, die sichere Kommunikation sowie auf die Leistungsmerkmale Ihrer Lösung aus.

Der HTTP-Kanal bietet bessere Sicherheitsoptionen, während der TCP-Kanal die bessere Leistung aufweist.

Ihnen stehen die folgenden Hauptoptionen für das Hosting von Remoteobjekten zur Verfügung:

• Hosting in ASP.NET
• Hosting in einem Windows-Dienst
• Hosting in einer Konsolenanwendung

Empfehlung

Damit Sie den Vorteil der von ASP.NET und IIS bereitgestellten Sicherheitsinfrastruktur nutzen können, wird empfohlen, das Hosting für Remoteobjekte in ASP.NET durchzuführen. Dies erfordert, dass die Clients mit den Remoteobjekten über den HTTP-Kanal kommunizieren. ASP.NET- und IIS-Funktionen für die Authentifizierung, Autorisierung und die sichere Kommunikation stehen für Remoteobjekte zur Verfügung, deren Hosting in ASP.NET erfolgt.

Erwägen Sie das Hosting von Remoteobjekten in Windows-Diensten, wenn die Leistung Ihr Hauptanliegen ist (und nicht die Sicherheit).

Hosting in ASP.NET

Folgendes trifft zu, wenn Sie das Hosting eines Remoteobjekts in ASP.NET durchführen:

• Auf das Objekt wird über das HTTP-Protokoll zugegriffen.
• Das Objekt besitzt einen Endpunkt, der über einen URL zur Verfügung steht.
• Es ist in einer Anwendungsdomäne innerhalb des Workerprozesses Aspnet_wp.exe vorhanden.
• Es erbt die von IIS und ASP.NET zur Verfügung gestellten Sicherheitsfunktionen.

Vorteile

Wenn Sie das Hosting von Remoteobjekten in IIS durchführen, bieten sich Ihnen folgende Vorteile:

• Von IIS und ASP.NET bereitgestellte Funktionen für die Authentifizierung, Autorisierung und sichere Kommunikation stehen unmittelbar zur Verfügung.
• Sie können die Überwachungsfunktionen von IIS verwenden.
• Sie besitzen umfangreiche Steuerungsmöglichkeiten für die ausführbare Hostdatei über das Element <processModel> in Machine.config. Sie können die Threadverwaltung, die Fehlertoleranz, die Speicherverwaltung usw. steuern.
• Sie können vor dem Remoteobjekt eine Nachbildungsebene für einen Webdienst erstellen.

Nachteile

Wenn Sie ASP.NET für das Hosting von Remoteobjekten verwenden, sollten Sie sich der folgenden Nachteile bewusst sein:

• Es erfordert die Verwendung des HTTP-Kanals, der langsamer als der TCP-Kanal ist.
• Benutzerprofile werden von ASP.NET nicht geladen. Verschiedene Verschlüsselungsverfahren (einschließlich DPAPI) erfordern möglicherweise Benutzerprofile.
• Wenn Code auf das Objekt zugreift, der in einer ASP.NET-Webanwendung ausgeführt wird, müssen Sie möglicherweise die Standardauthentifizierung verwenden.

Hosting in einem Windows-Dienst

Wenn Sie das Hosting eines Remoteobjekts in einem Windows-Dienst durchführen, befindet sich das Remoteobjekt in einer Anwendungsdomäne, die im Dienstprozess enthalten ist. Die Verwendung des HTTP-Kanals ist nicht möglich. Stattdessen müssen Sie den TCP-Kanal verwenden. Der TCP-Kanal unterstützt die folgenden Sicherheitsfunktionen:

• Authentifizierungsfunktionen
  Sie müssen eine benutzerdefinierte Authentifizierungslösung bereitstellen. Die Optionen umfassen Folgendes:

  • Verwenden der zugrunde liegenden Authentifizierungsdienste der SSPI. Sie können eine Kanaldatensenke erstellen, die die Anmeldeinformationen des Windows Security Service Provider Interface (SSPI) und der Kontextverwaltungs-Application Programming Interfaces (API oder Anwendungsprogrammierschnittstelle) verwendet, um den Benutzer zu authentifizieren und optional einen Identitätswechsel für ihn durchzuführen. Die Kanaldatensenke ist oberhalb des TCP-Kanals angesiedelt. In Verbindung mit dem TCP-Kanal ermöglicht es die SSPI dem Client und dem Server, Authentifizierungsinformationen auszutauschen. Nach der Authentifizierung können der Client und der Server Nachrichten senden, die die Integrität und Vertraulichkeit sicherstellen.

  • Verwenden eines zugrunde liegenden Transports, der die Authentifizierung unterstützt, z. B. Named Pipes. Der Named Pipe-Kanal verwendet Named Pipes als Transportmechanismus. Dadurch wird die Authentifizierung für den Benutzer bereitgestellt, und es werden die Sicherheit auf Basis der Access Control Lists (ACLs oder Zugriffssteuerungslisten) von Windows für die Pipe eingeführt und der Identitätswechsel für den Benutzer durchgeführt.

• Autorisierungsfunktionen Die Autorisierung ist nur möglich, wenn Sie eine benutzerdefinierte Authentifizierungslösung implementieren.

  • Wenn Sie in der Lage sind, den Identitätswechsel für den Benutzer durchzuführen (z. B. durch Verwenden eines zugrunde liegenden Named Pipe-Transports), können Sie WindowsPrincipal.IsInRole verwenden.

  • Wenn Sie ein IPrincipal-Objekt erstellen können, um den authentifizierten Client darzustellen, können Sie .NET-Rollen verwenden (über Hauptberechtigungen und explizite Rollenüberprüfungen mithilfe von IPrincipal.IsInRole).

• Funktionen für sichere Kommunikation

  Zwei Optionen stehen zur Wahl:

  • Verwenden Sie IPSec, um den Transport von Daten zwischen dem Client und dem Server zu sichern.

  • Erstellen Sie eine benutzerdefinierte Kanaldatensenke, die die asymmetrische Verschlüsselung durchführt. Diese Option wird weiter unten in diesem Modul erläutert.

Vorteile

Windows-Dienste als Host für Remoteobjekte zu verwenden hat folgende Vorteile:

• Ein hoher Grad an Steuerungsmöglichkeiten für die Aktivierung des Hostprozesses

• Die Vorteile der Windows-Dienstarchitektur werden geerbt

• Kein Bedarf, IIS auf der mittleren Ebene Ihrer Anwendung einzuführen

• Benutzerprofile werden automatisch geladen

• Die Leistung ist gut, da die Clients mithilfe binär verschlüsselter Daten über den TCP-Kanal kommunizieren

Nachteile

Wenn Sie einen Windows-Dienst als Host für Remoteobjekte verwenden, sollten Sie sich der folgenden Nachteile bewusst sein:

• Sie müssen benutzerdefinierte Authentifizierungs- und Autorisierungslösungen bereitstellen.

• Sie müssen sichere Kommunikationslösungen bereitstellen.

• Sie müssen Überwachungslösungen bereitstellen.

Hosting in einer Konsolenanwendung

Wenn Sie das Hosting eines Remoteobjekts in einer Konsolenanwendung durchführen, befindet sich das Remoteobjekt in einer Anwendungsdomäne, die im Konsolenanwendungsprozess enthalten ist. Die Verwendung des HTTP-Kanals ist nicht möglich. Stattdessen müssen Sie den TCP-Kanal verwenden.

Dieser Ansatz wird für Produktionslösungen nicht empfohlen.

Vorteile

Dieser Ansatz hat wenig Vorteile, obwohl er bedeutet, dass IIS auf der mittleren Ebene nicht erforderlich ist. Dieser Ansatz wird jedoch nur für die Entwicklung und zum Testen empfohlen und nicht für Produktionsumgebungen.

Nachteile

• Wenn Sie eine benutzerdefinierte ausführbare Datei für das Hosting von Remoteobjekten verwenden, sollten Sie sich der folgenden Nachteile bewusst sein:

• Der Host muss manuell gestartet und unter der interaktiven Anmeldesitzung ausgeführt werden (nicht empfehlenswert).

• Es ist keine Fehlertoleranz vorhanden.

• Sie müssen die benutzerdefinierte Authentifizierung und Autorisierung bereitstellen.

• Es sind keine Überwachungsfunktionen vorhanden.

Remoting im Vergleich zu Webdiensten

.NET bietet Clients viele unterschiedliche Techniken zur Kommunikation mit Remoteobjekten, einschließlich der Verwendung von Webdiensten.

Wenn die Interoperabilität zwischen heterogenen Systemen erforderlich ist, stellt ein Ansatz mit Webdiensten, der offene Standards wie SOAP, XML und HTTP verwendet, die richtige Wahl dar. Auf der anderen Seite bietet das Remoting die folgenden Funktionen, wenn Sie intranetbasierte Lösungen erstellen, die zwischen Servern verwendet werden:

• Hohe Objekttreue, da Remoting für jeden .NET-Typ (einschließlich benutzerdefinierter Typen, die mit den Entwicklungsprogrammen Microsoft C#® und Microsoft Visual Basic® .NET erstellt wurden) durchgeführt werden kann.
  Dies umfasst Klassen, Klassenhierarchien, Schnittstellen, Felder, Eigenschaften, Methoden, Delegate, Datasets, Hashtabellen usw.

• Objekte können nach Wert oder nach Referenz gemarshallt werden.

• Die Verwaltung der Objektlebensdauer basiert auf einer Lease.

• Hohe Leistung, insbesondere mit dem TCP-Kanal und der binären Formatierung.

• Es ermöglicht es Ihnen, mittlere Ebenen mit Lastenausgleich zu erstellen, wobei Sie den Netzwerklastenausgleich verwenden.

Tabelle 11.2: Die Hauptunterschiede zwischen Remoting und Webdiensten

Zusammenfassung

NET Remoting bietet kein eigenes Sicherheitsmodell. Durch das Hosting von Remoteobjekten in ASP.NET und durch Verwenden des HTTP-Kanals für die Kommunikation können Remoteobjekte von den Sicherheitsdiensten profitieren, die IIS und ASP.NET bereitstellen. Im Vergleich dazu bieten der TCP-Kanal und eine benutzerdefinierte, ausführbare Hostdatei höhere Leistung, jedoch keine integrierte Sicherheit.

• Wenn Sie den Client authentifizieren möchten, verwenden Sie den HTTP-Kanal, führen das Hosting in ASP.NET durch und deaktivieren den anonymen Zugriff in IIS.

• Verwenden Sie den TCP-Kanal für bessere Leistung, wenn die Authentifizierung des Clients für Sie nicht von Bedeutung ist.

• Verwenden Sie IPSec, um den Kommunikationskanal zwischen Client und Server zu sichern, wenn Sie den TCP-Kanal nutzen. Verwenden Sie SSL, um den HTTP-Kanal zu sichern.

• Wenn Sie vertrauenswürdige Aufrufe für Remoteressourcen durchführen müssen, führen Sie das Hosting der Komponente im Windows-Dienst und nicht in einer Konsolenanwendung durch.

• IPrincipal-Objekte werden nicht über .NET Remoting-Grenzen hinweg übermittelt. Sie sollten die Implementierung einer eigenen IPrincipal-Klasse erwägen, die serialisiert werden kann. Wenn Sie sich für diesen Schritt entscheiden, beachten Sie, dass es für einen unberechtigten Client relativ einfach ist, einen Spoofing-Vorgang des IPrincipal-Objekts durchzuführen und es an Ihr Remoteobjekt zu senden. Achten Sie auch auf IlogicalThreadAffinitive , wenn Sie eine eigene IPrincipal-Klasse für das Remoting implementieren.

• Stellen Sie Remoteobjekte niemals im Internet bereit. Verwenden Sie für dieses Szenario Webdienste.
  .NET Remoting sollte nur im Intranet verwendet werden. Der Zugriff auf Objekte sollte nur intern über Webanwendungen erfolgen. Auch wenn für Objekte das Hosting in ASP.NET erfolgt, sollten Sie diese nicht für Internetclients offen legen, da es sich bei den Clients um .NET-Clients handeln müsste.