WIF es sencillo, úsalo #3-3

En nuestra anterior entrada vimos como modificar el manejador de tokens de nuestro STS, de forma, que podíamos cambiar el sistema de autenticación de usarios dentro de este. De hecho, modificamos el STS generado por defecto con FedUtil introduciendo un UsernameSecurityTokenHandler personalizado. A lo largo de esta entrada, veremos algunos elementos particulares de nuestra configuración que no han sido tenidos en cuenta pero que también es importante entenderlos.

 

IssuerNameRegistry

Si leemos la documentación del SDK de WIF podemos ver a esta pieza como la responsable de rechazar los tokens de emisores inválidos, STS en los que no confiamos. Por defecto, las plantillas del asistente establecen un IssuerNameRegistry por defecto conocido como ConfigurationBasedIssuerNameRegistry que hace el mapeo y rechazo de los emisores en función del thumbprint del token ( certificado ) presentado. Como también se comenta en la documentación, este elemento debe de ser reemplazado en producción, creando un IssuerNameRegistry customizado

The <?XML:NAMESPACE PREFIX = [default] http://ddue.schemas.microsoft.com/authoring/2003/5 NS = «http://ddue.schemas.microsoft.com/authoring/2003/5» />IssuerNameRegistry class provides a name service that returns the issuer name of a given token. WIF provides a ConfigurationBasedIssuerNameRegistry to demonstrate an easy way to get started, but it is recommended that developers write a custom implementation that derives from the IssuerNameRegistry class.

Crear un nuevo issuer name registry es “tan sencillo o complicado” como crear una subclase de IssuerNameRegistry y sobreescribir el método GetIssuerName.

Si el valor devuelto por este método es nulo, entonces el sistema interpreta que este issuer no es admitido y por lo tanto no es posible aceptar tokens del mismo. Lógicamente, este trabajo requeriría en la realidad de disponer de un almacen configurable de issuers y propiedades de los mismos que pudiéramos configurar y administrar. Este trabajo, no lo haremos en este post ( igual en futuros …), solamente incluiremos una posible implementación “tonta” que devuelve el nombre del STS utilizado en los ejemplos.

 

 

AudienceUri

Si revisamos la configuración de nuestro RP veremos como la sección microsoft.identitymodel incluye dentro de ella un elemento llamado AudienceUris. Este elemento nos permite establecer una colección de elementos validos a los que se les aplica un toquen. Es decir, cuando un token es emitido este se establece o aplica para alguien, el RP que lo ha solicitado. Este token incluye una propiedad AppliesTo gracias a la cual podremos validar que el mismo se aplica al RP que tenemos. Por ello esta colección por defecto ya contiene la dirección del RP con el que estemos. Lógicamente, si esta información no es igual que la que trae el token se nos producirá una excepción de seguridad.

Federation Metadata

 

Otro de los elementos importantes cuando estamos trabajando con nuestros RP y STS es la información de metadata. Si recuerda de las primeras entradas, el asistente de WIF, FedUtil nos genera un nuevo STS y crea en el proyecto de este un archivo llamado FederationMetadata.xml. Este archivo, firmado por defecto con el asistente utilizando un certificado llamado STSCert nos permite exponer toda la información del STS, incluyendo en esta por ejemplo la información de los claims que este conoce y que puede enviar en los tokens de autenticación. Se podría decir que estos documentos son a la seguridad como el WSDL a los servicios. Como se imaginará, mantener estos documentos actualizados es una tarea vital, sobre todo si estos son nuestro contrato de relación con los RP. Por defecto, este trabajo no lo tenemos disponible de una forma sencilla, es decir, cuando creamos un STS el asistente nos genera el archivo de metadata y las entradas necesarios en el web.config para dejarlo accesible, sin embargo, si añadimos nuevas claims a nuestros tokens o bien cambiamos alguna configuración este archivo no se actualiza y por lo tanto podría darnos problemas. Lógicamente, como está firmado, trabajar a mano con este documento no es posible como se imaginará.

 

Para nuestra tarera de automatizar la generación dinámica de este archivo de metadata tenemos varias opciones, opciones que puede ver en este post. En realidad, cualquiera de las dos opciones es buena, la primera, la habitual de Vittorio Bertocci es la de disponer de un servicio WCF REST que genere esta metadata al vuelo, algo parecido al código siguiente. Tenga en cuenta que este código es “codigo demo” y por lo tanto no valdría directamente para producción ya que fija direcciones del STS, del login pasivo, del certificado a usar y hasta de las claims a emitir, no obstante, es una buena base para empezar a adaptar en caso de querer disponer de este sistema.

 

Una alternativa a la creación de un servicio WCF REST es la de crear un IHttpHandler que responda a una dirección, generalmente a algo como 2007-07/FederationMetadata.xml que genere, con un código similar al anterior, la información de metadata.

 

Con esto acabamos esta corta entrada, en capítulos siguientes veremos algunos elementos más avanzados como REALM,ActAs etc.. para despues pasar a elementos pasivos como ASP.NET y ASP.NET MVC….. hasta la siguiente

 

Saludos

Unai

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *