Festlegen von rollenbasierten Sicherheitsrichtlinien und Principals
Aktualisiert: November 2007
Mit rollenbasierter Sicherheit können aktuelle Benutzer und deren zugehörige Rollen während der Laufzeit von einer Komponente identifiziert werden. Diese Informationen werden anschließend mithilfe einer Richtlinie für Codezugriffssicherheit zugeordnet, um die zur Laufzeit gewährte Berechtigungsmenge festzulegen. Für eine angegebene Anwendungsdomäne kann der Host die standardmäßig rollenbasierte Sicherheitsrichtlinie ändern und ein Standardsicherheitsprincipal festlegen. Ein Sicherheitsprincipal repräsentiert einen Benutzer und dessen zugehörige Rollen.
Rollenbasierte Sicherheit wird in der Regel verwendet, um benutzerdefinierte Authentifizierungsschemas zu implementieren. Beispielsweise verwendet der ASP.NET-Host rollenbasierte Sicherheit, um ein auf Benutzerdaten basierendes Authentifizierungsschema zu implementieren. Die entsprechenden Daten bezieht der Host über die Internetinformationsdienste (IIS).
Die Definition sowohl des Benutzers als auch der Benutzerrolle ist anwendungsspezifisch. Das Benutzerkonzept einer Anwendung kann sich von dem für Windows unterscheiden. Beispielsweise kann der Benutzer bei der Anmeldung an eine Anwendung aufgefordert werden, ein Kennwort anzugeben. Dieses Benutzername/Kennwort-Paar ist unabhängig von dem bei der Windows-Anmeldung erforderlichen.
Explizites Festlegen des Principals für einen Thread
Wenn das Principal für einen Thread festgelegt wurde, werden die Richtlinie der Anwendungsdomäne und das Standardprincipal ignoriert. Zum Beispiel könnte der Thread sein eigenes Principal mithilfe der statischen CurrentPrincipal-Eigenschaft (Shared-Eigenschaft in Visual Basic) der Thread-Klasse festgelegt haben. Es ist auch möglich, dass der Thread sein Principal vom Thread erhalten hat, der es gestartet hat.
.gif "Hinweis") Hinweis: |
|---|
Wenn in .NET Framework, Version 2.0, ein Thread einen anderen Thread startet oder eine Arbeitsaufgabe zur Ausführung durch den Threadpool in die Warteschlange stellt, geht der Threadkontext (einschließlich Sicherheitsprincipal) automatisch an den untergeordneten Thread oder den Threadpool-Thread über. In .NET Framework, Versionen 1.0 und 1.1, ging der Kontext nur an Threads über, die von einem Thread gestartet wurden, nicht an Threadpool-Threads. |
Wenn ein Thread ohne Sicherheitsprincipal eine Aktion durchführt, die ein Principal erfordert, wird ein Principal auf Basis der aktuellen Sicherheitsrichtlinie der Anwendungsdomäne und des Standardsicherheitsprincipals bereitgestellt.
| Hinweis: |
|---|
Wenn ein Thread ohne Sicherheitsprincipal mithilfe der statischen CurrentPrincipal-Eigenschaft sein Principal abfragt, werden die Standardeinstellungen der Anwendungsdomäne verwendet, um das Principal festzulegen. Das bedeutet, dass CurrentPrincipal nie null zurückgibt. |
Richtlinie und Standardprincipal für eine Anwendungsdomäne
Ein Host kann durch Aufruf der SetThreadPrincipal-Methode ein Standardprincipal für eine Anwendungsdomäne festlegen. Wenn ein Standardprincipal bereitgestellt wurde, wird es jedem Thread zugewiesen, der in der Anwendungsdomäne ausgeführt wird, ein Principal benötigt und noch über kein Principal verfügt.
| Hinweis: |
|---|
Das Standardprincipal wird nicht automatisch auf den Thread angewendet, der SetThreadPrincipal aufruft, selbst wenn dieser Thread über kein Principal verfügt. Wenn der Thread später ein Principal benötigt und in der Zwischenzeit noch keines erhalten hat, wird ihm ein Principal entsprechend dem Standardprincipal und der Standardrichtlinie der Anwendungsdomäne, in der er zu dieser Zeit ausgeführt wird, zugewiesen. |
Wenn für die Anwendungsdomäne kein Standardprincipal festgelegt wurde, wird dem Thread ein Principal entsprechend der Richtlinie für die Anwendungsdomäne zugewiesen. Standardmäßig soll die Richtlinie einer Anwendungsdomäne dem Thread ein nicht authentifiziertes generisches Principal zuweisen. Ein Host kann diese Richtlinie für eine Anwendungsdomäne durch Aufruf der SetPrincipalPolicy-Methode ändern. Zum Beispiel erstellt der folgende verwaltete Code eine Anwendungsdomäne und legt deren Richtlinie so fest, dass das aktuelle Windows-Principal verwendet wird.
Dim ad As AppDomain = AppDomain.CreateDomain("Child")
ad.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal)
AppDomain ad = AppDomain.CreateDomain("Child");
ad.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
AppDomain^ ad = AppDomain::CreateDomain("Child");
ad->SetPrincipalPolicy(PrincipalPolicy::WindowsPrincipal);
Ein nicht verwalteter Host kann mithilfe der _AppDomain-Schnittstelle, die die Vtable-Reihenfolge in .NET Framework versionsübergreifend beibehält, auf Anwendungsdomänen zugreifen.