SSO y Federación con SAML y Liberty

Taller de Sistemas de Información 3 - 2008 Federación de Identidades
Federación de Identidades
Abstract- Este documento analiza las posibles herramientas y

tecnologías que faciliten Single Singn on tanto a nivel web como a
nivel de Servicios.
Taller de Sistemas de Información 3 Página 1

Tabla de contenido
I. Problemática.......................................................................................................................... 3
II. Estándares ............................................................................................................................. 4
1. SAML................................................................................................................................ 4
Single Sign-On Web.............................................................................................................. 4
Federación de Identidad ........................................................................................................ 5
Arquitectura........................................................................................................................... 5
2. Liberty ............................................................................................................................... 8
Arquitectura........................................................................................................................... 8
III. Caso de estudio ............................................................................................................... 12
1. SAML.............................................................................................................................. 13
Escenario ............................................................................................................................. 13
2. ID-WSF ........................................................................................................................... 20
Escenario ............................................................................................................................. 20
Diagrama de Interacción ..................................................................................................... 21
IV. Conclusiones ................................................................................................................... 22
V. Referencias.......................................................................................................................... 22

I. Problemática
La identidad es un concepto que es muy utilizado actualmente en internet. Cada vez más
son los servicios que requieren que una persona se identifique para permitirle el ingreso
a la información. Para el usuario el hecho de estar constantemente teniéndose que
loguear a una página puede ser muy tedioso. Por otro lado en el caso de una
organización que posee varias aplicaciones web, puede llegar a ser muy costoso
mantener las identidades de los usuarios de forma independiente en todas las
aplicaciones.
Un grupo de compañías que poseen acuerdos de negocios entre si y a su vez comparten

la identidad de los usuarios de sus respectivas aplicaciones web forman lo que
llamaremos “Círculo de Confianza”. A partir de éste se introduce el concepto de
Federación de Identidades que le permite a estas compañías ponerse de acuerdo en
establecer un nombre de identificación único para referirse a un usuario. De este modo
es posible compartir la información del usuario entre los componentes de la federación.
Se dice que un usuario posee una “Identidad Federada” cuando las distintas partes
llegaron a un acuerdo en el cómo referirse al usuario, por lo que éste para navegar
entre las distintas aplicaciones que componen la federación solo necesita loguearse en
una de ellas, esto se conoce como “Single Sing-on”.
Lo dicho hasta el momento es a nivel de aplicaciones web, pero las aplicaciones en las
cuales vamos a enfocar nuestro estudio poseen una arquitectura de SOA, por lo que
pueden consumir servicios que en su mayoría requieren de la autenticación por parte de
la aplicación para acceder a la información de cierto usuario. Por lo que sería deseable
que se manejara una identidad única tanto a nivel web como a nivel de servicios.
Por lo tanto, lo que intentaremos debelar en los siguientes capítulos es la forma en que
se puede lograr dicha identidad única utilizando estándares como SAML e ID-WSF.
Primero se dará una visión general de los estándares mencionados anteriormente y
luego se verán dos casos de estudio de la aplicación de los mismos en la realidad.

II. Estándares
A continuación presentaremos una serie de estándares que nos permiten lograr la

identidad única anteriormente mencionada, ya sea a nivel web y/o a nivel de servicios.
1. SAML
La implementación de protocolos para la administración distribuida de la seguridad
(autenticación, autorización, etc.) requiere de un estándar que especifique los elementos
de seguridad requeridos y la forma en que estos son transmitidos en forma segura entre
los distintos componentes. Esta es la tarea que cumple el estándar SAML que se
encuentra actualmente en la versión 2.
SAML fue desarrollado tomando como base el problema del Single Sign-On entre
aplicaciones web. La solución que especifica SAML define la existencia de dos
componentes lógicos: un generador de información de seguridad y un consumidor,
también son llamados IDP (identity provider) y SP (service provider)
respectivamente.
Para comprender un poco más la problemática vamos a describir a continuación los dos
casos de uso principales que fueron la base para el desarrollo de SAML: Single Sign-On
Web y Federación de Identidad.
Single Sign-On Web
Sitio Web
de
GREATAIR
1
greatair.com
2
Sitio Web
de
BESTCARS
bestcars.com
Círculo de Confianza
Ilustración 1 – Ejemplo de sinlge sign-on utilizando SAML

En este caso el usuario ingresa al sitio web del la empresa GREATAIR y se
En este caso el usuario ingresa al sitio web del la empresa GREATAIR y se loguea.
Luego en forma transparente o no, el usuario es dirigido hacia el sitio web de

