SecurityTokenService.GetOutputClaimsIdentity Methode

protected:
 abstract System::Security::Claims::ClaimsIdentity ^ GetOutputClaimsIdentity(System::Security::Claims::ClaimsPrincipal ^ principal, System::IdentityModel::Protocols::WSTrust::RequestSecurityToken ^ request, System::IdentityModel::Scope ^ scope);

protected abstract System.Security.Claims.ClaimsIdentity GetOutputClaimsIdentity (System.Security.Claims.ClaimsPrincipal principal, System.IdentityModel.Protocols.WSTrust.RequestSecurityToken request, System.IdentityModel.Scope scope);

abstract member GetOutputClaimsIdentity : System.Security.Claims.ClaimsPrincipal * System.IdentityModel.Protocols.WSTrust.RequestSecurityToken * System.IdentityModel.Scope -> System.Security.Claims.ClaimsIdentity

Protected MustOverride Function GetOutputClaimsIdentity (principal As ClaimsPrincipal, request As RequestSecurityToken, scope As Scope) As ClaimsIdentity

Parameter

Gibt zurück

Ein ClaimsIdentity, das die Sammlung von Ansprüchen enthält, die in das ausgestellte Sicherheitstoken eingefügt werden.

Beispiele

Das Codebeispiel, das in diesem Thema verwendet wird, stammt aus dem Custom Token Beispiel. Dieses Beispiel enthält benutzerdefinierte Klassen, die die Verarbeitung von Einfachen Webtoken (SWT) ermöglichen, sowie eine Implementierung eines passiven STS, der ein SWT-Token bereitstellen kann. Ein Beispiel für die Implementierung eines aktiven STS finden Sie im Federation Metadata Beispiel. Informationen zu diesen Beispielen und anderen für WIF verfügbaren Beispielen und zum Herunterladen finden Sie unter WIF-Codebeispielindex. Der folgende Code zeigt, wie Sie die GetOutputClaimsIdentity -Methode überschreiben, um Ansprüche für Ihren STS zurückzugeben. In diesem Beispiel wird die Meldung Anforderungssicherheitstoken (Request Security Token, RST) ignoriert, und eine Sammlung von Ansprüchen basierend auf dem Benutzer, der am STS authentifiziert ist, wird zurückgegeben.

/// <summary>
/// This method returns the content of the issued token. The content is represented as a set of
/// IClaimIdentity intances, each instance corresponds to a single issued token. Currently, the Windows Identity Foundation only
/// supports a single token issuance, so the returned collection must always contain only a single instance.
/// </summary>
/// <param name="scope">The scope that was previously returned by GetScope method</param>
/// <param name="principal">The caller's principal</param>
/// <param name="request">The incoming RST, we don't use this in our implementation</param>
/// <returns></returns>
protected override ClaimsIdentity GetOutputClaimsIdentity( ClaimsPrincipal principal, RequestSecurityToken request, Scope scope )
{
    //
    // Return a default claim set which contains a custom decision claim
    // Here you can actually examine the user by looking at the IClaimsPrincipal and 
    // return the right decision based on that. 
    //
    ClaimsIdentity outgoingIdentity = new ClaimsIdentity();
    outgoingIdentity.AddClaims(principal.Claims);

    return outgoingIdentity;
}

Hinweise

Die GetOutputClaimsIdentity -Methode wird aus der Tokenausstellungspipeline aufgerufen, die von der Issue -Methode implementiert wird. Es gibt eine ClaimsIdentity zurück, die die Ansprüche enthält, die in das ausgestellte Sicherheitstoken aufgenommen werden sollen, basierend auf dem Anforderer des Tokens (dem principal Parameter), der eingehenden RST (der request Parameter) und der vertrauenden Seite, für die das Token vorgesehen ist (der scope Parameter). Die Logik in dieser Methode befasst sich in erster Linie mit der Beantwortung der folgenden Fragen:

• Welche Anspruchstypen sollten in die Antwort aufgenommen werden, basierend auf dem RP, für den sie vorgesehen ist? In der Regel wird dies pro RP anhand von Listen von Anspruchstypen entschieden, die für jeden RP erforderlich sind, oder auf Anforderungsbasis, indem die Claims Eigenschaft der Anforderung untersucht wird. Die Logik und die Details zum Bestimmen der Ansprüche, die in die Antwort einbezogen werden sollen, sind jedoch vollständig von Ihrer Implementierung abhängig.

• Welche Anspruchswerte sollten den Ansprüchen in der Antwort zugewiesen werden? Für einen Identitätsanbieter (IP-STS) bedeutet dies in der Regel die Verwendung eines oder mehrerer Ansprüche im Anforderer ClaimsPrincipal (vom principal -Parameter bereitgestellt), um auf einen Speicher (oder eine andere Entität) zuzugreifen, um Werte für die erforderlichen Anspruchstypen zurückzugeben. Für einen Verbundanbieter (Federation Provider, R-STS) bedeutet dies in der Regel, dass die eingehenden Ansprüche des Anforderers verarbeitet werden, um die Anforderung zu erfüllen. möglicherweise eine Filterung oder Transformation für einige ansprüche, die vom Anforderer präsentiert werden, während andere unverändert übergeben werden. Wie bei der Entscheidung, welche Ansprüche in die Antwort aufgenommen werden sollen, sind die Details und die Logik, wie die Werte dieser Ansprüche bestimmt werden, natürlich von Ihrer Implementierung bestimmt.

Hinweise für Ausführende

In Ihrer Implementierung der SecurityTokenService-Klasse müssen Sie diese Methode überschreiben.

Gilt für:

Weitere Informationen

• Scope
• Issue(ClaimsPrincipal, RequestSecurityToken)