En nuestra anterior entrega empezamos describiendo los motivos de la entrada en juego de WIF y de cuales son las principales preguntas a las que tenemos que dar respuesta, a lo largo de esta segunda entrada, trataremos de poner de manifiesto algunos conceptos que es necesario entender/comprender  así como los elementos de trabajo que tendremos..

 

Algunos conceptos para empezar..

 

Dentro del escenario planteado en la entrada anterior podemos observar distintos conceptos como los siguientes:

 

• Security Token Service

 

 

 

Un Security Token Service, más comunmente llamado STS, se encarga, a grosso modo, de entregarnos, una vez autenticados, un token des seguridad (security token). Para realizar esta tarea, disponemos de un protoco estándard que tanto .NET como otras tecnologías podrían implementar. Este protocolo, se conoce como WS-Trust y sobre su versión 1.3 puede obtener más información aquí, Windows Identity Foundation implementa este protocolo por medio de un servicio WCF cuyo contrato, IWSTrust13SyncContract, está definido en Microsoft.IdentityModel.Protocols.WSTrust. Realmente WS-Trust es un protocolo que funciona con paquetes SOAP por lo tanto aquellos elementos que quieran interactuar con el para, emitir, renovar o cancelar un token tendrán que entender  SOAP. A estos clientes, generalmente se les conoce como Clientes Activos. Lógicamente, hay escenarios dónde los clientes que necesiten un token de seguridad no entienden SOAP, por ejemplo un navegador web y html, para estos escenarios, hay un conjunto de recetas que tenemos disponibles para solventar el problema, este conjunto de recetas se conoce como WS-Federation, y sobre esto puede obtener más información en el siguiente enlace.

 

• Security Token

 

 

 

Acabamos de hablar del encargado de emitir, renovar o cancelar tokens de seguridad así como de los protocolos que usa pero ¿qué es un token de seguridad?  Un token de seguridad no es más que un conjunto de claims (aserciones, afirmaciones) que representan atributos de una entidad, por ejemplo el nombre, la edad, el correo electrónico, cualquier cosa en definitiva ( lógicamente existe un conjunto de claims comunes como name,role, action etc, pero nosotros podemos definir nuestras propias claims). Como es de esperar, este contenido de claims está securizado por medio de una firma digital que garantice que en el proceso de emisión y recepción nadie pueda tocar este elemento. La definición de este elemento se hace por medio de un lenguaje XML conocido como SAML ( Security Assertion Markup Language ).

 

• Relaying Party

 

 

 

Una Relying Party no es má que aquella aplicación o servicio que tiene externalizado el proceso de autenticación en un Security Token Service. Hablando de lo que nosotros conocemos sería cualquier aplicación ASP.NET o Servicio WCF que delega su proceso de autenticación en un STS con un proveedor de identidad determinado

 

 

 

Con estas pequeñas y someras definiciones ya nos hemos adentrado en la mayoría de los conceptos que tenemos que entender dentro de la seguridad orientada a claims. En las siguientes entradas, veremos como mapear todo esto con ejemplo de código, tanto para clientes activos como para clientes pasivos.

 

 

Saludos

Unai