BESTCARS. En este caso se asume que ya existe una federación de identidades para el
usuario (es decir existe una asociación entre la identidades locales de forma que los
sistemas puedan referirse al usuario de forma unívoca). El IDP (greatair.com) envía junto
con la solicitud, información adicional (por ejemplo información sobre la identidad del
usuario) de forma que el SP (bestcars.com) pueda autorizar al usuario a acceder al
recurso solicitado sin que se requiera volver a autenticarlo.
Una variante de la situación descripta anteriormente se produce cuando el usuario no se

encuentra autenticado en el IDP y comienza la interacción desde el SP. En este caso el
usuario ingresa a bestcars.com y como no está autenticado se lo redirige al sitio
greatair.com junto con una solicitud de autenticación de SAML. En el IDP el usuario es
autenticado y se lo redirige nuevamente a bestcars.com junto con la información de
autenticación correspondiente.
Federación de Identidad
Veamos ahora utilizando como base el ejemplo anterior como se logra la federación de
identidad.
1. El usuario estando en el IDP tiene la posibilidad de federar su identidad local

con la del SP.
2. El usuario es redirigido al IDP.
3. El usuario se autentica con su cuenta local y el IDP genera un identificador

(seudónimo como se lo denomina en el estándar) que será utilizado únicamente
por el ID y el SP para referirse un forma unívoca al usuario.
4. El usuario es redirigido al IDP junto con el seudónimo.
5. El SP obtiene el seudónimo y busca el usuario correspondiente. Dado que es

una nueva federación, éste todavía no existe.
6. El usuario se autentica en el SP y se asocia el usuario local con el seudónimo.
Una vez completada la interacción se tiene una forma segura de relacionar los usuarios
entre los sistemas.
Arquitectura
El estándar SAML define cuatro conceptos fundamentales:
Assertions: los Assertions definen las afirmaciones de seguridad de una entidad dentro
de un sistema. Estas afirmaciones pueden ser de tres tipos. Los Authentication
statements indican simplemente que el usuario ha sido autenticado por alguna
aplicación. Los Attribute statements son más específicos e incluyen información sobre
los atributos del usuario (por ejemplo que un usuario pertenece a un determinado grupo
con más privilegios). Authorization decision statements son aun más específicos e
incluyen directamente los privilegios que posee el usuario (por ejemplo que un usuario
tenga permisos para comprar cierto producto).
Los Assertions y otros componentes del estándar se basan en XML lo que permite que
puedan ser utilizados en otros contextos. Por ejemplo WS-Security define un Security
Token que permite utilizar Assertions SAML para proteger los mensajes SOAP.

A continuación presentamos un ejemplo de un Assertion con un Authentication

statement y un Attribute statement:
<saml:Assertion
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z">
<saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
<ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
<saml:Subject>
<saml:NameID
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
3f7b3dcf-1674-4ecd-92c8-1544f346baf8
</saml:NameID>
</saml:Subject>
<saml:AuthnStatement
AuthnInstant="2004-12-05T09:22:00Z"
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute
xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
x500:Encoding="LDAP"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
FriendlyName="eduPersonAffiliation">
<saml:AttributeValue
xsi:type="xs:string">member</saml:AttributeValue>
<saml:AttributeValue
xsi:type="xs:string">staff</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
Protocols: para que SAML sea útil se requiere que además de definir un formato
estándar para los Assertions, se defina un mecanismo para el intercambio automático de
Assertions. Para esto el estándar define un conjunto de protocolos de pedido/respuesta
que permite la obtención de Assertions de un usuario.
SAML define los siguientes protocolos:
• Authentication Request Protocol
Cuando un SP tiene que autenticar a un usuario utiliza el protocolo

Authentication Request Protocol. Un ejemplo de un mensaje de solicitud de este
protocolo es el siguiente:
<samlp:AuthnRequest
Version="2.0"
IssueInstant="2004-12-05T09:21:59Z">
<saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>
<samlp:NameIDPolicy
AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</samlp:AuthnRequest>
La respuesta a este mensaje debe contener por lo menos un Authentication

statement y puede contener además uno o varios Attribute statements y
Authorization decision statements.

• Single Logout Protocol
Define la forma de realizar un logout simultáneo de las sesiones asociadas a un

