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

Question

¿Hay algunos ejemplos dignos de la siguiente disposición:

Mirando a través de la WIF SDK , hay ejemplos del uso de WIF en conjunción con ASP.NET utilizando el WSFederationAuthenticationModule (FAM) para redirigir a un sitio ASP.NET piel fina en la parte superior de un servicio de token de seguridad (STS) que utiliza el usuario para autenticar (vía el suministro de un nombre de usuario y contraseña).

Acceso

basada en notificaciones Si entiendo WIF y correctamente, me gustaría que mi aplicación para proporcionar su propia pantalla de inicio de sesión que los usuarios proporcionan su nombre de usuario y contraseña y dejar que este delegado a un STS para la autenticación, el envío de los datos de acceso a un punto final a través un estándar de seguridad (WS *), y esperar un SAML símbolos que debe devolverse. Idealmente, el SessionAuthenticationModule funcionaría según los ejemplos que usan FAM conjuntamente con SessionAuthenticationModule es decir, ser responsable de la reconstrucción de la IClaimsPrincipal de la sesión de seguridad fragmentada galleta y volver a dirigir a mi página de inicio de sesión de aplicación cuando la sesión caduca seguridad.

Es lo que describo posible utilizando FAM y SessionAuthenticationModule con los ajustes apropiados web.config, o tengo que pensar en escribir un HttpModule mí mismo para manejar esto? Como alternativa, se redirigir a una delgada STS sitio web donde los usuarios inician sesión en el enfoque de facto en un escenario solicitante pasiva?

Answer 1

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

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

Yo te sugeriría leer los dos primeros capítulos de entender todos los principios subyacentes. Este blog cubre los aspectos específicos de MVC + WIF:

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

Control de la experiencia de inicio de sesión está perfectamente bien. Usted sólo debe implementar sus propios STS (en su dominio, con su look & feel, etc). Sus aplicaciones serían simplemente confiar en ella para AuthN (Es por eso que una aplicación se suele denominar una "parte que confía").

La ventaja de la arquitectura es que authn se delega a 1 componente (STS) y no se extendió a lo largo de muchas aplicaciones. Pero el otro (enorme) ventaja es que se puede habilitar escenarios más sofisticados con mucha facilidad. Por ejemplo, usted ahora puede federar con proveedores de identidad de otra organización.

Espero que ayuda Eugenio

@RisingStar:

El token (que contiene las reivindicaciones) puede estar opcionalmente encriptada (de lo contrario estarán en texto claro). Es por eso que siempre se recomienda SSL 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.

Answer 2

Esa es una pregunta interesante con lo solicitado. Sé que por cualquier razón, Microsoft puso fuera de este marco "Windows Identity Foundation" sin mucha documentación. Lo sé porque he recibido el encargo de encontrar la manera de usarlo con un nuevo proyecto y su integración con la infraestructura existente. He estado buscando en la web durante meses en busca de una buena información.

Me he tomado un ángulo algo diferente para resolver el problema que usted describe.

Me tomó un inicio de sesión existente de aplicaciones e integrado de fontanería WIF de Microsoft en él. Por eso, quiero decir que tengo una aplicación en la que un usuario se conecta. El inicio de sesión presenta la solicitud las credenciales proporcionadas por el usuario a otro servidor que devuelve la identidad usuarios (o indica log-en caso de fallo).

En cuanto a algunos de los ejemplos de Microsoft, veo que hagan lo siguiente: Construir un SignInRequestMessage de una cadena de consulta (generado por una aplicación de usuario de confianza), la construcción de un servicio de token de seguridad de una clase personalizada, y finalmente llamar FederatedSecurityTokenServiceOperations.ProcessSignInresponse con el httpcontext.response actual. Por desgracia, no puedo explicarlo bien aquí; que realmente necesita para mirar los ejemplos de código.

