ASP.NET MVC 2 y autenticación usando WIF(Windows Identity Foundation)

asp.net-mvc authentication

Question

¿Hay algún buen ejemplo de lo siguiente disponible?

Examinando el WIF SDK , hay ejemplos de uso de WIF junto con ASP.NET utilizando WSFederationAuthenticationModule (FAM) para redirigir a un sitio delgado ASP.NET sobre un Security Token Service (STS) que el usuario usa para autenticarse ( mediante el suministro de un nombre de usuario y contraseña).

Si entiendo correctamente el WIF y el acceso basado en reclamos, me gustaría que mi aplicación proporcione su propia pantalla de inicio de sesión donde los usuarios brinden su nombre de usuario y contraseña, y deleguen en un STS para autenticación, enviando los detalles de inicio de sesión a un punto final a través de un estándar de seguridad (WS- *), y esperando que se devuelva un token SAML. Idealmente, el SessionAuthenticationModule funcionaría según los ejemplos que usan FAM junto con SessionAuthenticationModule es decir, será responsable de reconstruir el IClaimsPrincipal de la cookie de seguridad de la sesión y redireccionar a la página de inicio de sesión de la aplicación cuando caduque la sesión de seguridad.

¿Es posible describir lo que describo utilizando FAM y SessionAuthenticationModule con la configuración web.config apropiada, o tengo que pensar en escribir un HttpModule para manejar esto? Alternativamente, ¿se está redirigiendo a un sitio web delgado STS donde los usuarios inician sesión en el enfoque de facto en un escenario de solicitante pasivo?

Answer 1

Esa es una pregunta interesante que has hecho. Sé que por alguna razón, Microsoft lanzó este marco de "Fundación de Identidad de Windows" sin mucha documentación. Lo sé porque me han encargado que averigüe cómo usarlo con un nuevo proyecto e integrarlo con la infraestructura existente. He estado buscando en la web durante meses buscando buena información.

He tomado un ángulo algo diferente para resolver el problema que describes.

Tomé una aplicación de inicio de sesión existente e integé la plomería WIF de Microsoft en ella. Con eso, quiero decir que tengo una aplicación donde un usuario inicia sesión. La aplicación de inicio de sesión envía las credenciales suministradas por el usuario a otro servidor que devuelve la identidad de los usuarios (o indica el error de inicio de sesión).

Mirando algunos de los ejemplos de Microsoft, veo que hacen lo siguiente: construir un SignInRequestMessage desde una cadena de consulta (generado por una aplicación de terceros), construir un servicio de token de seguridad desde una clase personalizada y finalmente llamar a FederatedSecurityTokenServiceOperations.ProcessSignInresponse con el httpcontext actual .respuesta. Desafortunadamente, no puedo explicarlo bien aquí; realmente necesitas mirar las muestras de código.

Parte de mi código es muy similar al ejemplo de código. Donde va a estar interesado en implementar una gran parte de su propia lógica es en GetOutputClaimsIdentity . Esta es la función que construye la identidad de reclamos que describe el usuario que inició sesión.

Ahora, esto es lo que creo que realmente te interesa saber. Esto es lo que Microsoft no le dice en su documentación, AFAIK.

Una vez que el usuario inicia sesión, se los redirige a la aplicación de la parte dependiente. Independientemente de cómo funcione la aplicación de inicio de sesión, las clases WIF enviarán una respuesta al navegador del usuario que contiene una entrada HTML "oculta" que contiene el certificado de firma de tokens y las afirmaciones del usuario. (Los reclamos estarán en texto claro). Al final de esta respuesta, se redirige al sitio web de su parte dependiente. Solo sé sobre esta acción porque la capturé con "Fiddler"

Una vez de regreso en el sitio web de la parte confiante, las clases WIF se encargarán de la respuesta (antes de ejecutar cualquiera de sus códigos). El certificado será validado De forma predeterminada, si ha configurado el sitio web de su parte dependiente con FedUtil.exe (haciendo clic en "Agregar referencia STS en su aplicación de parte confiante de Visual Studio"), la clase de Microsoft verificará la huella digital del certificado.

Finalmente, el marco WIF establece cookies en el navegador del usuario (en mi experiencia, los nombres de las cookies comienzan con "FedAuth") que contienen los reclamos de los usuarios. Las cookies no son legibles por humanos.

