Ignacio Cattivelli

Tamaño: px

Comenzar la demostración a partir de la página:

Download "Ignacio Cattivelli [email protected]"

Rocío Benítez Valenzuela
hace 10 años
Vistas:

1 Ignacio Cattivelli

2 Una identidad digital provee información sobre un sujeto Individuo Aplicación PC La identidad es representada por un token Constituido por un conjunto de Claims Incluye información sobre un sujeto

es representada por un token Constituido por un

3 Cada claim contiene un dato del sujeto No está limitado únicamente al nombre del mismo Los claims son validados por la aplicación que recibe el token

4 Los tipos de tokens más populares hoy en día son Token de usuario / password Ticket Kerberos Token SAML Certificados X.509 Esta realidad lleva a que los tokens puedan clasificarse en Tokens de formato fijo Tokens de formato variable

5 Token de usuario / password Contiene dos claims: el nombre de usuario y la contraseña del sujeto Es el tipo de token más usado hoy en día en Internet Ticket Kerberos Contiene el nombre del sujeto, su dominio, los grupos a los que pertenece, entre otros AD los genera de forma nativa Soportan delegación de identidad Certificados X.509 Contienen claims identificando el sujeto y la autoridad certificadora, entre otros

dominio, los grupos a los que pertenece, entre otros AD los genera de forma nativa Soportan delegación

6 Tokens SAML (Security Assertion Markup Language) Lenguaje de Markup basado en XML propuesto por el grupo OASIS Sus claims son agregados según las necesidades de la aplicación Gran flexibilidad al representar una identidad

OASIS Sus claims son agregados según las necesidades de

7 Toda identidad digital debe ser creada por un proveedor de identidades Es una autoridad confiada que realiza claims sobre un sujeto Incluye los claims en tokens provistos por una fuente de tokens Emiten tokens válidos para un alcance definido (identity scope)

un sujeto Incluye los claims en tokens provistos por una fuente

8 Algunos ejemplos Seguridad integrada de dominio Proveedor de identidades: La compañía Fuente de tokens: El servicio de directorios Alcance de la identidad: El dominio Windows Live ID Proveedor de identidades: Microsoft Fuente de tokens: Servicio de Windows Live ID Alcance de la identidad: Sitios Web de Microsoft Aplicación web con usuario / contraseña Proveedor de identidades: El usuario Fuente de tokens: El usuario Alcance de la identidad: La aplicación web

tokens: Servicio de Windows Live ID Alcance de la identidad: Sitios Web de Microsoft Aplicación web con usuario /

10 Una vez obtenida la identidad digital, la aplicación puede: Autenticar al usuario: Verificar que los claims sean provistos por un proveedor confiable Autorizar al usuario: Comparar su identidad con una ACL Obtener roles del token y usar RBAC Obtener las operaciones permitidas del token Conocer al usuario Obtener información del token para personalizar la aplicación al usuario

identidad con una ACL Obtener roles del token y usar RBAC Obtener las operaciones permitidas

11 Se sabe que una aplicación siempre será accedida por clientes dentro de un mismo dominio Aplicación basada en un dominio Se apoya sobre el servicio de directorios del dominio Ej: Active Directory Domain Services Usa tokens de formato fijo Ej: Tickets Kerberos Este tipo de aplicaciones es cada vez menos común

directorios del dominio Ej: Active Directory Domain Services Usa tokens de

13 En el modelo anterior se realizan consultas adicionales sobre el servicio de directorios Esto se podría mejorar en una aplicación basada en claims Para ello aparece Active Directory Federation Services En lugar de generar tickets Kerberos, se generan tokens SAML Estos tokens contienen todos los claims necesarios para la aplicación

aparece Active Directory Federation Services En lugar de generar tickets Kerberos,

15 Los claims obtenidos en la aplicación pueden contener Información de autorización para realizar ciertas operaciones Restricciones a las acciones que puede realizar el usuario Información de personalización Pertenencia a roles de aplicación (no necesariamente de dominio)

las acciones que puede realizar el usuario Información de

16 Los usuarios quieren acceder a aplicaciones que se encuentran fuera del alcance de la identidad Comunicación con un dominio que no implementa ADFS Opciones Replicar usuarios y roles en el dominio de la aplicación Federar identidades

con un dominio que no implementa ADFS Opciones Replicar

17 Por qué usar identidades federadas? Los usuarios acceden a todas las aplicaciones mediante single sign-on Los usuarios acceden a las aplicaciones desde diversos lugares Se reducen los costos de administración al no replicar identidades entre dominios No es necesario sincronizar las identidades de los diferentes dominios

usuarios acceden a las aplicaciones desde diversos lugares Se reducen los costos

20 Se apoya sobre la especificación WS- Federation El resource domain confía en el account domain ADFS puede agregar nuevos claims en el token según lo recibido La aplicación obtiene el resultado enriquecido por ADFS Es imprescindible para la federación que el formato de los tokens sea flexible

según lo recibido La aplicación obtiene el resultado enriquecido por

21 Especificación propuesta y apoyada por Microsoft, IBM, Oracle y otros. Define de forma genérica la forma en que deberían federarse las identidades Cuenta con dos perfiles Active Requestor profile Passive Requestor profile

22 FS-A STS (Security token service) - Account Confía en Tokens de FS-A FS-R STS (Security token service) - Resource Confía en tokens de FS-R Cliente Servicio Federado (FS) Account Domain Resource Domain

23 Passive Requestor Profile Cliente sin inteligencia Se basa en redirects enviados al browser Implementado por ADFS, etc. Limitado a aplicaciones web

24 Active Requestor Profile Cliente inteligente Se basa en WS-Trust

25 Una vez establecida la confianza, no se vuelven a realizar todas las operaciones para continuar realizando transacciones Se utiliza WS-SecureConversation con este fin Se confía en el cliente en el contexto de una sesión Similar al modelo de autenticación web

26 FS-A STS - Account RST FS-R STS - Resource RST RSTR RSTR Cliente activo Conversación Servicio Federado (FS)

27 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Documentos relacionados

Nuevos SKU s Project y Visio

Nuevos SKU s Project y Visio Manuel Cortizo [email protected] Project Lite Capacidades y licencias 1. Desde un punto de vista técnico, en el lanzamiento, Project Lite ofrecerá las mismas capacidades