Post on 07-Jul-2020
Creación de Federación de Iden-dad para las Redes Académicas Camila Santos Analista em TIC – RNP
Iden/ty Management Workshop (CHAINREDS-‐ELCIRA) Cancún, México Mayo/2014
• Analista en TIC de RNP (Brasil) • Ingeniera informá-ca por la UNICAMP (Brasil), especialista en
ingeniería de redes y sistemas de telecomunicaciones • Cer-ficada ISO 20000 y ITIL v3 • Trabaja con el equipo de ges-ón de servicios en RNP desde
2009, y en federaciones de iden-dad desde 2010 • Miembro del Comité Técnico de Ges-ón de Iden-dad en
Brasil
Camila Santos
• Federaciones de iden-dad • Elementos y conceptos de una federación • Cómo funciona una federación • Definición de polí-cas • Definición del esquema • Proveedores de iden-dad y de servicio • Discovery Service • Cer-ficados • Metadatos de la federación • Ges-ón de iden-dad
Índice
• El problema de cuentas de usuario versus acceso académico a servicios
― En ambientes académicos es posible encontrar los siguientes escenarios: ― Sistemas que solo pueden ser u-lizados dentro de la red
de la ins-tución
― Sistemas que solo pueden ser u-lizados por usuarios específicos
Federaciones de iden/dad
• El problema de cuentas de usuario versus acceso académico a servicios
― En ambientes académicos es posible encontrar los siguientes escenarios: ― Sistemas que solo pueden ser u-lizados dentro de la red
de la ins-tución
― Sistemas que solo pueden ser u-lizados por usuarios específicos
Federaciones de iden/dad
Poco cómodo
Nuevas cuentas de usuario
• Hay posibilidades… ― U/lización de proxy para acceso remoto a servicios
§ Puede exigir conocimiento técnico del usuario § Mayor trabajo del equipo de soporte
― Una cuenta para cada servicio, por usuario § El usuario debe acordarse de muchos nombres y
contraseñas § El administrador debe definir diferentes permisos para
cada cuenta de cada usuario ― Cuenta única para departamentos o para clases de usuarios
§ No hay como diferenciar los derechos de un usuario § No hay como hacer una auditoria
Federaciones de iden/dad
• … o se puede u/lizar una federación • ¿Qué es? ― Red de confianza en que cada ins/tución es responsable por
realizar la auten/cación y proveer informaciones sobre sus usuarios hasta servicios autorizados
― Sus conceptos están basados en una infraestructura de auten/cación y autorización, que permite a los usuarios que mantengan todos sus atributos en la ins/tución de origen y acceder a los recursos ofrecidos por la federación
― Los servicios de la federación deben estar basados en las relaciones de confianza definidas por la RNIE
Federaciones de iden/dad
• Beneficios para la creación de federaciones – para quién accede ― Acceso a recursos y servicios restrictos al ambiente
académico de fuera de la red de la ins/tución y sin necesidad de un proxy
― Una única iden/dad sirve como pasaporte para los servicios académicos y para los servicios federados
― Seguridad en el envío de informaciones y reconocimiento del usuario
― Single Sign-‐on (SSO)
Federaciones de iden/dad
• Beneficios para la creación de federaciones – para quién provee ― Controle de acceso y garan_a de iden/dad de los usuarios ― Adopción creciente por ins/tuciones en todo el mundo ― No necesita mantener cuentas de usuario ― Menor cuesto de manutención del servicio
Federaciones de iden/dad
• Federaciones existentes actualmente #Austria - ACOnet#Australia - AAF#Bélgica - Belnet#Brasil - CAFe#Canadá - CAF#Suiza - SWITCHaai#Chile - COFRe#República Checa – eduID.cz#Alemania - DFN-AAI#Dinamarca - WAYF#Estonia - TAAT#España - SIR#
Finlandia - Haka#Francia - Fédération Éducation-Recherche#Grecia - GRNET#Croacia - AAI@EduHr###Hungría - eduID.hu#Irlanda - Edugate#Italia - IDEM#Japón - GakuNin#Letonia – LAIFE#Holanda - SURFfederatie#Noruega - FEIDE#Nueva Zelanda - Tuakiri New Zealand Access Federation#Portugal - RCTSaai#Suecia - SWAMID#Eslovaquia - ArnesAAI Slovenska #Reino Unido - UK Access Management Federation for Education and Research#Estados Unidos - InCommon#Internacional - IGTF#
#
30 federaciones, más 11 federaciones piloto#
Federaciones de iden/dad
• REFEDS -‐ Research and Educa/on Federa/ons ― Tiene por obje/vo el cambio de procesos, prác/cas y
polí/cas entre federaciones de iden/dad, y también de favorecer la discusión de modos de facilitar la interacción entre federaciones
― REFEDS man/ene una lista de todas las federaciones que trabajan asociadas a ins/tuciones de enseñanza y inves/gación
Federaciones de iden/dad
• REFEDS – Discovery Guide ― Una documentación publicada por REFEDS es el Discovery
Guide, un guía sobre como presentar la iden/dad federada a sus usuarios, buenas prác/cas en federaciones y ejemplos de como tener una buena experiencia de u/lización
hap://discovery.refeds.org/
Federaciones de iden/dad
• REFEDS – Mejores prác/cas en el Discovery Guide
Federaciones de iden/dad
Dónde el usuario debe auten/carse
• REFEDS – Mejores prác/cas en el Discovery Guide
Federaciones de iden/dad
Cómo presentar auten/caciones locales
• REFEDS – Mejores prác/cas en el Discovery Guide
Federaciones de iden/dad
U/lización de un Discovery Service
• REFEDS – Mejores prác/cas en el Discovery Guide
Federaciones de iden/dad
Opciones para los usuarios
• REFEDS – Mejores prác/cas en el Discovery Guide ― Basado en el modelo definido por Espresso: Establishing
Suggested Prac/ces Regarding Single Sign-‐On
Federaciones de iden/dad
hap://www.niso.org/workrooms/sso
• Single Sign-‐on (SSO) ― Mecanismo que posibilita que un usuario pueda acceder a
múl/plos servicios con una única acción de auten/cación ― Mientras el token de auten/cación sea válido, el usuario no
tendrá que se auten/car de nuevo en cualquier servicio de la federación
― U/lización de las credenciales académicas para acceso a todos los servicios de la federación
― Asociación con la base de datos académica a través de un LDAP
― Definición de esquemas para uniformizar la comunicación y el cambio de atributos
Elementos y conceptos de una federación
• Single Sign-‐on (SSO): herramientas open-‐source más u/lizadas en federaciones académicas
Elementos y conceptos de una federación
• Proveedor de iden/dad (IdP) ― Elemento que realiza la auten/cación del usuario y fornece
sus atributos al servicio ― Fornece un token de auten/cación al servicio, conteniendo
informaciones del usuario (atributos) ― Integrase con el sistema de auten/cación ins/tucional para
proveer auten/cación y atributos a un servicio
Elementos y conceptos de una federación
• Proveedor de iden/dad (IdP) ― Elemento que realiza la auten/cación del usuario y
fornece sus atributos al servicio
― Fornece un token de auten/cación al servicio, conteniendo informaciones del usuario (atributos)
― Integrase con el sistema de auten/cación ins/tucional para proveer auten/cación y atributos a un servicio
Elementos y conceptos de una federación
• Proveedor de iden/dad: ejemplos ― Proveedor de una RNIE: RNP, InCommon, REUNA ― Proveedor de una universidad: USP, INICTEL, PUC ― Proveedor de otras ins/tuciones de enseñanza e inves/gación:
ministerios, museos, laboratorios, centros de inves/gación, …
Elementos y conceptos de una federación
• LDAP (Lightweight Directory Access Protocol) ― Protocolo para gerenciamiento de directórios, basado
en TCP/IP ― Acceso a informaciones a través de busca en árbol por
los registros
Elementos y conceptos de una federación
• Directorio de usuarios en LDAP ― Directorio que man/ene las credenciales de auten/cación y
de los atributos de cada usuario ― Es consultado por el IdP para realizar la auten/cación
Elementos y conceptos de una federación
• Proveedor de servicios ― Representa un servicio que puede ser u/lizado por los
miembros de una federación ― Después de recibir los atributos de un usuario, enviado por
su IdP, puede hacer su autorización para uso del servicio ― Puede también restringir el acceso del usuario a recursos de
acuerdo con los atributos recibidos
Elementos y conceptos de una federación
• Proveedor de servicios: ejemplos ― Sistemas académicos, bibliotecas online de universidades,
repositorios y si/os de publicaciones ― Compra de libros y sofware con beneficios a miembros de
ins/tuciones ― Almacenamiento y cambio de archivos
Elementos y conceptos de una federación
• Discovery Service (WAYF) ― Servicio para descubierta de la ins/tución de origen del
usuario ― El usuario es direccionado a la página de auten/cación de su
ins/tución
Elementos y conceptos de una federación
• Discovery Service: ejemplos ― Embedded Discovery Service (Shibboleth)
Elementos y conceptos de una federación
• Discovery Service: ejemplos ― Embedded Discovery Service ― DiscoJuice (UNINETT)
Elementos y conceptos de una federación
• La interconexión de todas las en/dades
Elementos y conceptos de una federación
Fuente: SWITCH AAI-‐Federa-on
Cómo funciona una federación
Institución d e l usuario
Requisición/Respuesta HTTP Redireccionamiento HTTP Conexión servidor/servidor
Fuente: ESR-‐RNP
Cómo funciona una federación
Institución d e l usuario
Requisición/Respuesta HTTP Redireccionamiento HTTP Conexión servidor/servidor
Fuente: ESR-‐RNP
Cómo funciona una federación
Institución d e l usuario
Conexión servidor/servidor Redireccionamiento HTTP Requisición/Respuesta HTTP
Fuente: ESR-‐RNP
Credenciales
Cómo funciona una federación
Institución d e l usuario
Fuente: ESR-‐RNP
Credenciales
Requisición/Respuesta HTTP Redireccionamiento HTTP Conexión servidor/servidor
• Demostración de auten/cación y autorización – Portal de periódicos CAPES
Cómo funciona una federación
• Demostración de auten/cación y autorización – Portal CAPES
Cómo funciona una federación
Auten/cación local
• Demostración de auten/cación y autorización – Portal CAPES
Cómo funciona una federación
Auten/cación federada
• Servicio de teste de atributos
Cómo funciona una federación
U/lizado por el Portal de Periódicos CAPES
• Comunicación entre los elementos ― SAML (Security Asser/on Markup Language): Padrón
que describe los mensajes XML enviados e recibidos por los elementos de la federación
― Estos mensajes posibilitan el cambio de datos para auten/cación y autorización entre productores y consumidores de aserciones
Cómo funciona una federación
• ¿Qué es una polí/ca? ― Definición de las reglas de una federación: cómo
adherir, cómo salir, obligaciones y derechos de los miembros y de la federación, etc.
― Documento formal que define los acuerdos entre los miembros de una federación y de ellos con la propia federación
― Debe garan/r que la u/lización de los servicios no viole las reglas definidas por la RNIE o mismo por el país del usuario
Definición de polí/cas
• Modelos de documentos de polí/cas (inglés) ― Iden/ty Federa/on Policy: template document
Definición de polí/cas
Fuente: Iden-ty Federa-on Policy: template document
• Modelos de documentos de polí/cas (inglés) ― Iden/ty Federa/on Policy: template document
Definición de polí/cas
Fuente: Iden-ty Federa-on Policy: template document
• Modelos de documentos de polí/cas (inglés) ― Iden/ty Federa/on Policy: template document (REFEDS
Wiki)
Definición de polí/cas
Fuente: h^ps://refeds.terena.org/index.php/Iden-ty_Federa-on_Policy_-‐_template_document
Ya compa/ble com eduGAIN!
• Modelos de documentos de polí/cas (inglés) ― Iden/ty Federa/on Policy: template document -‐
hap://www.terena.org/ac/vi/es/eurocamp/oct12/slides/Iden/ty%20Federa/on%20Policy%20Template%20v0.4.pdf
― Iden/ty Federa/on Policy: template document (REFEDS Wiki) -‐ haps://refeds.terena.org/index.php/Iden/ty_Federa/on_Policy_-‐_template_document
Definición de polí/cas
• ¿Qué es un esquema? ― Colección de atributos que pueden calificar un objeto
― Definición del nombre y formato de los atributos
― Cada atributo debe tener un OID (Object Iden8fier) asociado, ya definido, caso sea un atributo existente, o atribuido dentro de un registro definido para la ins/tución
― Informaciones sobre el registro de atributos: hap://www.oid-‐info.com/faq.htm
Definición del esquema
• Dependencia de los esquemas ― Ya existen esquemas definidos para algunos objetos:
personas, organizaciones, eventos, etc.
― Se hay la necesitad, se puede registrar un nuevo esquema, conteniendo atributos que no aún existen y que pueden ser u/lizados por su federación
― En 2001, Internet2 creó la primera versión de el esquema eduPerson, para u/lización dentro del ámbito académico
Definición del esquema
• Personalizaciones del eduPerson ― brEduPerson (Brasil) ― swissEduPerson (Suiza) ― auEduPerson (Australia) ― … y otras
― Existen también las federaciones que u/lizan solo esquemas ya definidos, sin personalizaciones
― Esta es una de las definiciones a se hacer en el proyecto de la federación
Definición del esquema
• Esquemas más usados: ― person: hap://schema.org/Person ― eduPerson:
hap://middleware.internet2.edu/eduperson/docs/internet2-‐mace-‐dir-‐eduperson-‐201203.html
― inetOrgPerson: hap://www.ier.org/rfc/rfc2798.txt
― SCHAC: hap://www.terena.org/ac/vi/es/r-‐emc2/docs/schac/schac-‐20061212-‐1.3.0.schema.txt
• U/lización de esquemas por federación: ― haps://refeds.terena.org/index.php/
Federa/onSchema
Definición del esquema
• Proveedores de servicio (SP): en/dades que prestan algún /po de servicio para algunos o todos los miembros de una federación
• Después que se hace la auten/cación de un usuario, el SP puede definir diferentes perfiles de acceso, que cambian de acuerdo con las informaciones recibidas sobre el usuario ― Un sistema de atribución y visualización de calificaciones de
alumnos en una universidad ― Un portal de publicaciones en que diferentes ins/tuciones
pueden tener diferentes acuerdos de permisos para sus miembros
Proveedores de iden/dad y de servicio
• Proveedores de iden/dad (IdP): en/dades dónde están almacenadas las informaciones de acceso de un usuario a la federación y sus atributos
• Es a quien el proveedor de servicios envía las credenciales digitadas por el usuario que intenta hacer una auten/cación
• Es también quién realiza la auten/cación del usuario
• Si la auten/cación es bien sucedida, envía el token de auten/cación y los atributos del usuario al proveedor de servicios
Proveedores de iden/dad y de servicio
• Los proveedores de iden/dad y de servicios son definidos en la federación por medio de los metadatos, un archivo XML que con/ene las informaciones que posibilitan la auten/cación y el cambio de atributos
Proveedores de iden/dad y de servicio
• Estructuras principales en el archivo de metadatos (Shibboleth 2.X): ― En88esDescriptor: es el descriptor de una en/dad o de un
grupo de en/dades. Ejemplo: un archivo de metadatos, un SP o un IdP
― Role descriptors: describen el rol de la en/dad que está siendo descripta. Roles importantes son <md:IDPSSODescriptor> y <md:AaributeAuthorityDescriptor> cuándo la en/dad en cues/ón es un IdP, y <md:SPSSODescriptor> para un SP
― Contact person: describe las informaciones de contacto del responsable por una en/dad. Esta es la persona que debe ser contactada en caso de problemas de auten/cación a un servicio específico
Proveedores de iden/dad y de servicio
• Tiene por obje/vo posibilitar que el usuario informe al proveedor de servicios su ins/tución de origen
• Se puede u/lizar de dos modos ― Centralizado ― A par/r del SP
Discovery Service
• DS centralizado ― Está dentro de la federación, con acceso a su archivo de
metadatos ― Busca informaciones sobre las ins/tuciones en los
metadatos de la federación y al ofrece al usuario las opciones de ins/tución
― El SP debe enviar el usuario a la página del DS de la federación para descubrir la ins/tución del usuario
Discovery Service
• DS a par/r del SP ― Está en uno de los SPs de la federación. El SP busca en
su instancia del archivo de metadatos las opciones posibles de IdPs y las presenta al usuario
― El modelo u/lizado para el Discovery Service puede ser elegido por la federación o por el proveedor de servicio
Discovery Service
• Para garan/zar la confiabilidad y permi/r la iden/ficación de en/dades, se puede u/lizar la criptograya de llave pública para firmar los metadatos
• Así, los cer/ficados u/lizados en las en/dades deben ser los mismos que aquellos presente en sus metadatos
Cer/ficados
• El Shibboleth recomienda la u/lización del cer/ficado todo en los metadatos en vez de u/lizar nombres y llaves públicas
• Este nivel de seguridad y confiabilidad es también parte de las definiciones a se hacer para la federación
• haps://wiki.shibboleth.net/confluence/display/SHIB2/BuildAFedera/on
Cer/ficados
• El archivo de metadatos es lo que define una federación • Este archivo con/ene todas las en/dades de la
federación, o sea, todos los metadatos de los SPs y IdPs
Metadatos de la federación
SP1.xml
IdP1.xml
IdP2.xml
Metadatos.xml <>
SP1.xml IdP1.xml IdP2.xml
</>
• Cada en/dad de la federación debe decir que reconoce el archivo de la federación como una fuente segura de datos de otros proveedores (MetadataProvider)
• En este archivo, el DS buscará todos os proveedores de iden/dad federados donde un usuario podrá auten/carse
Metadatos de la federación
• El archivo también con/ene informaciones de los IdPs; así, el DS puede informar al SP cuál es la dirección que él debe contactar para pedir la auten/cación del usuario
• Un proveedor reconoce otra en/dad como miembro de la federación comparando su nombre en el mensaje SAML con los nombres presentes en los metadatos
Metadatos de la federación
• El archivo de metadatos de la federación puede ser construido de dos modos ― Archivo único: todos los metadatos están concentrados en
un único archivo, que debe ser editado manualmente siempre que un nuevo IdP o SP adherir a la federación
― Archivos múl/plos: cada bloco de metadatos está en un archivo, dentro o fuera del dominio de la federación. En este caso, se debe u/lizar una herramienta para se agregar los metadatos
• El modo de manutención de los metadatos de las en/dades es también una opción que se puede hacer en el proyecto de la federación
Metadatos de la federación
• Ejemplos de herramientas de agregación de metadatos ― Shibboleth Metadata Aggregator (en desarrollo) ― RepoX ― OAICat ― … y otros
Metadatos de la federación
• Una das etapas necesarias para asegurar que el concepto de federación sea mantenido es la ges/ón de iden/dad
• Esta es la garan_a de que las cuentas con acceso federado corresponden a personas que son miembros de las ins/tuciones
• La federación puede confiar que el IdP hace su propia ges/ón o ayudarlo a hacerla
Ges/ón de iden/dad
• Desayos ― Impedir el acceso de iden/dades ar/ficiales en la federación:
administrador, cuentas de departamento, cuentas de grupos, roles, etc.
― Garan/zar que todos los usuarios sean únicos: no se debe almacenar cuentas duplicadas, nombres errados, registros duplicados en bases dis/ntas…
― Garan/zar que todos los usuarios tengan un vínculo válido con la ins/tución, sin cuentas expiradas o revocadas
Ges/ón de iden/dad
• Posibilidades para se hacer la ges/ón en ins/tuciones ― Busca por datos y nombres duplicados, data mining ― Iden/ficación de cuentas de departamento y cuentas
asociadas a roles en vez de personas ― Desarrollo de scripts personalizados para integrar diferentes
bases y mantener la consistencia y la unicidad de los registros
Ges/ón de iden/dad
Alto esfuerzo!
• Posibilidades para se hacer la ges/ón en ins/tuciones ― U/lización de una herramienta para hacer las operaciones
de unificación, eliminación de registros duplicados y sincronización con bases ya existentes
Ges/ón de iden/dad
• Herramienta para ges/ón de iden/dad -‐ EID ― Sofwares EID (Export Import Directory Tool) & EID2LDAP:
unificación de bases, conciliación de registros, sincronización agentada de todas las fuentes de datos, populación de una base LDAP con los registros ya tratados
― Desarrollado por la Universidade Federal de Minas Gerais (Brasil)
― Disponible en sourceforge, solo en portugués
hap://sourceforge.net/projects/eid/
Ges/ón de iden/dad
• Herramienta para ges/ón de iden/dad -‐ EID ― El EID construye un metadirectorio a par/r de diferentes
bases de datos: relacional, textual, CSV, Excel…
― Con el metadirectorio, es posible hacer la conciliación de registros aparentemente duplicados. Estos registros detectados por la herramienta automá/camente, pero el administrador debe decidir si son registros parecidos o los mismos registros. Ejemplo: homónimos, gemelos, nombres parecidos
Ges/ón de iden/dad
• EID: Procesamiento del metadirectorio ― Después de la creación del metadirectorio, se puede crear un
nuevo directorio LDAP unificado u/lizando el EID2LDAP
― La sincronización entre las bases an/guas y la nueva se hace por medio del sistema
― Así, es posible mantener un directorio para la federación sin alterar las configuraciones de las bases originales de la ins/tución, consistente con los cambios hechos en estas bases
Ges/ón de iden/dad
• Casos no contemplados por el EID ― Iden/dades ar/ficiales
― Duplicación de usuarios en diferentes ins/tuciones
Ges/ón de iden/dad
• Herramienta para ges/ón de iden/dad – OpenIAM Iden/ty Manager ― Interesante para cuándo ya existe algún tratamiento de las
iden/dades dentro de la ins/tución
― Con/ene servicios como definición de polí/cas de contraseña, auditoría, reportes, administración de cuentas por el usuario
Ges/ón de iden/dad
• U/lización del AD ― Una das herramientas de directorio u/lizadas por las
ins/tuciones es el AD
― Problema: no es posible extraer directamente el vínculo de un usuario con la ins/tución. Sería necesario hacer una personalización de los atributos o u/lizar un script para extraer el vínculo de otra fuente
― Ni siempre los responsables por los IdPs poseen este conocimiento del directorio
Ges/ón de iden/dad
• AD: Como hicimos en CAFe ― Muchas ins/tuciones nos pedían ayuda sobre como
liberar el atributo de vínculo, y no se tenía soporte oficial a directorios AD dentro de la federación
― Solución: creación de un directorio paralelo u/lizando AD LDS y u/lización de un atributo adicional apenas para comunicación entre AD y Shibboleth, conteniendo las informaciones de parentesco
― En esta solución, la verificación de las credenciales ocurren en el AD. Si fueron validadas, los atributos del usuario son enviados al SP por el AD LDS
― El EID es también compa/ble con esa solución
Ges/ón de iden/dad
• Informaciones ú/les sobre federaciones: haps://wiki.shibboleth.net/confluence/display/SHIB2/Home
• Guías de instalación hap://www.switch.ch/aai/support/iden/typroviders/ hap://www.switch.ch/aai/support/serviceproviders/
Páginas ú/les