Formato pdf

Curso para operadores de Proveedores
de Identidad
1.0
Sixto Martin y Lorenzo Gil
June 18, 2012
ÍNDICE GENERAL
1. Introducción
1.1. Qué es una federación de identidades . . . . . . . .
1.2. Ventajas de la federación de identidades . . . . . . .
1.3. Ejemplos de federaciones . . . . . . . . . . . . . .
1.4. Conceptos (IdP, SP, AA, WAYF, atributos, bindings)
1.5. Protocolos (SAML PAPI, OpenId) . . . . . . . . . .
1.6. Autenticación y autorización (AuthN & AuthZ) . . .
.
.
.
.
.
.
2
2
3
3
5
7
9
2. Posibles arquitecturas de las federaciones de identidad
2.1. Modelos de interconexión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
11
3. Descripción de la arquitectura desplegada en Confía
3.1. Entorno en Confía . . . . . . . . . . . . . . . . . . .
3.2. Arquitectura de Confía . . . . . . . . . . . . . . . . .
3.3. Entornos y servicios comunes desplegados en el CICA
3.4. Workflow de alta de IdP o Servicio (SP) . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
14
14
15
15
4. Gestión de los metadatos
4.1. Modelos de gestión de metadatos . . . . . . . . .
4.2. Los metadatos en simpleSAMLphp . . . . . . . .
4.3. Gestor de metadatos en simpleSAMLphp - JANUS
4.4. PEER . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
18
20
32
5. Gestión de los datos del usuario
5.1. La importancia del conjunto común de atributos
5.2. LoAs . . . . . . . . . . . . . . . . . . . . . . .
5.3. Políticas de liberación de atributos (ARPs) . . .
5.4. Validación y consolidación de atributos en el IdP
5.5. Consentimiento informado . . . . . . . . . . . .
5.6. Configuración del consentimiento informado . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
33
33
34
34
36
37
6. Protocolo de resolución de incidencias en un entorno de federación de identidades
6.1. Errores más frecuentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2. Protocolo de gestión de errores actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
41
41
7. Desplegar un IdP con SimpleSAMLphp
7.1. Recursos de ayuda . . . . . . . . . .
7.2. Instalación y configuración . . . . . .
7.3. Backends de autenticación . . . . . .
7.4. Repaso de filtros en simpleSAMLphp
43
43
43
50
51
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
I
7.5.
Alta disponibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
8. El IdP como SP
8.1. Caso base: IdP y SP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2. Hub & Spoke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3. IdP como SP en federación Hub & Spoke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
60
60
61
9. Referencias
9.1. Protocolos . . . . . . . . . . . .
9.2. Iniciativas de federación . . . . .
9.3. Federaciones de identidad . . . .
9.4. Especificación SAML . . . . . .
9.5. Implementaciones de SAML . . .
9.6. Hub&Spoke . . . . . . . . . . .
9.7. WAYF embebido . . . . . . . . .
9.8. Consentimiento informado . . . .
9.9. Gestión centralizada de metadatos
9.10. Otros conceptos avanzados . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
64
64
64
64
65
65
65
65
66
66
66
10. Anexo A. Despliegue de entorno Hub&Spoke
10.1. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . .
10.2. Implementación basada en simpleSAMLphp. “nodo bridge”
10.3. Migración del modelo de estrella al modelo Hub&Spoke. .
10.4. Tareas de mantenimiento. . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
67
67
68
76
76
11. Anexo B. assertion.encryption, redirect.sign y redirect.validate
11.1. assertion.encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2. redirect.sign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3. redirect.validate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
77
77
78
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
II
Curso para operadores de Proveedores de Identidad, 1.0
Esta documentación pertenece al curso para operadores de Proveedores de Identidad que se celebra en Sevilla el 12 de
Junio y en Granada el 14 de Junio de 2012.
ÍNDICE GENERAL
1
CAPÍTULO
ONE
INTRODUCCIÓN
1.1 Qué es una federación de identidades
Una federación de identidades es un grupo o conjunto de entidades que comparten la técnología, estandares y casos
de uso que permiten transmitir información de identidad de un usuario de manera segura facilitando la autenticación y
autorización entre diferentes dominios.
En una federación de identidades se establece un círculo de confianza que permite que un usuario autenticado en un
organismo de la federación acceda a recursos de otro organismo de la misma federación. La idetificación se realiza en
los Proveedores de Identidad (abrev. ingl. IdP). El Proveedor de Servicio (abrev. ingl. SP) al que accede el usuario
confía en los datos del usuario que le son suministrados por el IdP y en función de los mismos autoriza al usuario a
hacer uso de los recursos.
En una federación de identidades los servicios perciben al usuario como una entidad homogenea y no como un conjunto
de porciones de información sin relación entre ellas. Se denomina identificador opaco al identificador único que
mantiene la privacidad del usuario y que representa la asociación entre la cuenta del usuario en un Proveedor de
Servicio y la que posee en el Proveedor de Identidad.
Figura 1.1: Esquema federación
Es tarea del operador de la federación de identidades:
Decidir y gestionar la integración de los miembros (tanto proveedores de identidad como de servicio) a la
federación.
2
Curso para operadores de Proveedores de Identidad, 1.0
Gestionar las políticas de liberación de atributos (ARPs) y velar porque estás se cumplan.
Definir los esquemas de datos que van a utilizar los diferentes miembros con el fin de homogeneizar atributos.
Actuar como intermediario e incluso poder gestionar el consentimiento de cesión de datos para servicio que
accede el usuario.
Velar por el correcto funcionamiento de la federación.
Gestionar la interoperabilidad con otras federaciones formando confederaciones de identidades.
1.2 Ventajas de la federación de identidades
Ventajas para los usuarios:
Identidad única para todos los servicios federados: Una única clave que le da acceso a todos los servicios.
Single Sign ON (SSO) Web. Una vez identificado el usuario en un sistema federado tendrá acceso al resto de
servicios hasta que se finalice la sesión (log out) sin tener que volver a introducir sus credenciales de acceso.
Single Log Out (SLO). Al cerrar sesión de una aplicación se cerrará la sesión de todas las aplicaciones
federadas, mejorando así la seguridad del sistema.
Fiable, fácil y rápido. Al usuario se le presentá un único sistema de autenticación que conoce.
Ventajas para administradores de sistemas:
Facilita los procedimientos. Se despliega un escenario controlado en el que los accesos están
monitorizados y todos el procesos controlados.
Menor número de incidencias:
Al existir una clave única los administradores dejan de atender a incidencias relacionadas con
pérdidas y reseteos de claves.
Los datos de los usuarios pasan a estar en un punto común verificados y actualizados por lo que se
reducen las duplicidades de cuentas y los conflictos.
Mayor control de los datos del usuario. Mediante la definición de ARPs (Attribute Release
Policies) adecuadas el administrador puede decidir, dentro del conjunto de datos que posee de cada
usuario, cuáles enviar a un servicio concreto.
Ventajas para las organizaciones:
Ahorro en costes. Se ha demostrado que su uso reduce considerablemente sus costes de mantenimiento.
Mayor interoperabilidad / productividad. Fácil integración con multitud de sistemas heterogéneos. la
tecnología SAML2 se erige como el futuro de los sistemas de federación de identidades. Un ejemplo son los
exitodos sistemas de acceso unificado de Facebook o Google, que permiten acceder a todos sus servicios bajo
el protocolo SAML2.
Reducción de riesgos de seguridad. Las comunicaciones que envían información del usuario siempre van
cifradas incluso cuando se accede por protocolos no seguros como HTTP. La contraseña del usuario nunca
viaja entre los distintos nodos de la federación. Se utiliza tecnología PKI para todo este proceso de cifrado de
comunicaciones.
1.3 Ejemplos de federaciones
En la actualidad podemos identificar muchas federaciones de identidad basadas en la tecnología SAML:
1.2. Ventajas de la federación de identidades
3
Curso para operadores de Proveedores de Identidad, 1.0
Europeas:
Españolas:
En Andalucía existe Confía que es una federación de identidades de las universidades andaluzas.
En España tenemos el Servicio de dentidad de SIR operado por REDIRIS
En Dinamarca tienen la federación de identidades WAYF operado por el WAYF-secretariat.
En Reino Unido tienen la JANET(UK) operada por JISC y EDINA
En Finlandia tienen HAKA operada por
En Holanda tienen la SURFfederatie operada por SURFnet
En Norugega tienen FEIDE operada por Uninett
En la República Checa tienen SWITCHaai operada por SWITCH
Existe una confederación de los paises nórdicos denominada Kalmar Union
Existe una federación para la educación superior y la investigación europea llamada Edugate
También a nivel europeo destacamos el proyecto STORK que trata de proveer una plataforma de interoperabilidad de identidades.
No europeas:
En Australia tienen la AFF
1.3. Ejemplos de federaciones
4
Curso para operadores de Proveedores de Identidad, 1.0
En USA tienen la InCommon Federation
En Brasil tienen la federación CAFe
En Canada tienen la federación CAF-CANARIE
En China tienen federación CARSI
En Japón tienen la federación GakuNin
Se puede consultar más información sobre federaciones en una wiki de Terena.
1.4 Conceptos (IdP, SP, AA, WAYF, atributos, bindings)
IdP Proveedor de Identidad. Organización que provee la autenticación del usuario y devuelve los datos del usuario
que el SP requiere para autorizar su acceso al recurso o servicio.
SP Proveedor de Servicio. Cualquier organismo o institución registrado en la federación que provee acceso al usuario
final a algún servicio y recurso basandose en una serie de atributos que satisfacen sus requerimientos de autorización.
WAYF Cuando un SP está conectado a varios proveedores de identidad surge la necesidad de que el usuario seleccione
en que entidad se desea identificar. A este proceso de identificar tu proveedor de identidad se le conoce como WAYF,
que viene de las siglas Where Are You From.
AA Autoridad de atributos. Sistema que responde consultas sobre atributos.
1.4. Conceptos (IdP, SP, AA, WAYF, atributos, bindings)
5
Curso para operadores de Proveedores de Identidad, 1.0
Gestor de metadatos Elemento encargado de gestionar los diferentes metadatos de las entidades que componen la
federación (IdPs y SPs). Dichos metadatos deberán de estar actualizados periódicamente. Además opcionalmente
puede validar los metadatos, clasificarlos, validar los certificados de los metadatos o gestionar las ARPs.
Scoping Indica al IdP el ambito de la petición. De que SP surgió y con que contexto.
Binding Mapeo de una petición SAML o de una aserción de respuesta con un protocolo específico de transporte.
(HTTP-Redirect, HTTP-POST, Artifact o SOAP)
Descubrimiento En terminos de federación se hace referencia al descubrimiento como la acción de obtener la lista de
proveedores de identidad.
Metadatos Conjunto de datos que conforman la información necesaria para que una entidad se comunique con otra
entidad de la federación. En el protocolo SAML distinguimos los metadatos de los IdPs y de los SPs.
Entity ID Dentro de los metadatos de una entidad se define el entity id como el identificador que unívocamente al SP
o IdP. La última tendencia es la de utilizar como entity id la url en la que se publican los metadatos de dicha entidad.
ARP Política de liberación de atributos. Política que rige la distribución de los atributos del usuario a los diferentes
SPs.
Atributo Parte sencilla de los datos de un usuario (como por ejemplo el nombre, apellido, email, etc). Pueden ser
generales o personales. Uno o la agrupación de varios atributos identifican univocamente al usuario.
Esquema de atributos Compendio de nombres de atributos estandarizado. Surge de la necesidad de definir un vocablo
común que defina un nombre para los diferentes atributos que forman parte de la información del usuario que van a
transferirse entre los elementos de la federación de identidades.
Identificador opaco Identificador persistente que puede ser usado para conectar cuentas de usuario conservando la
privacidad.
Consentimiento En términos de federación se hace referencia al consentimiento como a la acción en la que el usuario
acepta que los atributos que posee un IdP se transfieran a un SP (cumpliendo la ARP y de forma segura).
SAML Es el lenguaje de marcado para las aserciones de seguridad. Un estandar definido y mantenido por OASIS.
Está basado en XML y diseñado para el intercambio de información sensible de forma segura.
XML Encryption Un estandar W3C para cifrar un documento XML. Es usado en SAML para cifrar la Aserción
SAML con el fin de dificultar que una entidad o individuo que no pertenezca a la federación pueda obtener los datos
del usuario.
XML Signature Un estandar W3C para firmar un documento XML. Es usado en SAML para autenticar al organismo
que firmo el documento permitiendo establecer una relación de confianza.
Profile Reglas que definen como integrar las aserciones SAML y como extraerlas de otros protocolos para poder
habilitar el SSO y el SLO. Define también el flujo de peticiones y respuestas SAML que se efectuan en un determinado
caso de uso.
SSO Single Sign On. Procedimiento de autenticación que habilita al usuario para acceder a varios sistemas con una
sola instancia de identificación. En una federación de identidades el SSO habilita al usuario a acceder a cada uno de
los SP (previa autorización en el mismo) una vez se haya identificado en un IdP.
SLO Single Log Out. Procedimiento por el cual el usuario deja de estar identificado en el conjunto de
aplicaciones/elementos en los que estuviera logado.
Puede ampliar su glosario de terminos con el siguiente documento.
1.4. Conceptos (IdP, SP, AA, WAYF, atributos, bindings)
6
Curso para operadores de Proveedores de Identidad, 1.0
1.5 Protocolos (SAML PAPI, OpenId)
1.5.1 SAML
Security Assertion Markup Language. Está basado en XML y es un estandar abierto para el intercambio de información
de autorización y autenticación entre dominios de forma segura. Fue creado por la empresa OASIS
Básicamente define como debe de hacerse de forma segura la tránsmisión de los diferentes tipos de aserciones SAML
entre IdPs y SPs utilizando un binding definido.
Para saber mas del protocolo SAML puede consultar el siguiente tutorial
1.5.2 PAPI
PAPI es un sistema de SSO desarrollado por RedIRIS desde el año 2001. Permite desplegar una infraestructura de
autenticación y autorización y un sistema de Single Sign-On fácilmente.
Los componentes principales del sistema son: El servidor de autenticación (AS) y los puntos de acceso (PoA).
Un PoA se encarga de interceptar los accesos a recursos o servicios forzando la auntenticación del usuario en un
AS (cada PoA puede estar conectado a uno o varios AS),La autenticación se produce contra alguno de los backends
configurados en el AS (Ldap, BD, etc) y tras producirse se genera una aserción que se transmite al POA, y que contiene
datos del usuario autenticado.
Existe un elemento especial que se denomina GPoA que se conecta con varios PoAs y a un AS, que se comporta como
si fuera un AS para sus PoAs, estableciendo una relación de confianza con ellos y suya a su vez con el AS.
1.5. Protocolos (SAML PAPI, OpenId)
7
Curso para operadores de Proveedores de Identidad, 1.0
Si el PoA no puede integrarse con la aplicación a federar (diferente tecnologia, diferente entorno) se hace uso de un
elemento conocido como Proxy PAPI.
El funcionamiento de PAPI es bastante similar al Browser Post Profile de Liberty/SAML 2.0: la aserción es transmitida
mediante el método POST de HTTP desde un proveedor de autenticación hasta los proveedores de servicio, solo que
dicha aserción no es SAML (ni siquiera XML).
Puede obtener más información sobre el protocolo en la wiki del proyecto PAPI
1.5.3 OpenID
OpenID es un sistema de identificación digital descentralizado, con el que un usuario puede identificarse en una
aplicación web a través de una URL (o un XRI en la versión actual) y ser verificado por cualquier servidor que soporte
el protocolo.
En los aplicaciones web que soportan OpenID, los usuarios no requieren tener una cuenta de acceso. En su lugar, solo
necesitan disponer de un identificador creado en un servidor que verifique OpenID, llamado proveedor de identidad o
IdP.
1.5. Protocolos (SAML PAPI, OpenId)
8
Curso para operadores de Proveedores de Identidad, 1.0
1.6 Autenticación y autorización (AuthN & AuthZ)
Es importante diferenciar estos 2 conceptos.
La autenticación es el proceso de verificar la identidad de una persona mientras que la autorización es el proceso
de verificación de que una persona conocida tiene la autoridad para realizar una cierta operación o acceder a un
servicio/recurso .
Generalmente el acceso de un usuario sigue el siguiente procedimiento:
1. El usuario solicita acceso a un sistema.
2. El sistema solicita al usuario que se autentique.
3. El usuario aporta las credenciales que le identifican y permiten verificar la autenticidad de la identificación.
(autenticación)
1.6. Autenticación y autorización (AuthN & AuthZ)
9
Curso para operadores de Proveedores de Identidad, 1.0
4. El sistema valida según sus reglas si las credenciales aportadas son suficientes para dar acceso al usuario o
no. (autorización)
En un sistema federado:
La autenticación se realiza en el IdP.
La autorización se realiza en el SP o en la propia aplicación
1.6. Autenticación y autorización (AuthN & AuthZ)
10
CAPÍTULO
TWO
POSIBLES ARQUITECTURAS DE LAS
FEDERACIONES DE IDENTIDAD
2.1 Modelos de interconexión
Existen varios modelos atendiendo a como se conectan cada uno de los elementos que forman una federación de
identidades. Cada módelo tiene sus ventajas y desventajas por lo que dependiendo del entorno y contexto optaremos
por uno u otro modelo.
2.1.1 Modelo centralizado
Figura 2.1: Arquitectura centralizada
Los SP se conectan a un único nodo IdP cuyas fuentes de autenticación (auth backends) son Ldaps, BDs, etc de
diferentes instituciones.
11
Curso para operadores de Proveedores de Identidad, 1.0
Si el IdP tiene soporte los SP podrían comunicarse en los diferentes protocolos de autenticación actualmente
existentes: SAML2, sHibboleth, OpenId, PAPI
Los proveedores de identidad delegarían la petición del consentimiento en el único nodo posible: el IdP central.
Cada SP está directamente conectado con el IdP (no habría descubrimiento de IdP) siendo necesario especificar
de alguna forma contra que backend de autenticación actuar.
El SP podría pasarle un parámetro al IdP o ser el IdP directamente el que decidiera a donde ir dependiendo de
donde le llegue la petición, del username del usuario, etc.
2.1.2 Modelo distribuido
Figura 2.2: Arquitectura distribuida
Cada SP está conectado con cada IdP.
Cada IdP tiene que soportar los diferentes protocolos con los que se comuniquen los SPs.
El consentimiento se realizaría en cada uno de los IdPs.
El descubrimiento se realizaría en el SP.
2.1.3 Modelo Hub & Spoke
Cada SP está conectado con un nodo central que a su vez está conectado a cada IdP.
Puede que un SP y un IdP que no tengan protocolos compatibles de comunicación puedan comunicarse haciendo
uso del nodo central que hará de puente (bridging) y traduzca las aserciones de un protocolo a otro.
Los IdPs delegarían la petición del consentimiento en el nodo central (aunque también puede haber un doble
consentimiento y requerirse el consentimiento tanto en el IdP como en el nodo central).
El descubrimiento se realizaría en el nodo central. (Aunque existen federaciones con esta arquitectura que
realizan un wayf embebido en la aplicación federada).
Ventajas del modelo Hub & Spoke
2.1. Modelos de interconexión
12
Curso para operadores de Proveedores de Identidad, 1.0
Figura 2.3: Arquitectura Hub & Spoke
Desacople de los diferentes elementos, desacople tecnológico (al poder coexistir diferentes protocolos siempre
que el nodo central sea compatible con los mismos y actue de bridge). Mejora escalabilidad.
Poder tener centralizados los servicios de la federación: consentimiento, descubrimiento (wayf), filtros
de atributos, validación de atributos, monitorización, estadísticas. Reduciendo costes y facilitando el
mantenimiento.
Posibilidad de inter-federación. Conectando el nodo central con otro nodo central de otra federación
conseguimos que los nodos de ambas federaciones queden conectados.
2.1. Modelos de interconexión
13
CAPÍTULO
THREE
DESCRIPCIÓN DE LA ARQUITECTURA
DESPLEGADA EN CONFÍA
3.1 Entorno en Confía
Existen 3 entornos replicados en Confía:
Producción. Es el entorno oficial, el que utilizan los usuarios finales.
Pre-producción. Es utilizado como entorno de pruebas. Antes de pasar cualquier IdP o SP a producción debe
de validarse dicho elemento en este entorno.
Laboratorio. Es utilizado para desarrollar nuevos plugins y para probar nuevos servicios.
3.2 Arquitectura de Confía
La federación Confía está desplegada con una arquitectura Hub & Spoke.
Figura 3.1: Entorno Confía
14
Curso para operadores de Proveedores de Identidad, 1.0
En Confía es obligatorio que de cada IdP y de cada SP se ofrezcan 2 instancias: La instancia oficial y la instancia
de pruebas sobre la que se harán nuevos desarrollos o se validaran nuevas versiones del software.
3.3 Entornos y servicios comunes desplegados en el CICA
Actualmente en el CICA se tienen desplegado lo siguiente:
Figura 3.2: Entornos y servicios desplegados en el CICA
3.4 Workflow de alta de IdP o Servicio (SP)
El proceso de incorporar un nuevo IdP o un nuevo SP en la infraestructura del Confía es la siguiente:
1. Lo primero será realizar los “tramites burocráticos” para que se acepte la incorporación del servicio: Aceptación
por parte de la AUPA-TIC, ofrecer información del servicio al Comité, visto bueno técnico por parte del Comité.
2. Se desarrollará el IdP o el Servicio (SP) conectándolo con el entorno de laboratorio.
3. Una vez desarrollado el IdP o el Servicio y una vez pasados los “trámites burocráticos” se pasará al entorno de
pre-producción en el que el operador de la infraestructura validará que todo está en orden
3.3. Entornos y servicios comunes desplegados en el CICA
15
Curso para operadores de Proveedores de Identidad, 1.0
4. Se Conectará el IdP o el Servicio con el entorno de producción. Y se conectará una instancia no oficial con
el entorno de laboratorio para seguir mejorando el servicio o para cuando haya que hacer pruebas con nuevas
versiones de software.
Por tanto:
En el entorno de producción únicamente habrá instancias de IdPs y SPS oficiales.
En el entorno de pre-producción habrá instancias de IdPs y SPs oficiales, e instancias que van a ser validadas
como oficiales.
En el entorno de laboratorio deberá de haber instancias de pruebas de los IdPs y SPs.
A efectos prácticos dar de alta en un determinado entorno no es más que registrar el correspondiente metadato de la
entidad en el gestor de metadatos de dicho entorno.
3.4. Workflow de alta de IdP o Servicio (SP)
16
CAPÍTULO
FOUR
GESTIÓN DE LOS METADATOS
La gestión de los metadatos constituye una tarea esencial para el funcionamiento de las federaciones de identidades
basadas en el protocolo SAML. Es imprescindible proporcionar metadatos confiables, disponibles y precisos a los
participantes de la federación: la descripción de las entidades, sus responsables y sobre todo las url donde ofrecen las
funcionalidades y las claves públicas.
Dentro de los metadatos se incluyen 2 atributos opcionales que hay que tener muy en cuenta a la hora de realizar la
gestión de los metadatos:
validUntil: Indica en tiempo absoluto cuando caducan los metadatos
cacheDuration: Indica el máximo periodo de tiempo en el que las entidades deberían de confiar en esos
metadatos y albergarlos en su “cache” (en simpleSAMLphp la cache está basada en ficheros de sistema que
se alojan dentro de la carpeta metadata).
También es importante ver como se llegó al consenso para que los entityIDs de las entidades coincidieran con las urls
donde se alojan sus metadatos, lo cual facilita el trabajo de la gestión de los metadatos.
4.1 Modelos de gestión de metadatos
4.1.1 Modelo de agregación
La arquitectura de agregación permite actualizar los metadatos en el lado de la entidad que los va a consumir y debido
al simple modelo de confianza, los metadatos serán considerados válidos siempre que estos sean descargados de una
fuente fiable (URL pre-acordada y los metadatos convenientemente firmados con una clave pública del publicador)
4.1.2 Modelo distribuido
En la arquitectura distribuida cada entidad es responsable de la gestión y publicación de sus propios metadatos. Con
este modelo los metadatos de un determinado punto pueden ser obtenidos bajo demanda sin la necesidad de la descarga
periódica de una colección de gran tamaño de metadatos. (Se realiza el descubrimiento dinámico de metadatos en
función de las necesidades). Es un modelo que puede acarrear problemas ya que se relaja el concepto de “confianza”.
4.1.3 Modelo centralizado utilizado en Confía
Es una arquitectura que viene muy bien en federaciones Hub & Spoke, en el nodo bridge o en un nuevo nodo, se
despliega un sistema que será responsable de almacenar, monitorizar y verificar los metadatos de las entidades de una
federación.
17
Curso para operadores de Proveedores de Identidad, 1.0
Los metadatos de la federación son agregados periódicamente, almacenados y publicados como un archivo XML
convenientemente firmado.
El sistema deberá de disponer de mecanismos para poder delegar las responsabilidades de gestión de un determinado
metadato al administrador de la entidad a la que describe.
4.2 Los metadatos en simpleSAMLphp
4.2.1 Configurar los directorios que albergan los metadatos en simpleSAMLphp
En el fichero config/config se especifica con el parámetro ‘metadata.sources’ donde simpleSAMLphp va a buscar los
ficheros que contienen las fuentes de los diferentes metadatos.
Si queremos que además de en el directorio metadata/ (directorio en el que siempre por defecto se buscan los
metadatos) se busquen metadatos dentro del directorio example1:
’metadata.sources’ => array(
// Habilita los metadatos que se encuentren en los archivos del directorio metadata
array(’type’ => ’flatfile’),
// Habilita los metadatos que se encuentren en los archivos del directorio metadata/example1
array(’type’ => ’flatfile’, ’directory’ => ’metadata/example1’),
),
Además es posible configurar el tipo de fichero en el que simpleSAMLphp espera leer los metadatos. Las alternativas
son flatfile (formato propio de ssp) o xml.
4.2.2 Metarefresh
Para conectar un proveedor de identidad (IdP) o un proveedor de servicio (SP) a una federación, es necesario especificar
los metadatos de las fuentes en las que se confía. En muchas federaciones es normal configurar una distribución
automatizada de los metadatos utilizando el formato de metadatos XML SAML 2.0. Generalmente una administración
o autoridad central proporciona una URL con un documento SAML 2.0 que incluye los metadatos de todas las
entidades de la federación.
Mediante el módulo metarefresh de simpleSAMLphp es posible obtener los metadatos remotos de una URL y
almacenarlos en un archivo.
Instalación y configuración del módulo metarefresh
El módulo metarefresh existe en la instalación básica de simpleSAMLphp por lo que únicamente tendremos que
habilitarlo:
# touch <ruta hasta simplesamlphp>/simplesamlphp/modules/metarefresh/enable
Puesto que el módulo utiliza wget para realizar las descargas de los metadatos deberemos tener este software instalado
en la máquina:
# yum install wget
El módulo tiene un archivo de configuración propio que debemos alojar en el directorio config
del simpleSAMLphp. El fichero config-metarefresh.php (podemos encontrar una plantilla en
simplesamlphp/modules/metarefresh/config-templates/config-metarefresh.php).
El contenido del fichero sería el siguiente:
4.2. Los metadatos en simpleSAMLphp
18
Curso para operadores de Proveedores de Identidad, 1.0
<?php
$config = array(
’sets’ => array(
// Pueden habilitarse varios conjuntos
’confia’ => array(
// El cron se ejecutará cada hora descargandose metadatos.
’cron’
=> array(’hourly’),
/* Pueden habilitarse varios fuentes, por ejemplo se podría
tener los metadatos de los IdPs y de los SPs por separado. */
’sources’
=> array(
array(
’src’ => ’URL_DE_LA_FUENTE_DE_METADATOS’,
),
),
// Tiempo en el que expiraran los metadatos descargados.
’expireAfter’
=> 60*60*24*4,
/* Directorio en el que se crearan los ficheros saml20-idp-remote.php
y saml20-sp-remote.php */
’outputDir’
=> ’metadata/federation/’,
// Formato en que se encuentran los metadatos
’outputFormat’ => ’flatfile’,
),
),
);
Donde URL_DE_LA_FUENTE_DE_METADATOS es la URL de la fuente de metadatos SAML 2.0 en XML. En el
array cron hay que especificar alguna de las perioricidades que defina el módulo de cron (en este caso ‘hourly’). Esto
se explica más abajo.
A continuación hay que crear el directorio donde se guardarán los metadatos descargados, tal y como se especifica en
el atributo outputDir del fichero anterior:
# mkdir simplesamlphp/metadata/federation
Es muy importante que este directorio tenga permisos de escritura para el usuario con el que se ejecuta el servidor web
(y por tanto, el intérprete de PHP). En el caso de máquinas con RedHat? o Centos este usuario se llama apache, en el
caso de máquinas basadas en Debian, el usuario es www-data.:
# chown -R apache:apache <ruta-al-simplesamlphp>/simplesamlphp/metadata/federation
Para que metarefresh funcione correctamente, es necesario configurar el módulo sanitycheck para lo cual simplemente
copiamos a la carpeta config de simpleSAMLphp la plantilla config-sanitycheck.php y configuramos los
cron_tag que queramos.
Habilitar y configurar módulo cron y el crontab
Es necesario activar también el módulo cron:
# touch <ruta hasta simplesamlphp>/modules/cron/enable
Y crear el fichero de configuración config/module_cron.php:
<?php
/*
* Configuration for the Cron module.
*
* $Id: $
4.2. Los metadatos en simpleSAMLphp
19
Curso para operadores de Proveedores de Identidad, 1.0
*/
$config = array (
’key’ => ’secret’,
’allowed_tags’ => array(’daily’, ’hourly’, ’frequent’),
’debug_message’ => TRUE,
’sendemail’ => TRUE,
);
?>
Alternativamente, se puede desactivar el envío de correos, que puede llegar a ser intensivo, poniendo ‘sendemail’ =>
FALSE,. En el array ‘allowed_tags’ hay que definir frecuencias a las que se puedan enganchar los distintos módulos.
En nuestro caso, metarefresh lo hace con ‘hourly’.
Estas tags no son más que cadenas arbitrarias. Quien decide con qué frecuencia se ejecuta cada tag es el propio cron,
bien con scripts en los directorios /etc/cron.[hourly|daily|weekly...] o en ficheros crontab en /etc/cron.d. Para que se
descarguen periódicamente los metadatos, hay que colocar un fichero crontab en /etc/cron.d con una línea para cada
tag definida. En nuestro caso, necesitamos una línea que se ejecute diariamente, otra cada hora y otra “frecuentemente”
(cada minuto, por ejemplo):
0 0 * * * root wget --quiet -O /dev/null --no-check-certificate
"https://HOST_SSP/simplesaml/module.php/cron/cron.php?key=secret&tag=daily"
0 * * * * root wget --quiet -O /dev/null --no-check-certificate
"https://HOST_SSP/simplesaml/module.php/cron/cron.php?key=secret&tag=hourly"
* * * * * root wget --quiet -O /dev/null --no-check-certificate
"https://HOST_SSP/simplesaml/module.php/cron/cron.php?key=secret&tag=frequent"
Donde HOST_SSP es el dominio de la máquina en la que está funcionando nuestro simpleSAMLphp.
Por último es necesario copiar el fichero config-sanitycheck.php de modules/sanitycheck/config-templates/ a config/.
Crear directorio que albergará los metadatos
Por último, es necesario configurar simpleSAMLphp para que, además de utilizar los ficheros de metadatos generales
(los ficheros de metadata/), utilice también los que Metarefresh dejará en el directorio metadata/federation/. Para ello
hay que editar el fichero config/config.php, concretamente la opción metadata.sources, para añadirle nuestra nueva
fuente de metadatos:
’metadata.sources’ => array(
array(’type’ => ’flatfile’),
array(’type’ => ’flatfile’, ’directory’ => ’metadata/federation’),
),
Es posible consultar más documentación del módulo metarefresh.
4.3 Gestor de metadatos en simpleSAMLphp - JANUS
En simpleSAMLphp existe un módulo llamado Janus que permite: * Gestionar los metadatos de IdPs y SPs (Posee
diferentes niveles de permisos para los usuarios) * Publicar subconjuntos de los metadatos registrados. * Gestionar
ARPs para los SPs, (el estandar SAML permite definir ARPs e incluirlas dentro de los metadatos de un SP).
4.3. Gestor de metadatos en simpleSAMLphp - JANUS
20
Curso para operadores de Proveedores de Identidad, 1.0
4.3.1 Instalación
JANUS no es más que un módulo de simpleSAMLphp. En una federación de identidades Hub & Spoke podemos
desplegar el gestor de metadatos dentro de la instancia del “nodo bridge” o en una instancia nueva. (Explicamos como
se desplegaría en una nueva instancia.
Al servicio Janus lo protegeremos con una fuente de autenticación local en la que habilitemos los diferentes
administradores que van a gestionar los metadatos. Lo ideal sería que el Janus estuviese protegido de forma federada,
pero se puede dar el caso de que un administrador no pudiera acceder al servicio Janus a través de su Proveedor de
Identidad precisamente porque los metadatos del mismo son los que necesitan ser actualizados.
Lo primero que debemos hacer es obtener el código del software Janus el cual obtendremos ejecutando:
# svn co http://janus-ssp.googlecode.com/svn/tags/v.1.11.0 janus
Una vez realizado esto copiamos el directorio janus dentro del directorio modules y lo activamos:
# touch /var/www/janus/simplesamlphp/modules/janus/enable
En Janus, los diferentes metadatos van a ser almacenados en una base de datos por tanto deberemos tener acceso a un
sistema de base de datos.
Configuración de Apache
Se debe crear un fichero de configuración para el VirtualHost de janus.example.com.conf en el directorio
/etc/httpd/conf.d/ con el siguiente contenido:
<VirtualHost *:80>
ServerName janus.example.com
DocumentRoot /var/www/janus/simplesamlphp/www
SSLProxyEngine On
ProxyPreserveHost On
Alias /simplesaml /var/www/janus/simplesamlphp/www
<Location />
ProxyPass https://localhost
</Location>
</VirtualHost>
<VirtualHost *:443>
ServerName janus.example.com
DocumentRoot /var/www/janus/simplesamlphp/www
Alias /simplesaml /var/www/janus/simplesamlphp/www
SSLEngine on
SSLCertificateFile /etc/httpd/ssl/janus.example.com/crt/janus.example.com.crt
SSLCertificateKeyFile /etc/httpd/ssl/janus.example.com/key/janus.example.com.key
</VirtualHost>
Además es necesario crear los certificados (autogenerados) que se han especificado en la configuracion del VirtualHost
para https. Se deberán seguir las siguientes instrucciones:
1. Crear el directorio donde alojar los certificados, en este caso, /etc/httpd/ssl/janus.example.com/:
# mkdir -p /etc/httpd/ssl/janus.example.com/crt /etc/httpd/ssl/janus.example.com/key
2. Cambiar el directorio actual por /etc/httpd/ssl/janus.example.com/:
# cd /etc/httpd/ssl/janus.example.com/
3. Creación de la clave sin contraseña y con una encriptación 1024:
4.3. Gestor de metadatos en simpleSAMLphp - JANUS
21
Curso para operadores de Proveedores de Identidad, 1.0
# openssl genrsa -out key/janus.example.com.key 1024
4. Generar el fichero CSR (solicitud de certificado):
# openssl req -new -key key/janus.example.com.key -out janus.example.com.csr
5. Generar el certificado autofirmado:
# openssl x509 -req -days 1825 -in janus.example.com.csr -signkey key/janus.example.com.key
-out crt/janus.example.com.crt
Por último, es necesario reiniciar el servicio httpd para que la nueva configuración sea aplicada:
# service httpd restart
Certificado (janus.example.com.crt) y clave (janus.example.com.key) deberemos también de tenerlos accesibles en la
carpeta cert del simpleSAMLphp para que sean usados en el firmado y cifrado de aserciones. Para ello lo mejor es
crear enlaces simbólicos:
# ln -s /etc/httpd/ssl/janus.example.com/key/janus.example.com.key
/var/www/janus/simplesamlphp/cert/janus.example.com.key
# ln -s /etc/httpd/ssl/janus.example.com/crt/janus.example.com.crt
/var/www/janus/simplesamlphp/cert/janus.example.com.crt
Creación de la base de datos y configuración
Una vez reiniciado el servidor apache podremos acceder a un script que posee Janus para crear la base de datos y las
tablas pertinentes. Dicho script se ejecuta accediendo por navegador a la URL:
https://janus.example.com/simplesaml/module.php/janus/install/
Una vez que lo hayamos ejecutado y se hayan creado las tablas oportunas deberemos de borrar el archivo install por
motivos de seguridad:
# rm
-rf /var/www/janus/simplesamlphp/modules/janus/install
A continuación copiaremos la plantilla de configuración de janus del janus/config-templates/module_janus.php al
directorio de configuración de simplesamlphp config/ :
# cp /var/www/janus/simplesamlphp/modules/janus/config-templates/module_janus.php
/var/www/janus/simplesamlphp/config/module_janus.php
Y editaremos el archivo convenientemente con la configuración que más nos interese. A continuación vamos a ir
detallando los diferentes parámetros y el valor que recomendamos darles.
Configuración de datos del administrador:
// Nombre del administrador de Janus
’admin.name’ => ’JANUS admin’,
// Email del administrador de Janus, aparecerá como contacto de la aplicación,
’admin.email’ => ’janusadmin@example.org’,
Configuración de la base de datos Janus:
’store’ => array(
// Configuración de conexión con la base de datos.
’dsn’
=> ’mysql:host=localhost;dbname=janus_db’,
’username’ => ’janus’,
// Usuario de la base de datos
4.3. Gestor de metadatos en simpleSAMLphp - JANUS
22
Curso para operadores de Proveedores de Identidad, 1.0
’password’
’prefix’
=> ’’,
=> ’janus__’,
// Password para acceder a la base de datos
// Prefijo utilizado en las tablas, si lo hubiera
),
Configuración de cron:
/* Habilita un cron que se ejecutará y refrescará los metadatos de cada una de
las entidades */
’metadata_refresh_cron_tags’ => array(’janus’),
/* Hay otras 2 tareas que son importantes ejecutar periodicamente que se
habilitan con estos 2 parámetros, básicamente validan que los certificados
y los metadatos sean correctos, en caso contrario se puede activar el
sendMail para que se envien correos al administrador */
’validate_entity_certificate_cron_tags’ => array(’daily’),
’validate_entity_endpoints_cron_tags’
=> array(’daily’),
/* Si habilitamos la validación de certificados es necesario indicar la ruta
donde se encuentren las CAs */
’ca_bundle_file’ => ’/etc/pki/tls/certs/ca-bundle.crt’,
Configuración de acceso al Janus:
/* Crearemos en el authsources una fuente de autenticación del tipo exampleauth con
la lista de usuarios de janus */
’auth’ => ’janus-users’,
/* Este atributo del usuario es el que va a ser comparado con el identificador
de usuarios de la base de datos de Janus para relacionar el usuario */
’useridattr’ => ’uid’,
/* Con el valor a TRUE permite que el Janus cree al usuario en la base de datos si
se ha autenticado correctamente */
’user.autocreate’ => false,
Configuración visual de Janus:
// Permite paginar la pestaña INBOX de Janus
’dashboard.inbox.paginate_by’ => 20,
/* Metadato de la entidad que será utilizado en la vista de conexión para la identificación
visual de la entidad. Se puede usar el ’entityid’ o el ’name’ (este ultimo, si es
suficientemente representativo y existe en todas las entidades) */
’entity.prettyname’ => ’entityid’,
Configuración de uso:
// Lo habitual en una federación con nodos simpleSAMLphp es habilitar IdPs y SPs del tipo SAML 2.0
’enable.saml20-sp’ =>
true,
’enable.saml20-idp’ => true,
’enable.shib13-sp’ =>
false,
’enable.shib13-idp’ => false,
// Indica el estado al que se va a asociar a una entidad cuando se registre.
’workflowstate.default’ => ’testaccepted’,
Configuración del sistema Janus:
El conjunto de estados que puede tener una entidad se va a definir en la array ‘workflowstates’
4.3. Gestor de metadatos en simpleSAMLphp - JANUS
23
Curso para operadores de Proveedores de Identidad, 1.0
El conjunto de metadatos posibles que van a tener las entidades se definen en las variables
‘metadatafields.saml20-idp’, ‘metadatafields.saml20-sp’, ‘metadatafields.shib13-idp’ y ‘metadatafields.shib13sp’
El conjunto de permisos sobre acciones de Janus se define en la array ‘access’
Los cambios posibles de estado de las entidades se definen en la array ‘workflow_states’
El conjunto de tipos de usuarios se define en la array ‘usertypes’
Configuración de ARPs:
/* Cuando asociamos una ARP a un SP, se añadiran a los metadatos una serie de etiquetas
RequestedAttribute. En simpleSAMLphp, en el caso de que esté definido un filtro
attributelimit y una ARP para un SP, se tomarán esos atributos definidos en el ARP
para filtrar los atributos que se liberan desde el IdP */
/* Permite configurar una lista con los atributos que conformarán la ARP
que se asociará a los SPs que no tengan una ARP asociada. Si no queremos
establecer ninguna ARP debemos de dejar la array vacia. */
’entity.defaultarp’ => array(
’eduPersonTargetdID’,
),
// Conjunto de atributos que van a estar disponibles para crear las ARPs
’attributes’ => array(
’uid’ => array(
’name’ => ’uid’
),
’common name (cn)’ => array(
’name’ => ’cn’
),
’surname’ => array(
’name’ => ’sn’,
),
’gn’ => array(
’name’ => ’gn’,
),
’displayName’ => array(
’name’ => ’displayName’,
),
’eduPersonPrincipalName’ => array(
’name’ => ’eduPersonPrincipalName’,
),
’mail’ => array(
’name’ => ’mail’,
),
’irisMailMainAddress’ => array(
’name’ => ’irisMailMainAddress’,
),
’eduPersonAffiliation’ => array(
’name’ => ’eduPersonAffiliation’,
),
’eduPersonPrimaryAffiliation’ => array(
’name’ => ’eduPersonPrimaryAffiliation’,
),
’eduPersonScopedAffiliation’ => array(
’name’ => ’eduPersonScopedAffiliation’,
),
4.3. Gestor de metadatos en simpleSAMLphp - JANUS
24
Curso para operadores de Proveedores de Identidad, 1.0
’preferredLanguage’ => array(
’name’ => ’preferredLanguage’,
),
’eduPersonEntitlement’ => array(
’name’ => ’eduPersonEntitlement’,
),
’eduPersonTargetedID’ => array(
’name’ => ’eduPersonTargetedID’,
),
),
Configuración de la exportación de metadatos:
// Este atributo define el formato posible para las publicaciones de metadatos
’mdexport.allowed_mime’ => array(
1 => ’application/xml’,
2 => ’application/samlmetadata+xml’,
3 => ’application/simplesamlphp+text’, // SSP flat file format
),
/* Este atributo define un conjunto de opciones por defecto con el que se publicarán
los metadatos de las entidades */
’mdexport.default_options’ => array(
’entitiesDescriptorName’ => ’Federation’,
// Nombre del set de entidades
’mime’ => ’application/xml’,
// Formato de salida
’maxCache’
=> 60*60*24,
// 24 horas de límite de cache
’maxDuration’ => 60*60*24*5, // 5 días de para que caduquen los metadatos de la entidad
/* Si queremos que los metadatos se firmen, de ser así posteriormente podrán ser
comprobados en el modulo metarefreh */
’sign.enable’ => FALSE,
// Datos del certificado con el que se firmará la publicación, en caso de que se habilite
’sign.privatekey’ => ’janus.example.com.key’,
’sign.privatekey_pass’ => NULL,
’sign.certificate’ => ’janus.example.com.crt’,
),
Configuración de los feeds de publicaciones:
’mdexport.feeds’ => array(
// Este feed publica bajo firma
’sp-prod’ => array(
’types’
=>
’states’
=>
’mime’
=>
’exclude’
=>
’postprocessor’
=>
’entitiesDescriptorName’ =>
’filename’
=>
’maxCache’
=>
’maxDuration’
=>
’sign.enable’
=>
’sign.privatekey’
=>
’sign.privatekey_pass’
=>
’sign.certificate’
=>
),
todas los proveedores de servicio del tipo SAML 2.0
array(’saml20-sp’),
array(’prodaccepted’),
’application/samlmetadata+xml’,
array(),
NULL,
’SPs del SINED’,
’sp_sined.xml’,
60*60*48, // 24 hour cache time
60*60*24*7, // Maximum 5 days duration on ValidUntil.
TRUE,
’janus.example.com.key’,
’’,
’janus.example.com.crt’,
// Este feed publica bajo firma todas los proveedores de identidad del tipo SAML 2.0
4.3. Gestor de metadatos en simpleSAMLphp - JANUS
25
Curso para operadores de Proveedores de Identidad, 1.0
’idp-prod’ => array(
’types’
’states’
’mime’
’exclude’
’postprocessor’
’entitiesDescriptorName’
’filename’
’maxCache’
’maxDuration’
’sign.enable’
’sign.privatekey’
’sign.privatekey_pass’
’sign.certificate’
),
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
=>
array(’saml20-idp’),
array(’prodaccepted’),
’application/samlmetadata+xml’,
array(),
NULL,
’IdPs del SINED’,
’idp_sined.xml’,
60*60*48, // 24 hour cache time
60*60*24*7, // Maximum 5 days duration on ValidUntil.
TRUE,
’janus.example.com.key’,
’’,
’janus.example.com.crt’,
/* Este feed publica bajo firma todas los proveedores de identidad y de servicio del tipo
SAML 2.0 (salvo los del nodo bridge) */
’idpsp-prod’ => array(
’types’
=> array(’saml20-idp’,’saml20-sp’),
’states’
=> array(’prodaccepted’),
’mime’
=> ’application/samlmetadata+xml’,
’exclude’
=> array(
’https://wayf.example.com/simplesaml/saml2/idp/metadata.php’,
’https://wayf.example.com/simplesaml/module.php/saml/sp/metadata.php/saml’
),
’postprocessor’
=> NULL,
’entitiesDescriptorName’ => ’IDPs & SPs del SINED’,
’filename’
=> ’idpsp_sined.xml’,
’maxCache’
=> 60*60*48, // 24 hour cache time
’maxDuration’
=> 60*60*24*7, // Maximum 5 days duration on ValidUntil.
’sign.enable’
=> TRUE,
’sign.privatekey’
=> ’janus.example.com.key’,
’sign.privatekey_pass’
=> ’’,
’sign.certificate’
=> ’janus.example.com.crt’,
),
),
Otros parametros:
’entity.useblacklist’ => true,
’entity.usewhitelist’ => false,
/* Permite habilitar listas blancas o negras a que IdPs se les
ESTA o NO ESTA permitido conectar con un SP */
Existe una wiki en la web de Janus donde viene más información sobre documentación de cada uno de estos atributos.
Importante. El cron que vamos a asociar al Janus para que automáticamente actualice los metadatos de
las entidades haciendo uso de la URL donde dichos metadatos están publicados por la entidad (atributo
‘metadata_refresh_cron_tags’ del archivo de configuración Janus) debe de estár dado de alta como tag válido en el
module_cron.php. Además tenemos que crear una entrada en el servicio de cron para que se ejecute con la periocidad
que deseemos.
4.3.2 Funcionamiento
A continuación se describen las principales vistas del software Janus. También puede consultar una serie de videos en
la web de Janus para entender su funcionamiento.
4.3. Gestor de metadatos en simpleSAMLphp - JANUS
26
Curso para operadores de Proveedores de Identidad, 1.0
Panel de administración de usuarios
Desde esta vista podremos crear, editar o eliminar usuarios. Cada usuario tendrá asociado un tipo y será identificado
por el ID de usuario. Una funcionalidad a destacar es que Janus permite tener usuarios inactivos, siempre será mejor
esta opción que la de borrarlo en el caso de que tengamos dudas sobre la cuenta.
Panel de administración de entidades
Desde esta vista podremos crear, deshabilitar o eliminar entidades, así como visualizar y editar los permisos de los
usuarios sobre las entidades. Si un usuario tiene permiso sobre una entidad, le aparecerá en su vista de listado de
entidades.
4.3. Gestor de metadatos en simpleSAMLphp - JANUS
27
Curso para operadores de Proveedores de Identidad, 1.0
Listado de entidades
En esta vista veremos un listado de las entidades que el usuario administra. Podremos ver el estado de cada una de las
entidades (se usan diferentes colores para cada estado y para saber si está habilitado o no. Estos colores se definen en
el archivo de configuración de Janus).
Además en esta vista podremos dar de crear nuevas entidades especificando el tipo de la entidad (IdP / SP) y el entityID
de la misma.
Exportador de entidades
En esta vista podremos exportar los metadatos de las entidades probando diferentes configuraciones. En esta vista
podremos simular posibles “feeds de entidades” que luego podremos configurar en el archivo de configuración de
janus, en el atributo ‘mdexport.feeds’
4.3. Gestor de metadatos en simpleSAMLphp - JANUS
28
Curso para operadores de Proveedores de Identidad, 1.0
Edición de ARPs
En esta vista podremos administrar las diferentes ARPs de Janus. Por cada ARP se le asigna un nombre, una
descripción y el conjunto de atributos que la componen. Además se puede establecer una determinada ARP para
que sea la ARP por defecto que se asocie a una entidad. Si una entidad no tiene ARP, Janus le asociará la ARP que
tenga configurada en el atributo ‘entity.defaultarp’ (Si no queremos que se asocie ARP dejaremos este atributo vacio
y no definiremos ARP en la entidad.
Si seleccionamos una determinada ARP, además de editarla se nos mostrará el conjunto de entidades que la están
utilizando en ese momento.
Panel de administración de una entidad
En esta vista se nos presenta información relacionada con la entidad:
Connection ID. Que es el entityID de la entidad
Metadata URL. Que es la dirección en la que se encuentran disponibles los metadatos de la entidad, y que es
la URL que es utilizada para que JANUS actualice automáticamente sus metadatos
ARP. Define la ARP asociada a la entidad
Revision note. Indica algún comentario asociado a la actual reversión de datos de la entidad
Parent revision. Indica cual es la revisión que precede a la actual.
State. Estado actual en el que se encuentra la entidad. El Workflow por el que pasan las entidades viene definido
en el archivo de configuración de Janus
Type. Tipo de entidad.
4.3. Gestor de metadatos en simpleSAMLphp - JANUS
29
Curso para operadores de Proveedores de Identidad, 1.0
Desde esta vista podemos acceder a diferentes vistas:
Metadata. Vista de edición de los metadatos
Import metadata. Vista de importación de los metadatos
History. Vista del historico. Desde esta vista podremos volver a una revisión anterior de los datos de la entidad.
Validate. VIsta de validación. Desde esta vista podremos validar los metadatos de la entidad. Hay que tener en
cuenta que si los certificados son autofirmados siempre se devolvera un error en la vista de validación.
Export. Vista de exportación de metadatos
Importador de metadatos de una entidad
Desde esta vista podremos importar los metadatos de una entidad. Se permiten varias formas:
Importar metadatos publicados en una URL.
Importar metadatos copiando su XML.
Importar metadatos copiando su JSON.
4.3. Gestor de metadatos en simpleSAMLphp - JANUS
30
Curso para operadores de Proveedores de Identidad, 1.0
Editor de metadatos de una entidad
Desde esta vista podremos editar los metadatos de una entidad.
4.3. Gestor de metadatos en simpleSAMLphp - JANUS
31
Curso para operadores de Proveedores de Identidad, 1.0
Vista de metadatos de una entidad
Desde esta vista podremos comprobar los metadatos que se están publicando de una determinada entidad. Se muestran
varios formatos: XML, “flatfile”
4.4 PEER
PEER es un proyecto para desarrollar un directorio de metadatos de los diferentes Proveedores de Identidad y
Proveedores de Servicio existentes en la actualidad. Los administradores de cada entidad pueden darla de alta en
el sistema trás la verificación de que ese administrador controla dicha entidad. Este directorio es capaz de publicar
colecciones de metadatos por lo que puede ser utilizado como servicio fuente fiable de metadatos.
4.4. PEER
32
CAPÍTULO
FIVE
GESTIÓN DE LOS DATOS DEL
USUARIO
5.1 La importancia del conjunto común de atributos
En un sistema federado, debido a la probable hetereogeneidad de los elementos que lo componen (IdPs y SPs), es
importante definir un conjunto común de los nombres de atributos que van a viajar por el. Siempre que se pueda se
deben de utilizar esquemas estandarizados de atributos: schac, eduPerson, eduOrg, etc
Puede darse el caso de que los nombres de atributos que el IdP recoja de la fuente de autenticación (BD, Ldap, etc) no
coincidan con los nombres utilizados en la federación. Esto se soluciona implementando filtros de mapeo de atributos
en el IdP que renombraran los atributos. Puede ocurrir que si tenemos un IdP conectado a 2 federaciones tengamos
que aplicar 2 filtros de mapeo de atributos diferentes según a que federación iran a parar los datos.
De la misma forma pueden llegar a un SP una serie de nombres de atributos y ser necesario que se tengan que renombrar
a los nombres de atributos que entiende el servicio al que el SP protege.
Cuando se trata de unir federaciones para formar una confederación es habitual interponer un elemento intermedio
que realizará el mapeo de atributos en ambos sentidos en el caso de que sea necesario.
Las federación de identidad deben de tener publicada la lista de atributos que utiliza para que los IdPs/SPs que quieran
adherirse a ella implementen los filtros necesarios. Por ejemplo estos son los atributos de la federación WAYF y estos
los atributos de la federación Confía.
Es importante que cada IdP conectado a un sistema federado devuelva un conjunto de atributos que satisfaga la ARP
de los diferentes SP. De lo contrario podría darse el caso de que un usuario aún estando identificado en la federación no
tuviera acceso a un recurso/servicio por no proporcionar al SP/aplicación el suficiente conjunto de atributos para poder
ejecutar su lógica de autorización/negocio. En el caso de que esto se permita es importante que al menos se avise al
usuario de lo que sucede, para facilitar la traceabilidad del problema. Generalmente las federaciones de indentidades
disponen de mecanismos para validar los atributos y comprobar que estos cumplen las diferentes ARP con datos
válidos.
5.2 LoAs
LoA (Level of Assurance). Es el nivel de garantía (confiabilidad) que le asignamos a un determinado proveedor de
identidad en un contexto determinado.
En una federación podemos definir por un lado diferentes LoAs para cada uno de los proveedores de identidad, y por
otro lado definir los niveles mínimos que requiere cada proveedor de servicio.
33
Curso para operadores de Proveedores de Identidad, 1.0
Existe una demo implementada como módulo de simpleSAMLphp que desarrolla este concepto. También está
disponible documentación del proyecto y el código del mismo. Tras ser presentado tuvo buena aceptación, JISC emitió
este informe final
La definición de LoAs y del Account Linking (permitir enlazar cuentas de bajo LoA a cuentas de mayor LoA) es aún
un campo muy interesante que aún está en investigación.
5.3 Políticas de liberación de atributos (ARPs)
Es una política que rige la liberación de los atributos del usuario desde los proveedores de identidad hacia los diferentes
proveedores de servicio.
Ya hemos visto que desde el gestor de metadatos Janus, era posible definir ARPs y asociarlas a los SPs. Ese conjunto
de atributos se definen dentro de los metadatos enmarcados con la etiqueta RequestedAttribute.
En simpleSAMLphp, en el caso de que esté definido el filtro attributeLimit y una ARP en los metadatos del SP, se
tomarán estos atributos como limitadores para ese determinado servicio.
5.4 Validación y consolidación de atributos en el IdP
Es bueno que cada Proveedor de Identidad aplique filtros para validar los datos que va a ofrecer a una federación o
a un proveedor de servicio en concreto. Siempre se ha de comprobar que al menos los atributos obligatorios que se
envían son válidos.
Una buena práctica a realizar por los administradores de los sistemas de gestión de identidad consistiría en ejecutar un
script que fuera recorriendo el arbol ldap y los registros de las bases de datos buscando entradas de usuarios que no
cumplieran los requisitos de la federación de identidad. (Detección temprana)
En simpleSAMLphp podemos utilizar el filtro ValidationFilter implementado en el módulo externo AttributeValidator.
Este filtro comprueba la presencia y el valor de los atributos devueltos por el IdP y los clasifica en requeridos,
recomendados, opcionales o desconocidos dependiendo de la configuración del filtro. El conjunto de atributos devuelto
por el IdP es considerado válido si todos los atributos requeridos están presentes en el esquema y son válidos.
(Detección al vuelo)
5.4.1 Instalación y configuración
Para usarlo lo descargamos en la carpeta modules
cd /var/www/idp/simplesamlphp/modules/
svn co https://forja.rediris.es/svn/confia/attributevalidator/trunk/ attributevalidator
y lo habilitamos
touch /var/www/idp/simplesamlphp/modules/attributevalidator/enable
Ejemplo de fichero de configuración (config-attributevalidator.php), se puede copiar una plantilla de la
carpeta config-template:
<?php
$config = array (
’auth’ => ’saml’,
’required_attrs’ => array (
’givenName’, ’cn’, ’sn’, ’schacSn1’, ’schacSn2’, ’displayName’,
5.3. Políticas de liberación de atributos (ARPs)
34
Curso para operadores de Proveedores de Identidad, 1.0
’irisMailMainAddress’, ’eduPersonScopedAffiliation’,
’eduPersonAffiliation’, ’eduPersonPrimaryAffiliation’,
’eduPersonPrincipalName’, ’eduPersonOrgDN’,
’schacPersonalUniqueID’,
),
’recommended_attrs’ => array (
’irisMailAlternateAddress’, ’mail’, ’schacUserPresenceID’,
’irisClassifCode’, ’schacUserStatus’,
’eduPersonEntitlement’, ’irisUserEntitlement’,
’schacUserPrivateAttribute’, ’schacPersonalUniqueCode’,
),
’optional_attrs’ => array (
’schacMotherTonge’, ’schacGender’, ’chacDateOfBirth’,
’schacPlaceOfBirth’, ’schacCountryOfCitizenship’,
’jpegPhoto’, ’eduPersonNickname’, ’schacPersonalTitle’,
’title’, ’preferredLanguage’, ’schacYearOfBirth’,
’postalAddress’, ’homePostalAddress’, ’street’, ’l’,
’postalCode’, ’mobile’, ’homePhone’, ’telephoneNumber’,
’fax’, ’schacCountryOfResidence’, ’eduPersonAssurance’,
’userCertificate’, ’userSMIMECertificate’,
’irisPublicKey’, ’uid’, ’o’, ’ou’, ’labeledURI’,
’description’, ’seeAlso’,
),
’generated_attrs’ => array(
’eduPersonTargetedID’, ’schacHomeOrganization’,
’schacHomeOrganizationType’,
),
’format_validation_regex’ => array(
’irisMailMainAddress’ =>
’/^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,3})$/i’,
’eduPersonScopedAffiliation’ =>
’/^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,3})$/i’,
’schacPersonalUniqueID’ =>
’/urn:mace:terena.org:schac:personalUniqueID:es:(.+):(.+)/’,
’schacUserStatus’ =>
’/urn:mace:terena.org:schac:userStatus:es:(.+):([0-9]{8}):(.+):(.+):(.+)/’,
’irisMailAlternateAddress’ =>
’/^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,3})$/i’,
’mail’ =>
’/^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,3})$/i’,
),
),
);
Ejemplo de filtro en el IdP (metadata/saml20-idp-source.php):
...
/* Este filtro impide que el usuario continúe con el proceso de autenticación si sus datos no
pasan el filtro. */
’authproc’ =>
array(
....
80 => array(
’class’ => ’attributevalidator:ValidationFilter’,
’check’ => array(’required_attrs’),
),
....
),
5.4. Validación y consolidación de atributos en el IdP
35
Curso para operadores de Proveedores de Identidad, 1.0
Es posible leer más documentación del filtro AttributeValidator
5.4.2 Funcionalidad de comprobación visual
Además del filtro, el módulo attributevalidator ofrece una vista a la que se accede desde el enlace “Módulo de
validación de atributos” de la pestaña de federación donde el usuario puede autenticarse y comprobar si los datos
que el Proveedor de Identidad ofrece de él són válidos.
Figura 5.1: Pantalla de validación de atributos
Esta implementación de validación es bastante génerica y sencilla, podrían construirse filtros más complejos que
por ejemplo fueran recorriendo los diferentes Proveedores de Servicio conectados, fueran leyendo los atributos que
requieren y se fuera indicando en cada caso si los atributos del ofrecidos por el IdP cumplen con las exigencias de cada
uno de ellos.
5.5 Consentimiento informado
El consentimiento informado consiste en delegar en el usuario la aprobación de que ciertos datos suyos sean
transferidos desde el Proveedor de Identidad hasta el Proveedor de Servicio. En caso de que el usuario rechazara
dicha aprobación, los datos del usuario no viajarían al Proveedor de Servicio por lo que seguramente se le impediría
el acceso al servicio o se le daría una funcionalidad limitada del mismo.
Es muy importante defininir una buena política de ARPs (Attribute Release Policy) para que a cada aplicación se le
envíen los datos mínimos que necesita del usuario.
En una federación de modelo Hub & Spoke, lo normal es que cada Proveedor de Identidad, delegue la responsabilidad
del consentimiento informado en el nodo central. Así se tendrá un único punto en el que se registren los
consentimientos de los usuarios.
5.5. Consentimiento informado
36
Curso para operadores de Proveedores de Identidad, 1.0
Figura 5.2: Pantalla de consentimiento informado
5.6 Configuración del consentimiento informado
En simpleSAMLphp La funcionalidad del consentimiento informado se obtiene añadiendo un filtro consent:Consent .
Una cosa importante a tener en cuenta es que el filtro necesita que definamos un atributo como clave primaria
a la que asociar el consentimiento, que será el que tengamos configurado en el parámetro ‘userid.attribute’ del
metadata/saml20-idp-hosted.php. Si no se ha especificado ninguno tomará por defecto el ‘eduPersonPrincipalname’. De no existir ese atributo en los datos de usuario el filtro dará una excepción.
Dicho filtro se encuentra en el módulo consent que debemos habilitar:
# touch /var/www/idp/simplesamlphp/modules/consent/enable
Puesto que en nuestro IdP de pruebas no todos los usuarios tienen definido el ‘eduPersonPrincipalname’, haremos uso
del ‘uid’ como clave primaria, por lo que añadiremos en el metadata/saml20-idp-hosted.php
’userid.attribute’ => ’uid’,
Tendremos la posibilidad de que el sistema “recuerde” que el usuario ha aceptado dar consentimiento a una
determinada transferencia de datos hacia un determinado Proveedor de Servicio para que no vuelva a presentarse
la petición del consentimiento. Existen 2 alternativas a la hora de almacenar dicho consentimiento:
Consentimiento informado almacenado en Cookies.
Consentimiento informado almacenado en base de datos.
Consentimiento informado básico que no se almacena
5.6. Configuración del consentimiento informado
37
Curso para operadores de Proveedores de Identidad, 1.0
El consentimiento no se almacena nunca. El sistema interrogará al usuario cada vez que se vaya a transferir sus datos
a un proveedor de servicio.
Para configurarlo añadiremos el filtro en el IdP para que sea lo último que se ejecute. Para ello añadimos el filtro en la
array ‘authproc’ del metadata/saml20-idp-hosted.php
’authproc’ => array(
...
90 => array(
’class’
=> ’consent:Consent’,
),
...
),
Consentimiento informado guardado en Cookies
El consentimiento se almacena en la cookie del navegador.
Características:
Es muy facil eliminar el consentimiento borrando la Cookie del navegador. Su nombre será de la forma:
“sspmod_consent:<identificador>”
Si cambiamos de PC tendrémos que volver a dar
Para configurarlo añadiremos el filtro en el IdP para que sea lo último que se ejecute. Para ello añadimos el filtro en la
array ‘authproc’ del metadata/saml20-idp-hosted.php
’authproc’ => array(
...
90 => array(
’class’
=> ’consent:Consent’,
’store’
=> ’consent:Cookie’,
’focus’
=> ’yes’, /* Para poner el foco en "Si" o en el "No". Los posibles valores son
"yes" y "no" */
’checked’
=> TRUE,
/* Para que por defecto la casilla de "Recordar consentimiento" esté
o no habilitada */
’ìncludeValues’ => FALSE, /* Sirve para que en caso de que los atributos cambien se
invalide el anterior consentimiento y se vuelva a pedir.
Por defecto False */
’hiddenAttributes’ array() /* Es una array con un conjunto de valores que serán enviados al
Proveedor de Servicio pero que no serán mostrados al usuario,
generalemente se ocultan valores de control o que necesita la
propia federación. */
),
...
),
Consentimiento informado guardado en Base de datos
Requiere una base de datos para funcionar.
Para permitir que un usuario pueda borrar su consentimiento deberemos habilitar el módulo consentAdmin. El
acceso a dicho módulo se realiza en la pestaña de configuración en el enlace “Administración de consentimiento”
Si cambiamos de PC no se nos requerirá consentimiento, ya que se encuentra almacenado en una base de datos
en el servidor
La Base de datos debe tener una tabla con la siguiente estructura:
CREATE TABLE consent (
consent_date TIMESTAMP NOT NULL,
usage_date TIMESTAMP NOT NULL,
5.6. Configuración del consentimiento informado
38
Curso para operadores de Proveedores de Identidad, 1.0
hashed_user_id VARCHAR(80) NOT NULL,
service_id VARCHAR(255) NOT NULL,
attribute VARCHAR(80) NOT NULL,
UNIQUE (hashed_user_id, service_id)
);
Para configurar el filtro añadiremos el filtro en el IdP para que sea lo último que se ejecute. Para ello añadimos el filtro
en la array ‘authproc’ del metadata/saml20-idp-hosted.php
’authproc’ => array(
...
90 => array(
’class’
=> ’consent:Consent’,
’store’
=> array(
’consent:Database’,
’dsn’ => ’mysql:host=localhost;dbname=consent’,
’username’ => ’consentuser’,
’password’ => ’consentpass’,
),
’focus’
=> ’yes’,
’checked’
=> TRUE
’hiddenAttributes’ => array (’groups’),
),
...
),
Para permitir que el usuario pueda borrar el consentimiento que se guarda en base de datos hemos dicho que hace falta
habilitar el módulo consentAdmin:
# touch /var/www/idp/simplesamlphp/modules/consentAdmin/enable
y lo configuramos siguiendo la plantilla que existe en config-template/module_consentAdmin.php:
$config = array(
/*
* Hace falta configurar la base de datos, copiamos la info del filtro de consentimiento
*/
’consentadmin’ => array(
’consent:Database’,
’dsn’ => ’mysql:host=localhost;dbname=consent’,
’username’ => ’consentuser’,
’password’ => ’consentpass’,
),
// Indicar si hemos habilitado el parámetro ’includeValues’ en el filtro o no.
’attributes.hash’ => FALSE,
// Indicar donde queremos redirigir al usuario si sale del sistema.
’returnURL’ => ’https://idp.example.com/simplesaml/module.php/core/frontpage_welcome.php’,
/* Indicar si queremos añadir la descripción de los servicios en la vista que se le presenta
al usuario para gestionar sus permisos (Por defecto está a ’true’) */
’showDesription’ => true,
/* Establecer la fuente que tengamos definida en el authsources en la que se encuentre
el filtro de consentimiento. (Se requerirá al usuario que se autentique para acceder
al panel de administración de consentimiento) */
’authority’ => ’saml’,
);
5.6. Configuración del consentimiento informado
39
Curso para operadores de Proveedores de Identidad, 1.0
Acceder a documentación adicional sobre consentimiento informado
Personalización de la vista de consentimiento
Si queremos personalizar la vista de consentimiento deberemos acceder a la carpeta templates del módulo consent
y modificar el archivo consentform.php y los archivos de diseño del www/style.css. Aunque lo ideal realmente no es
sobreescribir este archivo sino crear un tema (nuevo módulo de simplesamlphp en el que se redefinen plantillas y se
almacenan imagenes personalizadas).
5.6. Configuración del consentimiento informado
40
CAPÍTULO
SIX
PROTOCOLO DE RESOLUCIÓN DE
INCIDENCIAS EN UN ENTORNO DE
FEDERACIÓN DE IDENTIDADES
6.1 Errores más frecuentes
Los errores más frecuentes que se dan en nuestra federación son:
Problemas en las conexiones a las fuentes de atributos como servidores de bases de datos o directorios. En
ocasiones el servidor de base de datos funciona correctamente pero lo que se queda bloqueado es el conector
del IdP a esa base de datos.
Usuarios que no tienen los atributos obligatorios. En este caso el nodo Hub es capaz de detectar este problema
e informa de esto al usuario.
Usuarios que no tienen el atributo eduPersonPrincipalName. Se produce una excepción ya que ese atributo es
requerido por simpleSAMLphp para funcionar correctamente ya que es el atributo que está establecido como
identificador del usuario.
Que las correspondencias de asignaturas en los LMS no sean correctas.
Si en el flujo de autenticación el usuario le da al botón de atrás del navegador, o se corta la conexión u otro
fallo inesperado, se pierde la sesión y es necesario que cierre el navegador y vuelva a empezar. El error que se
visualiza en este caso es “Lost state”.
Si el usuario hace click dos veces seguidas en el botón de autenticar se produce el error “Duplicated assertion
sent”.
6.2 Protocolo de gestión de errores actual
6.2.1 Falta de datos
Si el problema se ocasiona en el nodo Hub y se debe a que los atributos necesarios no están disponibles, se le presenta
una pantalla al usuario y se le informa de esta circunstancia indicandole que se ponga en contacto con el administrador
de su IdP. En esta caso se obtiene el IdP concreto a partir del atributo eduPersonPrincipalName.
Sin embargo, si uno de los atributos que faltan es el propio eduPersonPrincipalName se produce una excepción y entre
otras cosas el sistema no sabe qué IdP debe indicarle para solucionar el problema. En este caso se envía un correo a
los operadores de la federación con los atributos del usuario de los que se dispone. Los operadores examinan estos
atributos para ver si es posible averiguar el IdP de orígen de dicho usuario para informar a su administrador. Si el
41
Curso para operadores de Proveedores de Identidad, 1.0
usuario está utilizando la dirección de correo institucional, la tarea de obtener su IdP de orígen suele ser fácil. Sin
embargo, en muchas ocasiones, los usuarios utilizan correos de proveedores externos como Hotmail, GMail, etc. y por
tanto, no es posible obtener el IdP a partir de la dirección de correo.
6.2.2 Excepciones
Si se produce cualquier otro de los errores frecuentes anteriormente citados se le presenta al usuario una pantalla en
la que se le permite al usuario “reportar el error”. Ese correo se envía al operador de la federación en el caso de que
se produzca en el nodo hub (y si está bien configurado el IdP también debe llegar al administrador del proveedor de
identidad).
6.2.3 ¿Que pasa si el problema persiste?
Actualmente si el problema persiste, el operador de la federación accede a la cuenta de correo de contacto de
confia.aupa.info y desde esa cuenta informa al usuario el motivo de por qué se está produciendo dicho error y le
propone una solución: Borrar las cookies del navegador, tener cuidado en la navegación o ponerse en contacto con el
CAU de su universidad.
6.2. Protocolo de gestión de errores actual
42
CAPÍTULO
SEVEN
DESPLEGAR UN IDP CON
SIMPLESAMLPHP
7.1 Recursos de ayuda
Documentación de instalación de simpleSAMLphp
Documentación de configuración como IdP en simpleSAMLphp
Docuemntación de la wiki de Confía (y como actualizar de una version a otra)
Lista de correo
7.2 Instalación y configuración
7.2.1 Instalación y dependencias
Vamos a explicar como instalar SimpleSAMLphp en una distribución CentOS 5.6, la cual está disponible para su
descarga desde http://isoredirect.centos.org/centos/5/isos/x86_64/
Una vez se encuentre el sistema operativo instalado, se debe proceder a la instalación de los siguientes paquetes,
requeridos para el correcto funcionamiento de SimpleSAMLphp:
php53
php53-pdo
php53-mysql
php53-mbstring
php55-xml
zlib
pcre
openssl
httpd
libmcrypt
libmcrypt-devel
php53-devel
43
Curso para operadores de Proveedores de Identidad, 1.0
mhash
mhash-devel
mod_ssl
SimpleSAMLphp requiere, además de los anteriores paquetes, de ‘php53-mcrypt’ y ‘php53-memcache’. Por defecto,
estas dependencias no se encuentran en los repositorios oficiales de CentOS 5.6, asi que es necesario compilar dichas
extensiones.
Compilación de php53-mcrypt
Se deben seguir los siguientes pasos para conseguir la extensión de mcrypt:
1. Descargar el código fuente de php-5.3.3 http://es.php.net/get/php-5.3.3.tar.bz2/from/this/mirror y descomprimir
el tarball.
2. Acceder al directorio de extensiones llamado ‘ext’:
# cd php-5.3.3/ext
3. Acceder al directorio de la extension ‘mcrypt’:
# cd mcrypt
4. Preparar la extension antes de ser compilada:
# phpize
# aclocal
5. Proceder con la configuración, compilación e instalación:
# ./configure && make && make install
6. La extensión se deberá instalar en el directorio /usr/lib64/php/modules/. Es necesario crear un fichero
de configuración para la nueva extensión de PHP en el directorio /etc/php.d/ con el siguiente contenido:
extension=mcrypt.so
7. Reiniciar el servicio httpd:
# servide httpd restart
8. Es posible comprobar que el nuevo módulo se encuentra activo creando un fichero index.php en el directorio
de publicación de Apache2 con el siguiente código:
<?php phpinfo(); ?>
Compilación de php53-memcache
Se deben seguir los siguientes pasos para conseguir la extensión memcached:
1. Descargar el código de memcached http://pecl.php.net/get/memcache-2.2.4.tgz y lo descomprimir.
2. Preparar el paquete con la utilizar phpize:
# phpize
3. Configurar, compilar e instalar el módulo:
7.2. Instalación y configuración
44
Curso para operadores de Proveedores de Identidad, 1.0
# ./configure && make && make install
4. La nueva extensión deberá haberse instalado en el directorio /usr/lib64/php/modules/. Es necesario
crear un fichero de configuración para la nueva extensión de PHP en el directorio /etc/php.d/ con el
siguiente contenido:
; Enable memcache extension module
extension=memcache.so
5. Reiniciar el servicio httpd:
# service httpd restart
6. Es posible comprobar que el nuevo módulo se encuentra activo creando un fichero index.php en el directorio
de publicación de Apache2 con el siguiente código:
<?php phpinfo(); ?>
7.2.2 Instalación de SimpleSAMLphp
Una vez resueltas todas las dependencias, la instalación de SimpleSAMLphp es realmente sencilla, solamente es
necesario descargar el código fuente en un directorio del sistema, por ejemplo en el directorio /var/www/idp/:
# svn co http://simplesamlphp.googlecode.com/svn/branches/simplesamlphp-1.8 simplesamlphp
Estructura general
|--cert
|--config
|--config-templates
|--metadata
|--metadata-templates
|--modules
|--lib
|--www
|--templates
|--dictionaries
|--docs
|--log
|--attributemap
|--schemas
|--bin
Directorio
Directorio
Directorio
Directorio
Directorio
Directorio
Directorio
Directorio
Directorio
Directorio
Directorio
Directorio
Directorio
Directorio
Directorio
donde alojar el certificado y la clave que serán usados para firmar
con los ficheros de configuración de simpleSAMLphp
con plantillas de los ficheros de configuración
donde alojar el fichero de los metadatos del IdP y ficheros con los
con plantillas de los ficheros de metadatos
con los diferentes módulos de simpleSAMLphp
con las librerias de simpleSAMLphp
con la lógica web de simpleSAMLphp
con las plantillas web de simpleSAMLphp
con las traducciones de simpleSAMLphp
con dcd ocumentación
donde alojar los logs de simpleSAMLphp (Requiere configurar el conf
con ficheros con lógica para realizar el mapeo de atributos
con esquemas xsd.
con herramientas de scripts
Hay que asegurarse que el servidor Apache tenga acceso de escritura a los directorios logs y metadata.
Configuración general
Los ficheros de configuración de simpleSAMLphp se localizan dentro del directorio config donde se haya
instalado simpleSAMLphp. En el directorio config-templates se encuentran plantillas de los principales ficheros
de configuración que se pueden necesitar en simpleSAMLphp. Es bastante útil partir de una de estas plantillas y
modificarla a conveniencia en lugar de crear el fichero de configuración correspondiente desde cero, lo cuál suele ser
mucho más propenso a errores.
El primer fichero a modificar es el fichero config.php. Por tanto, lo mejor es copiar su plantilla correspondiente:
7.2. Instalación y configuración
45
Curso para operadores de Proveedores de Identidad, 1.0
# cp /var/www/idp/simplesamlphp/config-templates/config.php /var/www/idp/simplesamlphp/config/config.
Como todos los ficheros de configuración de simpleSAMLphp es un fichero PHP con las reglas de sintáxis de este
lenguaje. Un comando útil que debemos ejecutar siempre que hagamos modificaciones a este fichero es php -l ya que
nos dirá si hay fallos de sintaxis y puede ahorrar tiempo y problemas:
# php -l /var/www/idp/simplesamlphp/config/config.php
No syntax errors detected in /var/www/idp/simplesamlphp/config/config.php
A continuación se detallan las partes más habituales del fichero config.php que hay que modificar:
Contraseña de administración de simpleSAMLphp
’auth.adminpassword’ => ’admin’,
Es importante cambiar esta contraseña porque además de ser un problema de seguridad si se deja tal cual,
simpleSAMLphp lo detectará y dará un error.
Sal aleatoria y secreta:
’secretsalt’ => ’defaultsecretsalt’,
Para generar este valor se puede utilizar el siguiente comando:
# tr -c -d ’0123456789abcdefghijklmnopqrstuvwxyz’ </dev/urandom
| dd bs=32 count=1 2>/dev/null;echo
1zpz5ztl1w5hnqhx8969thxab68us5og
Nombre y dirección de correo del administrador de este simpleSAMLphp:
’technicalcontact_name’ => ’Administrator’,
’technicalcontact_email’ => ’na@example.org’,
Zona horaria:
’timezone’ => NULL,
Un valor de ejemplo para este parámetro es ‘Europe/Madrid’
Idioma predeterminado:
’language.default’ => ’en’,
Lo más habitual es poner el valor ‘es’ para que la interfaz de simpleSAMLphp salga en español.
Hay muchas más opciones de configuración pero estás son las más básicas y necesarias de modificar. Los comentarios
en el fichero config.php explican bastante bien para qué sirve cada uno de los parámetros de configuración.
Configuración como IdP
Para configurar simpleSAMLphp como IdP es necesario habilitar el parámetro ‘enable.saml20-idp’ en el fichero de
configuración config/config.php:
’enable.saml20-idp’ => true,
7.2.3 Configuración de las fuentes de autenticación
La configuración de una fuente de autenticación en SimpleSAMLphp
config/authsources.php. Para ello es necesario seguir dos pasos:
7.2. Instalación y configuración
se
realiza
en
el
fichero
46
Curso para operadores de Proveedores de Identidad, 1.0
1. Habilitar los módulos de autenticación que necesitemos, como ejemplo, habilitaremos el módulo ‘exampleauth’:
# touch modules/exampleauth/enable
2. Se deberá editar el fichero config/authsources.php, añadiendo fuentes de autenticación. En este
ejemplo vemos configuradas fuentes sencillas (admin, exampleauth):
<?php
$config = array(
’admin’ => array(
// The default is to use core:AdminPassword, but it can be replaced with
// any authentication source.
’core:AdminPassword’,
),
’example-userpass’ => array(
’exampleauth:UserPass’,
’usuario1:usuario1.’ => array(
’uid’ => array(’usuario1’),
’eduPersonAffiliation’ => array(’member’, ’student’),
),
’usuario2:usuario2.’ => array(
’uid’ => array(’usuario2’),
’eduPersonAffiliation’ => array(’member’, ’employee’),
),
),
);
?>
En la web de simpleSAMLphp se dispone de documentación sobre configuraciones de las fuentes de autenticación
7.2.4 Configuración del metadato del IdP
Los metadatos del IdP deben de definirse dentro de la carpeta metadata en el fichero saml20-idp-hosted.php.
A continuación se presenta un ejemplo:
<?php
/* The index of the array is the entity ID of this IdP. */
$metadata[’https://idp.example.com/simplesaml/saml2/idp/metadata.php’] = array(
’host’ => ’idp.example.com’,
/* Configuration options. */
/* Organization info */
’OrganizationName’ => array(
’en’ => ’Example organization’,
’es’ => ’Organizacion de ejemplo’,
),
’OrganizationURL’ => array(
’en’ => ’http://idp.example.com’,
’es’ => ’http://idp.example.com’,
),
/* The private key and certificate used by this IdP. */
’certificate’ => ’idp.example.com.crt’,
’privatekey’ => ’idp.example.com.key’,
7.2. Instalación y configuración
47
Curso para operadores de Proveedores de Identidad, 1.0
/*
* The authentication source for this IdP. Must be one
* from config/authsources.php.
*/
’auth’ => ’example-userpass’,
// Logout requests and logout responses sent from this IdP should be signed
’redirect.sign’ => TRUE,
// All communications are encrypted
’assertion.encryption’ => TRUE,
);
?>
La clave del array $metadata es el identificador de entidad (EntityID) y es importante que coincida con la URL que
devuelve los metadatos del propio IdP por motivos de interoperabilidad SAML 2.0. Normalmente es suficiente con
modificar el nombre del host y dejar el resto de la URL tal cual se ve en este ejemplo.
A continuación se detallan los principales parámetros que hay que configurar dentro del array de metadatos para una
entidad en concreto:
host Nombre del host de esta máquina que se utiliza en el VirtualHost de Apache correspondiente
certificate y privatekey Son las dos partes (pública y privada) del certificado usado en el IdP. Estos ficheros deben
encontrarse en el directorio cert del directorio raíz de simpleSAMLphp a no ser que se haya cambiado esa
ubicación en el fichero config.php
auth Este parámetro debe tener como valor el nombre de la fuente de autenticación que se desea usar para autenticar
a los usuarios de este IdP. En el ejemplo anterior ‘example-ldap’ hace referencia a la fuente de autenticación
LDAP que se configuró anteriormente.
redirect.sign, redirect.validate Estos parámetros deben estar a TRUE para que las aserciones se validen y se firmen
assertion.encryption Este parámetro deben estar a TRUE para que se cifren las aserciones SAML que genera este
IdP
7.2.5 Configuración de los metadatos de los SPs
Los metadatos de los SP en los que el IdP va a confiar deben de definirse dentro de la carpeta metadata en el fichero
saml20-sp-remote.php. A continuación se presenta un ejemplo:
<?php
/* The index of the array is the entity ID of this SP. */
$metadata[’https://sp.example.com/simplesaml/module.php/saml/sp/metadata.php/saml’] = array (
’AssertionConsumerService’ => ’https://sp.example.com/simplesaml/module.php/saml/sp/saml2-acs.php
’SingleLogoutService’ => ’https://sp.example.com/simplesaml/module.php/saml/sp/saml2-logout.php/s
’certData’ => ’MIICmTCCAgICCQDHTTCmM3WMCzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UEBhMCRVMxDjAMBgNVBAgTBX
zcC5leGFtcGxlLmNvbTEXMBUGA1UEAxMOc3AuZXhhbXBsZS5jb20xHjAcBgkqhkiG9w0BCQEWD3NtYXJ0a
YDVQQGEwJFUzEOMAwGA1UECBMFc3BhaW4xEDAOBgNVBAcTB3NldmlsbGUxDTALBgNVBAoTBHlhY28xFzAV
BwGCSqGSIb3DQEJARYPc21hcnRpbkB5YWNvLmVzMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCnhEe
W1edLwVW72mZ8enl+jL3eEqwlUUz88GyC4h5t/inZ4WTW8jXc5WSNZYUXvk3F0uAO/PmKBEjFoUrA8It3J
grB9Ax8t53uTbtVkXTb/haCwrWDuRywnMjgx7QhpN5RhL5UXPU1n617V2NROVNTH+2ROlhRyPS8l2KpAuV
eug2M7gZeK’,
);
?>
7.2. Instalación y configuración
48
Curso para operadores de Proveedores de Identidad, 1.0
7.2.6 Configuración de Apache
Se debe crear un fichero de configuración para el VirtualHost de idp.example.com.conf en el directorio
/etc/httpd/conf.d/ con el siguiente contenido:
<VirtualHost *:80>
ServerName idp.example.com
DocumentRoot /var/www/idp/simplesamlphp/www
SSLProxyEngine On
ProxyPreserveHost On
Alias /simplesaml /var/www/idp/simplesamlphp/www
<Location />
ProxyPass https://localhost
</Location>
</VirtualHost>
<VirtualHost *:443>
ServerName idp.example.com
DocumentRoot /var/www/idp/simplesamlphp/www
Alias /simplesaml /var/www/idp/simplesamlphp/www
SSLEngine on
SSLCertificateFile /etc/httpd/ssl/idp.example.com/crt/idp.example.com.crt
SSLCertificateKeyFile /etc/httpd/ssl/idp.example.com/key/idp.example.com.key
</VirtualHost>
Además es necesario crear los certificados (autogenerados) que se han especificado en la configuracion del VirtualHost
para https. Se deberán seguir las siguientes instrucciones:
1. Crear el directorio donde alojar los certificados, en este caso, /etc/httpd/ssl/idp.example.com/:
# mkdir -p /etc/httpd/ssl/idp.example.com/crt /etc/httpd/ssl/idp.example.com/key
2. Cambiar el directorio actual por /etc/httpd/ssl/idp.example.com/:
# cd /etc/httpd/ssl/idp.example.com/
3. Creación de la clave sin contraseña y con una encriptación 1024:
# openssl genrsa -out key/idp.example.com.key 1024
4. Generar el fichero CSR (solicitud de certificado):
# openssl req -new -key key/idp.example.com.key -out idp.example.com.csr
5. Generar el certificado autofirmado:
# openssl x509 -req -days 1825 -in idp.example.com.csr -signkey key/idp.example.com.key
-out crt/idp.example.com.crt
Por último, es necesario reiniciar el servicio httpd para que la nueva configuración sea aplicada:
# service httpd restart
Certificado (idp.example.com.crt) y clave (idp.example.com.key) deberemos también de tenerlos accesibles en la
carpeta cert del simpleSAMLphp para que sean usados en el firmado y cifrado de aserciones. Para ello lo mejor
es crear enlaces simbólicos:
ln -s /etc/httpd/ssl/idp.example.com/key/idp.example.com.key /var/www/idp/simplesamlphp/cert/idp.exam
ln -s /etc/httpd/ssl/idp.example.com/crt/idp.example.com.crt /var/www/idp/simplesamlphp/cert/idp.exam
7.2. Instalación y configuración
49
Curso para operadores de Proveedores de Identidad, 1.0
7.3 Backends de autenticación
Las fuentes de autenticación son usadas para identificar al usuario y obtener de el una serie de atributos. En un entorno
de SSO, las fuentes de autenticación sólo son consultadas una única vez ya que los atributos del usuario se encontraran
cacheados hasta que el usuario se deslogue.
En simpleSAMLphp las fuentes de auntenticación se configuran en config/authsources.php. En dicho fichero
pueden definirse cuantas fuentes de autenticación se deseen (incluso varias del mismo tipo).
El patrón es el siguiente:
$config = array(
...
’<nombre-fuente>’ => array(
’<modulo-fuente-autenticacion>:<nombre-fuente-autenticacion>’,
<configuration>
...
’example-userpass’ => array(
’exampleauth:UserPass’,
’usuario1:usuario1.’ => array(
’uid’ => array(’usuario1’),
’eduPersonAffiliation’ => array(’member’, ’student’),
),
),
...
);
Podemos encontrar multitud de fuentes en simpleSAMLphp:
authfacebook:Facebook
authlinkedin:LinkedIn
authmyspace:MySpace
authX509:X509userCert
authwindowslive:LiveID
authtwitter:Twitter
authYubiKey:YubiKey
cas:CAS
exampleauth:External
exampleauth:Static
exampleauth:UserPass
InfoCard:ICAuth
ldap:LDAP
ldap:LDAPMulti
multiauth:MultiAuth
openid:OpenIDConsumer
radius:Radius
saml:SP
7.3. Backends de autenticación
50
Curso para operadores de Proveedores de Identidad, 1.0
7.4 Repaso de filtros en simpleSAMLphp
Los filtros pueden definirse en el IdP o en el SP. Dentro de cada elemento se pueden configurar en distintos sitios:
En config.php, lo cual afectará globalmente al toda la instancia de simpleSAMLphp. Los filtros se pueden
colocar dentro de dos parámetros:
En ‘authproc.idp’, lo cual hará que se ejecuten los filtros en la parte IdP para todas las entidades alojadas.
En ‘authproc.sp’, lo cual hará que se ejecuten los filtros en la parte SP para todas las entidades alojadas.
Los siguientes filtros se ejecutan de manera local y se definen en la array ‘authproc’:
En un SP:
En config/authsources.php, lo cual afectará al propio SP.
En saml20-idp-remote.php, lo cual afectará a un IdP remoto concreto.
En un IdP:
En saml20-idp-hosted.php, lo cual afectará al propio IdP.
En saml20-sp-remote.php, lo cual afectará a un SP remoto concreto.
Es importante en que orden se ejecutan los filtros ya que el resultado final puede ser diferente. Por ello es importante
observar que todos los filtros definidos tengan el orden correcto que viene indicado por el número del índice del array
(los números más bajos se ejeutan antes).
Existe documentación detallada sobre los filtros de atributos implementados en simpleSAMLphp.
7.4.1 Ejemplos de filtros de atributos
Generación de atributos
ePTI: Implementado como filtro core:AttributeAlter:
10 => array(
’class’ => ’core:AttributeAlter’,
’subject’ => ’eduPersonTargetedID’,
’pattern’ => ’/^(.*)$/’,
’replacement’ => ’\1@<dominio>’
),
Comprobación de atributos
Filtro DNI: Implementado como filtro core:PHP:
11 => array(
’class’ => ’core:PHP’,
’code’ => ’
if(isset($attributes["schacPersonalUniqueID"])) {
foreach($attributes["schacPersonalUniqueID"] as $i => $personaluniqueid) {
$regex = "/urn:mace:terena.org:schac:personalUniqueID:es:(.*):([0-9]{8})$/";
if(preg_match($regex, $personaluniqueid, $values)) {
$dni = $values[2];
$letraNif= substr("TRWAGMYFPDXBNJZSQVHLCKE",$dni %23,1);
$attributes["schacPersonalUniqueID"][$i] .= $letraNif;
7.4. Repaso de filtros en simpleSAMLphp
51
Curso para operadores de Proveedores de Identidad, 1.0
}
}
}
’,
),
Eliminación de atributos
Filtro contraseña: Implementado como filtro core:AttributeAdd:
12 => array(
’class’ => ’core:AttributeAdd’,
’ %replace’,
’userPassword’ => ’’,
),
Fitro limitador de atributos (sólo deja pasar los atributos aquí definidos): Implementado como
core:AttributeLimit:
13 => array(
’class’ => ’core:AttributeLimit’,
// required
’gn’,’givenName’, ’cn’, ’sn’, ’schacSn1’, ’displayName’,
’irisMailMainAddress’, ’eduPersonScopedAffiliation’,’eduPersonAffiliation’,
’eduPersonPrimaryAffiliation’,’eduPersonPrincipalName’,’schacPersonalUniqueID’,
// recommended
’irisMailAlternateAddress’, ’mail’, ’schacUserPresenceID’,
’irisClassifCode’, ’schacUserStatus’,
’eduPersonEntitlement’, ’irisUserEntitlement’,
’schacUserPrivateAttribute’, ’schacPersonalUniqueCode’,
// optionals
’schacSn2’, ’schacMotherTonge’, ’schacGender’, ’chacDateOfBirth’,
’schacPlaceOfBirth’, ’schacCountryOfCitizenship’,
’jpegPhoto’, ’eduPersonNickname’, ’schacPersonalTitle’,
’title’, ’preferredLanguage’, ’schacYearOfBirth’,
’postalAddress’, ’homePostalAddress’, ’street’, ’l’,
’postalCode’, ’mobile’, ’homePhone’, ’telephoneNumber’,
’fax’, ’schacCountryOfResidence’, ’eduPersonOrgDN’,
’eduPersonAssurance’, ’userCertificate’, ’userSMIMECertificate’,
’irisPublicKey’, ’uid’, ’o’, ’ou’, ’labeledURI’,
’description’, ’seeAlso’,
// others
’eduPersonTargetedID’, ’schacHomeOrganization’, ’schacHomeOrganizationType’,
),
Ejemplo de creación de datos con core:PHP
Creación de datos de un usuario para realizar tests:
60 => array(
’class’ => ’core:PHP’,
’code’ =>
’
if(isset($attributes["eduPersonPrincipalName"]) &&
strpos($attributes["eduPersonPrincipalName"][0], "confiatest@") !== false) {
$scope_university = "university.es";
7.4. Repaso de filtros en simpleSAMLphp
52
Curso para operadores de Proveedores de Identidad, 1.0
$attributes = array();
$attributes["uid"] = array("confiatest");
$attributes["givenName"] = array("Pruebas");
$attributes["cn"] = array("Pruebas Confia");
$attributes["sn"] = array("Confia");
$attributes["schacSn1"] = array("Confia");
$attributes["schacSn2"] = array("");
$attributes["displayName"] = array("Pruebas Confia");
$attributes["irisMailMainAddress"] = array("confiatest@".$scope_university);
$attributes["eduPersonAffiliation"] = array("affiliate");
$attributes["eduPersonScopedAffiliation"] = array("affiliate".$scope_university);
$attributes["eduPersonPrimaryAffiliation"] = array("affiliate");
$attributes["eduPersonPrincipalName"] = array("confiatest@".$scope_university);
$attributes["schacPersonalUniqueID"] = array("urn:mace:terena.org:schac:personalUniqu
$attributes["schacUserStatus"] = array();
$base_course = "urn:mace:terena.org:schac:userStatus:es:campusandaluzvirtual.es:";
$attributes["schacUserStatus"][] = $base_course."98705999:2009-10:student:active";
$attributes["schacUserStatus"][] = $base_course."98706999:2009-10:student:active";
$attributes["schacUserStatus"][] = $base_course."98708999:2009-10:student:active";
$attributes["schacUserStatus"][] = $base_course."98711999:2009-10:student:active";
$attributes["schacUserStatus"][] = $base_course."98717999:2009-10:student:active";
$attributes["schacUserStatus"][] = $base_course."98748999:2009-10:student:active";
$attributes["schacUserStatus"][] = $base_course."98749999:2009-10:student:active";
$attributes["schacUserStatus"][] = $base_course."98750999:2009-10:student:active";
$attributes["schacUserStatus"][] = $base_course."98758999:2009-10:student:active";
$attributes["schacUserStatus"][] = $base_course."98763999:2009-10:student:active";
$attributes["schacUserStatus"][] = $base_course."99999999:2009-10:student:active";
}
’,
),
AttributeCollector
El AttributeCollector permite añadir atributos desde otra fuente, ya sea una BD (attributecollector:SQLCollector) o un
ldap (attributecollector:LDAPCollector).
Ejemplo:
’authproc’ => array(
10 => array(
’class’ => ’attributecollector:AttributeCollector’,
’existing’ => ’preserve’,
’uidfield’ => ’subject’,
# Aqui se añade la configuración del filtro concreto
)
),
Parámetros:
class: La clase del filtro. Siempre : ‘attributecollector:AttributeCollector’
uidfield: El nombre del campo usado como identificador único del usuario. El colector configurado recibe este
identificador para poder realizar la busqueda de atributos.
collector: Configuración del colector que va a ser usado.
7.4. Repaso de filtros en simpleSAMLphp
53
Curso para operadores de Proveedores de Identidad, 1.0
existing: Opcional. Dice al filtro que hacer cuando ya exista un valor para el atributo encontrado en la
recolección. Las aleternativas pueden ser:
‘preserve’: Ignora el valor del atributo recolectado y conserva el que ya tenía. Opción por omisión.
‘replace’: Ignora lo que había y la remplaza con el valor nuevo.
‘merge’: Mezcla lo recolectado con lo que ya se tenía.
Configuración del filtro attributecollector:SQLCollector
Recolecta atributos de un ldap.
Parámetros:
dsn: EL DSN que debe ser usado para conectar con la base de datos. Visualiza los diferentes formatos en
http://php.net/manual/en/pdo.drivers.php
username: El nombre de usuario que debe de ser usado para conectar con la BD.
password: Password para autenticarse con la BD.
query: Consulta sql para obtener los atributos. Puedes usar la cadena especial :uidfield para hacer referencia al
valor del atributo que se especifico en el campo uidfield.
Ejemplo
’collector’ => array(
’class’ => ’attributecollector:SQLCollector’,
’dsn’ => ’pgsql:host=localhost;dbname=simplesaml’,
’username’ => ’simplesaml’,
’password’ => ’secretpassword’,
’query’ => ’select address, phone, country from extraattributes where uid=:uidfield’,
)
Ejemplo complejo:
’collector’ => array(
’class’ => ’attributecollector:SQLCollector’,
’dsn’ => array(’oci:dbname=first’,
’mysql:host=localhost;dbname=second’
),
’username’ => array(’first’, ’second’),
’password’ => array(’first’, ’second’),
’query’ => array("SELECT sid as SUBJECT from subjects where uid=:uid",
"SELECT sid as SUBJECT from subjects where uid=:uid AND status=’OK’",
),
),
)
Configuración del filtro attributecollector:LDAPCollector
Recolecta atributos de una base de datos.
Parámetros:
host: Host del servidor LDAP
port: Puerto del servidor LDAP
protocol: Protocolo LDAP
binddn: El nombre de usuario que debe ser usado para conectar con el LDAP
password: Password del usuario necesario para conectar con el LDAP
7.4. Repaso de filtros en simpleSAMLphp
54
Curso para operadores de Proveedores de Identidad, 1.0
basedn: DN base para las búsquedas LDAP
attrlist: Array asociativo de [LDAP attr1 => atr1, LDAP attr2 => atr2]
searchfilter: Filtro usado para buscar en el directorio. Puedes usar la cadena especial :uidfield para hacer
referencia al valor del atributo que se especifico en el campo uidfield.
Ejemplo:
’collector’ => array(
’class’ => ’attributecollector:LDAPCollector’,
’host’ => ’myldap.srv’,
’port’ => 389,
’binddn’ => ’cn=myuser’,
’password’ => ’secret’,
’basedn’ => ’dc=my,dc=org’,
’searchfilter’ => ’uid=:uidfield’,
’protocol’ => 3,
’attrlist’ => array(
// LDAP attr => real attr
’objectClass’ => ’myClasses’,
),
),
AttributeValueFilter
El filtro AttributeValueFilter elimina determinados valores de los atributos basándose en patrones definidos.
Parámetros:
class: La clase del filtro, que es siempre: ‘coursefilter:CourseFilter’.
attributename: El nombre del campo de los atributos que queremos filtrar
spmapping: Contiene el mapeo entity_id <–> patrón de busqueda (y opcionalmente el valor a remplazar)
Ejemplo:
<?php
$course_pattern = ’urn:mace:terena.org:schac:userStatus:es:’ .
’example.com:987 %CODE %\d{3}:\d{4}-\d{2}:student:(in)?active’;
$sps = array(
’example1.com’ => ’48’,
’example2.com’ => ’05’,
’example3.com’ => ’06’,
’example4.com’ => ’08’,
);
foreach ($sps as $sp => $code)
$sps_patterns["|$sp|"] = str_replace(’ %CODE %’, $code, $course_pattern);
$config = array(
’authproc.idp’ => array(
60 => array(
’class’
=> ’attributevaluefilter:AttributeValueFilter’,
’attributename’ => ’schacUserStatus’,
’spmapping’ => $sps_patterns,
),
),
);
7.4. Repaso de filtros en simpleSAMLphp
55
Curso para operadores de Proveedores de Identidad, 1.0
7.5 Alta disponibilidad
7.5.1 Replicación y balanceo de carga
Lo primero que debemos hacer es replicar las instancias tantas veces como queramos. Cuantas mas instancias tengamos
replicadas mayor podra ser el reparto de carga y más dificil será que el sistema quede fuera de servicio.
Lo ideal es que las instancias replicadas se encuentren en máquinas fisicas diferentes para que si se produce un fallo
fisico sigan quedando instancias operativas.
Como balanceador de carga si no se dispone de un balanceador físico recomendamos el balanceador software HA
Proxy. Generalmente los balanceadores de carga para ver si una instancia está operativa o no requieren la inclusión
de un pequeño fichero que es instalado en cada una de las instancias. Dicho fichero es consultado de forma periódica
para tener actualizado el estado de cada instancia. Si una instancia no está operativa el balanceador no lo considera a
la hora de repartir las peticiones que recibe.
7.5.2 Alta disponibilidad en simpleSAMLphp
Configurar un SP o un IdP en alta disponibilidad no es dificil ya que hay muy poco estado que compartir entre los nodos
de un cluster al no necesitar de un almacenamiento persistente como una base de datos relacional. El “nodo bridge”
que generalmente alberga más funcionalidad que los nodos periféricos (consentimiento, descubrimiento, validación,
estadísticas, monitorización, gestión de metadatos) si que requerirá de un poco más de planificación para ponerlo en
alta disponibilidad.
En los IdPs y SPs lo único que es importante compartir entre los nodos de SimpleSAMLPHP es la sesión de los
usuarios. En este sentido es muy cómodo utilizar el soporte para Memcached disponible en SimpleSAMLphp para
que las sesiones entre varias instancias se compartan.
Otra alternativa menos recomendable, es que las sesiones esten almacenadas en una instancia diferente a las instancias
que se quieren poner en alta disponibilidad, por ejemplo en una base de datos. Para lo cual habría que configurar que
el manejador de sesiones de simpleSAMLphp sea del tipo database.
Y por ultimo nos quedaría montar un sistema de ficheros compartido entre las diferentes instancas y que el manejador
de sesiones sea del tipo files.
La ventaja de utilizar memcache es que es un sistema robusto con el que conseguiremos tener un sistema de failover
de las sesiones. A continuación explicamos como se configuraría.
En SimpleSAMLPHP la configuración de los servidores Memcached se realiza por grupos. Cada elemento de
información se almacena en todos los grupos por motivos de redundancia. Cada grupo está compuesto por varios
servidores Memcached pero cada elemento de información se almacena en uno sólo de ellos. En este caso el tener
varios servidores se hace para conseguir un mayor rendimiento.
Lo más importante de todo es que SimpleSAMLPHP se encarga de gestionar todo esto de forma automática. Lo único
que hay que decirle es las direcciones de los servidores Memcached.
7.5.3 Instalación de memcached
Instalamos el servidor de memcached y el cliente para php:
yum install memcached php-pecl-memcache
Y configuramos el servicio:
7.5. Alta disponibilidad
56
Curso para operadores de Proveedores de Identidad, 1.0
# vim /etc/sysconfig/memcached
PORT="11211"
USER="memcached"
MAXCONN="1024"
CACHESIZE="512"
OPTIONS=""
# 512MB
A continuación añadimos el servicio de memcache en el arranque del sistema y lo iniciamos:
chkconfig memcached on
service memcached start
Podemos comprobar que el servicio está funcionando ejecutando:
echo stats | nc localhost 11211
A continuación instalamos el cliente php de memcache:
yum install php php-pecl-memcache
Y reiniciamos el servidor apache:
/etc/init.d/httpd restart
7.5.4 Configuración de memcached en simpleSAMLphp
Para conseguir la configuración mostrada en la siguiente figura
7.5. Alta disponibilidad
57
Curso para operadores de Proveedores de Identidad, 1.0
tendríamos que añadir esta información al fichero config/config.php de SimpleSAMLPHP:
’store.type’ => ’memcache’,
’memcache_store.servers’ => array(
array(
array(’hostname’ => ’1A’),
array(’hostname’ => ’1B’),
array(’hostname’ => ’1C’),
),
array(
array(’hostname’ => ’2A’),
array(’hostname’ => ’2B’),
array(’hostname’ => ’2C’),
),
array(
array(’hostname’ => ’3A’),
array(’hostname’ => ’3B’),
array(’hostname’ => ’3C’),
),
),
7.5. Alta disponibilidad
58
Curso para operadores de Proveedores de Identidad, 1.0
Cada grupo de servidores es un array de servidores. Cada servidor es un array con las siguientes claves:
hostname. Nombre del servidor o dirección IP del servidor Memcache. Es la única opción obligatoria.
port. Número del puerto del servidor Memcache. Por defecto es 11211.
weight. Peso de este servidor dentro de su grupo. Influye en la probabilidad de que se elija este servidor en la
tarea de balanceo de carga interna que se realiza para guardar cada sesión.
timeout. Tiempo que se espera a que el servidor responda. Por defecto es 3 segundos.
Con esta configuración se podrían perder los tres servidores del grupo 1, 2 ó 3 sin que se perdiera ninguno dato de
sesión. Si se pierden los tres servidores etiquetados como A, B o C entonces sí habría perdida de información.
7.5. Alta disponibilidad
59
CAPÍTULO
EIGHT
EL IDP COMO SP
8.1 Caso base: IdP y SP
La estructura más básica a la hora de conectar un proveedor de servicio con un proveedor de identidad es, obviamente,
conectarlos de forma directa. Esta es la base de muchas federación en forma de malla o mesh. El principal
inconveniente es que cuando aumenta el número de servicios que el proveedor de identidad quiere soportar o cuando
aumenta el número de proveedores de identidad que el proveedor de servicio quiere soportar, el coste en mantenimiento
es lineal.
Figura 8.1: Caso básico de un SP conectado a un IdP
8.2 Hub & Spoke
En una arquitectura Hub & Spoke ambos tipos de nodos se conectan a un nodo concentrador o hub. De esta forma se
consigue que cada nuevo servicio de la federación está potencialmente disponible a todos los proveedores de identidad
con sólo conectarlo al Hub. Con un nuevo proveedor de servicio se consigue el mismo beneficio.
En este modelo es crucial el nodo central o hub. Este nodo tiene dos interfaces: por el lado al que se conectan los
proveedores de servicio simula ser un proveedor de identidad y por el lado al que se conectan los proveedores de
60
Curso para operadores de Proveedores de Identidad, 1.0
identidad simula ser un proveedor de servicio. Realmente es un puente entre ambos lados haciendo las conversiones
necesarias entre peticiones y respuestas.
En SimpleSAMLphp es sencillo configurar un nodo para que actue de hub. Consulte el apéndice 1 para averiguar
cómo.
Figura 8.2: Federación según modelo Hub & Spoke
8.3 IdP como SP en federación Hub & Spoke
Después de repasar los conceptos y tipos de conexión en federaciones SAML2 procedemos a estudiar el caso de que
un IdP actue como SP en determinadas ocasiones. Como se puede ver en la figura IdP configurado para ser también
un SP al exterior es exactamente el mismo caso que el del hub.
El principal motivo para querer configurar un IdP de esta forma es mejorar la experiencia de usuario de la mayoría
de usuarios de dicho IdP. Es lógico pensar que la mayoría de usuarios de un SP son los miembros de la institución
donde está ubicado el IdP. Así, por ejemplo, es fácil comprender que la mayoría de los usuarios de un LMS de una
Universidad son los propios alumnos de dicha Universidad. Por este motivo, es deseable darles un trato preferente a
dichos usuarios en ese servicio. En lugar de conectar el servicio directamente con el nodo Hub de la federación, se
conectaría con el IdP de dicha institución. Si un usuario llega a dicho IdP (al intentar acceder al SP) y no pertenece a
esa institución, dispondrá de un mecanismo para dar el salto al Hub de la federación y seguir el proceso como hasta
ahora. Por tanto, se está penalizando a lo usuarios externos (haciendo que vean una pantalla más) para poder beneficiar
a los usuarios internos a la institución que, recordemos, suelen ser muchos más.
Además, esta configuración disminuye los costes de mantenimiento de los servicios ofrecidos por la institución. Al
igual que el modelo Hub&Spoke disminuye los costes de mantenimiento frente a un modelo Mesh, el configurar un
IdP como un SP disminuye el coste de conectar un nuevo proveedor de identidad que tenga acceso potencial a todos
los servicios de la instutición ya que sólo es necesario conectarlo al IdP de la institución. Similarmente al conectar un
8.3. IdP como SP en federación Hub & Spoke
61
Curso para operadores de Proveedores de Identidad, 1.0
Figura 8.3: IdP configurado para ser también un SP al exterior
8.3. IdP como SP en federación Hub & Spoke
62
Curso para operadores de Proveedores de Identidad, 1.0
nuevo servicio de la institución al IdP institucional se consigue que todos los IdPs que ya estaban conectados al IdP
institucional disponen de un nuevo servicio sin hacer nada.
Figura 8.4: Pantalla de autenticación de un IdP configurado para ser también un SP al exterior
8.3. IdP como SP en federación Hub & Spoke
63
CAPÍTULO
NINE
REFERENCIAS
9.1 Protocolos
SAML2
PAPI
OpenID
9.2 Iniciativas de federación
Web de OASIS
Web de la iniciativa Kantara
Web de JISC para el tema de acceso e identidad
Web de Switch
Web del proyecto STORK
Web de InCommon
9.3 Federaciones de identidad
Web de la federación andaluza. CONFIA
Web de federación danesa. WAYF
Web del Servicio de Identidad de RedIRIS. SIR
Web de la federacion de UK.
Web de la federación australiana. AFF
Web de la federación nórdica. Kalmar Union
Web de la federación finlandesa. HAKA
Web de la federación holandesa. SURFfederatie
Web de la federación de Suiza. SWITCHaai
Web de la federación noruega. Feide
64
Curso para operadores de Proveedores de Identidad, 1.0
Web de la federación americana. ‘InCommon Federation
Wiki con información extendida de las federaciones existentes
9.4 Especificación SAML
Security Assertion Markup Language
SAML Profiles
SAML Bindings
SAML Metadata
SAML Conformance
SAML Security and Privacity
9.5 Implementaciones de SAML
simpleSAMLphp (doc_ssp) (código_ssp)
Shibboleth (doc_shib) (código_shib)
OpenSSO (doc_opensso) (doc2_opensso) (código_opensso)
OpenAM
pySAML2 (doc_pysaml) (código_pysaml)
djangosaml2
Lasso
OpenSAML
ESOE
9.6 Hub&Spoke
Introducing transparency in hub-and-spoke federation architectures using SAML2 authentication request
scoping elements
Inter-federation
WAYF federation
Federated Identity: Scenarios, Architecture, and Implementation
9.7 WAYF embebido
Documentación sobre WAYF embebidos de Switch
9.4. Especificación SAML
65
Curso para operadores de Proveedores de Identidad, 1.0
9.8 Consentimiento informado
User experience in WAYF federation (info , video)
Withdrawel of consent only withdraws the consent
How Better Attribute Management Helps Federation
User consent can be governed centrally but presented locally
Consentimiento informado en SimpleSAMLphp
9.9 Gestión centralizada de metadatos
Metadata administraition as selfservice
Documentación de Janus
SAML Metadata Management for eduID.cz
Proyecto PEER
Basic Metadata Aggregation Profile
Otras referencias
Gestión de metadatos en SimpleSAMLphp
9.10 Otros conceptos avanzados
Enhancement of the graphical user interface of Where Are You From
Attribute release policies made simple
ARP size matters – and less is more!
Filtros en simpleSAMLphp
SAML V2.0 Identity Assurance Profiles Version 1.0
9.8. Consentimiento informado
66
CAPÍTULO
TEN
ANEXO A. DESPLIEGUE DE ENTORNO
HUB&SPOKE
10.1 Funcionamiento
Figura 10.1: Arquitectura Hub & Spoke
Cuando conectamos un SP con el nodo central, delegamos la funcionalidad de descubrimiento en ese nodo.
1. Cuando tratemos de acceder en una aplicación protegida con el SP, el SP redireccionará al nodo central
2. En el nodo central se le mostrará al usuario una pantalla con el conjunto de IdPs disponibles de la federación.
3. El usuario seleccionara uno de los IdPs y se le redireccionará a ese IdP
4. Al usuario se le muestra el formulario de autenticación del IdP, tras identificarse, los datos viajan al nodo central
5. En el nodo central los datos del usuario son a su vez reenviados al SP y ahí acaba el flujo.
67
Curso para operadores de Proveedores de Identidad, 1.0
10.2 Implementación basada en simpleSAMLphp. “nodo bridge”
El software simpleSAMLphp puede funcionar como un IdP, como un SP o como ambos a la vez (bridge), habilitando
el modelo Hub & Spoke.
El esquema sería:
Figura 10.2: Esquema conexión nodo bridge
Los IdPs se conectarían con el lado SP del “nodo bridge” y los SPs con el lado IdP del “nodo bridge”. Un aspecto
importante a tener en cuenta es el orden de ejecución de los filtros que establezcamos en el “nodo bridge”. Los filtros
del lado SP del “nodo bridge” se ejecutarán antes que los filtros del lado IdP.
10.2.1 Instalación de simpleSAMLphp y dependencias
Lo primero será instalar las dependencias de simplesamlphp. Explicaremos como se realiza la instalación de dependencias en una distribución CentOS 5.6, la cual está disponible para su descarga desde
http://isoredirect.centos.org/centos/5/isos/x86_64/. Supondremos a partir de ahora que el
despliegue será realizado en la ruta /var/www/wayf/.
Una vez se encuentre el sistema operativo instalado, se debe proceder a la instalación de los siguientes paquetes,
requeridos para el correcto funcionamiento de SimpleSAMLphp:
php53
php53-pdo
php53-mysql
php53-mbstring
php55-xml
zlib
pcre
openssl
httpd
libmcrypt
libmcrypt-devel
php53-devel
mhash
mhash-devel
10.2. Implementación basada en simpleSAMLphp. “nodo bridge”
68
Curso para operadores de Proveedores de Identidad, 1.0
mod_ssl
SimpleSAMLphp requiere, además de los anteriores paquetes, de ‘php53-mcrypt’ y ‘php53-memcache’. Por defecto,
estas dependencias no se encuentran en los repositorios oficiales de CentOS 5.6, asi que es necesario compilar dichas
extensiones.
Compilación de php53-mcrypt
Se deben seguir los siguientes pasos para conseguir la extensión de mcrypt:
1. Descargar el código fuente de php-5.3.X y descomprimir el tarball.
2. Acceder al directorio de extensiones llamado ‘ext’:
# cd php-5.3.X/ext
3. Acceder al directorio de la extension ‘mcrypt’:
# cd mcrypt
4. Preparar la extension antes de ser compilada:
# phpize
# aclocal
5. Proceder con la configuración, compilación e instalación:
# ./configure && make && make install
6. La extensión se deberá instalar en el directorio /usr/lib64/php/modules/. Es necesario crear un fichero
de configuración para la nueva extensión de PHP en el directorio /etc/php.d/ con el siguiente contenido:
extension=mcrypt.so
7. Reiniciar el servicio httpd:
# servide httpd restart
8. Es posible comprobar que el nuevo módulo se encuentra activo creando un fichero index.php en el directorio
de publicación de Apache2 con el siguiente código:
<?php phpinfo(); ?>
Compilación de php53-memcache
Se deben seguir los siguientes pasos para conseguir la extensión memcached:
1. Descargar el código de memcached http://pecl.php.net/get/memcache y descomprimir.
2. Preparar el paquete con la utilizar phpize:
# phpize
3. Configurar, compilar e instalar el módulo:
# ./configure && make && make install
4. La nueva extensión deberá haberse instalado en el directorio /usr/lib64/php/modules/. Es necesario
crear un fichero de configuración para la nueva extensión de PHP en el directorio /etc/php.d/ con el
siguiente contenido:
; Enable memcache extension module
extension=memcache.so
10.2. Implementación basada en simpleSAMLphp. “nodo bridge”
69
Curso para operadores de Proveedores de Identidad, 1.0
5. Reiniciar el servicio httpd:
# service httpd restart
6. Es posible comprobar que el nuevo módulo se encuentra activo creando un fichero index.php en el directorio
de publicación de Apache2 con el siguiente código:
<?php phpinfo(); ?>
Una vez instaladas las dependencias, la instalación de SimpleSAMLphp es realmente sencilla, solamente es necesario
descargar el código fuente en un directorio del sistema, por ejemplo en el directorio /var/www/wayf/:
# svn co http://simplesamlphp.googlecode.com/svn/branches/simplesamlphp-1.9 simplesamlphp
10.2.2 Configuración parte Común
El primer fichero a modificar es el fichero config.php. Por tanto, lo mejor es copiar su plantilla correspondiente:
# cp /var/www/wayf/simplesamlphp/config-templates/config.php
/var/www/wayf/simplesamlphp/config/config.php
Como todos los ficheros de configuración de simpleSAMLphp es un fichero PHP con las reglas de sintáxis de este
lenguaje. Un comando útil que debemos ejecutar siempre que hagamos modificaciones a este fichero es php -l ya que
nos dirá si hay fallos de sintaxis y puede ahorrar tiempo y problemas:
# php -l /var/www/wayf/simplesamlphp/config/config.php
No syntax errors detected in /var/www/wayf/simplesamlphp/config/config.php
A continuación se detallan las partes más habituales del fichero config.php que hay que modificar:
Contraseña de administración de simpleSAMLphp:
’auth.adminpassword’ => ’admin’,
Es importante cambiar esta contraseña porque además de ser un problema de seguridad si se deja tal cual,
simpleSAMLphp lo detectará y dará un error.
Sal aleatoria y secreta:
’secretsalt’ => ’defaultsecretsalt’,
Para generar este valor se puede utilizar el siguiente comando:
# tr -c -d ’0123456789abcdefghijklmnopqrstuvwxyz’ </dev/urandom | dd bs=32 count=1 2>/dev/null;
echo 1zpz5ztl1w5hnqhx8969thxab68us5og
Nombre y dirección de correo del administrador de este simpleSAMLphp:
’technicalcontact_name’ => ’Administrator’,
’technicalcontact_email’ => ’na@example.org’,
Zona horaria:
’timezone’ => NULL,
Un valor de ejemplo para este parámetro es ‘Europe/Madrid’
Idioma predeterminado:
10.2. Implementación basada en simpleSAMLphp. “nodo bridge”
70
Curso para operadores de Proveedores de Identidad, 1.0
’language.default’ => ’en’,
Lo más habitual es poner el valor ‘es’ para que la interfaz de simpleSAMLphp salga en español.
Hay muchas más opciones de configuración pero estás son las más básicas y necesarias de modificar. Los comentarios
en el fichero config.php explican bastante bien para qué sirve cada uno de los parámetros de configuración.
Configuración de Apache
Se debe crear un fichero de configuración para el VirtualHost de wayf.example.com.conf en el directorio
/etc/httpd/conf.d/ con el siguiente contenido:
<VirtualHost *:80>
ServerName wayf.example.com
DocumentRoot /var/w/wayf/simplesamlphp/www
SSLProxyEngine On
ProxyPreserveHost On
Alias /simplesaml /var/www/wayf/simplesamlphp/www
<Location />
ProxyPass https://localhost
</Location>
</VirtualHost>
<VirtualHost *:443>
ServerName wayf.example.com
DocumentRoot /var/www/wayf/simplesamlphp/www
Alias /simplesaml /var/www/wayf/simplesamlphp/www
SSLEngine on
SSLCertificateFile /etc/httpd/ssl/wayf.example.com/crt/wayf.example.com.crt
SSLCertificateKeyFile /etc/httpd/ssl/wayf.example.com/key/wayf.example.com.key
</VirtualHost>
Además es necesario crear los certificados (autogenerados) que se han especificado en la configuracion del VirtualHost
para https. Se deberán seguir las siguientes instrucciones:
1. Crear el directorio donde alojar los certificados, en este caso, /etc/httpd/ssl/wayf.example.com/:
# mkdir -p /etc/httpd/ssl/wayf.example.com/crt /etc/httpd/ssl/wayf.example.com/key
2. Cambiar el directorio actual por /etc/httpd/ssl/wayf.example.com/:
# cd /etc/httpd/ssl/wayf.example.com/
3. Creación de la clave sin contraseña y con una encriptación 1024:
# openssl genrsa -out key/wayf.example.com.key 1024
4. Generar el fichero CSR (solicitud de certificado)
# openssl req -new -key key/wayf.example.com.key -out wayf.example.com.csr
5. Generar el certificado autofirmado:
# openssl x509 -req -days 1825 -in wayf.example.com.csr -signkey key/wayf.example.com.key
-out crt/wayf.example.com.crt
Por último, es necesario reiniciar el servicio httpd para que la nueva configuración sea aplicada:
10.2. Implementación basada en simpleSAMLphp. “nodo bridge”
71
Curso para operadores de Proveedores de Identidad, 1.0
# service httpd restart
Certificado (wayf.example.com.crt) y clave (wayf.example.com.key) deberemos también de tenerlos accesibles en la
carpeta cert del simpleSAMLphp para que sean usados en el firmado y cifrado de aserciones. Para ello lo mejor es
crear enlaces simbólicos
# ln -s /etc/httpd/ssl/wayf.example.com/key/wayf.example.com.key
/var/www/wayf/simplesamlphp/cert/wayf.example.com.key
# ln -s /etc/httpd/ssl/wayf.example.com/crt/wayf.example.com.crt
/var/www/wayf/simplesamlphp/cert/wayf.example.com.crt
10.2.3 Configuración parte IdP
Para configurar simpleSAMLphp como SP es necesario habilitar el parámetro ‘enable.saml20-sp’ en el fichero de
configuración config/config.php:
’enable.saml20-idp’ => true,
10.2.4 Configuración de las fuente de autenticación
En este caso no hace falta especificar fuente de autenticación ya que la fuente de autenticación será la parte SP del
“nodo bridge” que posteriormente configuraremos (config/authsourcesphp).
Configuración del metadato del IdP
Los metadatos del IdP deben de definirse dentro de la carpeta metadata en el fichero saml20-idp-hosted.php.
A continuación se presenta un ejemplo:
<?php
/* The index of the array is the entity ID of this WAYF. */
$metadata[’https://wayf.example.com/simplesaml/saml2/wayf/metadata.php’] = array(
’host’ => ’wayf.example.com’,
/* Configuration options. */
/* Organization info */
’OrganizationName’ => array(
’en’ => ’Example organization’,
’es’ => ’Organizacion de ejemplo’,
),
’OrganizationURL’ => array(
’en’ => ’http://wayf.example.com’,
’es’ => ’http://wayf.example.com’,
),
/* The private key and certificate used by this IdP. */
’certificate’ => ’wayf.example.com.crt’,
’privatekey’ => ’wayf.example.com.key’,
/*
* The authentication source for this IdP. Must be one
* from config/authsources.php.
10.2. Implementación basada en simpleSAMLphp. “nodo bridge”
72
Curso para operadores de Proveedores de Identidad, 1.0
*/
’auth’ => ’saml’,
// Logout requests and logout responses sent from this IdP should be signed
’redirect.sign’ => TRUE,
// All communications are encrypted
’assertion.encryption’ => TRUE,
);
?>
Nota: Observamos que la fuente de autenticación es la anteriormente especificada: ‘saml’ (La fuente de
autenticación del IdP será la parte SP del “nodo bridge” en lugar del típico ldap o BD)
La clave del array $metadata es el identificador de entidad (EntityID) y es importante que coincida con la URL
que devuelve los metadatos del propio “nodo bridge” por motivos de interoperabilidad SAML 2.0. Normalmente es
suficiente con modificar el nombre del host y dejar el resto de la URL tal cual se ve en este ejemplo.
A continuación se detallan los principales parámetros que hay que configurar dentro del array de metadatos para una
entidad en concreto:
host Nombre del host de esta máquina que se utiliza en el VirtualHost de Apache correspondiente
certificate y privatekey Son las dos partes (pública y privada) del certificado usado en el IdP. Estos ficheros deben
encontrarse en el directorio cert del directorio raíz de simpleSAMLphp a no ser que se haya cambiado esa
ubicación en el fichero config.php
auth Este parámetro debe tener como valor el nombre de la fuente de autenticación que se desea usar para autenticar
a los usuarios de este “nodo bridge”.
redirect.sign* Este parámetro debe estar a TRUE para que las aserciones se firmen
redirect.validate Este parámetro debe estar a TRUE para que las aserciones se validen
assertion.encryption Este parámetro deben estar a TRUE para que se cifren las aserciones SAML
Configuración de los metadatos de los SPs que se van a conectar al “nodo bridge”
Los metadatos de los SP en los que el “nodo bridge” va a confiar deben de definirse dentro de la carpeta metadata en
el fichero saml20-sp-remote.php. A continuación se presenta un ejemplo:
<?php
/* The index of the array is the entity ID of this SP. */
$metadata[’https://sp.example.com/simplesaml/module.php/saml/sp/metadata.php/saml’] = array (
’AssertionConsumerService’ =>
’https://sp.example.com/simplesaml/module.php/saml/sp/saml2-acs.php/saml’,
’SingleLogoutService’ =>
’https://sp.example.com/simplesaml/module.php/saml/sp/saml2-logout.php/saml’,
’certData’ => ’MIICmTCCAgICCQDHTTCmM3WMCzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UEBhMCRVMxDjAMBg
NVBAgTBXNwYWluMRAwDgYDVQQHEwdzZXZpbGxlMQ0wCwYDVQQKEwR5YWNvMRcwFQYDVQQLEw5
zcC5leGFtcGxlLmNvbTEXMBUGA1UEAxMOc3AuZXhhbXBsZS5jb20xHjAcBgkqhkiG9w0BCQEW
D3NtYXJ0aW5AeWFjby5lczAeFw0xMTA0MjAwODU1MDBaFw0xNjA0MTgwODU1MDBaMIGQMQswCQ
YDVQQGEwJFUzEOMAwGA1UECBMFc3BhaW4xEDAOBgNVBAcTB3NldmlsbGUxDTALBgNVBAoTBHlh
Y28xFzAVBgNVBAsTDnNwLmV4YW1wbGUuY29tMRcwFQYDVQQDEw5zcC5leGFtcGxlLmNvbTEeM
BwGCSqGSIb3DQEJARYPc21hcnRpbkB5YWNvLmVzMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQK
BgQCnhEeto90m5agvGnarL8J/uXTOYoJF5XfMKhUNkB12g3geRFXd/w/xqAfktat0YM9of0f/
W1edLwVW72mZ8enl+jL3eEqwlUUz88GyC4h5t/inZ4WTW8jXc5WSNZYUXvk3F0uAO/PmKBEjFo
UrA8It3JnY9Nuu5f95DL6dRuLIBwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAHAirMjySJpFq4D
grB9Ax8t53uTbtVkXTb/haCwrWDuRywnMjgx7QhpN5RhL5UXPU1n617V2NROVNTH+2ROlhRyP
10.2. Implementación basada en simpleSAMLphp. “nodo bridge”
73
Curso para operadores de Proveedores de Identidad, 1.0
S8l2KpAuVpAI1vznIE14JD3C8giWY3BRm009fKqKH2sC2evQyZk/UDG26Db509bIvcpSA3aXFE
eug2M7gZeK’,
);
?>
10.2.5 Configuración parte SP
A diferencia del IdP en el SP los metadatos propios se configuran en el fichero config/authsources.php. Al
tratarse del “nodo bridge” esta definicion de metadatos del SP va a usarse como fuente de autenticación del “nodo
bridge”.:
<?php
$config = array(
’saml’ => array(
’saml:SP’,
’host’ => ’wayf.example.com’,
’entityID’ =>
’https://wayf.example.com/simplesaml/module.php/saml/sp/metadata.php/saml’,
’idp’ => NULL,
’certificate’ => ’wayf.example.com.crt’,
’privatekey’ => ’wayf.example.com.key’,
// All communications are encrypted and signed
’redirect.sign’ => TRUE,
’redirect.validate’ => TRUE,
’assertion.encryption’ => TRUE,
’OgnizationName’ => array (
’en’ => ’Example organization’,
’es’ => ’Organizacion de ejemplo’,
),
’OrganizationDisplayName’ => array (
’en’ => ’Example organization’,
’es’ => ’Organizacion de ejemplo’,
),
’OrganizationURL’ => array (
’en’ => ’http://wayf.example.com’,
’es’ => ’http://wayf.example.com’,
),
),
);
?>
Nota: Al no especificar IdP el simpleSAMLphp buscara entre los metadatos que tiene registrados en el directorio
metadata los de los IdPs. En este caso el “nodo bridge” realizará un servicio de descubrimiento de los IdPs definidos
en metadata/saml20-idp-remote.php
Para seleccionar el IdP al que conectarnos simpleSAMLphp nos mostrará una lista de IdPs o bien un combobox dependiendo del valor que configuremos en la variable ‘’idpdisco.layout’ => ‘dropdown’,’ del config/config.php.
Las opciones son ‘links’ para el listado o ‘dropdown’ para el combobox.
Es posible hacer que el “nodo bridge” recuerde el IdP que el usuario seleccionó para una posterior petición de login
con las variables del config/config.php:
10.2. Implementación basada en simpleSAMLphp. “nodo bridge”
74
Curso para operadores de Proveedores de Identidad, 1.0
’idpdisco.enableremember’ => TRUE,
’idpdisco.rememberchecked’ => TRUE,
// Para que recuerde la selección y no vuelva a preguntar
// Marcar por defecto que se guarde el IdP seleccionado.
Esta opción de recuerdo es útil siempre que sepamos que los usuarios sólo van a identificarse a través de un sólo IdP,
pero en el caso de que pueda hacerlo desde diferentes fuentes, se desaconseja el establecer “recordar el IdP utilizado”
ya que esa opción se guarda en la cookie y para que se deje de recordar, será necesario limpiar la cookie o bien acceder
al enlace poco accesible ya que se encuentra en la pestaña de federacion de simplesamlphp “Borrar mis opciones de
IdP en los servicios de descubrimiento de IdP”. “Borrar mis opciones de IdP en los servicios de descubrimiento de
IdP”
Personalización de la vista de descubrimiento
Si queremos personalizar la vista de descubrimiento deberemos acceder a la carpeta templates y modificar el
archivo selectidp-links.php o el selectidp-dropdown.php según tengamos configurada una u otra
opción. Realmente lo ideal no es sobreescribir estos archivos sino crear un tema (nuevo módulo de simplesamlphp
en el que se redefinen plantillas y se almacenan imagenes personalizadas). Para crear un módulo tema lo primero que
haremos será crear el módulo dentro de la carpeta modules y lo configuramos para que esté activo por defecto:
mkdir <nombre_modulo_tema>
touch <nombre_modulo_tema>/default-enable
Creamos el tema dentro del módulo en la carpeta themes:
mkdir -p <nombre_modulo_tema>/themes/<nombre_tema>
Creamos las carpeta que albergaran las templates por defecto del módulo
mkdir <nombre_modulo_tema>/themes/<nombre_tema>/default/
Y creamos las carpeta para los ficheros que se incluyen en el resto de ficheros de SSP como son el header.php y el
footer.php:
mkdir <nombre_modulo_tema>/themes/<nombre_tema>/default/includes/
Debemos crear también el directorio que alojare los recursos por defecto, donde copiaríamos por ejemplo la css:
mkdir <nombre_modulo_tema>/resources/<nombre_tema/
Si queremos modificar la plantilla para un módulo concreto tendríamos que crear su carpeta dentro del tema y alojar
ahi el fichero:
mkdir <nombre_modulo_tema>/themes/<nombre_tema>/<nombre_modulo_a_modificar/
cp modules/<nombre_modulo_a_modificar>/<fichero_a_modificar>
<nombre_modulo_tema>/themes/<nombre_tema>/<nombre_modulo_a_modificar/<fichero_a_modificar>
Es una buena práctica copiarnos las templates de que vayamos a modificar del base de simpleSAMLphp y usarlas
como plantillas:
cp templates/includes/header.php
modules/<nombre_modulo_tema>/themes/<nombre_tema>/default/includes/
cp templates/includes/footer.php
modules/<nombre_modulo_tema>/themes/<nombre_tema>/default/includes/
Y ya podríamos hacer una primera modificación, en el header.php modificaríamos:
<link rel="stylesheet" type="text/css"
href="/<?php echo $this->data[’baseurlpath’]; ?>resources/default.css" />
//por :
<link rel="stylesheet" type="text/css"
href="/<?php echo $this->data[’baseurlpath’]; ?>resources/<nombre_module_tema>/default.css" />
10.2. Implementación basada en simpleSAMLphp. “nodo bridge”
75
Curso para operadores de Proveedores de Identidad, 1.0
También es posible redefinir las vistas completamente alojando nuevos archivos en una carpeta www que alojemos en
nuestro tema.
Una vez terminado el modulo del tema, para que simpleSAMLphp lo use únicamente deberemos de registrarlo en el
archivo de configuración de simpleSAMLphp:
’theme.use’ => ’<nombre_modulo_tema>:<nombre_tema>’,
10.3 Migración del modelo de estrella al modelo Hub&Spoke.
Para migrar de un modelo en estrella a un modelo Hub & Spoke habría que:
Desplegar y configurar el nodo central, añadiendole el conjunto de metadatos de los IdPs y de los SPs que
existían en la federación
Añadir en cada IdP el metadato de la parte SP del nodo central
Añadir en cada SP el metadato de la parte IdP del nodo central.
Configurar el config/authsources.php del SP para que su IdP sea el entityID de la parte IdP del nodo central
en lugar de un valor NULL (el IdP estaría auto-descubriendo) o en lugar del entityID de un IdP con el que
previamente lo hubieramos conectado.
Generalmente en las federaciones para permitir conexiones unilaterales sin pasar por el nodo central se guardan en
cada SP los IdPs de la federación y en cada IdP los SPs de la federación
Pero hay que tener en cuenta que si un SP confía en el nodo central y un IdP confían en el nodo central,
automáticamente ese SP y ese IdP estarían bajo un marco de confianza sin necesidad de que el SP y el IdP añadieran
los metadatos del uno y del otro.
Se deja en mano de los operadores/responsables de cada uno de los IdPs y SPs si únicamente quieren añadir los
metadatos del nodo bridge (todas las transmisiones de datos tendrían que pasar por el nodo central) o los metadatos de
los restantes nodos (se permitirían transmisiones directas de un IdP a un SP sin pasar por el nodo central).
10.4 Tareas de mantenimiento.
El mantenimiento de un nodo hub & spoke no difiere del mantenimiento normal que pueda tener un IdP o un SP.
Básicamente habrá que:
Tener los metadatos actualizados de los IdP y SPs que tiene conectados.
Mantener vigente el certificado que utilice.
En una federación grande basada en el modelo Hub & Spoke es necesario disponer de una serie de elementos
comunes (servicio de descubrimiento, servicio de consentimiento, gestor de metadatos) que facilitarán la gestión y
el mantenimiento de la federación.
10.3. Migración del modelo de estrella al modelo Hub&Spoke.
76
CAPÍTULO
ELEVEN
ANEXO B. ASSERTION.ENCRYPTION,
REDIRECT.SIGN Y
REDIRECT.VALIDATE
Estos 3 parametros hacen referencia al cifrado, el firmado y la validación de las aserciones. Dependiendo donde
especifiquemos estos parámetros significarán una cosa u otra.
Si un elemento requiere que la aserción vaya firmada o cifrada no aceptará ninguna aserción que le llegue de un
elemento que no cumpla con esos requisitos.
Dependiendo de los archivos donde definamos esos valores significaran en simpleSAMLphp una determinada cosa.
Estos valores tendrán una traducción en los metadatos que del IdP y SP se exporten. Analicemoslo con detenimiento.
11.1 assertion.encryption
Este valor puede especificarse:
En el IdP en:
En el saml20-idp-hosted. TRUE para que las aserciones que envíe este IdP se cifren. Valor por defecto False
En el saml20-sp-remote. TRUE‘para que la aserción que se envíe a este SP se cifre. Valor por defecto ‘False.
Sobreescribe a lo definido en el saml20-idp-hosted..
En el SP en:
En el authsources. TRUE Si la aserción recibida en este SP proveniente de cualquier IdP debe de ir cifrada. Por
defecto False.
En el saml20-idp-remote. TRUE Si la aserción recibida por este IdP debería de estar cifrada. Por defecto False.
Sobreescribe a lo definido en el authources.
(Se hace uso en modules/saml/lib/IdP/SAML2.php encryptAssertion y modules/saml/lib/Message.php decryptAssertion)
11.2 redirect.sign
Se traduce en los metadatos por un WantAuthnRequestSigned
Este valor puede especificarse:
77
Curso para operadores de Proveedores de Identidad, 1.0
En el IdP en:
En el saml20-idp-hosted. TRUE si se quiere que la petición de autenticación, petición de logout y la respuesta
de logout enviadas por este IdP se cifren. Valor por defecto False
En el saml20-sp-remote. TRUE si se quiere que la la petición de autenticación, petición de logout y la respuesta
de logout que se envíen desde el IdP a este SP se cifren. Valor por defecto False. Sobreescribe a lo definido en
el saml20-idp-hosted..
En el SP en:
En el authsources. TRUE Si la petición de autenticación, petición de log out y respuesta de log out enviadas
desde este SP a cualquier IdP deben de estar firmadas. Por defecto False.
En el saml20-idp-remote. TRUE Si la petición de autenticación, petición de log out y respuesta de log out
enviadas a este IdP deben de estar firmadas. Por defecto False. Sobreescribe a lo definido en el authources.
(Se hace uso en modules/saml/lib/Message.php addRedirectSign , que hará que se incluya la firma . También se incluira
si especificamos sign.logout o sign.authnrequest)
11.3 redirect.validate
Este valor puede especificarse:
En el IdP en:
En el saml20-idp-hosted. TRUE si la petición de autenticación, petición de logout o la respuesta de logout
enviadas desde este IdP deben de ser validadas. Por defecto False
En el saml20-sp-remote. TRUE si la petición de autenticación, petición de logout o la respuesta de logout
recibidas de este SP deben de ser validadas. Por defecto False
En el SP en:
En el authsources. TRUE‘ si la petición de autenticación, petición de logout o la respuesta de logout recibidas
en este SP deben de ser validadaa. Por defecto False
En el saml20-idp-remote. TRUE si la petición de autenticación, petición de logout o la respuesta de logout
recibidas desde este IdP deben de ser validadas. Por defecto False. Sobreescribe a lo definido en el authources.
(Se hace uso en modules/saml/lib/Message.php validateMessage, tambien se validara si especificamos validate.logout
o validate.authnrequest)
Además de lo anterior en el IdP se hace uso de:
saml20.sign.response para firmar la respuesta. Puede definirse tanto en el saml20-idp-hosted como en los
saml20-sp-remote.
saml20.sign.assertion para firmar la aserción. Puede definirse tanto en el saml20-idp-hosted como en los
saml20-sp-remote.
(Se hace uso en modules/saml/lib/IdP/SAML2.php buildResponse, buildAssertion)
11.3. redirect.validate
78