ClaimsAuthenticationManager, ClaimsAuthorizationManager y OriginalIssuer
ClaimsAuthenticationManager
ClaimsAuthenticationManager le permite realizar la transformación de notificaciones, incluido agregar, modificar y eliminar notificaciones extraídas de un token entrante antes de que las reciba la aplicación de RP. Proporciona un único lugar para autenticar las notificaciones. Es un lugar común entre una aplicación de ASP.NET y otra de WCF en el que hace la pregunta: "¿Puedo confiar en el emisor para realizar estas notificaciones?"
Para interceptar las notificaciones entrantes, cree una clase que derive de ClaimsAuthenticationManager e implemente su único método, Authenticate. Justo antes de que la aplicación de RP reciba las notificaciones extraídas del token, WIF llama a este método y pasa una colección ClaimsIdentityCollection que contiene notificaciones extraídas de un token entrante. Puede modificar esta colección y, a continuación, devolverla desde el método. A continuación, la aplicación de RP recibe la colección de notificaciones modificada.
Para utilizar ClaimsAuthenticationManager, también debe agregarlo al archivo de configuración de la aplicación de RP, o establecerlo en la propiedad ClaimsAuthenticationManager del objeto ServiceConfiguration. Para obtener más información acerca del objeto ServiceConfiguration, vea Configuración.
ClaimsAuthorizationManager
ClaimsAuthorizationManager proporciona un único lugar para autorizar o denegar las solicitudes entrantes antes de que las reciba la aplicación de RP. Este es el lugar en el que hace la pregunta: "¿Permito al solicitante realizar esta acción en este recurso?"
Para interceptar las solicitudes entrantes, cree una clase que derive de ClaimsAuthorizationManager e implemente su único método, CheckAccess. El parámetro AuthorizationContext contiene los siguientes miembros:
Action, una colección de objetos Claim que representa la acción.Principal, el objeto IClaimsPrincipal del solicitante.Resource, una colección de objetos Claim que representa el recurso.
Observe que AuthorizationContext.Action corresponde a ClaimsPrincipalPermission.Operation, no a ClaimsPrincipalPermission.SecurityAction. AuthorizationContext.Resource corresponde a ClaimsPrincipalPermission.Resource.
Para utilizar ClaimsAuthorizationManager, también debe agregarlo al archivo de configuración de la aplicación de RP, o establecerlo en la propiedad ClaimsAuthorizationManager del objeto ServiceConfiguration. Para obtener más información acerca del objeto ServiceConfiguration, vea Configuración.
Observe que para los extremos del servicio de WCF, el recurso pasado a ClaimsAuthorizationManager normalmente es un URI de extremo. Esto es cierto para los siguientes extremos:
Los servicios de WCF.
Los servicios REST invocados con el método POST.
Las aplicaciones de ASP.NET con un objeto ClaimsAuthorizationModule que se invocan con el método POST.
Esto no es cierto para los siguientes extremos:
Los servicios REST invocados con el método GET.
Las aplicaciones de ASP.NET con un objeto ClaimsAuthorizationModule que se invocan con el método GET.
Para autorizar o denegar solicitudes basándose en el URI de extremo, no puede realizar una comparación de cadenas estricta, porque el URI varía con cada solicitud dependiendo de los parámetros de consulta de la cadena de solicitud.
Tenga en cuenta también que no debería tomar decisiones de autorización en métodos de devolución de llamada asincrónica, ya que ClaimsAuthorizationManager no se invoca para estos métodos. Puede tomar decisiones de autorización en un método Beginxxx, pero no en una devolución de llamada asincrónica o método Endxxx.
OriginalIssuer
Cuando la aplicación de usuario de confianza (RP) debe tomar una decisión de directiva basada en el STS que emitió originalmente la notificación, puede utilizar la propiedad OriginalIssuer. Esta propiedad la establece el Security Token Service (STS) que emite el token que contiene la notificación.
Como ejemplo, suponga que el RP recibe un token de su STS de Usuario de confianza (STS de RP). El propio STS de RP confía en varios STS de Proveedor de identidad (STS de IP). El RP confía en su STS de RP, lo cual, por extensión, significa que también confía en los STS de IP. Sin embargo, el RP debe tomar una decisión de directiva basada en si el token contiene notificaciones emitidas originalmente por el STS de RP o uno de los STS de IP. La propiedad OriginalIssuer permite que hacer esto.
El valor de la propiedad OriginalIssuer no se puede comprobar mediante criptografía. Por consiguiente, puede utilizarlo para tomar decisiones de directiva, pero no debería utilizarlo para tomar decisiones de seguridad.
Nota
Un STS de una cadena de delegación debe conservar el valor de OriginalIssuer en todas las notificaciones que recibió al emitir otro token que contiene estas notificaciones.