Algunos de mi código es muy similar al del ejemplo de código. ¿Dónde vas a estar interesado en la implementación de una gran cantidad de su propia lógica está en el GetOutputClaimsIdentity. Esta es la función que construye la reivindicaciones-identidad que describe el usuario conectado.

Ahora, esto es lo que creo que estás realmente interesado en saber. Esto es lo que Microsoft no le dice en su documentación, que yo sepa.

Una vez que el usuario inicia sesión, es redirigido de nuevo a la aplicación de confianza. Independientemente de cómo el registro en funcionamiento de la aplicación, las clases WIF enviará una respuesta al navegador del usuario que contiene una entrada de HTML "oculta" que contiene el certificado de firma de tokens y demandas del usuario. (Las reclamaciones serán en texto claro). Al final de esta respuesta es una redirección a su sitio web depender de partido. Lo único que sé acerca de esta acción porque yo capturé con "El violinista"

Una vez de vuelta en el sitio web de usuario de confianza, las clases WIF se encargará de la respuesta (antes de cualquiera de su código se ejecuta). El certificado será validado. Por defecto, si ha configurado su sitio web usuario de confianza con FedUtil.exe (haciendo clic en "Añadir STS de referencia en la aplicación de usuario de confianza desde Visual Studio), la clase de Microsoft verificará la huella digital del certificado.

Por último, las galletas conjuntos marco WIF en el navegador del usuario (En mi experiencia, los nombres de galletas comienzan con "FedAuth") que contiene las demandas de los usuarios. Las cookies no son legibles.

Una vez que esto sucede, es posible realizar opcionalmente operaciones sobre las reclamaciones de los usuarios dentro del sitio web de usuario de confianza utilizando el ClaimsAuthenticationClass. Aquí es donde su código en funcionamiento de nuevo.

Sé que esto es diferente de lo que usted describe, pero tengo este trabajo de instalación. Espero que esto ayude!

ps. Por favor, echa un vistazo a las otras preguntas que he frecuentes sobre Windows Identity Foundation.

ACTUALIZACIÓN: A la pregunta de respuesta en el comentario a continuación:

Una cosa que me he dejado es que la redirección a la STS-log de la aplicación ocurre a través de una redirección con una cadena de consulta que contiene la dirección URL de la aplicación el usuario inicia sesión en a. Esta redirección sucede automáticamente la primera vez que un usuario intenta acceder a una página que requiere autenticación. Por otra parte, creo que se podría hacer la redirección de forma manual con el módulo WSFederationAuthentication.

Yo nunca he tratado de hacer esto, pero si usted desea utilizar un inicio de sesión en la página de la aplicación en sí, creo que el marco debe permitir el uso de los siguientes:

1) Encapsular el código STS dentro de una biblioteca. 2) Referencia a la biblioteca de su aplicación. 3) Crear un inicio de sesión en la página dentro de su aplicación. Asegurarseque dicha página no requiere autenticación. 4) Establecer la propiedad del elemento emisor wsFederation dentro de la sección Microsoft.IdentityModel de su web.config a la página de inicio de sesión.

Answer 3

Lo que se quiere hacer es un signin activo. WIF incluye WSTrustChannel (de fábrica), que le permite comunicarse directamente con la STS y obtener un token de seguridad. Si desea que su formulario de acceso para trabajar de esta manera, se puede seguir el ejemplo "WSTrustChannel" de la WIF 4.0 SDK. Una vez que haya obtenido el token, el código siguiente se llevará a esa señal y llamar al manejador de WIF para crear un token de sesión y fijar la cookie correspondiente:

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 hecho esto, su sitio debe comportarse el mismo que si se hubiera producido la firma pasiva.

Answer 4

Se puede utilizar el control FederatedPassiveSignIn.

Answer 5

Configuración de la galleta de la siguiente manera: FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie (sessionToken); trabajo doens't para SSO a otros dominios.

Para la galleta debe ser fijado por la STS no en el RP.