ClaimsAuthenticationManager, ClaimsAuthorizationManager und OriginalIssuer

ClaimsAuthenticationManager

Mit ClaimsAuthenticationManager können Sie eine Anspruchstransformation durchführen. Dazu zählen das Hinzufügen, Ändern und Löschen von Ansprüchen, die aus einem eingehenden Token extrahiert wurden, bevor sie von der RP-Anwendung empfangen werden. Damit wird ein einziger Ort zum Authentifizieren von Ansprüchen bereitgestellt. Dabei handelt es sich um einen gemeinsamer Ort zwischen einer ASP.NET- und einer WCF-Anwendung, an dem die Frage gestellt wird: "Vertraue ich dem Aussteller, diese Ansprüche ausstellen zu dürfen?"

Um eingehende Ansprüche abzufangen, erstellen Sie eine Klasse, die von ClaimsAuthenticationManager abgeleitet wird und die ihre einzige Methode implementiert: Authenticate. Bevor die RP-Anwendung die aus dem Token extrahierten Ansprüche empfängt, ruft WIF diese Methode auf und übergibt eine ClaimsIdentityCollection, die aus einem eingehenden Token extrahierte Ansprüche enthält. Sie können diese Sammlung ändern und sie anschließend von der Methode zurückgeben. Die RP-Anwendung empfängt dann die geänderte Sammlung von Ansprüchen.

Um ClaimsAuthenticationManager zu verwenden, muss dieser auch der Konfigurationsdatei der RP-Anwendung hinzugefügt oder im ClaimsAuthenticationManager des ServiceConfiguration-Objekts festgelegt werden. Weitere Informationen zum ServiceConfiguration-Objekt finden Sie unter Konfiguration.

ClaimsAuthorizationManager

ClaimsAuthorizationManager stellt einen einzigen Ort bereit, um eingehende Anforderungen zu autorisieren oder zu verweigern, bevor diese von der RP-Anwendung empfangen werden. Dies ist der Ort, an dem die Frage gestellt wird: "Erlaube ich dem Anforderer, diese Aktion auf dieser Ressource durchzuführen?"

Um eingehende Anforderungen abzufangen, erstellen Sie eine Klasse, die von ClaimsAuthorizationManager abgeleitet wird und die ihre einzige Methode implementiert: CheckAccess. Der AuthorizationContext-Parameter enthält die folgenden Member:

1. Action, eine Sammlung von Claims, die die Aktion darstellt.

2. Principal, das IClaimsPrincipal des Anforderers.

3. Resource, eine Sammlung von Claims, die die Ressource darstellt.

AuthorizationContext.Action entspricht dabei ClaimsPrincipalPermission.Operation, nicht ClaimsPrincipalPermission.SecurityAction. AuthorizationContext.Resource entspricht ClaimsPrincipalPermission.Resource.

Um ClaimsAuthorizationManager zu verwenden, muss dieser auch der Konfigurationsdatei der RP-Anwendung hinzugefügt oder im ClaimsAuthorizationManager des ServiceConfiguration-Objekts festgelegt werden. Weitere Informationen zum ServiceConfiguration-Objekt finden Sie unter Konfiguration.

Beachten Sie, dass bei WCF-Dienstendpunkten die an ClaimsAuthorizationManager übergebene Ressource in der Regel ein Endpunkt-URI ist. Dies gilt für die folgenden Endpunkte:

1. WCF-Dienste

2. Mit der POST-Methode aufgerufene REST-Dienste

3. Mit der POST-Methode aufgerufene ASP.NET-Anwendungen mit einem ClaimsAuthorizationModule

Dies gilt nicht für die folgenden Endpunkte:

1. Mit der GET-Methode aufgerufene REST-Dienste

2. Mit der GET-Methode aufgerufene ASP.NET-Anwendungen mit einem ClaimsAuthorizationModule

Um Anforderungen anhand des Endpunkt-URIs zu autorisieren oder zu verweigern, kann kein strikter Zeichenfolgenvergleich durchgeführt werden, da der URI in den einzelnen Anforderungen je nach Abfrageparametern der Anforderungszeichenfolge abweicht.

Beachten Sie auch, dass Sie keine Autorisierungsentscheidungen in asynchronen Rückrufmethoden treffen sollten, da ClaimsAuthorizationManager für diese Methoden nicht aufgerufen wird. Sie können Autorisierungsentscheidungen in einer Beginxxx-Methode treffen, jedoch nicht in einem asynchronen Rückruf oder einer Endxxx-Methode.

OriginalIssuer

Wenn die Anwendung der vertrauenden Seite (Relying Party, RP) eine Richtlinienentscheidung anhand des STS treffen muss, von dem der Anspruch ursprünglich ausgestellt wurde, können Sie dazu die OriginalIssuer-Eigenschaft verwenden. Diese Eigenschaft wird vom Sicherheitstokendienst (STS) festgelegt, von dem das Token mit dem Anspruch ausgegeben wird.

Nehmen Sie als Beispiel an, dass die vertrauende Seite ein Token vom zugehörigen STS der vertrauenden Seite (RP-STS) empfängt. Der RP-STS selbst vertraut mehreren Identitätsanbieter-STS (IP-STS). Die vertrauende Seite vertraut ihrem RP-STS, was in der Folge bedeutet, dass sie auch den IP-STS vertraut. Die vertrauende Seite muss jedoch eine Richtlinienentscheidung auf der Grundlage treffen, ob das Token Ansprüche enthält, die ursprünglich vom RP-STS oder einem der IP-STS ausgestellt wurden. Dies geschieht mithilfe der OriginalIssuer-Eigenschaft.

Der Wert der OriginalIssuer-Eigenschaft ist kryptografisch nicht überprüfbar. Daher können Sie ihn verwenden, um Richtlinienentscheidungen zu treffen, Sie sollten damit jedoch keine Sicherheitsentscheidungen treffen.