usuario. El logout puede ser iniciado directamente por el usuario, o iniciado por
un IDP o SP debido a la expiración por tiempo o también por decisión de un
administrador.
• Assertion Query and Request Protocol
Define un conjunto de consultas por la cuales se pueden obtener Assertions

SAML. La forma de Request de este protocolo permite solicitar a un IDP un
Assertion haciendo refencia a su ID. La forma de Query define como solicitar
Assertions en base al usuario y el tipo de Assertion.
• Name Identifier Management Protocol
Provee mecanismos para cambiar el valor o formato del identificador usado

para referirse al usuario. El protocolo también define la forma de terminar una
asociación de la identidad del usuario entre el IDP y el SP.
• Name Identifier Mapping Protocol
Provee un mecanismo para poder mapear un identificador de usuario usado

entre un IDP y un SP de forma de obtener el utilizado entre el IDP y otro SP.
• Artifact Resolution Protocol
El protocolo Artifact Resolution Protocol básicamente permite que se puedan

transportar los Assertions por referencia (a esta referencia se le denomina
Artifact en el estándar) en vez de valor. Para lo cual este protocolo define como
obtener el Assertion dada la referencia. Esto facilita el uso en un ambiente web
porque permite la transmisión de Assertions por otros protocolos de transporte
aparte de HTTP.
Bindings: los dos conceptos anteriores están definidos como un esquema XML. Para
ser utilizados en la práctica se requiere de un mapeo a los distintos protocolos de
transporte utilizados (HTTP-GET, HTTP-POST, SOAP).
Profiles: Los protocolos y los bindings por si solos no permiten la interoperabilidad de

SAML. Los profiles definen la secuencia específica de mensajes y los bindings
requeridos en cada caso que se requieren para completar cada uno de los casos de uso
definidos en el estándar (por ejemplo SSO web).
Por cada combinación de caso de uso y binding se pueden obtener variaciones de un

mismo profile (no todas con posibilidad de utilizarse en la práctica). En el caso del
profile SSO Web, teniendo en cuenta también desde donde se inicia el proceso, se
obtienen tres variaciones:
• SSO iniciado por el SP con el binding Redirect/POST
• SSO iniciado por el SP con el binding POST/Artifact
• SSO iniciado por el IDP con el binding POST
Más adelante se describirá con más detalle la segunda variante en el contexto del
ejemplo que se llevó a la práctica.

2. Liberty
Arquitectura
A continuación veremos un esquema con los tres grandes módulos que forman la
arquitectura de Liberty. Los módulos de ID-FF y ID-WSF serán desarrollados en
secciones posteriores. En el punto 2 se muestran los estándares que Liberty adopta o
extiende, como es el caso de SAML que lo extiende con ID-FF.
Ilustración 2 – Arquitectura Liberty

a. ID-FF
EL estándar Liberty ID-FF permite la administración y federación de identidades, fue
construido a partir de la versión 1.0 de SAML. Este puede ser usado por si solo o en
conjunto con otras herramientas de administración. Este framework está diseñado para
trabajar con plataformas heterogéneas y con todo tipo de dispositivos de red, incluyendo
computadoras personales, teléfonos celulares, PDAs y otros dispositivos emergentes.
ID-FF incluye las siguientes características:
Opt-in Account Linking
Permite a usuarios con múltiples cuentas en diferentes sitios basados en Liberty,

linkear sus cuentas para futuras autenticaciones y sign-in en dichos sitios (por
ejemplo federación).
Simplified Sign-On
Permite a un usuario loguearse una vez a un sitio basado en Liberty

ID-FF y acceder a cualquier otro sitio (basado en Liberty) sin necesidad de
loguearse nuevamente.
Fundamental Session Management
Permite a compañías u organizaciones linkear cuentas para comunicar el tipo de

autenticación que debe de ser usado cuando un usuario inicia una sesión.
También hace posible el sing-out global, o sea que el usuario quede
automáticamente deslogueado de todos los sitios que componen la federación al
momento de cerrar la sesión en alguno de ellos.
Affiliations
Le permite a un usuario elegir si federarse a un grupo de sitios afiliados.
Anonymity
Le permite a un servicio solicitar ciertos atributos sin necesidad de saber la
identidad del usuario.
Protocol for the Real-time Discovery and Exchange of Meta Data

Para que los providers se puedan comunicar entre ellos necesitan previamente
haber obtenido cierta metadata como: certificados X.509 y service endpoints.
Esta característica de ID-FF facilita el intercambio en tiempo real de dicha
información.

b. Identity Web Services Framework (ID-WSF)

