Mes: mayo 2011

En la última entrada del blog me hacía eco de la publicación de la primera CTP de EF 4.1 Power Tools, en esta entrada se mostró como a partir de una modelo de entidades y una unidad de trabajo de tipo DbContext podríamos generar un fichero EDM ( de solo lectura ) que nos permitera ver, de una forma gráfica, el modelo de entidades con el que estamos trabajando.Realmente, esto no es una novedad demasiado importante, puesto que, esto mismo, lo podemos hacer ahora mismo con unas pequeñas lineaas de código, gracias a una de esas nuevas clases incorporadas en EF 4.1, llamada EDMXWriter.

 

El uso, sería algo tan sencillo como lo siguiente:

Para el caso del modelo ( SampleUnitOfWork con entidades Customer y Order) obtendríamos un EDMX como se puede apreciar  en la siguiente imagen, fíjese como también se agrega la entidad EdmMetadata.

 

 

 

 

Saludos

Unai

Lo tengo que decir y la verdad es que no me lo creo, si hace “cuatro dias” que ha salido EF 4.1, y yo mi libro sobre el tema , ahora resulta que vamos a tener unas Power Tools ¿?¿?… Por lo que se cuenta en el post de esta noticia esta primera CTP contendrá elementos referidos sobre todo a la integración de Code First con Visual Studio. De entre las novedades podemos ver algunas interesantes como:

 

• Reverse Engineer: Gracias a la cual con una entrada en nuestro menu contextual podremos hacer “ingeniería inversa” de una base de datos e incorporar en nuestro proyecto clases y sus correspondientes mapeos ( usando el api fluent) que representen a esta base de datos. (Si quieres ampliar la información vete al post original )
• View Entity Data Model: Permite obtener un EDMX de solo lectura que representa al modelo Code First, simplemente por ayuda a ver esta representación de forma visual.
• View Entity Data Model XML y DDL SQL: Nos permite ver el XML del EDMX “asociado” y la vista DDL de la base de datos con la que nuestro DbContext intenta trabajar.
• Optimize Entity Data Model: Permite “pre-generar” las vistas del modelo, sobre esto se ha hablado ya en este blog en distintos performance tips….

 

Saludos

Unai

 

Aunque relativamente hace poco que se publicaba mi libro sobre ADO.NET EF 4.0, ya se dejaba claro, tanto en el libro como en algún post, que cuando la versión final de EF 4.1 estuviera lista se incluiría en el un pequeño apéndice con las novedades que este “agregado” incluyera. Poco a poco, esta idea quedaba claro que sería relativamente dificil de hacer, puesto que, el tamaño del apéndice estaba siendo “excesivamente grande” para el propósito que un apéndice tiene. Después de revisar con el editor las distintas posiblidades que teníamos, acordamos hacer una “segunda edición del libro” incluyendo un capítulo de unas 100 páginas aproximadamente sobre EF 4.1. Puesto que este cambio, con esta gran cantidad nueva de páginas, hacia muy dificil etiquetar la versión como simplemente una nueva edición, decididimos hacer una nueva “version” modificando incluso la carátula del mismo para dejar claro el cambio, incluyendo por supuesto un nuevo ISBN.

Lógicamente, los que hayais comprando el libro anterior os estaréis haciendo la pregunta de “ ¿y ahora que, tengo que comprarme un libro nuevo para acceder al contenido nuevo?, que faena ”. Pues  bien, tal y como ya había adelantado en algunos post, para todos los compradores ( ojo, una cosa es disponer del libro, regalado en algún evento por ejemplo, y otra haberlo comprado) habrá un cupón especial que les permitirá acceder a un PDF con el contenido extra por la cantidad de 3 € .  Acceder a este precio se hará directamente por medio de una comunicación del editor con vosotros, os enviará, a todos los compradores, un correo con las instrucciones precisas.Para todos aquellos que no tengais la edición anterior, o bien fuera un regado, el contenido extra estará disponible por 10 € , cantidad que considero más que aceptable ( 10 céntimos por página ) aunque no sean los 5 € de los que hablaba Jose Manuel Alarcón en un de sus últimos post.

Para terminar, queda hablar de los precios del nuevo libro entero como tal, en este caso, la edición en papel tendrá el precio de 45 € y en su edición digital en 30 €.

Bueno, sin más un saludo y, si tenéis algún comentario, no dudeis en dejarlo..

 

Unai Zorrilla Castro

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

 

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.