SecurityTokenService.GetOutputClaimsIdentity Método

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

Parámetros

Devoluciones

ClaimsIdentity que contiene la colección de reclamaciones que se coloquen en el token de seguridad emitido.

Ejemplos

El ejemplo de código que se usa en este tema se toma del Custom Token ejemplo. En este ejemplo se proporcionan clases personalizadas que permiten el procesamiento de tokens web simples (SWT) e incluye una implementación de un STS pasivo que es capaz de atender un token SWT. Para obtener un ejemplo de cómo implementar un STS activo, puede ver el Federation Metadata ejemplo. Para obtener información sobre estos ejemplos y otros ejemplos disponibles para WIF y sobre dónde descargarlos, consulte Índice de ejemplo de código WIF. En el código siguiente se muestra cómo invalidar el GetOutputClaimsIdentity método para devolver notificaciones para el STS. En este ejemplo, se omite el mensaje Token de seguridad de solicitud (RST) y se devuelve una colección de notificaciones basadas en el usuario como autenticado en el STS.

/// <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;
}

Comentarios

Se GetOutputClaimsIdentity llama al método desde la canalización de emisión de tokens, que implementa el Issue método . Devuelve un ClaimsIdentity valor de tipo que contiene las notificaciones que se van a incluir en el token de seguridad emitido en función del solicitante del token (el principal parámetro), el RST entrante (el request parámetro) y el usuario de confianza para el que se pretende el token (el scope parámetro). La lógica de este método se ocupa principalmente de responder a las siguientes preguntas:

• ¿Qué tipos de notificación se deben incluir en la respuesta en función del RP para el que está previsto? Normalmente, esto se decide por rp en listas de tipos de notificación necesarios para cada RP o por solicitud mediante el examen de la Claims propiedad de la solicitud. Sin embargo, la lógica y los detalles para determinar las notificaciones que se van a incluir en la respuesta están completamente en su implementación.

• ¿Qué valores de notificación se deben asignar a las notificaciones en la respuesta? Para un proveedor de identidades (IP-STS), normalmente significa usar una o varias notificaciones en el solicitante ClaimsPrincipal (proporcionado por el principal parámetro) para acceder a un almacén (u otra entidad) para devolver valores para los tipos de notificación necesarios. Para un proveedor de federación (R-STS), esto normalmente significa realizar algún tipo de procesamiento en las notificaciones entrantes del solicitante para cumplir la solicitud; quizás realice el filtrado o la transformación en algunas notificaciones presentadas por el solicitante, mientras se pasan a otros usuarios sin modificar. Por supuesto, como en el caso de decidir qué notificaciones incluir en la respuesta, los detalles y la lógica de cómo determinar los valores de estas notificaciones es hasta la implementación.

Notas a los implementadores

Debe reemplazar este método en la implementación de la clase SecurityTokenService.

Se aplica a

Consulte también

• Scope
• Issue(ClaimsPrincipal, RequestSecurityToken)