Liberty ID-WSF define un framework para crear, descubrir y consumir servicios de
identidad. Esto le permitirá a las distintas entidades ofrecer a los usuarios servicios más
valiosos y personalizados.
ARQUITECTURA
Ilustración 3 - Arquitectura ID-WSF
Terminologia y Conceptos
Actores/roles
Usuario – Una entidad del sistema cuya identidad fue autenticada. Normalmente es
sinónimo de “persona física”, pero también puede ser un grupo de personas o una
entidad organizacional como una corporación.
Identity Provider (IdP) – Es una entidad del sistema que se encarga del manejo de
la información de identidad y provee assertions para la autenticación de usuarios de
otros providers.
Service Provider (SP) – Es un sitio web o aplicación web que provee servicios a
usuarios que desean realizar operaciones de autenticación o almacenar atributos de
identidad.
Web Service Consumer (WSC) – Es una entidad del sistema que solicita cierta
información o acción de un web service. Service providers pueden llegar a actuar
como un WSC cuando requieren información que provee un servicio externo.
Web Service Provider (WSP) – Es una entidad del sistema que provee un web
service. Un SP actúa como un WSP cuando otras entidades desean obtener cierta
información de él.

Servicios
Discovery Service (DS) – Es un tipo especial de web service que permite a los
WSCs encontrar un WSP asociado a una identidad de usuario determinada. Como
primer paso se debe de registrar el web service en el DS. No solo le permite a un
WSC descubrir donde se encuentra localizado los diferentes atributos de identidad
del usuario, sino que le permite al WSC enviar un request a un WSP endpoint
incluyendo en el request un identity token determinado.
Identity Mapping Service (IMS) – Es un web service especial que permite el

mapeo de identificadores de usuario con los diferentes identificadores de los
distintos providers.
Interaction Service (IS) – Un web service especial, cuyo objetivo es facilitar la

comunicación entre un provider y el usuario de forma de obtener el permiso para
utilizar los atributos de identidad pertenecientes al usuario.
Authentication Service (AS) – Es un web service que soporta clientes con

habilidades especiales para participar activamente en un intercambio de mensajes de
web services basados en Liberty. El AS permite a los clientes basados en Liberty
autenticarse en un IdP para obtener el token que le permita hacer la llamada a un
WSP determinado.
Single Sign On Service (SSOS) – Es un web service que le permite a los clientes
basados en liberty realizar SSO con un SP de la misma manera que lo haría en un
browser(por medio de cookies).
Algunas de las principales características de ID-WSF son:
Permission Based Attribute Sharing
Esta característica permite a una compañía u organización ofrecer a sus usuarios

servicios personalizados basados en atributos y preferencias que el usuario eligió para
compartir. Distintos protocolos permiten que se produzca un diálogo entre un attribute
povider y un service provider para poder intercambiar información de los atributos.
Estos protocolos también son usados para obtener permisos por parte del usuario para
poder compartir su información y definir la forma de que esta será usada.
Identity Service Discovery
Para que un service provider pueda ofrecer el servicio de identidad al usuario, éste
debe de tener acceso a todas las porciones de información de identidad que se
encuentran distribuidas por múltiples providers. El service provider puede usar el
discovery service para localizar un servicio de identidad específico para un usuario.
Este último le permite a las entidades obtener de forma dinámica y segura la
descripción de un servicio de identidad de un determinado usuario.

Interaction Service
Un Identity Service puede llegar a necesitar el permiso del usuario para permitirle
compartir su información con los servicios que lo requieren. Éste define una serie de
protocolos y perfiles para interacciones que le permitan a los servicios llevar a cabo
dichas acciones.
Security Profiles
Esta especificación describe una serie de perfiles y requerimientos para asegurar que
el descubrimiento y uso de los Identity Services se realice de forma confiable y
segura. Esto incluye requerimientos de seguridad para proteger la privacidad, y
asegurar la integridad y confiabilidad de los mensajes que se intercambian entre los
service providers.
Simple Object Access Protocol (SOAP) Binding
El ID-WSF SOAP Binding provee a los identity services un framework para las
invocaciones basado en SOAP. Define un grupo de bloques de encabezados SOAP y
reglas de procesamiento que permite la invocación de identity services por medio de
SOAP requests y responses.
Extended Client Support
Esto permite el alojamiento web de identity services basados en Liberty sin requerir el
uso de un servidor http o poder ser direccionado vía IP desde Internet. Esto es
realmente útil ya que muchos dispositivos en la actualidad poseen un cliente http
pero no poseen la capacidad para tener un servidor http o una dirección IP propia.
III. Caso de estudio
Para poder entender mejor las especificaciones descriptas anteriormente vamos a

