ClaimsPrincipalPermission Klasse

Definition

public ref class ClaimsPrincipalPermission sealed : System::Security::IPermission, System::Security::Permissions::IUnrestrictedPermission

[System.Serializable]
public sealed class ClaimsPrincipalPermission : System.Security.IPermission, System.Security.Permissions.IUnrestrictedPermission

[<System.Serializable>]
type ClaimsPrincipalPermission = class
    interface IPermission
    interface ISecurityEncodable
    interface IUnrestrictedPermission

Public NotInheritable Class ClaimsPrincipalPermission
Implements IPermission, IUnrestrictedPermission

Vererbung

Object

ClaimsPrincipalPermission

Attribute

SerializableAttribute

Implementiert

IPermission ISecurityEncodable IUnrestrictedPermission

Beispiele

Das folgende Beispiel zeigt, wie eine Ressource mithilfe der Demand -Methode, der CheckAccess -Methode oder einer ClaimsPrincipalPermissionAttribute -Deklaration geschützt wird. In jedem Fall wird das konfigurierte ClaimsAuthorizationManager aufgerufen, um den aktuellen Prinzipal anhand der angegebenen Ressource und Aktion auszuwerten. Wenn der aktuelle Prinzipal für die angegebene Aktion für die angegebene Ressource nicht autorisiert ist, wird ein SecurityException ausgelöst, andernfalls wird die Ausführung fortgesetzt.

using System;
using System.IdentityModel.Services;
using System.Security.Claims;
using System.Security.Permissions;
using System.Threading;

namespace ClaimsBasedAuthorization
{
    /// <summary>
    /// Program illustrates using Claims-based authorization
    /// </summary>
    class Program
    {
        static void Main(string[] args)
        {
            //
            // Method 1. Simple access check using static method. 
            // Expect this to be most common method.
            //
            ClaimsPrincipalPermission.CheckAccess("resource", "action");

            //
            // Method 2. Programmatic check using the permission class
            // Follows model found at http://msdn.microsoft.com/library/system.security.permissions.principalpermission.aspx
            //
            ClaimsPrincipalPermission cpp = new ClaimsPrincipalPermission("resource", "action");
            cpp.Demand();

            //
            // Method 3. Access check interacting directly with the authorization manager.
            //            
            ClaimsAuthorizationManager am = new ClaimsAuthorizationManager();
            am.CheckAccess(new AuthorizationContext((ClaimsPrincipal)Thread.CurrentPrincipal, "resource", "action"));

            //
            // Method 4. Call a method that is protected using the permission attribute class
            //
            ProtectedMethod();

            Console.WriteLine("Press [Enter] to continue.");
            Console.ReadLine();
        }

        //
        // Declarative access check using the permission class. The caller must satisfy both demands.
        //
        [ClaimsPrincipalPermission(SecurityAction.Demand, Resource = "resource", Operation = "action")]
        [ClaimsPrincipalPermission(SecurityAction.Demand, Resource = "resource1", Operation = "action1")]
        static void ProtectedMethod()
        {
        }
    }
}

Der folgende XML-Code zeigt die Mindestkonfiguration, die erforderlich ist, um einen benutzerdefinierten Berechtigungsautorisierungs-Manager mit der ClaimsPrincipalPermission -Klasse zu verwenden. Sie müssen mindestens die system.identityModel Abschnitte und system.identityModel.services im Element deklarieren und dann Ihren Autorisierungs-Manager <configSection> in einem <claimsAuthorizationManager-Element> unter der Standardidentitätskonfiguration angeben. Dadurch wird sichergestellt, dass der Autorisierungs-Manager von der Standardverbundkonfiguration referenziert wird. Alternativ können Sie den Namen der Identitätskonfiguration angeben, unter der Ihr Autorisierungs-Manager im identityConfigurationName Attribut des <federationConfiguration-Elements> angegeben wird.

<?xml version="1.0" encoding="utf-8" ?>  
<configuration>  
  <configSections>  
    <!-- WIF configuration sections -->  
    <section name="system.identityModel" type="System.IdentityModel.Configuration.SystemIdentityModelSection, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>  
    <section name="system.identityModel.services" type="System.IdentityModel.Services.Configuration.SystemIdentityModelServicesSection, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>  
  </configSections>  

  <startup>  
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />  
  </startup>  

  <system.identityModel>  
    <identityConfiguration>  
      <claimsAuthorizationManager type ="MyClaimsAuthorizationManager.MyClaimsAuthorizationManager, MyClaimsAuthorizationManager"/>  
    </identityConfiguration>  
  </system.identityModel>  

