WIF es sencillo, úsalo #3-2

 

En la anterior entrada hemos visto como usar WIF para configurar un servicio WCF que delegue todo el proceso de authenticación de los usarios conectados a este servicio.  En este sencillo ejemplo, no nos preocupamos de ningún tipo de configuración, dejando los parametros por defecto,  de los generados por el asistente  FedUtil. A lo  largo de esta entrada, veremos como modificar algunos elementos habituales en nuestros Security Token Service.  Para ello, partiremos del ejemplo entregado en la entrada 3-1 y sobre él haremos todo el trabajo.

Modificación de la autenticación

Una de las cosas más habituales en cuanto a la configuración de un STS ( lógicamente si este hace las tareas de un Identity Provider) es el cambio del mecanismo de autenticación. Por defecto, cuando creamos un STS por medio de nuestro asistente este nos presenta la configuración por defecto, delegando la autenticación de los tokens en un manejador llamado WindowsUserNameSecurityTokenHandler. Si no queremos utilizar las credenciales Windows como mecanismo de validación de los usuarios tenemos que modificar el “handler” asociado. Esta tarea, requiere de varios pasos, en primer lugar, modificar el binding asociado al endpoint que por defecto presenta el siguiente aspecto.

 

Aunque pueda pensar que nuestro trabajo consiste en delegar en WCF y sus enlaces todo el proceso, en realidad, WIF, puentea toda la infraestructura para delegar el trabajo en su propio stack. Si queremos establecer una autenticación en base a usuario y contraseña, por ejemplo, tendríamos que modificar la configuración anterior incluyendo el atributo clientCredentialType=”UserName”.

 

Una vez hecho esto, procederemos a indicarle a WIF cual será el manejador de los tokens que lleguen a nuestro STS, para ello, incluiremos la sección de configuración personalizada Microsoft.IdentityModel y estableceremos un “handler” concreto.

 

Fíjese como en esta sección se ha quitado el manejador encantado de “manejar” identidades windows por un nuevo manejador llamado CustomTokenHandler. Todos estos “manejadores” están incluído dentro de la jerarquía que impone SecurityTokenHandler y que por defecto ,podemos ver en la siguiente imagen extraída de reflector.

 

 

 

 

 

Cada uno de los handlers de esta jerarquía nos servirán como base para los distintos mecanismos de autenticación, usuario, kerberos, certificados, tokens saml11 o saml2 etc… Como nuestro propósito es crear un manejador para credenciales de tipo usuario/contraseña tendremos que hacer una implementación personalizada de la clase UserNameSecurityTokenHandler.

Crear un manejador de tokens de seguridad es tan sencillo como sobreescribir dos elementos, una propiedad llamada CanValidateToken y un método de validación de tokens ValidateToken. El siguiente fragmento de código nos muestra una posible implementación de un token de seguridad, lógicamente, es un ejemplo sencillo y no se hace la validación de los tokens contra ningún almacen, dejamos para usted, amigo lector, esta tarea.

 

 

Con estos pasos, ya tenemos modificado nuestro sistema de autenticación, aunque nos falta un pequeño paso. Este consiste en incluir el certificado a usar para la encriptación de los datos incluidos en el mensaje de validación (user/pwd) igual que con cualquier servicio WCF. Para ello, simplemente incluiremos dentro de nuestro comportamiento una entrada ServiceCredentials.

Ahora ya tenemos todo el trabajo realizado, solamente nos quedará actualizar nuestros clientes para actualizar la configuración de los enlaces hacia nuestros STS. Desde esta dirección de Sky Drive podrá descargarse el ejemplo modificado, lógicamente tendrá que actualizar la información refererida a los certificados.