ilustrarlas con un ejemplo de aplicación de las mismas en la realidad. Vamos a ver dos
ejemplos, en el primero se mostrara un caso de federación de una identidad en dos
sistemas y single sing-on web utilizando SAML como su implementación en la
herramienta Opensso (este caso de estudio viene junto con dicha herramienta) y en el
segundo se mostrara una aplicación de Liberty ID-WSF en la realidad mostrando la
interacción entre sus principales componentes, este ejemplo fue extraído de la
especificación de ID-WSF.

1. SAML
A continuación veremos una descripción del escenario en el cual se detalla la interacción
del usuario.
Escenario
Los pasos a seguir para lograr la federación son los siguientes:
• El usuario ingresa a BestCars.COM (SP) y decide federar su identidad en este

sistema con la de GreatAir.com (IDP).
• El usuario se loguea en GreatAir.com (IDP) y luego en BestCars.COM (SP).
• De ahora en adelante el usuario puede acceder a los dos sistemas autenticándose

una única vez.
Una vez creada la federación los pasos para realizar single sing-on son:
• El usuario ingresa a BestCars.COM (SP) y decide realizar single sing-on con

GreatAir.com (IDP).
• Este se loguea en GrateAir.com quedando logueado en ambos sitios.
• El usuario reserva un vuelo en GrateAir.com y luego continúa con la reserva del

automóvil.
A continuación veremos cómo se puede llevar este ejemplo a la práctica utilizando

Opensso. Se asume que la herramienta se encuentra previamente configurada, para
obtener más información de dicha configuración ver [1].
En la siguiente imagen se observa la configuración que se realiza en el servidor que

desempeña el rol de IDP. En dicha configuración se especifica la referencia al SP por
medio del protocolo, host, puerto y nombre de aplicación.

Ilustración 4 – Configuración del IDP
Es importante destacar que hay que realizar la misma configuración del lado del SP.
También se puede configurar directamente desde la consola del OpenSSO utilizando el
concepto de Metadata definido en el estándar SAML.
Una vez realizada esta configuración se puede observar en la consola del OpenSSO
como se creó el círculo de confianza entre el IDP y el SP, esto se muestra en la siguiente
imagen:

Ilustración 5 – Configuración de círculo de confianza
A continuación se describe a partir del ejemplo como se lleva a cabo la interacción entre
el IDP y el SP para lograr el SSO Web. Se utilizara para ello el profile SSO iniciado por
el SP con el binding POST/Artifact, es decir el usuario ingresa inicialmente en el sitio
web del SP. La comunicación se realiza por HTTP-POST y los Assertions se obtienen
por comunicación directa entre el IDP y SP por medio de SOAP sobre HTTP.

Ilustración 6 - Pantalla principal del ejemplo
El usuario selecciona “Login, secure provided by GreatAir”. Este genera un pedido de

la siguiente forma al IDP:
GET /opensso/SSORedirect/metaAlias/idp?SAMLRequest=nVR 946 HTTP/1.1
El parámetro SAMLRequest contiene el mensaje Authentication Request Protocal

codificado como especifica la sección de Binding de SAML.
Dado que el usuario no se encuentra autenticado (en el IDP) se lo redirige a la página

de login.
Luego de haber efectuado el login, el usuario es redirigido a la página del SP donde es

nuevamente autenticado. Una vez que el usuario es autenticado en ambos sistemas se
crea la asociación que enlaza las dos identidades locales de forma que de ahora en más
si el usuario tiene una sesión en cualquiera de los dos sistemas, este podrá ingresar al
otro sin volver a autenticarse. En la siguiente imagen se muestra la pantalla a la cual es
dirigido el usuario luego del proceso de autenticación:

Ilustración 7 - Pantalla del ejemplo luego de realizar la federación de identidades
Como se mencionó anteriormente en este ejemplo se utilizo el binding POST/Artifact

por lo que los Assertions se intercambian por medio de una referencia. A continuación
se muestran los mensajes intercambiados para desreferenciar los Assertions.