</configuration>  

Hinweise

Die ClaimsPrincipalPermission -Klasse bietet die Möglichkeit, imperative Zugriffsprüfungen mit dem durchzuführen, das ClaimsAuthorizationManager für eine Anwendung konfiguriert ist. Durch Aufrufen der Demand Methode oder der statischen CheckAccess Methode können Sie Ressourcen im Ausführungspfad Ihres Codes gemäß der für Ihren Anspruchsauthentifizierungs-Manager definierten Autorisierungsrichtlinie schützen. Deklarative Zugriffsprüfungen können mithilfe der ClaimsPrincipalPermissionAttribute -Klasse durchgeführt werden.

Auf einer Ebene ähnelt die von ClaimsPrincipalPermission bereitgestellte Funktionalität den rollenbasierten Zugriffsprüfungen (Role-Based Access Checks, RBAC), ClaimsAuthorizationManager die über die PrincipalPermission -Klasse bereitgestellt werden. Die -Klasse führt jedoch Überprüfungen basierend auf den vom aktiven Prinzipal bereitgestellten Ansprüchen aus. Dies ermöglicht eine weitaus detailliertere Granularität als die reine RBAC, bei der in der Regel viele Berechtigungen unter einer einzelnen Rolle gesammelt werden. Vielleicht noch wichtiger ist, dass die anspruchsbasierte Autorisierung eine bessere Trennung von Geschäftslogik und Autorisierungsrichtlinie ermöglicht, da berechtigungen für eine bestimmte Aktion für eine Ressource im Code angefordert werden können und die Back-End-Richtlinie verwendet werden kann, um zu konfigurieren, welche Ansprüche die präsentierende Entität besitzen muss, um die Nachfrage zu erfüllen. Führt wie RBAC ClaimsPrincipalPermission eine benutzerbasierte Zugriffsüberprüfung durch, d. h. im Gegensatz zur Codezugriffssicherheit, die von Klassen implementiert wird, die von der CodeAccessPermission Klasse abgeleitet werden und einen Stapellauf verwenden, um sicherzustellen, dass allen Aufrufenden des Codes eine Berechtigung erteilt wurde, ClaimsPrincipalPermission führt die Überprüfung nur für den aktuellen Prinzipal durch.

Die statische CheckAccess Methode überprüft den Zugriff auf eine angegebene Aktion für eine angegebene Ressource. Ressource und Aktion sind Zeichenfolgen und sind in der Regel URIs. Sie können auch eine instance von ClaimsPrincipalPermission mit einer Aktion und einer Ressource initialisieren und die Demand -Methode aufrufen. Obwohl der Konstruktor nur eine einzelne Ressource und Aktion benötigt, ClaimsPrincipalPermission können Objekte mit den Union Methoden und Intersect kombiniert werden. Eine mit diesen Methoden erstellte Berechtigung kann mehrere Ressourcen-Aktions-Paare enthalten.

Beide Methoden bestimmen den Zugriff, indem die ClaimsAuthorizationManager.CheckAccess Methode des konfigurierten Berechtigungsautorisierungs-Managers aufgerufen wird, der sich AuthorizationContext aus dem aktiven Prinzipal (Thread.CurrentPrincipal), der Ressource und der Aktion zusammensetzt. Sie lösen ein aus SecurityException , wenn der aktuelle Prinzipal nicht autorisiert ist, die Aktion für die Ressource auszuführen, andernfalls wird die Ausführung fortgesetzt.

Im Fall eines ClaimsPrincipalPermission , das mehrere Ressourcen-Aktionspaare enthält, wird die ClaimsAuthorizationManager.CheckAccess -Methode für jedes der Ressourcen-Aktionspaare aufgerufen, die in der Berechtigung enthalten sind. Damit der Aufruf von Demand erfolgreich ist, muss der aktive Prinzipal für alle ressourcen-aktions-Paare autorisiert sein, die in der Berechtigung enthalten sind.

Konstruktoren

Methoden

Gilt für:

Weitere Informationen

• ClaimsPrincipalPermissionAttribute
• FederationConfiguration
• ClaimsAuthorizationManager
• <federationConfiguration>