Una vez que eso sucede, puede realizar opcionalmente operaciones en los reclamos del usuario dentro del sitio web de la parte ClaimsAuthenticationClass utilizando ClaimsAuthenticationClass . Aquí es donde su código se está ejecutando nuevamente.

Sé que esto es diferente de lo que describes, pero tengo esta configuración funcionando. ¡Espero que esto ayude!

PD. Consulte las otras preguntas que le hice sobre Windows Identity Foundation.

ACTUALIZACIÓN: para responder la pregunta en el comentario a continuación:

Una cosa que omito es que la redirección a la aplicación de inicio de sesión de STS ocurre mediante una redirección con una cadena de consulta que contiene la URL de la aplicación en la que el usuario está iniciando sesión. Esta redirección ocurre automáticamente la primera vez que un usuario intenta acceder a una página que requiere autenticación. Alternativamente, creo que podría redirigir manualmente con el módulo WSFederationAuthentication .

Nunca he intentado hacer esto, pero si desea utilizar una página de inicio de sesión dentro de la aplicación, creo que el marco debería permitirle usar lo siguiente:

1) Encapsule su código STS dentro de una biblioteca. 2) Haga referencia a la biblioteca desde su aplicación. 3) Cree una página de inicio de sesión dentro de su aplicación. Asegúrese de que dicha página no requiera autenticación. 4) Establezca la propiedad del emisor del elemento wsFederation dentro de la sección Microsoft.IdentityModel de su web.config en la página de inicio de sesión.

Answer 2

Establezca su cookie así: FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie (sessionToken); Doens no trabaja para SSO en otros dominios.

Para cookie debe establecerse por el STS no en el RP.

Answer 3

Lo que quieres hacer es un inicio de sesión activo. WIF incluye WSTrustChannel(Factory) que le permite comunicarse directamente con el STS y obtener un token de seguridad. Si desea que su formulario de inicio de sesión funcione de esta manera, puede seguir el ejemplo "WSTrustChannel" del WIF 4.0 SDK. Una vez que haya obtenido el token, el siguiente código tomará ese token y llamará al controlador WIF para crear un token de sesión y establecer la cookie adecuada:

public void EstablishAuthSession(GenericXmlSecurityToken genericToken)
{
var handlers = FederatedAuthentication.ServiceConfiguration.SecurityTokenHandlers;
var token = handlers.ReadToken(new XmlTextReader(
new StringReader(genericToken.TokenXml.OuterXml)));
var identity = handlers.ValidateToken(token).First();
// create session token
var sessionToken = new SessionSecurityToken(
ClaimsPrincipal.CreateFromIdentity(identity));
FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken);
}

Una vez que haya hecho esto, su sitio debe comportarse de la misma manera que si se hubiera producido la firma pasiva.

Answer 4

Puede usar FederatedPassiveSignIn Control.

Answer 5

Un ejemplo de WIF + MVC está disponible en este capítulo de la "Guía de identidad de reclamaciones":

http://msdn.microsoft.com/en-us/library/ff359105.aspx

Sugiero leer los primeros dos capítulos para comprender todos los principios subyacentes. Esta publicación de blog cubre los detalles de MVC + WIF:

http://blogs.msdn.com/b/eugeniop/archive/2010/04/03/wif-and-mvc-how-it-works.aspx

Controlar la experiencia de inicio de sesión está perfectamente bien. Debería implementar su propio STS (en su dominio, con su apariencia, etc.). Sus aplicaciones simplemente se basarían en AuthN (es por eso que una aplicación generalmente se denomina "parte confiable").

La ventaja de la arquitectura es que authN se delega en 1 componente (STS) y no se distribuye en muchas aplicaciones. Pero la otra (enorme) ventaja es que puedes habilitar escenarios más sofisticados muy fácilmente. Por ejemplo, ahora puede federarse con los proveedores de identidad de otras organizaciones.

Espero que ayude a Eugenio

@Estrella naciente:

El token (que contiene los reclamos) se puede encriptar de manera opcional (de lo contrario, estarán en texto claro). Es por eso que SSL siempre se recomienda para las interacciones entre el navegador y el STS.

Tenga en cuenta que a pesar de que están en texto claro, la manipulación no es posible porque el token está firmado digitalmente.