<soap-env:Envelope>
<soap-env:Body>
<samlp:ArtifactResolve ID="s26...7af" IssueInstant="2008-07-22T01:03:03Z"
Destination="http://server1.tsi.com:8080/opensso/ArtifactResolver/metaAlias/idp">
<saml:Issuer>http://server2.tsi2.com:8080/opensso</saml:Issuer>
<samlp:Artifact>
AAQAAGHDmQF7wiDIE8NAeGCFnuj9TN/mN/0BCVzVZyAiOAKdk9CJXhn8MDE=
</samlp:Artifact>
</samlp:ArtifactResolve>
</soap-env:Body>
</soap-env:Envelope>
<soap-env:Envelope>
<soap-env:Body>
<samlp:ArtifactResponse ID="s2f...3d5" InResponseTo="s26...7af"
Destination="http://server2.tsi2.com:8080/opensso/Consumer/metaAlias/sp">
<saml:Issuer>http://server1.tsi.com:8080/opensso</saml:Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success">
</samlp:StatusCode>
</samlp:Status>
<samlp:Response ID="s23...f9f" InResponseTo="s23...946"
Destination="http://server2.tsi2.com:8080/opensso/Consumer/metaAlias/sp">
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success">
</samlp:StatusCode>
</samlp:Status>
<saml:Assertion ID="s24...048" IssueInstant="2008-07-22T01:03:03Z">
<saml:Subject>
<saml:NameID
1 NameQualifier="http://server1.tsi.com:8080/opensso"
SPNameQualifier="http://server2.tsi2.com:8080/opensso"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
F/OojycdHmFr3TYw3tXObNrVscDp
</saml:NameID>
<saml:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData
NotOnOrAfter="2008-07-22T01:13:03Z"
InResponseTo="s23090118c26cf8ed6cb8b79dd347ca738488a0946"
Recipient="http://server2.tsi2.com:8080/opensso/Consumer/metaAlias/sp" />
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions
NotBefore="2008-07-22T01:03:03Z"
NotOnOrAfter="2008-07-22T01:13:03Z">
<saml:AudienceRestriction>
<saml:Audience>
http://server2.tsi2.com:8080/opensso
</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2008-07-22T01:03:03Z"
2 SessionIndex="s2afece97f8bb7440609e82a18601d1bc593b52c01">
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
</saml:Assertion>
</samlp:Response>
</samlp:ArtifactResponse>
</soap-env:Body>
</soap-env:Envelope>

Se describen a continuación dos secciones importantes en el mensaje de respuesta:
1. Como mencionamos anteriormente la creación de una federación implica la

asociación de las identidades locales del usuario en los dos sistemas. Para ello
SAML define un identificador denominado seudónimo que es utilizado para hacer
referencia a la identidad del usuario. Dado que los identificadores son opacos se
requiere que estén calificados para hacerlos únicos globalmente. Para eso se
definen los atributos NameQualifier y SPNameQualifier. El uso de un seudónimo
tiene la consecuencia de mantener totalmente oculta la identidad del usuario para
un intruso que no tenga acceso al SP o al IDP. El atributo Format indica el tiempo
de vida del identificador, este puede ser persistente (hasta que se termine la
federación) o transitorio (solo por esa interacción).
2. En esta sección se observa una Authentication Statment asociado al usuario. Este

representa que el usuario ha sido autenticado por el IDP en el instante indicado.
Aquí se muestra además al uso de Authentication Contexts que permiten
especificar el método de autenticación realizado sobre el usuario, de forma de
poder realizar decisiones de autorización en base a la seguridad del método
empleado.
Por último resumimos la interacción entre los distintos componentes con el

siguiente diagrama :

2. ID-WSF
A continuación veremos una descripción del escenario en el cual se detalla la interacción
del usuario.
Escenario
Las cuentas se encuentran federadas entre sí utilizando Liberty ID-FF. Los

atributos de Joe Self se encuentran almacenados en BlueLiquor.COM (SP1),
este actúa como un Attribute Provider en el contexto de Liberty.
Joe Self ordena licores y pizzas on-line.
• Ingresa a BlueLiquor.COM, y hace click en el link single sign-on.
• Es redirigido a WhiteBroadBand.COM, y se autentica con su password.
• Es redirigido nuevamente a BlueLiquor.COM. Ésta última recibe un

SAML assertion de WhiteBroadBand.COM, esto significa que se
encuentra autenticado, y responde a Joe Self con la página de menú de
usuario.
• Ordena algunas cervezas on-line y éstas son llevadas a la dirección que se

encuentra registrada en BlueLiquor.COM.
• Solicita a BlueLiquor.COM que registre sus atributos personales que

