Autorisierung in Ansprüche unterstützenden Webanwendungen und -diensten
Aktualisiert: 19. Juni 2015
Gilt für: Azure
Gilt für
Zugriffssteuerung für Microsoft Azure Active Directory (auch Zugriffssteuerungsdienst oder ACS)
Windows® Identity Foundation (WIF)
ASP.NET
Windows Communication Foundation (WCF)
Zusammenfassung
In einer Anwendung der vertrauenden Seite bestimmt die Autorisierung, auf welche Ressourcen eine authentifizierte Identität zugreifen und welche Vorgänge sie mit diesen Ressourcen ausführen darf. Eine falsche oder schwache Autorisierung führt zu Offenlegung von Informationen und Datenmanipulation. In diesem Thema werden die verfügbaren Ansätze zum Implementieren der Autorisierung für anspruchsfähige ASP.NET Webanwendungen und Dienste mit ACS und WIF beschrieben.
Ziele
Aufführen der Autorisierungsmethoden, die Ansprüche verwenden.
Umreißen des Entwurfs für jede Vorgehensweise in der Übersicht.
Nennen der Vor- und Nachteile jeder Vorgehensweise.
Übersicht
Seit der ersten Version bietet .NET Framework einen flexiblen Mechanismus zum Implementieren der Autorisierung. Dieser Mechanismus basiert auf zwei einfachen Schnittstellen: IPrincipal und IIentity. Konkrete Implementierungen von IIentity stellen einen authentifizierten Benutzer dar. Die WindowsIdentity-Implementierung stellt beispielsweise einen Benutzer dar, der von Active Directory authentifiziert wird, und GenericIdentity stellt einen Benutzer dar, der von einer benutzerdefinierten Authentifizierung authentifiziert wird. Konkrete Implementierungen von IPrincipal überprüfen die Berechtigungen mithilfe von Rollen abhängig vom Rollenspeicher. Beispielsweise überprüft WindowsPrincipalWindowsIdentity auf die Mitgliedschaft in den Active Directory-Gruppen. Diese Überprüfung erfolgt durch Aufrufen der Methode IsInRole für die Schnittstelle IPrincipal. Die Überprüfung des Zugriffs anhand von Rollen wird als rollenbasierte Zugriffssteuerung (RBAC) bezeichnet. RBAC wird im Abschnitt "Rollenbasierte Zugriffssteuerung" in diesem Thema erläutert. Ansprüche können verwendet werden, um Informationen über Rollen weiterzugeben und so die vertrauenswürdigen, rollenbasierten Autorisierungsmechanismen zu unterstützen.
Ansprüche können außerdem verwendet werden, um vielfältigere Autorisierungsentscheidungen zu ermöglichen, die über Rollen hinausgehen. Ansprüche können auf praktisch beliebigen Angaben basieren - Alter, Postleitzahl, Schuhgröße usw. Die Überprüfung des Zugriffs basierend auf beliebigen Ansprüchen wird als CBAC (Claims-Based Access Control, anspruchsbasierte Zugriffssteuerung) bezeichnet. CBAC wird im Abschnitt "Anspruchsbasierte Zugriffssteuerung" in diesem Thema erläutert.
Autorisierungsprüfungen werden auf der Anwendungsseite ausgeführt, nicht auf der ACS-Seite. ACS dient als Sicherheitstokendienst (STS), der Token ausgibt, die die Ansprüche an die Anwendung tragen. Die Token werden mit Ansprüchen von Identitätsanbietern und optional von ACS selbst mit seinem Regelmodul erweitert. Wenn die Anwendung das Token mit Ansprüchen empfängt, kann sie das Token analysieren, die relevanten Ansprüche extrahieren und dann Autorisierungsentscheidungen mithilfe von RBAC oder eines anspruchsbasierten Ansatzes treffen. WIF wird zum Analysieren und zum Bereitstellen des Tokens für Autorisierungsentscheidungen über eine einfach zu verwendende API (Application Programming Interface) verwendet. Weitere Informationen zu WIF finden Sie im WIF SDK (https://go.microsoft.com/fwlink/?LinkID=187481). Berücksichtigen Sie die folgende Abbildung, wenn Sie Überlegungen zur Autorisierung in Ansprüche unterstützenden Anwendungen und Diensten anstellen. Beachten Sie, dass der Identitätsanbieter bei erfolgreicher Authentifizierung ein Token generiert (Das IdP-Token in der Abbildung). Das IdP-Token kann vom ACS-Regelmodul transformiert werden. ACS kann die Ansprüche hinzufügen, entfernen oder ändern, die im Token enthalten sind, das der Identitätsanbieter ausgibt. Schließlich wird das von ACS ausgestellte Token an die Anwendung gesendet und von WIF verarbeitet. Die Zugriffsüberprüfung wird in WIF mithilfe der RBAC- oder der CBAC-Vorgehensweise ausgeführt.
.gif "ACS v2 WIF Authorization")
Rollenbasierte Access Control
RBAC ist ein Autorisierungsansatz, in dem eine Anwendung Benutzerberechtigungen anhand von Benutzerrollen verwaltet und erzwingt. Wenn ein Benutzer über eine Rolle verfügt, die zum Ausführen einer Aktion erforderlich ist, wird der Zugriff erteilt. Andernfalls wird der Zugriff verweigert.
IPrincipal.IsInRole-Methode
Verwenden Sie zum Implementieren der RBAC-Vorgehensweise in Ansprüche unterstützenden Anwendungen die Methode IsInRole() der Schnittstelle IPrinicpal auf die gleiche Weise wie in Anwendungen, die keine Ansprüche unterstützen. Es gibt verschiedene Möglichkeiten, die Methode IsInRole() zu verwenden:
Ausdrücklicher Aufruf für IPrincipal.IsInRole("Administrator"). Das Ergebnis dieser Methode ist ein boolescher Wert. Verwenden Sie diese Methode in Bedingungsanweisungen. Sie kann an einer beliebigen Stelle im Code verwendet werden.
Verwenden der Sicherheitsforderung PrincipalPermission.Demand(). In diesem Ansatz ist das Ergebnis eine Ausnahme, falls die Anforderung nicht erfüllt wird. Der Ansatz sollte zu Ihrer Ausnahmebehandlungsstrategie passen. Für das Auslösen von Ausnahmen entsteht unter Leistungsgesichtspunkten im Vergleich zum Abrufen eines booleschen Werts mehr Aufwand. Dieser Ansatz kann an jeder beliebigen Stelle im Code verwendet werden.
Verwenden der deklarativen Attribute [PrincipalPermission(SecurityAction.Demand, Role = "Administrator")]. Dieser Ansatz wird als deklarativ bezeichnet, da er verwendet wird, um Methoden zu ergänzen. Er kann nicht in den Codeblöcken innerhalb der Implementierungen der Methode verwendet werden. Das Ergebnis ist eine Ausnahme, falls die Anforderung nicht erfüllt wird. Sie sollten überprüfen, ob dieser Ansatz Ihrer Ausnahmebehandlungsstrategie entspricht.
Verwenden der URL-Autorisierung mithilfe des< Autorisierungsabschnitts> in web.config. Dieser Ansatz eignet sich, wenn Sie die Autorisierung auf URL-Ebene verwalten. Dies ist von allen bisher erwähnten Ebenen die gröbste Ebene. Der Vorteil dieser Methode ist, dass Änderungen in der Konfigurationsdatei vorgenommen werden, d. h., dass der Code nicht kompiliert werden sollte, um von der Änderung zu profitieren.
Ausdrücken von Rollen als Ansprüche
Wenn die Methode IsInRole() aufgerufen wird, erfolgt eine Überprüfung, ob der aktuelle Benutzer diese Rolle inne hat. In den Ansprüche unterstützenden Anwendungen wird die Rolle durch einen Rollenanspruchstyp ausgedrückt, der im Token verfügbar sein soll. Der Rollenanspruchstyp wird mithilfe des folgenden URI ausgedrückt:
https://schemas.microsoft.com/ws/2008/06/identity/claims/role
Es gibt mehrere Möglichkeiten, ein Token mit einem Rollenanspruchstyp zu erweitern:
Verwenden Sie das ACS-Regelmodul– In diesem Fall erstellen Sie eine Regel mithilfe des ACS-Verwaltungsportals oder des ACS-Verwaltungsdiensts, um Anspruchstransformationsregeln zu erstellen, die Ansprüche eines bestimmten Rollentyps generieren. Weitere Informationen zu Regeln und Tokentransformation finden Sie unter Regelgruppen und Regeln und Vorgehensweise: Implementieren der Tokentransformationslogik mithilfe von Regeln.
Transformieren beliebiger Ansprüche in einen Anspruchsrollentyp mithilfe von "ClaimsAuthenticationManager" ClaimsAuthenticationManager ist eine Komponente, die im Lieferumfang von WIF enthalten ist. Sie ermöglicht ein Abfangen von Anforderungen, wenn diese eine Anwendung starten. Dabei werden Token überprüft und transformiert, indem Ansprüche hinzugefügt, geändert oder entfernt werden. Weitere Informationen zur Verwendung von ClaimsAuthenticationManager für die Transformation von Ansprüchen finden Sie unter How to: Implement Role Based Access Control (RBAC) in a Claims-Aware ASP.NET Application Using WIF and ACS
Zuordnen beliebiger Ansprüche zu einem Rollentyp mithilfe des Konfigurationsabschnitts "samlSecurityTokenRequirement" – Ein deklarativer Ansatz, bei dem die Anspruchstransformation nur mithilfe der Konfiguration ausgeführt wird und keine Codierung erforderlich ist.
Anspruchsbasierte Zugriffssteuerung
CBAC (Claims-Based Access Control, anspruchsbasierte Zugriffssteuerung) ist ein Autorisierungsverfahren, bei dem die Autorisierungsentscheidung, Zugriff zu erteilen oder zu verweigern, auf beliebiger Programmlogik basiert, die die in den Ansprüchen verfügbaren Daten verwendet, um die Entscheidung zu treffen. Beachten Sie, dass der einzige Anspruch, der in RBAC verwendet wird, der Rollentyp ist. Ein Rollentypanspruch wurde verwendet, um zu überprüfen, ob der Benutzer zu einer bestimmten Rolle gehört oder nicht. Die folgenden Schritte veranschaulichen den Prozess zum Treffen der Autorisierungsentscheidungen mithilfe des anspruchsbasierten Autorisierungsansatzes:
Die Anwendung empfängt eine Anforderung.
Die Anwendung extrahiert die eingehenden Ansprüche.
Die Anwendung übergibt die Ansprüche an den Entscheidungslogikmechanismus. Dabei kann es sich um Code im Arbeitsspeicher oder um einen Aufruf eines Webdiensts bzw. um eine Abfrage einer Datenbank handeln. Es kann auch eine anspruchsvolle Regel-Engine aufgerufen werden.
Der Entscheidungsmechanismus berechnet das Ergebnis auf Grundlage der Ansprüche.
Der Zugriff wird gewährt, wenn das Ergebnis "true" ist, und verweigert, wenn es "false" ist. Die Regel kann beispielsweise sein, dass der Benutzer 21 oder höher ist, in Washington State lebt und von Windows Live ID (Microsoft-Konto) authentifiziert wurde.
ACS dient als STS, das Token ausgibt, die die Ansprüche tragen. Sie können steuern, welche Ansprüche ausgegeben werden – sowohl die Arten von Ansprüchen als auch die Werte – mithilfe des ACS-Regelmoduls. Weitere Informationen zum ACS-Regelmodul finden Sie unter Regelgruppen und Regeln und Vorgehensweise: Implementieren der Tokentransformationslogik mithilfe von Regeln. ClaimsAuthorizationManager ist der Schlüssel für die Implementierung von CBAC in Ansprüche unterstützende Anwendungen. ClaimsAuthorizationManager ist eine Komponente, die im Lieferumfang von WIF enthalten ist. Mit ClaimsAuthorizationManager können Sie eingehende Anforderungen abfangen und eine Logik Ihrer Wahl implementieren, um Autorisierungsentscheidungen auf der Basis eingehender Ansprüche zu treffen. Außerdem handelt es sich um eine Erweiterungsmöglichkeit, um Autorisierungsentscheidungen extern zu verarbeiten und vom Anwendungscode zu entkoppeln. Dies ist wichtig, wenn die Autorisierungslogik geändert werden muss. In diesem Fall beeinträchtigt die Verwendung von ClaimsAuthorizationManager nicht die Integrität der Anwendung. Darüber hinaus wird die Wahrscheinlichkeit eines Anwendungsfehlers aufgrund der Änderung reduziert. Weitere Informationen zur Verwendung von ClaimsAuthorizationManager zum Implementieren der anspruchsbasierten Zugriffssteuerung finden Sie unter How to: Implement Claims Authorization in a Claims-Aware ASP.NET Application Using WIF and ACS.