Cómo ver el estado de redirección de un STS / IDP

Question

He buscado (sondeado, incluso) para una respuesta a esto, pero no he encontrado nada útil hasta ahora. Soy bastante nuevo en ADFS, STS en general y WiF, por favor, excusa cualquier ignorancia obvia o uso inadecuado de la terminología. ;)

Actualmente estoy integrando una aplicación MVC3 personalizada con un IDP externo, a través de ADFS. La configuración de ADFS a IDP se realiza y funciona.

Algunas partes del sitio son accesibles para los usuarios de Anon, en el modo Web.Config, el modo de autenticación se ha establecido en Ninguno. Las otras partes están protegidas por tener sus controladores / métodos de acción decorados por un sistema personalizado.web.mvc.authorizeatTribe.

Se han realizado todas las modificaciones habituales a la Web.config para usar el módulo de WSFEEDERAERATIONATHENTICETICO y funciona 95%; El usuario puede navegar a las partes accesibles de Anon del sitio. Cuando intentan y intentan las piezas protegidas, los atributos autorizan las verifican si tienen alguna información personalizada de nuestro IDP en iClaimsprincipals asociados con httpcontext.current.user y luego establece la ActionResult a 401 si no; El wsfredationauthenticationmodule se inicia y los redirige a la página de inicio de sesión de IDP. Cuando ingresan a sus detalles, sean redirigidos con éxito con algunas cookies de FedAuth y la autorización luego pasa.

El problema comienza cuando llegan a la página de inicio de sesión de IDP. Este IDP particular tiene un enlace para devolverle directamente a nuestro sitio (a la misma página que se realizó la solicitud original), con esta respuesta SAML incrustada en algún lugar (esto es de acuerdo con su documentación)

URN: OASIS: NOMBRES: TC: SAML: 2.0: Estado: AuthnFailed

En este punto, ahora están "no autorizados" y todo el usuario verá (al menos en DEV) es una página 401. Tienes que matar la sesión o deshacerse de esa cookie para comenzar de nuevo.

Lo que necesito hacer es interceptar que redirige la solicitud del IDP y, esencialmente, verifique que el estado de SAML en particular, porque el usuario debe ser redirigido a una de las áreas no autorizadas como si nada hubiera sucedido. He intentado algo como esto en el global.asax:

 protected void Application_Start()
    {
        // mvc stuff here....

        // add handler to intercept handling creation of security tokens by WsFederationAuthnticationModule
        FederatedAuthentication.ServiceConfigurationCreated += OnServiceConfigurationCreated;
    }

    void OnServiceConfigurationCreated(object sender, ServiceConfigurationCreatedEventArgs e)
    {
        FederatedAuthentication
            .WSFederationAuthenticationModule
            .SessionSecurityTokenCreated += WSFederationAuthenticationModule_SecuityTokenCreated;
    }

    public void WSFederationAuthenticationModule_SecuityTokenCreated (Object sender, SessionSecurityTokenCreatedEventArgs args) 
    {          
        var token = args.SessionToken;
        // do something with the session token here e.g. check for SAML status
    }

.. Pero no puedo ver nada útil en ese token; Nada que indique un estado de respuesta específico. El hecho de que haya una cookie FEDAUTH en absoluto , pero ninguna información personalizada del IDP es una muerte muerta para regalar que el usuario ha estado allí, pero de alguna manera no pudo autenticarse, pero en principio quiero poder Vea ese estado. Puede que tenga que lidiar con los tiempos de espera en el IDP también ...

Tal vez estoy haciendo todo esto mal, o simplemente no entiendo, pero de alguna manera puedo llenarme sobre cómo determinar esos estados de respuesta?

Phew. ¡Gracias! : D

Answer 1

OK, así que voy a responder a mi propia pregunta.

La respuesta a si puedo obtener ese estado personalizado de mi IDP es un NO, en este momento. : (

Pero esto es solo porque ADFS no está configurado para capturarlo y pasarlo. Aparentemente, debe hacer una codificación personalizada para capturar información del canal de atrás que se abre entre ADFS y el IDP .... Más allá del alcance actual del trabajo.

como un trabajo por el momento:

• Si se realiza una solicitud al sitio y no hay un token de SAML, es una nueva solicitud de un usuario que no ha intentado ningún intento de autenticación en el IDP
• Si hay un token de SAML, pero no hay identificación del IDP en el token (que solo está presente cuando está autorizando correctamente), entonces el usuario falló a autenticación por alguna razón
  • Si hay un token de SAML con la identificación presente, la autenticación del usuario debe describir correctamente

    no es genial pero aceptable. Por cierto, todo el crédito va a ymc en este So POST para el siguiente código que le permite verificar los tokens de SAML:

    void WSFederationAuthenticationModule_SecurityTokenReceived(object sender, SecurityTokenReceivedEventArgs e)
        {
            var message = SignInResponseMessage.CreateFromFormPost(Request) as SignInResponseMessage;
            var rstr = new WSFederationSerializer()
                .CreateResponse(message,
                new WSTrustSerializationContext(
                    SecurityTokenHandlerCollectionManager.CreateDefaultSecurityTokenHandlerCollectionManager()));
        } 
    

    PCE!