posee en este sitio en el Discovery Service, de este modo estos quedan
accesibles desde otras aplicaciones
• BlueLiquor.COM envía un Discovery Update message al Discovery

Service.
Ilustración 8 - Diagrama del ejemplo
• Subsecuentemente accede a YellowPizza.COM. Al haber sido

autenticado por WhiteBroadBand.COM, YellowPizza.COM puede
obtener un SAML assertion de WhiteBroadBand.COM, y responde a
Joe Self con el menú principal.

• Ordena la pizza on-line.
• YellowPizza.COM pregunta donde enviar el pedido.
• Solicita a YellowPizza.COM que obtenga sus atributos personales de otro

sitio.
• YellowPizza.COM envía una solicitud al Discovery Service y obtiene el

ResourceOffering de BlueLiquor.COM.
• YellowPizza.COM realiza un Query a BlueLiquor.COM y obtiene la

información de Joe.
• YellowPizza.COM realiza el envío de pizza a la dirección que obtuvo de

BlueLiquor.COM.
Diagrama de Interacción
Ilustración 9 - Diagrama de secuencia del ejemplo

IV. Conclusiones
Con lo visto hasta el momento podemos afirmar que SAML resulta ser una
especificación satisfactoria para lograr Single Sing-on web entre diversas aplicaciones. A
esto le podemos agregar que ya se encuentran disponibles herramientas como Opensso
que nos facilitan la utilización de dicho estándar.
Por otro lado está el caso de la federación de identidades a nivel de servicio, para esta
problemática pudimos constatar que el estándar ID-WSF resuelve el problema pero no se
pudo llevar a la practica con la versión actual de Opensso. Quedaría como trabajo a futuro
lograr implementar una aplicación que utilice el estándar, en particular podría ser el caso
de estudio presentado.
A pesar de encontrar diversas complicaciones a la hora de configurar el Opensso,

podemos decir que la experiencia con dicha herramienta fue buena ya que se logro
implementar con la misma un ejemplo de Single Sing-on con SAML. Lamentablemente
no se logro llevar a la práctica un ejemplo de WSF ya que se encontraron diversos errores
que por falta de tiempo y la poca documentación de dichos ejemplos no se pudieron
resolver.
Por último como trabajos a futuro quedaría ver la posibilidad de utilizar estándares como
WS Trust y WS Federation para solucionar la problemática de la federación de
identidades, en particular a nivel de servicios; los mismos fueron manejados como
alternativas durante el desarrollo del proyecto pero decidimos profundizar en los
estándares presentados en este documento y no en éstos.
V. Referencias
[SAMLAuthnCxt] J. Kemp et al. Authentication Context for the OASIS Security
Assertion Markup Language (SAML) V2.0. OASIS SSTC, Marzo 2005. http://docs.oasis-
open.org/security/saml/v2.0/saml-authncontext-2.0-os.pdf.
[SAMLBind] S. Cantor et al. Bindings for the OASIS Security Assertion Markup
Language (SAML) V2.0. OASIS SSTC, Marzo 2005.
http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf.
[SAMLCore] S. Cantor et al. Assertions and Protocols for the OASIS Security Assertion
Markup Language (SAML) V2.0. OASIS SSTC, Marzo 2005.
http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf.
[SAMLExecOvr] P. Madsen, et al. SAML V2.0 Executive Overview. OASIS SSTC, Abril,
2005.
http://www.oasisopen.org/committees/security/.
[SAMLGloss] J. Hodges et al. Glossary for the OASIS Security Assertion Markup
http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf.
[SAMLMeta] S. Cantor et al. Metadata for the OASIS Security Assertion Markup
http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf.
[SAMLProf] S. Cantor et al. Profiles for the OASIS Security Assertion Markup Language
(SAML) V2.0. OASIS SSTC, Marzo 2005.

http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf.
[SAMLWeb] OASIS Security Services Technical Committee web site,

http://www.oasisopen.org/committees/security.
[WSS] A. Nadalin et al. Web Services Security: SOAP Message Security 1.1 (WS-
Security
2004). OASIS WSS-TC, Febrero 2006.
http://www.oasis-open.org/committees/wss/.
[WSSSAML] R. Monzillo et al. Web Services Security: SAML Token Profile 1.1. OASIS
WSS-TC, Febrero 2006.
http://www.oasis-open.org/committees/wss/.
[XMLEnc] D. Eastlake et al. XML Encryption Syntax and Processing. World Wide Web
Consortium.
http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/.
[XMLSig] D. Eastlake et al. XML-Signature Syntax and Processing. World Wide Web
Consortium.
http://www.w3.org/TR/xmldsig-core/.
[LibertyIDWSFGuide] Weitzel, David, eds. "Liberty ID-WSF Implementation Guide,"

Version 2.0-02, Liberty Alliance Project (13 January, 2005).
http://www.projectliberty.org/specs
[Opensso]
https://opensso.dev.java.net/
http://download.java.net/general/opensso/stable/openssov1-build4/B4-
ReleaseNotes.html [1]
[Liberty]
http://www.projectliberty.org/
[Ros04] Jothy Rosenberg, David L. Remy, Securing Web Services with WS-Security.

SSO y Federación con SAML y Liberty

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

SSO y Federación con SAML y Liberty

Cargado por

Copyright:

Formatos disponibles

Taller de Sistemas de Información 3 - 2008 Federación de Identidades

Abstract- Este documento analiza las posibles herramientas y

Taller de Sistemas de Información 3 Página 1

II. Estándares ............................................................................................................................. 4

Single Sign-On Web.............................................................................................................. 4

Federación de Identidad ........................................................................................................ 5

III. Caso de estudio ............................................................................................................... 12

Diagrama de Interacción ..................................................................................................... 21

IV. Conclusiones ................................................................................................................... 22

Taller de Sistemas de Información 3 Página 2

Un grupo de compañías que poseen acuerdos de negocios entre si y a su vez comparten

Taller de Sistemas de Información 3 Página 3

A continuación presentaremos una serie de estándares que nos permiten lograr la

Single Sign-On Web

Ilustración 1 – Ejemplo de sinlge sign-on utilizando SAML

Taller de Sistemas de Información 3 Página 4

Una variante de la situación descripta anteriormente se produce cuando el usuario no se

1. El usuario estando en el IDP tiene la posibilidad de federar su identidad local

2. El usuario es redirigido al IDP.

3. El usuario se autentica con su cuenta local y el IDP genera un identificador

4. El usuario es redirigido al IDP junto con el seudónimo.

5. El SP obtiene el seudónimo y busca el usuario correspondiente. Dado que es

6. El usuario se autentica en el SP y se asocia el usuario local con el seudónimo.

El estándar SAML define cuatro conceptos fundamentales:

Taller de Sistemas de Información 3 Página 5

A continuación presentamos un ejemplo de un Assertion con un Authentication

SAML define los siguientes protocolos:

• Authentication Request Protocol

Cuando un SP tiene que autenticar a un usuario utiliza el protocolo

La respuesta a este mensaje debe contener por lo menos un Authentication

Taller de Sistemas de Información 3 Página 6

• Single Logout Protocol

Define la forma de realizar un logout simultáneo de las sesiones asociadas a un

• Assertion Query and Request Protocol

Define un conjunto de consultas por la cuales se pueden obtener Assertions

• Name Identifier Management Protocol

Provee mecanismos para cambiar el valor o formato del identificador usado

• Name Identifier Mapping Protocol

Provee un mecanismo para poder mapear un identificador de usuario usado

• Artifact Resolution Protocol

El protocolo Artifact Resolution Protocol básicamente permite que se puedan

Profiles: Los protocolos y los bindings por si solos no permiten la interoperabilidad de

Por cada combinación de caso de uso y binding se pueden obtener variaciones de un

• SSO iniciado por el SP con el binding Redirect/POST

• SSO iniciado por el SP con el binding POST/Artifact

• SSO iniciado por el IDP con el binding POST

Taller de Sistemas de Información 3 Página 7

Ilustración 2 – Arquitectura Liberty

Taller de Sistemas de Información 3 Página 8

ID-FF incluye las siguientes características:

Opt-in Account Linking

Permite a usuarios con múltiples cuentas en diferentes sitios basados en Liberty,

Permite a un usuario loguearse una vez a un sitio basado en Liberty

Fundamental Session Management

Permite a compañías u organizaciones linkear cuentas para comunicar el tipo de

Protocol for the Real-time Discovery and Exchange of Meta Data

Taller de Sistemas de Información 3 Página 9

b. Identity Web Services Framework (ID-WSF)

Ilustración 3 - Arquitectura ID-WSF

Taller de Sistemas de Información 3 Página 10

Identity Mapping Service (IMS) – Es un web service especial que permite el

Interaction Service (IS) – Un web service especial, cuyo objetivo es facilitar la