Curso Administrador SP

Curso para operadores de Proveedores
de Servicio
1.0
Sixto Martin
November 23, 2012

NDICE GENERAL
1. Introduccin 2
1.1. Que es federar/domesticar una aplicacin? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Autenticacin y autorizacin (AuthN & AuthZ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Arquitecturas de las federaciones de indentidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Tcnicas de federacin de aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Descripcin de la arquitectura desplegada en Confa 8

2.1. Entorno en Confa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Arquitectura de Confa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Entornos y servicios comunes desplegados en el CICA . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Workflow de alta de IdP o Servicio (SP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Gestin de los metadatos 11

3.1. Modelos de gestin de metadatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Los metadatos en simpleSAMLphp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Gestor de metadatos en simpleSAMLphp - JANUS . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4. PEER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4. Protocolo de resolucin de incidencias en un entorno de federacin de identidades 27

4.1. Errores ms frecuentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2. Protocolo de gestin de errores actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5. Desplegar un SP con SimpleSAMLphp 29

5.1. Recursos de ayuda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2. Instalacin y configuracin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3. Configuracin avanzada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6. Domesticacin de aplicaciones con simpleSAMLphp 41

6.1. Repaso de la API de simpleSAMLphp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.2. Autenticacin, autorizacin y provisionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.3. Ejemplo de aplicacin federada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.4. Algunas cuestiones a tener en cuenta a la hora de domesticar una aplicacin . . . . . . . . . . . . 44
6.5. Anlisis de algunas domesticaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.6. Conflictos con las sesiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.7. Algunos problemas a resolver a la hora de domesticar aplicaciones . . . . . . . . . . . . . . . . . . 48
7. Domesticacin de aplicaciones en otros lenguajes diferentes a PHP 50

7.1. SimpleSAMLphp+AuthMemCookie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.2. ShibbolethSP+REMOTE USER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.3. Aplicaciones Python/Django (PySAML2/djangosaml2) . . . . . . . . . . . . . . . . . . . . . . . . 63
I
7.4. Aplicaciones Java (SpringSecurity OIOSAML) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.5. Librerias para otros lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8. Referencias 72
8.1. Especificacin SAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
8.2. Implementaciones de SAML SP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
8.3. Documentacin de inters sobre domesticaciones de aplicaciones . . . . . . . . . . . . . . . . . . 72
8.4. Gestin centralizada de metadatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
8.5. Otros conceptos avanzados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
9. Anexo A. Conceptos sobre federacin de identidades 74

9.1. Qu es una federacin de identidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
9.2. Ventajas de la federacin de identidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
9.3. Ejemplos de federaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
9.4. Conceptos (IdP, SP, AA, WAYF, atributos, bindings) . . . . . . . . . . . . . . . . . . . . . . . . . . 77
9.5. Protocolos (SAML PAPI, OpenId) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
10. Anexo B. Software existente para implementar federaciones de identidades 82

10.1. Shibboleth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
10.2. simpleSAMLphp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
10.3. PySAML2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
10.4. OpenSSO / OpenAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
10.5. Lasso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
10.6. Solucin recomendada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
11. Anexo C. Mquina virtual con las aplicaciones de ejemplo federadas 85

11.1. Descarga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
11.2. Configuracin previa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
11.3. CONTENIDO DE LA MQUINA VIRTUAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
11.4. URLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
II
Curso para operadores de Proveedores de Servicio, 1.0
Esta documentacin pertenece al curso para operadores de Proveedores de Servicio que se celebra en Sevilla el X de
X y en Granada el Y de Y de 2012.
NDICE GENERAL 1
CAPTULO
ONE
INTRODUCCIN
1.1 Que es federar/domesticar una aplicacin?
Federar/domesticar una aplicacin es una expresin coloquial que utilizamos para referirnos a la accin de integrar
una aplicacin en un entorno de federacin de identidades. Existen diferentes grados de fedderar una aplicacin, siendo
el de mayor grado aquel que consigue que una aplicacin posea:
Funcionalidad de SSO y SLO globales (con opcin de conservar logout local).
Que los usuarios se creen/actualicen/inhabiliten/eliminen en funcin de la informacin que llega de la asercin
SAML.
Que los permisos locales de la aplicacin se configuren segn los datos de la asercin SAML.
1.2 Autenticacin y autorizacin (AuthN & AuthZ)
Es importante diferenciar estos 2 conceptos.

La autenticacin es el proceso de verificar la identidad de una persona mientras que la autorizacin es el proceso de
verificacin de que una persona ya identificada tiene la autoridad para realizar una cierta operacin o para acceder a
un cierto 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 identificacin.
(autenticacin)
4. El sistema valida segn sus reglas si las credenciales aportadas son suficientes para dar acceso al usuario o
no. (autorizacin)
En una federacin de identidad:
La autenticacin se realiza en el IdP.
La autorizacin se realiza en el SP o en la propia aplicacin
2
1.3 Arquitecturas de las federaciones de indentidad
Existen varios modelos atendiendo a como se conectan cada uno de los elementos que forman una federacin de
identidades. Cada mdelo tiene sus ventajas y desventajas por lo que dependiendo del entorno y contexto optaremos
por uno u otro modelo.
1.3.1 Modelo centralizado
Figura 1.1: Arquitectura centralizada
Los SP se conectan a un nico nodo IdP cuyas fuentes de autenticacin (auth backends) son Ldaps, BDs, etc de
diferentes instituciones.
Si el IdP tiene soporte los SP podran comunicarse en los diferentes protocolos de autenticacin actualmente
existentes: SAML2, sHibboleth, OpenId, PAPI
Los proveedores de identidad delegaran la peticin del consentimiento en el nico nodo posible: el IdP central.
Cada SP est directamente conectado con el IdP (no habra descubrimiento de IdP) siendo necesario especificar
de alguna forma contra que backend de autenticacin actuar.
El SP podra pasarle un parmetro al IdP o ser el IdP directamente el que decidiera a donde ir dependiendo de
donde le llegue la peticin, del username del usuario, etc.
1.3.2 Modelo distribuido
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 realizara en cada uno de los IdPs.
1.3. Arquitecturas de las federaciones de indentidad 3

Figura 1.2: Arquitectura distribuida
El descubrimiento se realizara en el SP.
1.3.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 comunicacin puedan comunicarse haciendo
uso del nodo central que har de puente (bridging) y traduzca las aserciones de un protocolo a otro.
Los IdPs delegaran la peticin del consentimiento en el nodo central (aunque tambin puede haber un doble
consentimiento y requerirse el consentimiento tanto en el IdP como en el nodo central).
El descubrimiento se realizara en el nodo central. (Aunque existen federaciones con esta arquitectura que
realizan un wayf embebido en la aplicacin federada).
Ventajas del modelo Hub & Spoke
Desacople de los diferentes elementos, desacople tecnolgico (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 federacin: consentimiento, descubrimiento (wayf), filtros
de atributos, validacin de atributos, monitorizacin, estadsticas. Reduciendo costes y facilitando el
mantenimiento.
Posibilidad de inter-federacin. Conectando el nodo central con otro nodo central de otra federacin
conseguimos que los nodos de ambas federaciones queden conectados.
1.3. Arquitecturas de las federaciones de indentidad 4

Figura 1.3: Arquitectura Hub & Spoke
1.4 Tcnicas de federacin de aplicaciones
1.4.1 Federacin nativa.
Esta federacin es posible cuando el software del SP y el software de la aplicacin que se quiere federar utilizan la
misma tecnologa y lenguaje. Desde la aplicacin que se quiere federar se har uso directo de las librerias del SP.
1.4.2 Federacin basada en webservice
Se basa en que el software de la aplicacin a federar posea un webservice con una serie de funciones de acceso y
registro (login, provisin, logout). Desde el SP se va haciendo uso de este webservice.
1.4. Tcnicas de federacin de aplicaciones 5

1.4.3 Federacin basada en authmemcookie
Cuando el software del SP y el software de la aplicacin a federar son de diferentes lenguajes y no puede realizarse
una integracin nativa puede optarse por esta opcin.
Consiste en que el SP almacene en el memcache datos del usuario que son leidos con el mdulo Auth memCookie de
Apache que protege la aplicacin a federar.
Una solucin alternativa es no usar el mdulo de Apache y directamente leer en la aplicacin a federar los datos de
memcache.

1.4.4 Federacin basada en REMOTE_USER / mod_shib
una integracin nativa puede optarse por esta opcin.
Se basa en que el Apache proteja la aplicacin a federar con la autenticacin shibboleth (Shibboleth SP) habilitando
el mod_shib. El Apache le hara llegar los datos del usuario a la aplicacin que queremos federar. El Apache utilizara
las cabeceras HTTP para hacerle llegar los datos del usuario a la aplicacin que queremos federar.

CAPTULO
TWO
DESCRIPCIN DE LA ARQUITECTURA
DESPLEGADA EN CONFA
2.1 Entorno en Confa
Existen 3 entornos replicados en Confa:

Produccin. Es el entorno oficial, el que utilizan los usuarios finales.
Pre-produccin. Es utilizado como entorno de pruebas. Antes de pasar cualquier IdP o SP a produccin debe
de validarse dicho elemento en este entorno.
Laboratorio. Es utilizado para desarrollar nuevos plugins y para probar nuevos servicios.
2.2 Arquitectura de Confa
La federacin Confa est desplegada con una arquitectura Hub & Spoke.
Figura 2.1: Entorno Confa
8
En Confa 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 harn nuevos desarrollos o se validaran nuevas versiones del software.
2.3 Entornos y servicios comunes desplegados en el CICA
Actualmente en el CICA se tienen desplegado lo siguiente:
Figura 2.2: Entornos y servicios desplegados en el CICA
2.4 Workflow de alta de IdP o Servicio (SP)
El proceso de incorporar un nuevo IdP o un nuevo SP en la infraestructura del Confa es la siguiente:

1. Lo primero ser realizar los tramites burocrticos para que se acepte la incorporacin del servicio: Aceptacin
por parte de la AUPA-TIC, ofrecer informacin del servicio al Comit, visto bueno tcnico por parte del Comit.
2. Se desarrollar el IdP o el Servicio (SP) conectndolo con el entorno de laboratorio.
3. Una vez desarrollado el IdP o el Servicio y una vez pasados los trmites burocrticos se pasar al entorno de
pre-produccin en el que el operador de la infraestructura validar que todo est en orden
2.3. Entornos y servicios comunes desplegados en el CICA 9

4. Se Conectar el IdP o el Servicio con el entorno de produccin. 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 produccin nicamente habr instancias de IdPs y SPS oficiales.
En el entorno de pre-produccin 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 prcticos dar de alta en un determinado entorno no es ms que registrar el correspondiente metadato de la
entidad en el gestor de metadatos de dicho entorno.
2.4. Workflow de alta de IdP o Servicio (SP) 10

CAPTULO
THREE
GESTIN DE LOS METADATOS
La gestin 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 federacin: la descripcin de las entidades, sus responsables y sobre todo las url donde ofrecen las
funcionalidades y las claves pblicas.
Dentro de los metadatos se incluyen 2 atributos opcionales que hay que tener muy en cuenta a la hora de realizar la
gestin de los metadatos:
validUntil: Indica en tiempo absoluto cuando caducan los metadatos
cacheDuration: Indica el mximo periodo de tiempo en el que las entidades deberan 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).
Tambin 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 gestin de los metadatos.
3.1 Modelos de gestin de metadatos
3.1.1 Modelo de agregacin
La arquitectura de agregacin permite actualizar los metadatos en el lado de la entidad que los va a consumir y debido
al simple modelo de confianza, los metadatos sern considerados vlidos siempre que estos sean descargados de una
fuente fiable (URL pre-acordada y los metadatos convenientemente firmados con una clave pblica del publicador)
3.1.2 Modelo distribuido
En la arquitectura distribuida cada entidad es responsable de la gestin y publicacin de sus propios metadatos. Con
este modelo los metadatos de un determinado punto pueden ser obtenidos bajo demanda sin la necesidad de la descarga
peridica de una coleccin de gran tamao de metadatos. (Se realiza el descubrimiento dinmico de metadatos en
funcin de las necesidades). Es un modelo que puede acarrear problemas ya que se relaja el concepto de confianza.
3.1.3 Modelo centralizado utilizado en Confa
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
federacin.
11
Los metadatos de la federacin son agregados peridicamente, almacenados y publicados como un archivo XML
convenientemente firmado.
El sistema deber de disponer de mecanismos para poder delegar las responsabilidades de gestin de un determinado
metadato al administrador de la entidad a la que describe.
3.2 Los metadatos en simpleSAMLphp
3.2.1 Configurar los directorios que albergan los metadatos en simpleSAMLphp
En el fichero config/config se especifica con el parmetro metadata.sources donde simpleSAMLphp va a buscar los
ficheros que contienen las fuentes de los diferentes metadatos.
Si queremos que adems 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),
),
Adems 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.
3.2.2 Metarefresh
Para conectar un proveedor de identidad (IdP) o un proveedor de servicio (SP) a una federacin, es necesario especificar
los metadatos de las fuentes en las que se confa. En muchas federaciones es normal configurar una distribucin
automatizada de los metadatos utilizando el formato de metadatos XML SAML 2.0. Generalmente una administracin
o autoridad central proporciona una URL con un documento SAML 2.0 que incluye los metadatos de todas las
entidades de la federacin.
Mediante el mdulo metarefresh de simpleSAMLphp es posible obtener los metadatos remotos de una URL y
almacenarlos en un archivo.
Instalacin y configuracin del mdulo metarefresh
El mdulo metarefresh existe en la instalacin bsica de simpleSAMLphp por lo que nicamente tendremos que
habilitarlo:
touch <ruta hasta simplesamlphp>/simplesamlphp/modules/metarefresh/enable
Puesto que el mdulo utiliza wget para realizar las descargas de los metadatos deberemos tener este software instalado
en la mquina:
yum install wget
El mdulo tiene un archivo de configuracin 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 sera el siguiente:
3.2. Los metadatos en simpleSAMLphp 12

<?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 podra
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 mdulo de cron (en este caso hourly). Esto
se explica ms abajo.
A continuacin hay que crear el directorio donde se guardarn 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 intrprete de PHP). En el caso de mquinas con RedHat? o Centos este usuario se llama apache, en el
caso de mquinas 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 mdulo 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 mdulo cron y el crontab
Es necesario activar tambin el mdulo cron:

touch <ruta hasta simplesamlphp>/modules/cron/enable
Y crear el fichero de configuracin config/module_cron.php:

<?php
/*
* Configuration for the Cron module.
*
* $Id: $
3.2. Los metadatos en simpleSAMLphp 13

*/
$config = array (
key => secret,
allowed_tags => array(daily, hourly, frequent),
debug_message => TRUE,
sendemail => TRUE,
);
?>
Alternativamente, se puede desactivar el envo 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 mdulos.
En nuestro caso, metarefresh lo hace con hourly.
Estas tags no son ms 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 peridicamente los metadatos, hay que colocar un fichero crontab en /etc/cron.d con una lnea para cada
tag definida. En nuestro caso, necesitamos una lnea 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 mquina 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, adems de utilizar los ficheros de metadatos generales
(los ficheros de metadata/), utilice tambin los que Metarefresh dejar en el directorio metadata/federation/. Para ello
hay que editar el fichero config/config.php, concretamente la opcin metadata.sources, para aadirle nuestra nueva
fuente de metadatos:
metadata.sources => array(
array(type => flatfile),
array(type => flatfile, directory => metadata/federation),
),
Es posible consultar ms documentacin del mdulo metarefresh.
3.3 Gestor de metadatos en simpleSAMLphp - JANUS
En simpleSAMLphp existe un mdulo 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).
3.3. Gestor de metadatos en simpleSAMLphp - JANUS 14

3.3.1 Instalacin
JANUS no es ms que un mdulo de simpleSAMLphp. En una federacin 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 desplegara en una nueva instancia.
Al servicio Janus lo protegeremos con una fuente de autenticacin local en la que habilitemos los diferentes
administradores que van a gestionar los metadatos. Lo ideal sera 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 travs 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 cdigo 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.
Configuracin de Apache
Se debe crear un fichero de configuracin 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>
Adems es necesario crear los certificados (autogenerados) que se han especificado en la configuracion del VirtualHost
para https. Se debern 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. Creacin de la clave sin contrasea y con una encriptacin 1024

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 configuracin sea aplicada
service httpd restart
Certificado (janus.example.com.crt) y clave (janus.example.com.key) deberemos tambin 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 simblicos
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
Creacin de la base de datos y configuracin
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 continuacin copiaremos la plantilla de configuracin de janus del janus/config-templates/module_janus.php al

directorio de configuracin 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 configuracin que ms nos interese. A continuacin vamos a ir
detallando los diferentes parmetros y el valor que recomendamos darles.
Configuracin de datos del administrador:
// Nombre del administrador de Janus
admin.name => JANUS admin,
// Email del administrador de Janus, aparecer como contacto de la aplicacin,

admin.email => janusadmin@example.org,
Configuracin de la base de datos Janus:

store => array(
// Configuracin de conexin con la base de datos.
dsn => mysql:host=localhost;dbname=janus_db,
username => janus, // Usuario de la base de datos

password => , // Password para acceder a la base de datos

prefix => janus__, // Prefijo utilizado en las tablas, si lo hubiera
),
Configuracin 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 parmetros, bsicamente 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 validacin de certificados es necesario indicar la ruta

donde se encuentren las CAs */
ca_bundle_file => /etc/pki/tls/certs/ca-bundle.crt,
Configuracin de acceso al Janus:

/* Crearemos en el authsources una fuente de autenticacin 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,
Configuracin visual de Janus:

// Permite paginar la pestaa INBOX de Janus
dashboard.inbox.paginate_by => 20,
/* Metadato de la entidad que ser utilizado en la vista de conexin para la identificacin

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,
Configuracin de uso:
// Lo habitual en una federacin 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,
Configuracin del sistema Janus:

El conjunto de estados que puede tener una entidad se va a definir en la array workflowstates

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.shib13-
sp
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
Configuracin de ARPs:
/* Cuando asociamos una ARP a un SP, se aadiran 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 tomarn esos atributos definidos en el ARP
para filtrar los atributos que se liberan desde el IdP */
/* Permite configurar una lista con los atributos que conformarn 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,
),

preferredLanguage => array(

name => preferredLanguage,
),
eduPersonEntitlement => array(
name => eduPersonEntitlement,
),
eduPersonTargetedID => array(
name => eduPersonTargetedID,
),
),
Configuracin de la exportacin 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 publicarn
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 lmite de cache

maxDuration => 60*60*24*5, // 5 das de para que caduquen los metadatos de la entidad
/* Si queremos que los metadatos se firmen, de ser as posteriormente podrn ser

comprobados en el modulo metarefreh */
sign.enable => FALSE,
// Datos del certificado con el que se firmar la publicacin, en caso de que se habilite
sign.privatekey => janus.example.com.key,
sign.privatekey_pass => NULL,
sign.certificate => janus.example.com.crt,
),
Configuracin de los feeds de publicaciones:

mdexport.feeds => array(
// Este feed publica bajo firma todas los proveedores de servicio del tipo SAML 2.0
sp-prod => array(
types => array(saml20-sp),
states => array(prodaccepted),
mime => application/samlmetadata+xml,
exclude => array(),
postprocessor => NULL,
entitiesDescriptorName => SPs del SINED,
filename => sp_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_pass => ,
),
// Este feed publica bajo firma todas los proveedores de identidad del tipo SAML 2.0

idp-prod => array(

types => array(saml20-idp),
exclude => array(),
entitiesDescriptorName => IdPs del SINED,
filename => idp_sined.xml,
),
/* 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),
exclude => array(
https://wayf.example.com/simplesaml/saml2/idp/metadata.php,
https://wayf.example.com/simplesaml/module.php/saml/sp/metadata.php/saml
),
entitiesDescriptorName => IDPs & SPs del SINED,
filename => idpsp_sined.xml,
),
),
Otros parametros:
entity.useblacklist => true, /* Permite habilitar listas blancas o negras a que IdPs se les
entity.usewhitelist => false, ESTA o NO ESTA permitido conectar con un SP */
Existe una wiki en la web de Janus donde viene ms informacin sobre documentacin de cada uno de estos atributos.
Importante. El cron que vamos a asociar al Janus para que automticamente actualice los metadatos de
las entidades haciendo uso de la URL donde dichos metadatos estn publicados por la entidad (atributo
metadata_refresh_cron_tags del archivo de configuracin Janus) debe de estr dado de alta como tag vlido en el
module_cron.php. Adems tenemos que crear una entrada en el servicio de cron para que se ejecute con la periocidad
que deseemos.
3.3.2 Funcionamiento
A continuacin se describen las principales vistas del software Janus. Tambin puede consultar una serie de videos en
la web de Janus para entender su funcionamiento.

Panel de administracin 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 opcin que la de borrarlo en el caso de que tengamos dudas sobre la cuenta.
Panel de administracin 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.

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 configuracin de Janus).
Adems 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 configuracin de
janus, en el atributo mdexport.feeds

Edicin de ARPs
En esta vista podremos administrar las diferentes ARPs de Janus. Por cada ARP se le asigna un nombre, una
descripcin y el conjunto de atributos que la componen. Adems 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, adems de editarla se nos mostrar el conjunto de entidades que la estn
utilizando en ese momento.
Panel de administracin de una entidad
En esta vista se nos presenta informacin relacionada con la entidad:

Connection ID. Que es el entityID de la entidad
Metadata URL. Que es la direccin en la que se encuentran disponibles los metadatos de la entidad, y que es
la URL que es utilizada para que JANUS actualice automticamente sus metadatos
ARP. Define la ARP asociada a la entidad
Revision note. Indica algn comentario asociado a la actual reversin de datos de la entidad
Parent revision. Indica cual es la revisin 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 configuracin de Janus
Type. Tipo de entidad.

Desde esta vista podemos acceder a diferentes vistas:

Metadata. Vista de edicin de los metadatos
Import metadata. Vista de importacin de los metadatos
History. Vista del historico. Desde esta vista podremos volver a una revisin anterior de los datos de la entidad.
Validate. VIsta de validacin. 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 validacin.
Export. Vista de exportacin 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.

Editor de metadatos de una entidad
Desde esta vista podremos editar los metadatos de una entidad.

Vista de metadatos de una entidad
Desde esta vista podremos comprobar los metadatos que se estn publicando de una determinada entidad. Se muestran
varios formatos: XML, flatfile
3.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 trs la verificacin 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.
3.4. PEER 26
CAPTULO
FOUR
PROTOCOLO DE RESOLUCIN DE
INCIDENCIAS EN UN ENTORNO DE
FEDERACIN DE IDENTIDADES
4.1 Errores ms frecuentes
Los errores ms frecuentes que se dan en nuestra federacin 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 excepcin 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 autenticacin el usuario le da al botn de atrs del navegador, o se corta la conexin u otro
fallo inesperado, se pierde la sesin 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 botn de autenticar se produce el error Duplicated assertion
sent.
4.2 Protocolo de gestin de errores actual
4.2.1 Falta de datos
Si el problema se ocasiona en el nodo Hub y se debe a que los atributos necesarios no estn 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 excepcin y entre
otras cosas el sistema no sabe qu IdP debe indicarle para solucionar el problema. En este caso se enva un correo a
los operadores de la federacin con los atributos del usuario de los que se dispone. Los operadores examinan estos
atributos para ver si es posible averiguar el IdP de orgen de dicho usuario para informar a su administrador. Si el
27
usuario est utilizando la direccin de correo institucional, la tarea de obtener su IdP de orgen suele ser fcil. 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 direccin de correo.
4.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 enva al operador de la federacin en el caso de que
se produzca en el nodo hub (y si est bien configurado el IdP tambin debe llegar al administrador del proveedor de
identidad).
4.2.3 Que pasa si el problema persiste?
Actualmente si el problema persiste, el operador de la federacin 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 solucin: Borrar las cookies del navegador, tener cuidado en la navegacin o ponerse en contacto con el
CAU de su universidad.
4.2. Protocolo de gestin de errores actual 28

CAPTULO
FIVE
DESPLEGAR UN SP CON
SIMPLESAMLPHP
5.1 Recursos de ayuda
Documentacin de instalacin de simpleSAMLphp

Documentacin de como configurar simpleSAMLphp como un SP
Docuemntacin de la wiki de Confa (y como actualizar de una version a otra)
5.2 Instalacin y configuracin
5.2.1 Instalacin y dependencias
Vamos a explicar como instalar SimpleSAMLphp en una distribucin CentOS 6.3, la cual est disponible para su
descarga desde http://isoredirect.centos.org/centos/6/isos/x86_64/
Una vez se encuentre el sistema operativo instalado, se debe proceder a la instalacin de las dependencias de
simpleSAMLphp:
yum install php pcre httpd zlib openssl mod_ssl php-mbstring php-mcrypt php-pdo
Es posible comprobar que los mdulos se encuentra activos creando un fichero index.php en el directorio de
publicacin de Apache2 con el siguiente cdigo:
<?php phpinfo(); ?>
5.2.2 Instalacin de SimpleSAMLphp
Una vez resueltas todas las dependencias, la instalacin de SimpleSAMLphp es realmente sencilla, solamente es
necesario descargar el cdigo fuente en un directorio del sistema, por ejemplo en el directorio /var/www/sp/
yum install subversion
mkdir /var/www/sp
svn co http://simplesamlphp.googlecode.com/svn/branches/simplesamlphp-1.10 simplesamlphp /var/www/sp/
29
Estructura general
|--cert Directorio donde alojar el certificado y la clave que sern usados para firmar
|--config Directorio con los ficheros de configuracin de simpleSAMLphp
|--config-templates Directorio con plantillas de los ficheros de configuracin
|--metadata Directorio donde alojar ficheros con los metadatos de los IdPs remotos en los
|--metadata-templates Directorio con plantillas de los ficheros de metadatos
|--modules Directorio con los diferentes mdulos de simpleSAMLphp
|--lib Directorio con las librerias de simpleSAMLphp
|--www Directorio con la lgica web de simpleSAMLphp
|--templates Directorio con las plantillas web de simpleSAMLphp
|--dictionaries Directorio con las traducciones de simpleSAMLphp
|--docs Directorio con dcd ocumentacin
|--log Directorio donde alojar los logs de simpleSAMLphp (Requiere configurar el conf
|--attributemap Directorio con ficheros con lgica para realizar el mapeo de atributos
|--schemas Directorio con esquemas xsd.
|--bin Directorio con herramientas de scripts
Hay que asegurarse que el servidor Apache tenga acceso de escritura a los directorios logs y metadata.
Configuracin general
Los ficheros de configuracin 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 configuracin 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 configuracin correspondiente desde cero, lo cul suele ser
mucho ms propenso a errores.
El primer fichero a modificar es el fichero config.php. Por tanto, lo mejor es copiar su plantilla correspondiente
cp /var/www/sp/simplesamlphp/config-templates/config.php /var/www/sp/simplesamlphp/config/config.php
Como todos los ficheros de configuracin de simpleSAMLphp es un fichero PHP con las reglas de sintxis 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/sp/simplesamlphp/config/config.php
# No syntax errors detected in /var/www/sp/simplesamlphp/config/config.php
A continuacin se detallan las partes ms habituales del fichero config.php que hay que modificar:
Contrasea de administracin de simpleSAMLphp
auth.adminpassword => admin,
Es importante cambiar esta contrasea porque adems 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 direccin de correo del administrador de este simpleSAMLphp:
5.2. Instalacin y configuracin 30

technicalcontact_name => Administrator,

technicalcontact_email => na@example.org,
Zona horaria:
timezone => NULL,
Un valor de ejemplo para este parmetro es Europe/Madrid

Idioma predeterminado:
language.default => en,
Lo ms habitual es poner el valor es para que la interfaz de simpleSAMLphp salga en espaol.

Hay muchas ms opciones de configuracin pero ests son las ms bsicas y necesarias de modificar. Los comentarios
en el fichero config.php explican bastante bien para qu sirve cada uno de los parmetros de configuracin.
Configuracin como SP
A diferencia del IdP en el SP los metadatos propios se configuran en el fichero config/authsources.php

<?php
$config = array(
saml => array(
saml:SP,
host => sp.example.com,
entityID => https://sp.example.com/simplesaml/module.php/saml/sp/metadata.php/saml,
idp => https://idp.example.com/simplesaml/saml2/idp/metadata.php,
certificate => sp.example.com.crt,
privatekey => sp.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 (
),
OrganizationURL => array (
en => http://sp.example.com,
es => http://sp.example.com,
),
),
);
?>
A continuacin se detallan los principales parmetros que hay que configurar:

host Nombre del host de esta mquina que se utiliza en el VirtualHost de Apache correspondiente

entityId Identificador de identidad. Debe corresponderse con la URL que obtiene los metadatos de este SP
idp El IdP que debe utilizar este SP para autenticarse. Debe aparecer el entityId de un nodo IdP (o WAYF).
certificate y privatekey Son las dos partes (pblica y privada) del certificado usado en el SP. Estos ficheros deben
encontrarse en el directorio cert del directorio raz de simpleSAMLphp a no ser que se haya cambiado esa
ubicacin en el fichero config.php
redirect.sign TRUE Si la peticin de autenticacin, peticin de log out y respuesta de log out enviadas desde este SP
a cualquier IdP deben de estar firmadas. Por defecto False.
redirect.validate TRUE si la peticin de autenticacin, peticin de logout o la respuesta de logout recibidas en este
SP deben de ser validadas. Por defecto False
assertion.encryption Este parmetro deben estar a TRUE si obligamos a que las aserciones recibidas en este SP
provenientes de cualquier IdP esten cifradas. Por defecto False.
5.2.3 Configuracin de los metadatos de los IdPs
Los metadatos de los IdPs en los que el SP va a confiar deben de definirse dentro de la carpeta metadata en el fichero
saml20-idp-remote.php. A continuacin se presenta un ejemplo
<?php
$metadata[https://idp.example.com/simplesaml/saml2/idp/metadata.php] = array (
metadata-set => saml20-idp-remote,
entityid => https://idp.example.com/simplesaml/saml2/idp/metadata.php,
SingleSignOnService => https://idp.example.com/simplesaml/saml2/idp/SSOService.php,
SingleLogoutService => https://idp.example.com/simplesaml/saml2/idp/SingleLogoutService.php,
certData => MIICQTCCAaoCCQCOMxLGB244ZzANBgkqhkiG9w0BAQUFADBlMQswCQYDVQQGEwJFUzESMBAGA1UECBMJQ
pc3RlbWFzMRgwFgYDVQQDEw9pZHAuZXhhbXBsZS5jb20wHhcNMTEwNDE4MDg1NDQ2WhcNMTYwNDE2MD
YDVQQHEwdTZXZpbGxhMRYwFAYDVQQKEw1ZYWNvIFNpc3RlbWFzMRgwFgYDVQQDEw9pZHAuZXhhbXBsZ
zoSgahBggvVPhmKROi0ajlAfVQ1YPwjpDstkK19Dhi99diw+ipJ6q44AEanpc8x/h0f1r2FJfBlF1HY
XbFtvbyngJTvZt91AgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAYdYYFxKibC32nm4E9RZCVk74Xcx6Lah
s9zXNPgyweSujcP54IVBH0qBSFJCmPdZc+0uasi4KClwOMjVIq3WpVvycA/sHl7kH1jYTtNea8rr1vS
NameIDFormat => urn:oasis:names:tc:SAML:2.0:nameid-format:transient,
OrganizationName =>
array (
),
OrganizationDisplayName =>
array (
),
OrganizationURL =>
array (
en => http://idp.example.com,
es => http://idp.example.com,
),
);
?>
.. _sp_configuracion_apache:

5.2.4 Configuracin de Apache
Se debe crear un fichero de configuracin para el VirtualHost de sp.example.com.conf en el directorio

/etc/httpd/conf.d/ con el siguiente contenido:
<VirtualHost *:80>
ServerName sp.example.com
DocumentRoot /var/demo-federation/sp/simplesamlphp/www
SSLProxyEngine On
ProxyPreserveHost On
Alias /simplesaml /var/demo-federation/sp/simplesamlphp/www
<Location />
ProxyPass https://localhost
</Location>
</VirtualHost>
<VirtualHost *:443>
ServerName sp.example.com
DocumentRoot /var/demo-federation/sp/simplesamlphp/www
Alias /simplesaml /var/demo-federation/sp/simplesamlphp/www
SSLEngine on
SSLCertificateFile /etc/httpd/ssl/sp.example.com/crt/sp.example.com.crt
SSLCertificateKeyFile /etc/httpd/ssl/sp.example.com/key/sp.example.com.key
</VirtualHost>
Nota: Si configuramos varias entradas para la misma IP deberemos habilitar el NameVirtualHost en el

/etc/httpd/conf/httpd.conf:
NameVirtualHost *:80
NameVirtualHost *:443
Adems es necesario crear los certificados (autogenerados) que se han especificado en la configuracion del VirtualHost
para https. Se debern seguir las siguientes instrucciones:
1. Crear el directorio donde alojar los certificados, en este caso, /etc/httpd/ssl/sp.example.com/
mkdir -p /etc/httpd/ssl/sp.example.com/crt /etc/httpd/ssl/sp.example.com/key
2. Cambiar el directorio actual por /etc/httpd/ssl/sp.example.com/

cd /etc/httpd/ssl/sp.example.com/
3. Creacin de la clave sin contrasea y con una encriptacin 1024

openssl genrsa -out server.pem 1024
4. Generar el fichero CSR (solicitud de certificado)

openssl req -new -key server.pem -out server.csr
5. Generar el certificado autofirmado

openssl x509 -req -days 1825 -in server.csr -signkey server.pem -out server.crt
5.2.5 Pruebas de autenticacin con los Proveedores de Identidad
En este punto ya es posible realizar una prueba de autenticacin con alguno de los IdP registrados en los metadatos
de este SP. Para ello hay que ir a la pestaa Autenticacin de la interfaz web de simpleSAMLphp y pinchar

en el enlace Probar las fuentes para la autentificacin ya configuradas. Despus hay que
seleccionar el nombre de la fuente en la que se ha configurado el SP. En el ejemplo anterior sera saml.
Si todo funciona correctamente, debera aparecer un listado de IdPs y tras seleccionar uno de ellos y autenticarse
correctamente en l debera aparecer una pantalla con el los atributos que este IdP ha enviado de vuelta al SP.
5.3 Configuracin avanzada
5.3.1 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 parmetros:
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 nmero del ndice del array
(los nmeros ms bajos se ejeutan antes).
Existe documentacin detallada sobre los filtros de atributos implementados en simpleSAMLphp.
Generacin de atributos
ePTI: Implementado como filtro core:AttributeAlter

<?php
10 => array(
class => core:AttributeAlter,

subject => eduPersonTargetedID,
pattern => /^(.*)$/,
replacement => \1@<dominio>
),
Comprobacin de atributos
Filtro DNI: Implementado como filtro core:PHP
5.3. Configuracin avanzada 34

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;
}
}
}
,
),
Eliminacin de atributos
Filtro contrasea: Implementado como filtro core:AttributeAdd

12 => array(
class => core:AttributeAdd,
%replace,
userPassword => ,
),
Fitro limitador de atributos (slo 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 creacin de datos con core:PHP
Creacin 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";
$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:personalUniqueID:es
$attributes["schacUserStatus"] = array();
$base_course = "urn:mace:terena.org:schac:userStatus:es:campusandaluzvirtual.es:";
$attributes["schacUserStatus"][] = $base_course."98705999:2009-10:student:active";
}
,
),
AttributeValueFilter
El filtro AttributeValueFilter elimina determinados valores de los atributos basndose en patrones definidos.
Parmetros:
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 <> patrn 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.sp => array(
60 => array(
class => attributevaluefilter:AttributeValueFilter,
attributename => schacUserStatus,
spmapping => $sps_patterns,
),
),
);
5.3.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 ms funcionalidad que los nodos perifricos (consentimiento, descubrimiento, validacin,
estadsticas, monitorizacin, gestin de metadatos) si que requerir de un poco ms de planificacin para ponerlo en
alta disponibilidad.
En los IdPs y SPs lo nico que es importante compartir entre los nodos de SimpleSAMLPHP es la sesin de los
usuarios. En este sentido es muy cmodo 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 habra que configurar que
el manejador de sesiones de simpleSAMLphp sea del tipo database.
Y por ultimo nos quedara 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 continuacin explicamos como se configurara.
En SimpleSAMLPHP la configuracin de los servidores Memcached se realiza por grupos. Cada elemento de
informacin se almacena en todos los grupos por motivos de redundancia. Cada grupo est compuesto por varios
servidores Memcached pero cada elemento de informacin se almacena en uno slo de ellos. En este caso el tener
varios servidores se hace para conseguir un mayor rendimiento.
Lo ms importante de todo es que SimpleSAMLPHP se encarga de gestionar todo esto de forma automtica. Lo nico
que hay que decirle es las direcciones de los servidores Memcached.
Instalacin de memcached
Instalamos el servidor de memcached y el cliente para php:

yum install memcached php-pecl-memcache
Y configuramos el servicio:
vim /etc/sysconfig/memcached
PORT="11211"
USER="memcached"
MAXCONN="1024"
CACHESIZE="512" # 512MB
OPTIONS=""
A continuacin aadimos 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
Y reiniciamos el servidor apache:

/etc/init.d/httpd restart
Configuracin de memcached en simpleSAMLphp
Para conseguir la configuracin mostrada en la siguiente figura

tendramos que aadir esta informacin 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(
),
),

Cada grupo de servidores es un array de servidores. Cada servidor es un array con las siguientes claves:
hostname. Nombre del servidor o direccin IP del servidor Memcache. Es la nica opcin obligatoria.
port. Nmero 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 sesin.
timeout. Tiempo que se espera a que el servidor responda. Por defecto es 3 segundos.
Con esta configuracin se podran perder los tres servidores del grupo 1, 2 3 sin que se perdiera ninguno dato de
sesin. Si se pierden los tres servidores etiquetados como A, B o C entonces s habra perdida de informacin.

CAPTULO
SIX
DOMESTICACIN DE APLICACIONES
CON SIMPLESAMLPHP
En el apartado anterior hemos visto como Desplegar un SP con SimpleSAMLphp En este apartado veremos como se
federara una aplicacin php haciendo uso de esa instancia SP.
Bsicamente la aplicacin php a la que llamaremos a partir de ahora aplicacin local cargar las libreras de la API
de simpleSAMLphp para iniciar el proceso de login, obtener los atributos del usuario, cerrar sesin, etc.
6.1 Repaso de la API de simpleSAMLphp
Existe documentacin sobre como utilizar la librera de simpleSAMLphp desde una aplicacin php
En resumen las funciones a utilizar son:
Inicializacin de la instancia de simpleSAMLphp
$as = new SimpleSAML_Auth_Simple(default-sp);
Forzar a que estamos autenticados

$as->requireAuth();
Comprobar que el usuario est autenticado

$as->isAuthenticated()
Obtener los atributos del usuario

$attributes = $as->getAttributes();
Desloguear al usuario
$as->logout();
6.2 Autenticacin, autorizacin y provisionamiento
A la hora de domesticar una aplicacin lo podemos hacer con mayor o menor profundidad.
41
6.2.1 Domesticacin bsica
La domesticacin bsica consistira en aadir soporte a la aplicacin local para permitir autenticar usuarios que ya
existieran en la aplicacin local a travs de un IdP haciendo uso del protocolo SAML, con lo que se conseguira a la
vez la funcionalidad del SSO.
Adicionalmente al SSO podra implementarse o no la funcionalidad de SLO (Single Log Out) que podra a su vez
cohabitar o no con el logout local de la aplicacin (Ojo con la usabilidad).
6.2.2 Domesticacin bsica + provisin
La domesticacin media consistira en aadir soporte de SSO y de provisin automtica del usuario. Se
implementara la lgica necesaria para que con los datos que llegan en la asercin SAML fuera posible
crear/modificar/desactivar/eliminar una cuenta de usuario.
6.2.3 Domesticacin media
En este escenario adems de autenticacin y provisionamiento se implementa toda la lgica necesaria para que la
autorizacin en la aplicacin a domesticar dependa de los atributos que le llegan de la asercin SAML. Aqu entrara
todo el tema de manejo de roles, permisos y grupos.
6.2.4 Domesticacin avanzada
Es la ms compleja. A la autenticacin, autorizacin y provisionamiento just-in-time se le aadira la capacidad de

que cuando un dato fuera modificado en el IdP, automticamente se modificara en la aplicacin local haciendo uso del
protocolo SAML.
Podemos ver aqui varios ejemplos: * Provision asncrona por lotes * Provisin asncrona de un usuario en varias
aplicaciones
El cdigo est dispible en github: Asynchronous-provisioning based on simpleSAMLphp
6.3 Ejemplo de aplicacin federada
Tenemos una aplicacin example_php con la siguiente estructura:

-config.php Que contiene los parametros de configuracin SAML
-index.php Que es la pantalla principal de la aplicacin
-login.php Que es la vista que contiene la funcionalidad del login SAML
-logout.php Que es la vista que contiene la funcionalidad de logout SAML
-resources Directorio que contiene css e imgenes
6.3.1 Fichero de configuracin [config.php]
<?php
$saml_lib_path = /var/www/sp/simplesamlphp/lib/_autoload.php;
require_once($saml_lib_path);
$aplication_base_url = https://sp.cursosaml.org/example-php/;
6.3. Ejemplo de aplicacin federada 42

$source = example-php; # Fuente de autenticacin definida en el authsources del SP
?>
Definimos donde se encuentra el archivo que carga las libreras de simpleSAMLphp Cargamos la librera Definimos
la url base de nuestra aplicacin Definimos la fuente de autenticacin SAML que queremos utilizar y que tenemos
definida en el config/authsources.php del SP simpleSAMLphp.
6.3.2 Fichero principal [index.php]
<html>
<head>
<title>Aplicacin PHP de ejemplo federada usando simpleSAMLphp</title>
<link href="resources/css/bootstrap.min.css" rel="stylesheet" media="screen">
</head>
<body>
<?php
require_once(config.php);
$as = new SimpleSAML_Auth_Simple($source); # Se pasa como parametro la fuente de autenticacin
echo <h3>Aplicacin PHP de ejemplo federada usando simpleSAMLphp</h3>;
if(!$as->isAuthenticated()) {
echo <p><a class="btn" href="login.php">Login</a></p>;
}
else {
echo <h4>Atributos del usuario:</h4>;
if(empty($attributes)) {
echo No se obtuvieron atributos del usuario;
}
else {
echo <table class="table table-bordered table-striped">;
foreach($attributes as $key => $values) {

echo <tr><td> . $key . </td><td>;
echo implode(<br>,$values);
echo </td></tr>;
}
echo </table>;
}
echo <p><a class="btn" href="logout.php">Cerrar sesin</a></p>;
}
?>
</body>
</html>
En esta vista si el usuario no se ha autenticado an, le ofrecemos el enlace para hacerlo, a la vista login.php. En caso
de que ya se haya autenticado, le mostramos sus atributos si se ha recibido alguno y le damos opcin a que cierre la
sesin.
6.3. Ejemplo de aplicacin federada 43

En el cdigo vemos que primero cargamos el fichero de configuracin para disponer de las variables alli definidas.
Luego instanciamos la clase de la fuente simpleSAMLphp pasandole como parmetro la fuente que queremos. Luego
comprobamos si el usuario est o no autenticado con la funcin isAuthenticated() y en caso de que lo est
obtenemos sus datos con la funcin getAttributes().
6.3.3 Fichero para inicio de sesin [login.php]
<?php
$as = new SimpleSAML_Auth_Simple($source); # Se pasa como parametro la fuente de autenticacin
$login_params = array(
ReturnTo => $aplication_base_url . index.php,
);
$as->requireAuth($login_params);
?>
En esta vista la novedad es que redirigimos al usuario para que inicie el login en el IdP, y le pasamos como parametro
(ReturnTo) la url de la vista principal para que una vez autenticado el usuario se le redirija a ella.
6.3.4 Fichero para cierre de sesin [logout.php]
<?php
$as = new SimpleSAML_Auth_Simple($source); # Se pasa como parametro la fuente de autenticacin de

if ($as->isAuthenticated()) {
$as->logout($aplication_base_url . index.php); # Se puede pasar como parametro a donde redir
}
else {
header(Location: .$aplication_base_url . index.php); # Si no estaba autenticado vuelvo a l
}
?>
En esta vista se comprueba si el usuario est autenticado en el sistema y si lo est se le fuerza a desloguear en el IdP.
Al final redirijimos al usuario a la vista principal ya sea porque no estuviera identificado que se ejecutara el header
Location, o si lo est porque le pasamos una url a la que redirigir como parametro del logout.
Lo ltimo que hay que hacer es servir la aplicacin en el apache, lo haremos bajo HTTPs por lo que lo meteremos en
el mismo virtualhost donde tengamos desplegado el simpleSAMLphp:
Alias /example-php /var/www/apps/example_php
Y reiniciar el apache:
6.4 Algunas cuestiones a tener en cuenta a la hora de domesticar

una aplicacin
Identificar las funciones para el manejo de login/logout y de cuenta de usuario. Existe una API documentada?
6.4. Algunas cuestiones a tener en cuenta a la hora de domesticar una aplicacin 44

Est la aplicacin preparada para trabajar sin la necesidad de que un usuario no posea password?
Analizar el Workflow de creacin de una cuenta de usuario. Tambin el de acceso del usuario y el termino de la
sesin.
Posee panel de administracin para poder configurar parametros va web? Posee fichero de configuracin?
Existe una API de autenticacin? Existn plugins de autenticacin o toda la lgica de autenticacin se realiza
en un mismo fichero?
Ver como maneja las sesiones
Analizar la vista de login y ver como integrar la autenticacin SAML
6.5 Anlisis de algunas domesticaciones
6.5.1 Ejemplo Tiki Wiki
Tiki Wiki es un software open source que es tiene un batiburrillo de aplicaciones: Wiki/CMS/Groupware/Forum/etc.
Analisis pre-federacin:
Existe panel de administracin.
Posee el concepto de plugin de autenticacin aunque no hay ninguna clase base definida.
Existe una clase usuario que se encuentra en el fichero lib/userslib.php. En dicha clase se definen las
funciones de autenticacin.
Existe una plantilla para el formulario de login templates/modules/mod-login_box.tpl y hay un
fichero que se carga al inicio que puede ser utilizado para forzar el login SAML tiki-setup_base.php
Para habilitar el panel para introducir los parmetros SAML identificamos los ficheros necesarios:
lib/prefs/auth.php En el que creamos un nuevo tipo de autenticacin
lib/prefs/ssp.php En el que definimos los parmetros que hay que configurar
En este commit se puede apreciar los cambios que fueron necesarios realizar para dar soporte SAML a dicha
aplicacin:
https://github.com/pitbulk/tiki-saml/commit/01df62e2613b4a7f2e4ea83b721f5043bfa0c447
6.5.2 Ejemplo Owncloud
Owncloud es un software que surgio para cubrir la necesidad del alojamiento y transferencia de ficheros pero que
ahora es mucho ms: Reproductor/Visualizador/Gestor de calendario/etc.
Posee el concepto de plugin de autenticacin y en general, cada componente (lo llaman app) que se integra
lo hace en forma de plugin. Adems cada app debe de cumplir una estructura. Y todas las aplicaciones se
encuentran en la carpeta apps. No hay una clase base de autenticacin.
Posee una clase base de usuario que puede ser extendida
Al igual que en el caso de Tiki Wiki, las funciones relacionadas con la autenticacin forman parte de la
Posee una serie de hooks que fueron utilizados para aadir el soporte SAML
6.5. Anlisis de algunas domesticaciones 45

Plugin disponible en: https://github.com/pitbulk/apps/tree/master/user_saml
6.5.3 Ejemplo Moodle
Posee el concepto de plugin de autenticacin, existe una clase base definida lib/authlib.php. Todos los plugin de
autenticacin se encuentran en la carpeta auth
No existe clase base de usuario pero si varias funciones para manejarlos en lib/moodlelib.php
El fichero que renderiza la vista de login no permite interaccin desde el plugin de autenticacin
Permite multiples maneras de almacenar sesiones (fichero, base de datos, etc). Posee su propia librera para
manejar las sesiones lib/sessionlib.php
Plugin disponible en: https://forja.rediris.es/svn/confia/moodle/trunk/v2.2.3/auth/saml/
6.6 Conflictos con las sesiones
6.6.1 Colisin de la sesin de la aplicacin local con la sesin de SSP
En el la aplicacin ejemplo example-php que mostramos anteriormente podemos ver que no existe una sesin local en
la que se guarde si el usuario est logado o no, sino que unicamente se trabaja con la sesin SAML.
En el mundo real, las aplicaciones que vayamos a domesticar dispondrn de su propia sesin local en la que se
guarde entre otras cosas, la informacin del usuario, informacin de acceso, etc. Tendremos que prevenir que la sesin
local y la sesin SAML no entren en conflicto y que la carga de libreras o las llamadas a funciones de la aplicacin
local o de la aplicacin SAML no provocan efectos colaterales en las sesiones.
La forma rpida de prevenir posibles colisiones con las sesiones es la de hacer que el tipo de almacenamiento de las
sesin local y de la sesin SAML sea siempre diferente. Esto se consigue configurando diferentes manejadores de
sesin. Existe files (por defecto), sqlite, memcached pero tambin es posible definir tu propio manejador.
El tipo de manejador que se utiliza en la aplicacin local puede definirse en el propio cdigo de la aplicacin con
la funcin session_set_save_handler pero si no se define se utilizar el que venga declarado en el php.ini en el valor
session.save_handler http://www.php.net/manual/en/session.configuration.php#ini.session.save-handler.
En simpleSAMLphp el tipo de manejador de sesiones que va a ser utilizado depende del valor del parmetro
store.type del archivo de configuracin config.php. Los valores posibles son sql, memcache o phpsession (lo
que estuviera definido en el php.ini).
La otra alternativa es estudiar muy bien el cdigo de la aplicacin local, ver que cdigo hace falta aadir para
implementar el soporte SAML, encontrar los puntos de conflicto y tratar de eliminarlos por ejemplo cambiando el
orden en el que se cargan y llaman las libreras de uno y otro (siempre que esto no afecte a la lgica inicial y el
resultado vaya a ser el mismo)
Si en el ejemplo anterior modificamos un poco el index.php para que simule la carga de librerias locales de la aplicacin
que provoquen conflictos con las sesiones de simpleSAMLphp.
Fichero para cierre de sesin [logout.php]
6.6. Conflictos con las sesiones 46

Fichero principal [index.php]
<html>
<head>
<title>Aplicacin PHP de ejemplo federada usando simpleSAMLphp con problemas con las sesiones</title>
<link href="resources/css/bootstrap.min.css" rel="stylesheet" media="screen">
</head>
<body>
<?php
$as = new SimpleSAML_Auth_Simple($source);
echo <h3>Aplicacin PHP de ejemplo federada usando simpleSAMLphp con problemas con las sesiones</h
include_once(applib.php); ### Nueva linea que aadimos
if(!$as->isAuthenticated()) {
echo <p><a class="btn" href="login.php">Login</a></p>;
}
else {
echo <h4>Atributos del usuario:</h4>;
}
else {

echo </td></tr>;
}
echo </table>;
}
echo <p><a class="btn" href="logout.php">Cerrar sesin</a></p>;
}
?>
</body>
</html>
Librerias de aplicacin local [applib.php]
<?php
// Imagine that we load here some libraries of the local app
// Here is a piece of code that will cause session problems.

broke_session();
6.6. Conflictos con las sesiones 47

// And here more staff
function broke_session() {
// initialize session
session_start();
// delete previous possible values

session_unset();
// add some values

$_SESSION[lang] = es;
}
?>
Colocamos ambos ficheros en el directorio www/apps/example_php-session-fail

Y servimos la aplicacin en el apache, lo haremos bajo HTTPs por lo que lo meteremos en el mismo virtualhost donde
tengamos desplegado el simpleSAMLphp:
Alias /example-php-session-fail /var/www/apps/example_php-session-fail
Y reiniciar el apache:
Si accedemos a la aplicacin, veremos que la federacin deja de funcionar debido a un conflicto con las sesiones
6.6.2 Error de lectura de la sesin de SSP
Otro problema relacionado con las sesiones ocurre cuando no tenemos acceso desde la aplicacin final a la sesin
del simpleSAMLphp por estar est relacionada con un dominio diferente, y por tanto inalcanzable. En el archivo
/config/config.php hay varios parametros importantes relacionados con la sesin que hay que tener en consideracin:
session.cookie.name => SimpleSAMLSessionID, # Nombre para la cookie de sesin
session.cookie.path => /, # Sirve para limitar las cookies para un subdirector
session.cookie.domain => , # Para especificar un dominio concreto para la sesi
session.cookie.secure => FALSE, # TRUE si el usuario nicamente va a acceder va HTT
enable.http_post => FALSE, # Activado, permite evitar que el navegador muestre
# pero el IdP deber ser accesible tanto va HTTP c
session.phpsession.cookiename => null,
session.phpsession.savepath => null,
session.phpsession.httponly => FALSE,
6.7 Algunos problemas a resolver a la hora de domesticar aplica-

ciones
6.7.1 Acceso del administrador
Si tras la domesticacin, la autenticacin SAML es la nica que queremos dejar habilitada para nuestros usuarios,
Que pasa si la federacin falla o si hemos configurado mal los parametros?.
Es siempre recomendable dejar una autenticacin alternativa para los usuarios administradores.
6.7. Algunos problemas a resolver a la hora de domesticar aplicaciones 48

6.7.2 El problema del password
Cuando un usuario accede por primera vez a una plataforma haciendo uso de la autenticacin SAML, a la hora de
crear la cuenta no disponemos del password de dicho usuario y por tanto no puede almacenarse un valor vlido en
la aplicacin local, por tanto ese usuario, a menos que exista la funcionalidad de resetear contrasea o que en el
proceso de registro automtico se le pida una clave, no podr acceder a la aplicacin a travs de las autenticaciones
tradicionales de user/pass (base de datos, ldap, fichero de claves, AuthBasic) que hubiera habilitadas en la aplicacin.
6.7.3 El problema de la duplicidad de cuentas
Es importante que si tenemos habilitadas en una aplicacin diferentes fuentes de autenticacin con la capacidad de
crear automaticamente cuentas, todas ellas devuelvan el mismo valor para el identificador de usuario que se utiliza en
la aplicacin a domesticar. De lo contrario se estaran creando varias cuentas para el mismo usuario.
6.7.4 Conflictos con los datos del usuario
Cuando habilitamos en un sitema multiples fuentes de datos, para evitar conflictos, es muy importante unificar el
espacio de nombres, compatibilizar los valores, priorizar las fuentes de datos, etc
Si tenemos habilitadas en una aplicacin diferentes fuentes de autenticacin con la capacidad de crear/modificar
automaticamente cuentas de usuario podemos encontrarnos con conflictos graves como el que se describe a
continuacin:
Imaginemos que permitimos el acceso a nuestra aplicacin a travs de Gmail y que tenemos la cuenta de
de la aplicacin a travs del email. Si en el IdP tenemos almacenado otro valor para el atributo emai
provisionamiento automatico el valor del email se actualizara y dejaramos de poder acceder a la apl
O nos podemos encontrar en que fuentes menos fiables sobreescriban en la aplicacin final valores que una fuente ms
fiable haba registrado.
6.7. Algunos problemas a resolver a la hora de domesticar aplicaciones 49

CAPTULO
SEVEN
DOMESTICACIN DE APLICACIONES
EN OTROS LENGUAJES DIFERENTES
A PHP
Cuando el lenguaje de la aplicacin que queremos federar no es php no podemos realizar una federacin nativa con
simpleSAMLphp (SP en php).
La solucin pasa por:
Recurrir a diferentes mecanismos de federacin como la basada en webservice, la basada en el REMOTE_USER
o en la basada en authmemcookie)
Utilizar un SP implementado en el lenguaje nativo de la aplicacin: python (pySAML2), en java (OIOSAML,
SprintSecurity), etc.
7.1 SimpleSAMLphp+AuthMemCookie
una integracin nativa puede optarse por est situacin.
Consiste en que el SP almacene en el memcache datos del usuario que son leidos en el mdulo Auth memCookie de
Apache que protege la aplicacin a federar.
Existe una documentacin sobre configuracin de autenticacin basada en authmemcookie disponible en simple-
SAMLphp
En Debian existe el paquete libapache2-mod-auth-memcookie por lo que es muy fcil instalar el mdulo
authmemcookie.
En CentOS no existe paquete y hay que compilar varias librerias obsoletas, que suelen dar problemas segn
las versiones. En lugar del mod_authmemcookie recomendamos hacer uso de mod_perl y de la libreria
Apache::Auth::AuthMemCookie que dan el mismo rendimiento.
A continuacin vamos a explicar como se desplegara y configurara este modulo mod_perl, el Apache y el
simpleSAMLphp para que todo funcione:
Instalamos las librerias necesarias desde el repositorio:
yum install libevent memcached php-pecl-memcache python-memcached
yum install mod_perl perl-CPAN
Abrimos una shell perl:
50
perl -MCPAN -e shell
E instalamos el modulo:
install Apache::Auth::AuthMemCookie
Aadimos el servicio memcached para que est siempre activo y lo activamos:

service memcached start
chkconfig memcached on
Lo siguiente que hay que hacer es habilitar en simpleSAMLphp el uso de AuthMemCookie, para ello lo primero es
editar el archivo de configuracin global de simpleSAMLphp config/config.php:
enable.authmemcookie => true,
Lo siguiente es crear el fichero de configuracin config/authmemcookie.php:

<?php
$config = array(
loginmethod => authsource,
authsource => authmemcookie,
cookiename => AuthMemCookie,
username => eduPersonPrincipalName,
groups => NULL,
memcache.host => 127.0.0.1,
memcache.port => 11211,
);
Y la fuente asociada en el config/authsources.php:

<?php
...
authmemcookie => array(

saml:SP,
// The entity ID of this SP.

// Can be NULL/unset, in which case an entity ID is generated based on the metadata URL.
entityID => https://sp.cursosaml.org/simplesaml/module.php/saml/sp/metadata.php/authmemcoo
// The entity ID of the IdP this should SP should contact.

// Can be NULL/unset, in which case the user will be shown a list of available IdPs.
idp => https://idp.cursosaml.org/simplesaml/saml2/idp/metadata.php,
privatekey => server.pem,

certificate => server.crt,
// The URL to the discovery service.

// Can be NULL/unset, in which case a builtin discovery service will be used.
discoURL => NULL,
),
?>
Con ello ya podramos crear nuestra aplicacin a federar que leyera los datos de las cabeceras que le enva el servidor
Apache
A continuacin vamos a ensear 2 ejemplos de aplicaciones federadas haciendo uso de sta tcnica.
Las alojaremos en una carpeta contenedora en /var/www/apps/authmemcookie/
7.1. SimpleSAMLphp+AuthMemCookie 51
En dicha carpeta vamos a colocar 2 archivos estticos:

index.html: Para enlazar a cada una de las aplicaciones.
logout.html: Cuando las aplicaciones cierren la sesin, dirigiremos al usuario a sta pgina.
Nota: Como el Apache va a proteger toda la carpeta que contiene el cdigo de
las aplicaciones federadas (va a requerir identificacin), necesitamos que
estos 2 ficheros estn en sitios desprotegidos para que puedan ser mostrados
al usuario, por eso los hemos colocado en una instancia superior.
7.1.1 Ejemplo de como federar una aplicacin PHP con esta tcnica
Creamos un directorio contenedor que albergar el ejemplo de la aplicacin de php example_php:

mkdir /var/www/apps/authmemcookie/example_php
Y dentro colocamos 2 archivos:

index.php Haciendo uso de la libreria lib.php obtiene los datos del usuario y se los muestra, y da opcin a cerrar
sesin.
lib.php Librera auxiliar que lee los datos de la variable server y los devuelve con la misma estructura a como
sueles devolverlos simpleSAMLphp
[index.php]
<html>
<head>
<title>Aplicacin PHP de ejemplo federada usando authmemCookie</title>
<link href="//sp.cursosaml.org/example-php/resources/css/bootstrap.min.css" rel="stylesheet" media="s
</head>
<body>
<h3>Aplicacin PHP de ejemplo federada usando authmemCookie</h3>
<h4>Atributos del usuario:</h4>
<table class="table table-bordered table-striped">

<?php
include_once("lib.php");
$attributes = get_attributes_from_apache();
}
else {

echo </td></tr>;
}
echo </table>;
}
?>
</table>
<p>
<a class="btn" href="https://sp.cursosaml.org/simplesaml/module.php/core/as_logout.php?AuthId=authm
</p>
</body></html>
[lib.php]
<?php
function get_attributes_from_apache() {
if(isset($_SERVER[HTTP_ATTR_UID]))
$attributes[uid] = $_SERVER[HTTP_ATTR_UID];
if(isset($_SERVER[HTTP_ATTR_EDUPERSONPRINCIPALNAME]))
$attributes[eduPersonPrincipalName] = $_SERVER[HTTP_ATTR_EDUPERSONPRINCIPALNAME];
if(isset($_SERVER[HTTP_ATTR_EDUPERSONAFFILIATION]))
$attributes[eduPersonAffiliation] = $_SERVER[HTTP_ATTR_EDUPERSONAFFILIATION];
if(isset($_SERVER[HTTP_ATTR_MAIL]))
$attributes[mail] = $_SERVER[HTTP_ATTR_MAIL];
if(isset($_SERVER[HTTP_ATTR_SN]))
$attributes[sn] = $_SERVER[HTTP_ATTR_SN];
if(isset($_SERVER[HTTP_ATTR_CN]))
$attributes[cn] = $_SERVER[HTTP_ATTR_CN];
if(isset($_SERVER[HTTP_ATTR_PREFERREDLANGUAGE]))
$attributes[preferredLanguage] = $_SERVER[HTTP_ATTR_PREFERREDLANGUAGE];
if(isset($_SERVER[HTTP_ATTR_OBJECTCLASS]))
$attributes[objectClass] = $_SERVER[HTTP_ATTR_OBJECTCLASS];
if(isset($_SERVER[HTTP_ATTR_GROUPS]))
$attributes[groups] = $_SERVER[HTTP_ATTR_GROUPS];
foreach($attributes as $key => $value) {

$attributes[$key] = explode(:, $value);
}
return $attributes;
}
?>
Por ltimo configuramos el apache para que proteja dicha aplicacin y enve los datos del usuario en la cabecera:
perlModule Apache::Auth::AuthMemCookie
PerlAuthenHandler Apache::Auth::AuthMemCookie::authen_handler
PerlSetVar AuthMemCookie "AuthMemCookie"
PerlSetVar AuthMemServers "127.0.0.1:11211"
# if you want to debug set to 1
PerlSetVar AuthMemDebug 0
# use headers instead of ENV vars
PerlSetVar AuthMemAttrsInHeaders 1
Alias /example-authmemcookie /var/www/apps/authmemcookie

Alias /example-authmemcookie-php /var/www/apps/authmemcookie/example_php
<Directory /var/www/apps/authmemcookie/example_php>
AuthType Cookie
AuthName "Auth Memcookie - PHP"
Require valid-user
ErrorDocument 401 "/simplesaml/authmemcookie.php"
</Directory>
Nota: Si habilitamos esta proteccin y no tenemos el servidor memcached corriendo, al tratar de acceder al recurso
entraremos en un blucle de redirecciones infinito.
Y reiniciamos el apache
Federando aplicaciones php remotas
Si tuvieramos la instancia de simpleSAMLphp en una mquina y quisieramos federar un software php que est en otra
mquina, podramos hacerlo haciendo uso de Authmemcookie.
Lo que haramos es configurar un servidor de memcached (accesible desde la otra mquina) en la mquina que tuviera
el simpleSAMLphp.
Se crea un archivo php que est protegido por el apache y cuyo contenido sea redirigir a la aplicacin que tenemos en
la otra mquina.
En otra mquina, en la aplicacin php a federar lo que deberemos de hacer es leer los datos del usuario del servidor
memcache, conociendo el cookiename y el sessionID. De no existir reenviaramos a la anterior vista protegida.
7.1.2 Ejemplo de como federar una aplicacin Python con esta tcnica
Lo primero es crear el proyecto django que llamaremos example_django y que incluiremos dentro de
/var/www/apps/authmemcookie:
django-admin.py startproject example_django
Nota: Si an no disponemos del entorno para trabajar con python/django ver como desplegar el entorno
Configuramos el proyecto demo en /var/www/apps/authmemcookie/example_django/example_django/settings.p
from os import path # Aadimos esto en la cabecera del fichero
BASEDIR = path.dirname(path.abspath(__file__))
DATABASES = {
default: {
ENGINE: django.db.backends.sqlite3, # Add postgresql_psycopg2, postgresql, mysql,
NAME: /var/www/apps/authmemcookie/example_django/example_django/example_django.sql3, # O
USER: , # Not used with sqlite3.
PASSWORD: , # Not used with sqlite3.
HOST: , # Set to empty string for localhost. Not used with sqlite3.
PORT: , # Set to empty string for default. Not used with sqlite3.
}
}
from os import path

TEMPLATE_DIRS = (
path.join(BASEDIR, templates),
)
Creamos el fichero que contendr la vista en la que mostremos los atributos que hemos obtenido del servidor Apache
www/apps/authmemcookie/example_django/example_django/views.py:
import string
from django.shortcuts import render_to_response

from django.template import RequestContext
def echo_attributes(request,
template=echo_attributes.html):
"""Example view that echo the attributes of an user server
by Apache (AuthMemCookie)"""
return render_to_response(template, {attributes: parse_attributes(request)},

context_instance=RequestContext(request))
def parse_attributes(request):
attributes = {}
attributes[uid] = request.META.get(HTTP_ATTR_UID, )
attributes[eduPersonPrincipalName] = request.META.get(HTTP_ATTR_EDUPERSONPRINCIPALNAME, )
attributes[eduPersonAffiliation] = request.META.get(HTTP_ATTR_EDUPERSONAFFILIATION, )
attributes[mail] = request.META.get(HTTP_ATTR_MAIL, )
attributes[sn] = request.META.get(HTTP_ATTR_SN, )
attributes[cn] = request.META.get(HTTP_ATTR_CN, )
attributes[preferredLanguage] = request.META.get(HTTP_ATTR_PREFERREDLANGUAGE, )
attributes[objectClass] = request.META.get(HTTP_ATTR_OBJECTCLASS, )
attributes[groups] = request.META.get(HTTP_ATTR_GROUPS, )
for field in attributes:

attributes[field] = string.split(str(attributes[field]), :)
return attributes
Y la plantilla para lo cual creamos el directorio templates y creamos el fichero

/var/www/apps/authmemcookie/example_django/example_django/templates/echo_attributes.html
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Aplicacin Python/Django de ejemplo federada usando AuthMemCookie</title>
<link href="https://sp.cursosaml.org/example-php/resources/css/bootstrap.min.css" rel="stylesheet
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
</head>
<body>
<h3>Aplicacin Python/Django de ejemplo federada usando AuthMemCookie</h3>

{% for attribute, value in attributes.items %}
<tr><td>{{ attribute }}:</td>
<td>{{ value|join:"<br> " }}</td></tr>
{% endfor %}
</table>
<p><a class="btn" href="https://sp.cursosaml.org/simplesaml/module.php/core/as_logout.php?AuthId=

</body>
</html>
Configuramos las urls de la demo en /var/www/apps/authmemcookie/example_django/example_django/urls.py

incluyendole la url de la vista que habiamos creado
urlpatterns = patterns(
(r^$, example_django.views.echo_attributes), # Vista basica de prueba.
)
Ahora iniciaremos la base de datos django con el comando:

python manage.py syncdb
Cambiamos los permisos para que Apache pueda sobreescribir:

chown -R apache:apache /var/www/apps/authmemcookie/example_django
Ahora aadimos la siguiente entrada en el apache, como la queremos servir por HTTPs lo colocamos en el mismo
Virtualhost que ya utilizamos anteriormente para servir el simpleSAMLphp
WSGIScriptAlias /example-authmemcookie-django /var/www/apps/authmemcookie/example_django/example_djan
Y tenemos que colocar fuera del virtualhost la siguiente instruccin para que se utilice el PythonPath adecuado:
WSGIPythonPath /var/www/apps/authmemcookie/example_django
(Si ya tenemos otro habra que poner> WSGIPythonPath <path_1>:<path_2>

Y proteger la vista:
<Location /example-authmemcookie-django>
AuthType Cookie
AuthName "Auth Memcookie - Python"
Require valid-user
ErrorDocument 401 "/simplesaml/authmemcookie.php"
</Location>
7.2 ShibbolethSP+REMOTE USER
una integracin nativa puede optarse por est opcin.
7.2. ShibbolethSP+REMOTE USER 56

Se basa en que el Apache proteja la aplicacin a federar con la autenticacin shibboleth (Shibboleth SP) habilitando
el mod_shib. El Apache le hara llegar los datos del usuario a la aplicacin que queremos federar. El Apache utilizara
las cabeceras HTTP para hacerle llegar los datos del usuario a la aplicacin que queremos federar.
Existe una documentacin sobre instalacin y configuracin de autenticacin shibboleth basada en RemoteUser.
Lo primero que hace falta es instalar shibboleth y sus dependencias por lo que tenemos que aadir el repositorio al
yum.
cd /etc/yum.repos.d
wget http://download.opensuse.org/repositories/security://shibboleth/CentOS_CentOS-6/security:shibbol
yum update
yum install shibboleth
Tras esto ya tendremos todo lo necesario en el sistema.

Los archivos de configuracin de shibboleth se encuentran en /etc/shibboleth
Lo primero que haremos ser sustitutir los ficheros que contienen los certificados por unos vlidos, estas son las rutas
donde deben estar:
/etc/shibboleth/sp-cert.pem
/etc/shibboleth/sp-key.pem
Lo siguiente que haremos sera descargarnos los metadatos del IdP en el que los shibboleth SP van a confiar.
wget --no-check-certificate https://idp.cursosaml.org/simplesaml/saml2/idp/metadata.php -O /etc/shibb
Lo siguiente que hay que hacer es editar el archivo de configuracin de shibboleth, shibboleth2.xml en el que
se configuran parmetros globales pero tambin los parmetros de cada SP que se quiera desplegar. Veamos ahora los
parmetros globales, y luego explcaremos como configurar cada uno de los SPs en los apartados posteriores.
Entityid
<ApplicationDefaults entityID="https://shib.cursosaml.org/Shibboleth.sso/Metadata"
REMOTE_USER="uid persistent-id targeted-id"
authType="TLS" id="default">
Opciones referentes a sesiones

<Sessions lifetime="28800" timeout="3600" relayState="ss:mem"
checkAddress="true" handlerSSL="true" cookieProps="https">
Configurar a que IdP lo conectamos:

<SSO entityID="https://idp.cursosaml.org/simplesaml/saml2/idp/metadata.php">
SAML2
</SSO>
<Logout>SAML2 Local</Logout>
Firmar los metadatos del SP

<Handler type="MetadataGenerator" Location="/Metadata" signing="true"/>
Vista de estado:
<Handler type="Status" Location="/Status" />
Nota: En entornos de produccin deberemos de aadirle un acl=127.0.0.1 si queremos que slo se pueda consultar
el estado desde la mquina local
Contacto:

<Errors supportContact="root@cursosaml.org"
helpLocation="/about.html"
styleSheet="/shibboleth-sp/main.css"/>
Los metatados del IdP:

<MetadataProvider type="XML" file="idp.xml"/>
Y por ultimo editamos un archivo en el que se configuran los protocolos a utilizar

/etc/shiboleth/protocols.xml , y dejamos:
<Protocols xmlns="urn:mace:shibboleth:2.0:native:sp:protocols">


<Protocol id="SAML2">
<Service id="SSO">
<Initiator id="SAML2" />
<Binding id="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" path="/SAML2/POST" />
</Service>
<Service id="Logout">
<Initiator id="SAML2" />
<Binding id="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" path="/SLO/Redirect" />
</Service>
</Protocol>


<Protocol id="Local">
<Service id="Logout">
<Initiator id="Local" />
</Service>
</Protocol>
</Protocols>
Lo siguiente que hay que hacer es configuar el mapper de atributos de simpleSAMLphp a shibboleth, editamos el
archivo /etc/shiboleth/attribute-map.xml:
<Attribute name="uid" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" id="uid"/>
<Attribute name="cn" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" id="cn"/>
<Attribute name="sn" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" id="sn"/>
<Attribute name="mail" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" id="mail"/>
<Attribute name="eduPersonPrincipalName" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basi
<Attribute name="eduPersonAffiliation" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
<Attribute name="displayName" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" id="disp
<Attribute name="givenName" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" id="givenN
<Attribute name="schacSn1" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" id="schacSn
<Attribute name="schacSn2" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" id="schacSn
<Attribute name="irisMailMainAddress" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
<Attribute name="schacUserStatus" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" id="
Cuando lo tengamos todo listo habra que iniciar el demonio de shibboleth y aadirlo para que se inicie en el arranque.
service shibd start
chkconfig shibd on
Aadimos la siguiente entrada en el apache:

<Location /Shibboleth.sso>
SetHandler shib
</Location>

Reiniciamos el server:
service httpd start
Si accedemos a https://shib.cursosaml.org/Shibboleth.sso/Status y vemos un xml que describe el estado de nuestro

servicio shibboleth es que todo ha ido bien
Si no vemos lo que esperabamos, podemos analizar las salidas de los logs de shibboleth que se encuentran en
/var/log/shibboleth/
Lo siguiente que hay que hacer es obtener los metadatos del SP que estn en
https://shib.cursosaml.org/Shibboleth.sso/Metadata , convertirlos e introducirlos en el
/var/www/idp/simplesamlphp/metadata/saml20-sp-remote.php
7.2.1 Ejemplo de como federar una aplicacin PHP con esta tcnica
Creamos un directorio contenedor que albergar el ejemplo de la aplicacin de php example_php:

mkdir /var/www/apps/shibboleth/example_php
Y dentro colocamos 2 archivos:

index.php Haciendo uso de la libreria lib.php obtiene los datos del usuario y se los muestra, y da opcin a cerrar
sesin.
lib.php Librera auxiliar que lee los datos de la variable server y los devuelve con la misma estructura a como
sueles devolverlos simpleSAMLphp
[index.php]
<html>
<head>
<title>Aplicacin PHP de ejemplo federada usando Shibboleth</title>
<link href="//sp.cursosaml.org/example-php/resources/css/bootstrap.min.css" rel="stylesheet" media="s
</head>
<body>
<h3>Aplicacin PHP de ejemplo federada usando Shibboleth</h3>

<?php
include_once("lib.php");
$attributes = get_attributes_from_remote_user();
}
else {

echo </td></tr>;
}
echo </table>;

?>
</table>
<p><a class="btn" href="https://shib.cursosaml.org/Shibboleth.sso/Logout">Cerrar sesin</a></p>
</body></html>
[lib.php]
<?php
function get_attributes_from_remote_user() {
if(isset($_SERVER[uid])) {
$attributes[uid] = $_SERVER[uid];
}
if(isset($_SERVER[eduPersonPrincipalName])) {
$attributes[eduPersonPrincipalName] = $_SERVER[eduPersonPrincipalName];
}
if(isset($_SERVER[eduPersonAffiliation])) {
$attributes[eduPersonAffiliation] = $_SERVER[eduPersonAffiliation];
}
if(isset($_SERVER[mail])) {
$attributes[mail] = $_SERVER[mail];
}
if(isset($_SERVER[sn])) {
$attributes[sn] = $_SERVER[sn];
}
if(isset($_SERVER[cn])) {
$attributes[cn] = $_SERVER[cn];
}
if(isset($_SERVER[preferredLanguage])) {
$attributes[preferredLanguage] = $_SERVER[preferredLanguage];
}
if(isset($_SERVER[objectClass])) {
$attributes[objectClass] = $_SERVER[objectClass];
}
if(isset($_SERVER[groups])) {
$attributes[groups] = $_SERVER[groups];
}
foreach($attributes as $key => $value) {

$attributes[$key] = explode(;, $value);
}
return $attributes;
}

Por ltimo configuramos el apache para que proteja dicha aplicacin y enve los datos del usuario en la cabecera:
Alias /php /var/www/apps/shibboleth/example_php
<Location /php>
AuthType shibboleth
ShibRequestSetting applicationId default
ShibRequestSetting requireSession 1
require valid-user
</Location>
Y lo reiniciamos:
7.2.2 Ejemplo de como federar una aplicacin Python/Django con esta tcnica
Lo primero es crear el proyecto django que llamaremos example_django_shib y que incluiremos dentro de
/var/www/apps/shibboleth:
django-admin.py startproject example_django_shib
Nota: Si an no disponemos del entorno para trabajar con python/django ver como desplegar el entorno
Configuramos el proyecto demo en /var/www/apps/authmemcookie/example_django/example_django_shib/setti
DATABASES = {
default: {
NAME: /var/www/apps/shibboleth/example_django/example_django_shib/example_django_shib.sql3
}
}
from os import path

TEMPLATE_DIRS = (
)
Creamos el fichero que contendr la vista en la que mostremos los atributos que hemos obtenido del servidor Apache
www/apps/shibboleth/example_django_shib/example_django_shib/views.py:
import string
from django.shortcuts import render_to_response

from django.template import RequestContext

def echo_attributes(request,
template=echo_attributes.html):
"""Example view that echo the attributes of an user server
by Apache (Shibboleth)"""
return render_to_response(template, {attributes: parse_attributes(request)},

context_instance=RequestContext(request))
def parse_attributes(request):
attributes = {}
attributes[uid] = request.META.get(uid, )
attributes[eduPersonPrincipalName] = request.META.get(eduPersonPrincipalName, )
attributes[eduPersonAffiliation] = request.META.get(eduPersonAffiliation, )
attributes[mail] = request.META.get(mail, )
attributes[sn] = request.META.get(sn, )
attributes[cn] = request.META.get(cn, )
attributes[preferredLanguage] = request.META.get(preferredLanguage, )
attributes[objectClass] = request.META.get(objectClass, )
attributes[groups] = request.META.get(groups, )
for field in attributes:

attributes[field] = string.split(str(attributes[field]), ;)
return attributes
Y la plantilla para lo cual creamos el directorio templates y creamos el fichero

/var/www/apps/shibboleth/example_django_shib/example_django_shib/templates/echo_attributes.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Aplicacin Python/Django de ejemplo federada usando Shibboleth</title>
<link href="https://sp.cursosaml.org/example-php/resources/css/bootstrap.min.css" rel="stylesheet
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
</head>
<body>
<h3>Aplicacin Python/Django de ejemplo federada usando Shibboleth</h3>

{% for attribute, value in attributes.items %}
<tr><td>{{ attribute }}:</td>
<td>{{ value|join:"<br> " }}</td></tr>
{% endfor %}
</table>
<p><a class="btn" href="https://shib.cursosaml.org/Shibboleth.sso/Logout">Cerrar sesin</a></p>

</body>
</html>
Configuramos las urls de la demo en /var/www/apps/shibboleth/example_django_shib/example_django_shib/ur

incluyendole la url de la vista que habiamos creado

(r^$, example_django_shib.views.echo_attributes), # Vista basica de prueba.
)


chown -R apache:apache /var/www/apps/shibboleth/example_django_shib
WSGIScriptAlias /django /var/www/apps/shibboleth/example_django_shib/example_django_shib/wsgi.py
WSGIPythonPath /var/www/apps/shibboleth/example_django_shib
(Si ya tenemos otro habra que poner> WSGIPythonPath <path_1>:<path_2>

Y protegemos la vista:
<Location /django>
AuthType shibboleth
ShibRequestSetting applicationId default
ShibRequestSetting requireSession 1
require valid-user
</Location>
7.3 Aplicaciones Python/Django (PySAML2/djangosaml2)
7.3.1 El entorno
Imaginemos que queremos desplegar una aplicacin django en el sistema a la que queremos aadir soporte SAML.
Lo primero que haremos ser comprobar que disponemos en el sistema de python. Posteriormente instalamos una
utilidad que facilita la instalacin de paquetes de python
yum install python-setuptools
A continuacin instalamos el framework django si no lo estuviera.

easy_install django
Instalamos el modulo mod_wsgi para desplegar la aplicacin django con el servidor apache
yum install mod_wsgi
7.3.2 Instalar librerias SAML para python
Instalamos 2 dependencias: xmlsec y xmlsec1-openssl. Dichos paquetes se encuentran disponibles en el repositorio

epel
7.3. Aplicaciones Python/Django (PySAML2/djangosaml2) 63

yum install http://dl.fedoraproject.org/pub/epel/6/x86_64/xmlsec1-1.2.16-2.el6.x86_64.rpm

yum install http://dl.fedoraproject.org/pub/epel/6/x86_64/xmlsec1-openssl-1.2.16-2.el6.x86_64.rpm
Tras instalar xmlsec1 del repo EPEL es necesario:

ln -s /usr/lib64/libxmlsec1-openssl.so.1 /usr/lib64/libxmlsec1-openssl.so
Una vez instaladas las dependencias instalamos la libreria pysaml2

easy_install pysaml2
Y la libreria djangosaml2
easy_install djangosaml2
7.3.3 Despliegue y configuracin de una aplicacin de ejemplo
Creamos el proyecto demo de django en /var/www/apps ejecutando:

django-admin.py startproject django_saml2_demo
Configuramos el proyecto demo en /var/www/apps/django_saml2_demo/django_saml2_demo/settings.py:

DATABASES = {
default: {
NAME: /var/www/apps/django_saml2_demo/django_saml2_demo/djangosaml2demo.sql3, # Or path
}
}
TEMPLATE_LOADERS = (
django.template.loaders.filesystem.Loader,
django.template.loaders.app_directories.Loader,
django.template.loaders.eggs.Loader, # Debe de estar descomentado!
)
from os import path

TEMPLATE_DIRS = (
)
AUTHENTICATION_BACKENDS = (
django.contrib.auth.backends.ModelBackend,
djangosaml2.backends.Saml2Backend,
)
LOGIN_URL = /example-django/saml2/login/ # url en donde se realizara el login

LOGOUT_URL = /example-django/saml2/logout/ # url en donde se realizara el logout

SESSION_EXPIRE_AT_BROWSER_CLOSE = True # parametro para definir si queremos que la sesion expire a
INSTALLED_APPS = (
django.contrib.auth,
django.contrib.contenttypes,
django.contrib.sessions,
django.contrib.sites,
django.contrib.messages,
django.contrib.staticfiles,
djangosaml2, # Insertamos esta aplicacion
)
from django_saml2_demo.pysaml2_setting * # importaremos nuevas configuraciones de pysaml2
Configuramos las urls de la demo en /var/www/apps/django_saml2_demo/django_saml2_demo/urls.py

incluyendole las urls de la librera djangosaml2
# ...
(r^$, djangosaml2.views.echo_attributes), # Vista basica de prueba.
(r^saml2/, include(djangosaml2.urls)),
# ...
)
Creamos el fichero pysaml2_settings.py con la configuracin:

from os import path
import saml2
SAML_DJANGO_USER_MAIN_ATTRIBUTE = username
SAML_CREATE_UNKNOWN_USER = True
SAML_ATTRIBUTE_MAPPING = {
uid: (username, ),
mail: (email, ),
cn: (first_name, ),
sn: (last_name, ),
}
SAML_CONFIG = {
# full path to the xmlsec1 binary programm
xmlsec_binary: /usr/bin/xmlsec1,
# your entity id, usually your subdomain plus the url to the metadata view
entityid: https://sp.cursosaml.org/example-django/saml2/metadata/,
# directory with attribute mapping
attribute_map_dir: path.join(BASEDIR, saml2/attributemaps),
# this block states what services we provide

# this block states what services we provide
service: {

# we are just a lonely SP

sp : {
name: Federated Django sample SP,
endpoints: {
# url and binding to the assetion consumer service view
# do not change the binding or service name
assertion_consumer_service: [
(https://sp.cursosaml.org/example-django/saml2/acs/,
saml2.BINDING_HTTP_POST),
],
# url and binding to the single logout service view
# do not change the binding or service name
single_logout_service: [
(https://sp.cursosaml.org/example-django/saml2/ls/,
saml2.BINDING_HTTP_REDIRECT),
],
},
# attributes that this project need to identify a user

required_attributes: [uid],
# attributes that may be useful to have but not required

optional_attributes: [eduPersonAffiliation],
},
# in this section the list of IdPs we talk to are defined

idp: {
# we do not need a WAYF service since there is
# only an IdP defined here. This IdP should be
# present in our metadata
# the keys of this dictionary are entity ids

https://idp.cursosaml.org/simplesaml/saml2/idp/metadata.php: {
single_sign_on_service: {
saml2.BINDING_HTTP_REDIRECT: https://idp.cursosaml.org/simplesaml/saml2/idp/SSOS
},
single_logout_service: {
saml2.BINDING_HTTP_REDIRECT: https:/idp.cursosaml.org/simplesaml/saml2/idp/Singl
},
},
},
},
# where the remote metadata is stored
metadata: {
local: [path.join(BASEDIR, saml2/remote_metadata.xml)],
},
# set to 1 to output debugging information

debug: 1,
# certificate
key_file: path.join(BASEDIR, saml2/djangosaml2demo.pem), # private part
cert_file: path.join(BASEDIR, saml2/djangosaml2demo.crt), # public part
# own metadata settings

contact_person: [
{given_name: Admin,
sur_name: Prueba,
company: CONFIA,

email_address: admin@confia.es,
contact_type: technical},
],
# you can set multilanguage information here
organization: {
name: [(CONFIA, es)],
display_name: [(CONFIA, es)],
url: [(http://www.confia.aupa.info, es)],
},
valid_for: 24, # how long is our metadata valid
}
Creamos los certificados y los ponemos en /var/www/apps/django_saml2_demo/django_saml2_demo/saml2/:

cd /var/www/apps/django_saml2_demo/django_saml2_demo
mkdir saml2
cd saml2
openssl genrsa -out djangosaml2demo.pem 1024
openssl req -new -key djangosaml2demo.pem -out djangosaml2demo.csr
openssl x509 -req -days 1825 -in djangosaml2.csr -signkey djangosaml2demo.pem -out djangosaml2demo.cr
Y copiamos los metadatos del idp accesibles en https://idp.cursosaml.org/simplesaml/saml2/idp/metadata.php?

dentro de un fichero remote_metadata.xml
Creamos el directorio attributemaps
Y descagamos en el los ficheros que podemos encontrarnos en el huevo de pysaml (ruta parecida a
/usr/lib/python2.6/site-packages/pysaml2-0.4.2-py2.6.egg/saml2/attributemaps/ o
en el repositorio

chown -R apache:apache /var/www/apps/django_saml2_demo
WSGIScriptAlias /django-example /var/www/apps/django_saml2_demo/django_saml2_demo/wsgi.py
WSGIPythonPath /var/www/apps/django_saml2_demo/
7.4 Aplicaciones Java (SpringSecurity OIOSAML)
7.4.1 Instalacin de Java, Tomcat y Maven
Lo primero que haremos es configurar el entorno Java.

1. Instalamos la maquina virtual de java y el tomcat
7.4. Aplicaciones Java (SpringSecurity OIOSAML) 67

yum install java-1.7.0-openjdk java-1.7.0-openjdk-devel tomcat6 tomcat6-admin-webapps tomcat6-webapps
2. Configuramos el tomcat en /etc/tomcat6/tomcat6.conf:

JAVA_OPTS="-Xmx768m -XX:PermSize=256m -XX:MaxPermSize=512m"
3. Configuramos la ruta del java

export JAVA_HOME=/usr/lib/jvm/java/bi
4. Y aadimos a la variable PATH la ruta donde se encuentre el bin de java, por ejemplo: /usr/lib/jvm/java/bin
export PATH=$PATH:/usr/lib/jvm/java/bin
5. Editamos /etc/tomcat6/tomcat-users.xml aadiendole la entrada:

<user username="admin" password="" roles="admin,manager"/>
6. Obtenemos e instalamos el maven:

wget http://archive.apache.org/dist/maven/binaries/apache-maven-3.0.4-bin.zip
unzip apache-maven-3.0.4-bin.zip
mv apache-maven-3.0.4 /usr/local/apache-maven
export M2_HOME=/usr/local/apache-maven
export M2=/usr/local/apache-maven/bin
export MAVEN_OPTS="-Xms256m -Xmx512m"
export PATH=$PATH:/usr/local/apache-maven/bin
Nota: Estas variables conviene definirlas para que se carguen siempre al arrancar la maquina (pueden definirse en el
/etc/enviroment)
JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre
JAVA_OPTS="-Xmx768m -XX:PermSize=256m -XX:MaxPermSize=512m"
M2_HOME=/usr/local/apache-maven
M2=/usr/local/apache-maven/bin
MAVEN_OPTS="-Xms256m -Xmx512m"
PATH=/usr/local/bin:/bin:/root/bin:/usr/bin:/usr/local/apache-maven/bin:/usr/lib/jvm/java-1.7.0-openj
7.4.2 Instalacin y configuracin de la aplicacin de ejemplo SpringSecurity
Vamos a analizar el ejemplo de federacin usando SpringSecutiry. Para ello descargamos el repositorio git la extensin
SAML de Spring Security
yum install git
cd /var/www/apps/
git clone https://github.com/SpringSource/spring-security-saml.git
Lo primero que hacemos es situarnos en la carpeta e instalar librerias usando maven:

cd /var/www/apps/spring-security-saml/
mvn clean install -Dmaven.test.skip=true
Ahora desplegamos la aplicacin de ejemplo ejecutando en el directorio saml2-sample

cd /var/www/apps/sprin-security-saml/saml2-sample
mvn clean tomcat:deploy

La aplicacin estar accesible en http://sp.cursosaml.org:8080/spring-security-saml2-sample

pero an no funcionar pues no la tenemos configurada. Accedemos por navegador y pasamos a configurar el SP acce-
diendo a la vista http://sp.cursosaml.org:8080/spring-security-saml2-sample/saml/web/metadata/gene
Store for the current session: No
Entity ID: http://sp.cursosaml.org:8080/spring-security-saml2-sample/saml/metadata/alias/springsecurity
Entity base URL: http://sp.cursosaml.org:8080/spring-security-saml2-sample
Entity alias: springsecurity
SSL/TLS Security profile: METAIOP
SSL/TLS Client authentication: None
Security profile: MetaIOP
Sign metadata: Yes
Sign sent AuthNRequests: Yes
Require signed authentication Assertion: Yes
Require signed LogoutRequest: No
Require signed LogoutResponse: No
Require signed ArtifactResolve: No
Single sign-on bindings: default and mark only SSO HTTP-POST
Supported NameID: Marcamos persistent
Include IDP Discovery profile: No
Generamos el metadato. Abrimos una nueva pestaa del navegador y convertimos el contenido del campo
metadata en el conversor de metadatos de simpleSAMLphp <https://sp.cursosaml.org/simplesaml/admin/metadata-
converter.php>.
Los metadatos convertidos los guardamos en /var/www/idp/simplesamlphp/metadata/saml20-sp-remote.php.
Hay tambin que actualizar el fichero de configuracin de la aplicacin spring con la config-
uracin generada por el asistente. Editamos el fichero /var/www/apps/spring-security-saml/saml2-
sample/src/main/resources/security/securityContext.xml:
<bean class="org.springframework.security.saml.metadata.ExtendedMetadataDelegate">
<constructor-arg>
<bean class="org.opensaml.saml2.metadata.provider.FilesystemMetadataProvider">
<constructor-arg>
<value type="java.io.File">classpath:security/sp.xml</value>
</constructor-arg>
<property name="parserPool" ref="parserPool"/>
</bean>
</constructor-arg>
<constructor-arg>
<bean class="org.springframework.security.saml.metadata.ExtendedMetadata">
<property name="local" value="true"/>
<property name="alias" value="springsecurity"/>
<property name="securityProfile" value="metaiop"/>
<property name="sslSecurityProfile" value="metaiop"/>
<property name="signingKey" value="apollo"/>
<property name="encryptionKey" value="apollo"/>
<property name="requireArtifactResolveSigned" value="false"/>
<property name="requireLogoutRequestSigned" value="false"/>

<property name="requireLogoutResponseSigned" value="false"/>

</bean>
</constructor-arg>
</bean>
Pero cambiamos el valor del java.io.File del SP por sp.xml y guardamos el xml con los metadatos en
/var/www/apps/spring-security-saml/saml2-sample/src/main/resources/security/sp.xml
Y configurar el bean del IdP:
<bean class="org.springframework.security.saml.metadata.ExtendedMetadataDelegate">
<constructor-arg>
<bean class="org.opensaml.saml2.metadata.provider.FilesystemMetadataProvider">
<constructor-arg>
<value type="java.io.File">classpath:security/idp.xml</value>
</constructor-arg>
<property name="parserPool" ref="parserPool"/>
</bean>
</constructor-arg>
<constructor-arg>
<bean class="org.springframework.security.saml.metadata.ExtendedMetadata">
</bean>
</constructor-arg>
</bean>
<!-- OPTIONAL used when one of the metadata files contains information about this service provider --
<property name="hostedSPName" value="springsecurity"/>
<!-- OPTIONAL property: can tell the system which IDP should be used for authenticating user by defau
<property name="defaultIDP" value="https://idp.cursosaml.org/simplesaml/saml2/idp/metadata.php"/>
Ahora guardamos los metadatos del IdP en el SP de spring-security:

wget --no-check-certificate https://idp.cursosaml.org/simplesaml/saml2/idp/metadata.php -O /var/www/a
Redespliegue la aplicacin para que los cambios tengan efecto ejecutando en /opt/federation-demo/aplications/spring-
security-saml/saml2-sample:
cd /var/www/apps/spring-security-saml/saml2-sample
mvn tomcat:redeploy
Y ya podr probar el login contra el IdP elegido accediendo a http://sp.cursosaml.org:8080/spring-security-saml2-
7.4.3 OIOSAML.JAVA
OIOSAML.JAVA es otra libreria que podemos utilizar para aadir soporte SAML a nuestras aplicaciones Java.
Podemos descargarnos la ultima versin en este enlace http://digitaliser.dk/resource/2298008/artefact/oiosaml.java-
9918.zip
Est basada en OpenSAML2.0. En el siguiente enlace encontrareis toda la informacin de como instalarlo y
configurarlo
7.4.4 Otras librerias JAVA
LASSO Java SP

7.5 Librerias para otros lenguajes
7.5.1 Librerias para aplicaciones .NET
OIOSAML.NET
ComponentSpace SAML (Comercial)
ASP.NET SAML COmponent (Comercial)
En Nordunet
7.5.2 Librerias para aplicaciones ruby & ruby on rails
saml2ruby
saml-sp
OmniAuth SAML
Onelogin ruby-saml (Comercial)
7.5.3 Librerias para aplicaciones Perl
Net::SAML - ZXID Perl

NET-SAML CPAN module
7.5.4 Librerias para aplicaciones C
Lasso C SP
OpenSAML
7.5. Librerias para otros lenguajes 71

CAPTULO
EIGHT
REFERENCIAS
8.1 Especificacin SAML
Security Assertion Markup Language

SAML Profiles
SAML Bindings
SAML Metadata
SAML Conformance
SAML Security and Privacity
8.2 Implementaciones de SAML SP
simpleSAMLphp (doc_ssp) (cdigo_ssp)

Shibboleth (doc_shib) (cdigo_shib)
pySAML2) (doc_pysaml2)
djangosaml2
Lasso
OpenSAML
OIOSAML .NET .JAVA
ESOE
ZXID
8.3 Documentacin de inters sobre domesticaciones de aplica-

ciones
SimpleSAMLphp SP API
Authmemcookie + simpleSAMLphp
mod_perl + simpleSAMLphp
72
Installation and Operation of the Shibboleth Service Provider

My First SP - Shibboleth https://wiki.surfnetlabs.nl/display/surfconextdev/My+First+SP+-+Shibboleth
My First SP - .NET
8.4 Gestin centralizada de metadatos
Metadata administraition as selfservice

Documentacin de Janus
SAML Metadata Management for eduID.cz
Proyecto PEER
Basic Metadata Aggregation Profile
Otras referencias
Gestin de metadatos en SimpleSAMLphp
8.5 Otros conceptos avanzados
Filtros en simpleSAMLphp
8.4. Gestin centralizada de metadatos 73

CAPTULO
NINE
ANEXO A. CONCEPTOS SOBRE

FEDERACIN DE IDENTIDADES
9.1 Qu es una federacin de identidades
Una federacin de identidades es un grupo o conjunto de entidades que comparten la tcnologa, estandares y casos
de uso que permiten transmitir informacin de identidad de un usuario de manera segura facilitando la autenticacin y
autorizacin entre diferentes dominios.
En una federacin de identidades se establece un crculo de confianza que permite que un usuario autenticado en un
organismo de la federacin acceda a recursos de otro organismo de la misma federacin. La idetificacin se realiza en
los Proveedores de Identidad (abrev. ingl. IdP). El Proveedor de Servicio (abrev. ingl. SP) al que accede el usuario
confa en los datos del usuario que le son suministrados por el IdP y en funcin de los mismos autoriza al usuario a
hacer uso de los recursos.
En una federacin de identidades los servicios perciben al usuario como una entidad homogenea y no como un conjunto
de porciones de informacin sin relacin entre ellas. Se denomina identificador opaco al identificador nico que
mantiene la privacidad del usuario y que representa la asociacin entre la cuenta del usuario en un Proveedor de
Servicio y la que posee en el Proveedor de Identidad.
Figura 9.1: Esquema federacin
Es tarea del operador de la federacin de identidades:
74
Decidir y gestionar la integracin de los miembros (tanto proveedores de identidad como de servicio) a la
federacin.
Gestionar las polticas de liberacin de atributos (ARPs) y velar porque ests 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 cesin de datos para servicio que
accede el usuario.
Velar por el correcto funcionamiento de la federacin.
Gestionar la interoperabilidad con otras federaciones formando confederaciones de identidades.
9.2 Ventajas de la federacin 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 sesin (log out) sin tener que volver a introducir sus credenciales de acceso.
Single Log Out (SLO). Al cerrar sesin de una aplicacin se cerrar la sesin de todas las aplicaciones
federadas, mejorando as la seguridad del sistema.
Fiable, fcil y rpido. Al usuario se le present un nico sistema de autenticacin que conoce.
Ventajas para administradores de sistemas:
Facilita los procedimientos. Se despliega un escenario controlado en el que los accesos estn
monitorizados y todos el procesos controlados.
Menor nmero de incidencias:
Al existir una clave nica los administradores dejan de atender a incidencias relacionadas con
prdidas y reseteos de claves.
Los datos de los usuarios pasan a estar en un punto comn verificados y actualizados por lo que se
reducen las duplicidades de cuentas y los conflictos.
Mayor control de los datos del usuario. Mediante la definicin de ARPs (Attribute Release
Policies) adecuadas el administrador puede decidir, dentro del conjunto de datos que posee de cada
usuario, cules 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. Fcil integracin con multitud de sistemas heterogneos. la
tecnologa SAML2 se erige como el futuro de los sistemas de federacin 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.
Reduccin de riesgos de seguridad. Las comunicaciones que envan informacin del usuario siempre van
cifradas incluso cuando se accede por protocolos no seguros como HTTP. La contrasea del usuario nunca
viaja entre los distintos nodos de la federacin. Se utiliza tecnologa PKI para todo este proceso de cifrado de
comunicaciones.
9.2. Ventajas de la federacin de identidades 75

9.3 Ejemplos de federaciones
En la actualidad podemos identificar muchas federaciones de identidad basadas en la tecnologa SAML:

Europeas:
Espaolas:
En Andaluca existe Confa que es una federacin de identidades de las universidades andaluzas.
En Espaa tenemos el Servicio de dentidad de SIR operado por REDIRIS
En Dinamarca tienen la federacin 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 Repblica Checa tienen SWITCHaai operada por SWITCH
Existe una confederacin de los paises nrdicos denominada Kalmar Union
Existe una federacin para la educacin superior y la investigacin europea llamada Edugate
Tambin a nivel europeo destacamos el proyecto STORK que trata de proveer una plataforma de interoperabili-
dad de identidades.
9.3. Ejemplos de federaciones 76

No europeas:
En Australia tienen la AFF
En USA tienen la InCommon Federation
En Brasil tienen la federacin CAFe
En Canada tienen la federacin CAF-CANARIE
En China tienen federacin CARSI
En Japn tienen la federacin GakuNin
Se puede consultar ms informacin sobre federaciones en una wiki de Terena.
9.4 Conceptos (IdP, SP, AA, WAYF, atributos, bindings)
IdP Proveedor de Identidad. Organizacin que provee la autenticacin 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 institucin registrado en la federacin que provee acceso al usuario
final a algn servicio y recurso basandose en una serie de atributos que satisfacen sus requerimientos de autorizacin.
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.
9.4. Conceptos (IdP, SP, AA, WAYF, atributos, bindings) 77

AA Autoridad de atributos. Sistema que responde consultas sobre atributos.

Gestor de metadatos Elemento encargado de gestionar los diferentes metadatos de las entidades que componen la
federacin (IdPs y SPs). Dichos metadatos debern de estar actualizados peridicamente. Adems opcionalmente
puede validar los metadatos, clasificarlos, validar los certificados de los metadatos o gestionar las ARPs.
Scoping Indica al IdP el ambito de la peticin. De que SP surgi y con que contexto.
Binding Mapeo de una peticin SAML o de una asercin de respuesta con un protocolo especfico de transporte.
(HTTP-Redirect, HTTP-POST, Artifact o SOAP)
Descubrimiento En terminos de federacin se hace referencia al descubrimiento como la accin de obtener la lista de
proveedores de identidad.
Metadatos Conjunto de datos que conforman la informacin necesaria para que una entidad se comunique con otra
entidad de la federacin. 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 unvocamente 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 Poltica de liberacin de atributos. Poltica que rige la distribucin 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 agrupacin de varios atributos identifican univocamente al usuario.
Esquema de atributos Compendio de nombres de atributos estandarizado. Surge de la necesidad de definir un vocablo
comn que defina un nombre para los diferentes atributos que forman parte de la informacin del usuario que van a
transferirse entre los elementos de la federacin de identidades.
Identificador opaco Identificador persistente que puede ser usado para conectar cuentas de usuario conservando la
privacidad.
Consentimiento En trminos de federacin se hace referencia al consentimiento como a la accin 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 diseado para el intercambio de informacin sensible de forma segura.
XML Encryption Un estandar W3C para cifrar un documento XML. Es usado en SAML para cifrar la Asercin
SAML con el fin de dificultar que una entidad o individuo que no pertenezca a la federacin 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 relacin 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 tambin el flujo de peticiones y respuestas SAML que se efectuan en un determinado
caso de uso.
SSO Single Sign On. Procedimiento de autenticacin que habilita al usuario para acceder a varios sistemas con una
sola instancia de identificacin. En una federacin de identidades el SSO habilita al usuario a acceder a cada uno de
los SP (previa autorizacin 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.
9.4. Conceptos (IdP, SP, AA, WAYF, atributos, bindings) 78

9.5 Protocolos (SAML PAPI, OpenId)
9.5.1 SAML
Security Assertion Markup Language. Est basado en XML y es un estandar abierto para el intercambio de informacin
de autorizacin y autenticacin entre dominios de forma segura. Fue creado por la empresa OASIS
Bsicamente define como debe de hacerse de forma segura la trnsmisin 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
9.5.2 PAPI
PAPI es un sistema de SSO desarrollado por RedIRIS desde el ao 2001. Permite desplegar una infraestructura de
autenticacin y autorizacin y un sistema de Single Sign-On fcilmente.
Los componentes principales del sistema son: El servidor de autenticacin (AS) y los puntos de acceso (PoA).
Un PoA se encarga de interceptar los accesos a recursos o servicios forzando la auntenticacin del usuario en un
AS (cada PoA puede estar conectado a uno o varios AS),La autenticacin se produce contra alguno de los backends
configurados en el AS (Ldap, BD, etc) y tras producirse se genera una asercin 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 relacin de confianza con ellos y suya a su vez con el AS.
9.5. Protocolos (SAML PAPI, OpenId) 79

Si el PoA no puede integrarse con la aplicacin 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 asercin es transmitida
mediante el mtodo POST de HTTP desde un proveedor de autenticacin hasta los proveedores de servicio, solo que
dicha asercin no es SAML (ni siquiera XML).
Puede obtener ms informacin sobre el protocolo en la wiki del proyecto PAPI
9.5.3 OpenID
OpenID es un sistema de identificacin digital descentralizado, con el que un usuario puede identificarse en una
aplicacin web a travs de una URL (o un XRI en la versin 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.


CAPTULO
TEN
ANEXO B. SOFTWARE EXISTENTE

PARA IMPLEMENTAR FEDERACIONES
DE IDENTIDADES
Dentro del abanico de software que implemetan federaciones de identidades nos centraremos en aquellas que
implementan el estandar SAML2 y son software libre.
10.1 Shibboleth
El software Shibboleth es un proyecto de la asociacin internet2 basado en estandares y software libre.

Shibboleth es un producto final que mantiene la compatibilidad hacia atrs. Dispone de IdP, de SP y de DS (servicio
de descubrimiento)
Soporta el perfil SAML 2.0 Web Browser SSO, Cardspace, perfil Shibboleth, ADFS y SAML 1.1
10.1.1 IdP
Est escrito en Java y funciona en cualquier contenedor servlet estandar.

Permite multiples fuentes de autenticacin: Ldap, SQL, Kerberos.
Los atributos pueden ser recogidos de la fuente o ser generados manualmente. Permitiendo posteriormente
realizar la transformacin con reglas previamente prefijadas o programadas.
10.1.2 SP
Funciona en Apache, IIS y NSAPI. Entornos que pueden ser utilizados detras de un proxy en Java y otros
servidores web.
Puede funcionar automticamente o bajo demanda.
Permite proteger el mismo los recursos o delegar en las aplicaciones para que manejen la autorizacin.
(Clusterizable)
82
10.1.3 Ventajas
Est bien documentado.

Numerosas aplicaciones tienen en la actualidad soporte de shibboleth. Ver lista
10.1.4 Desventajas
Sus archivos de configuracin son de gran tamao y a veces es fcil perderse en ellos.
La implementacin del SLO global no est soportada de forma oficial.
10.2 simpleSAMLphp
El software simpleSAMLphp es de la empresa UNINETT basado en estandares y software libre.

Dispone de una nica aplicacin que dependiendo de como sea configurada acta como IdP, SP o WAYF.
Soporta el perfil SAML 2.0 Web Browser SSO, est desarrollando el perfil Artifact y planea dar soporte a SOAP.
10.2.1 Ventajas
Est bien documentado.

Numerosas aplicaciones tienen en la actualidad soporte de simpleSAMLphp. Lista
Muy flexible. Posee un sistema de modulos y de filtros que permite fcilmente aadir funcionalidad extra.
Permite mediante cambios en la configuracin que el producto functione como un WAYF.
Posee un gestor de metadatos y de ARPs (aadiendole el mdulo Janus)
Soporta gran cantidad de backends de autenticacin: radius, ldap, mysql, postgres, facebook, gmail, openid,
oatuh, saml (la fuente de un IdP puede ser otro IdP), etc
Alta escalabilidad.
10.2.2 Desventajas
Es fcil perderse configurando entornos complejos.

No es totalmente un producto final, le faltan cosas. Por ejemplo el sistema de deteccin de errores y
autodiagnostico est an verde.
10.3 PySAML2
pySAML2 es una librera desarrollada en python que implementa IdPs y SPs basados en protocolo SAML2.
Existe una librera llamada djangosaml2 que hace uso de la librera pySAML2 y sirve para federar fcilmente
aplicaciones desarrolladas con el framework django.
10.2. simpleSAMLphp 83
10.3.1 Ventajas
Permite federar de forma nativa aplicaciones desarrolladas en python.
10.3.2 Desventajas
Es una librera joven:

Escasa comunidad
An le queda bastante desarrollo, falta mucho por implementar del estandar.
10.4 OpenSSO / OpenAM
OpenSSO es un producto Java de federacin de identidad que desde el 2010 se conoce con el nombre de OpenAM y
est soportado por la empresa ForgeRock.
10.5 Lasso
Lasso es una librera C que implementa los estandars de la Liberty Alliance. Utiliza SWIG para que se pueda usar la
libreria desde python, perl, java y .net en multiples plataformas. Soporta tanto funcionalidad de SP como de IdP.
10.6 Solucin recomendada
No existe una solucin ideal genrica. Dependiendo del tipo de integracin que se haya elegido utilizaremos un
software u otro.
Lo que si recomendamos es que en la medida de lo posible el software elegido para los diferentes componentes que
formen la federacin de sistemas sea lo ms homogeneo posible para facilitar el mantenimiento. Hay que evaluar
siempre que se vaya a integrar una aplicacin en la federacin de sistemas si el ahorro de esfuerzo de federar una
aplicacin con un determinado software diferente al utilizado en la federacin luego no va a conllevar un coste elevado
de mantenimiento.
Por lo general nosotros recomendamos que la infraestructura de la federacin se realice basandose en el software
simpleSAMLphp debido a que es muy flexible, dispone de todos los componentes que podremos necesitar, tiene una
gran comunidad detrs que lo soporta y est escrito en php por lo que podremos realizar una integracin de lenguaje
nativo para la gran variedad de aplicaciones escritas en php. Y utilizar authmemcookie para domesticar aplicaciones
desarrolladas en otros lenguajes.
10.4. OpenSSO / OpenAM 84

CAPTULO
ELEVEN
ANEXO C. MQUINA VIRTUAL CON

LAS APLICACIONES DE EJEMPLO
FEDERADAS
Junto con la documentacin se va a facilitar una mquina virtual con las aplicaciones de ejemplo federadas que se han
ido explicando durante el curso.
11.1 Descarga
Las mquinas virtuales estarn disponibles en http://files.confia.aupa.info en varios formatos:

.vdmk Formato para VMWare.
.vdi Formato para Virtualbox.
11.2 Configuracin previa
11.2.1 NAT y Anfitrin
Hace falta configurar 2 adaptadores de red:

Adaptador anfitrion vboxnet1
NAT con la direccin MAC 52:54:00:88:83:ba
11.2.2 HOSTS
Hace falta aadir las siguientes entradas en el hosts del anfitrion:

#curso saml
192.168.122.108 docs.cursosaml.org
192.168.122.109 idp.cursosaml.org
192.168.122.110 sp.cursosaml.org
192.168.122.111 shib.cursosaml.org
85
11.2.3 CREDENCIALES
Se ha utilizado la misma contrasera para acceder a la mquina como root y en general para cada uno de los
componentes: cursosaml
Para acceder al phpldapadmin hay que usar el usuario: cn=admin,dc=ldap,dc=cursosaml,dc=org
Recordar que para crear usuarios en el IdP podemos hacerlo desde la interfaz del phpldapadmin o desde el modulo
gestor de cuentas del IdP
11.3 CONTENIDO DE LA MQUINA VIRTUAL
Documentacion: /var/www/docs
Configuracin servidor Apache: /etc/httpd/conf.d/cursosaml.conf
Proveedor de identidad: /var/www/idp/simpleSAMLphp
PHPldapadmin: /etc/phpldapadmin/
Openldap: /etc/openldap
Proveedor de servicio:
SimpleSAMLphp /var/www/sp/simplesamlphp
Shibboleth /etc/shibboleth
Aplicaciones de ejemplo:
Nativas:
php: /var/www/apps/example_php
python/django: /var/www/apps/django_saml2_demo
java: /var/www/apps/spring-security-saml
Authmemcookie: /var/www/apps/authmemcookie
Shibboleth: /var/www/apps/shibboleth
11.4 URLS
11.4.1 Documentacin
http://docs.cursosaml.org
11.4.2 Proveedor de Identidad
SimpleSAMLphp: https://idp.cursosaml.org/simplesaml
phpLdapAdmin: https://idp.cursosaml.org/phpldapadmin/
Mdulo gestor de cuentas: https://idp.cursosaml.org/simplesaml/module.php/userregistration/index.php
11.3. CONTENIDO DE LA MQUINA VIRTUAL 86

11.4.3 Proveedor de Servicio
SimpleSAMLphp: https://sp.cursosaml.org/simplesaml
Shibboleth: https://shib.cursosaml.org/Shibboleth.sso/Status
11.4.4 Aplicaciones federadas
Nativas:
Con SpringSecurity: http://sp.cursosaml.org:8080/spring-security-saml2-sample/
Con Pysaml2/Django: https://sp.cursosaml.org/example-django
Con simpleSAMLphp:
https://sp.cursosaml.org/example-php
https://sp.cursosaml.org/example-php-session-fail
Authmemcookie:
https://sp.cursosaml.org/example-authmemcookie
PHP: https://sp.cursosaml.org/example-authmemcookie-php
Python/Django: https://sp.cursosaml.org/example-authmemcookie-django
Shibboleth:
https://shib.cursosaml.org/
PHP: https://shib.cursosaml.org/php
Python/Django: https://shib.cursosaml.org/django
11.4. URLS 87

Curso Administrador SP

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Curso Administrador SP

Загружено:

Авторское право:

Доступные форматы

Curso para operadores de Proveedores

November 23, 2012

2. Descripcin de la arquitectura desplegada en Confa 8

3. Gestin de los metadatos 11

4. Protocolo de resolucin de incidencias en un entorno de federacin de identidades 27

5. Desplegar un SP con SimpleSAMLphp 29

6. Domesticacin de aplicaciones con simpleSAMLphp 41

7. Domesticacin de aplicaciones en otros lenguajes diferentes a PHP 50

9. Anexo A. Conceptos sobre federacin de identidades 74

10. Anexo B. Software existente para implementar federaciones de identidades 82

11. Anexo C. Mquina virtual con las aplicaciones de ejemplo federadas 85

1.1 Que es federar/domesticar una aplicacin?

1.2 Autenticacin y autorizacin (AuthN & AuthZ)

Es importante diferenciar estos 2 conceptos.

1.3 Arquitecturas de las federaciones de indentidad

1.3.1 Modelo centralizado

Figura 1.1: Arquitectura centralizada

1.3.2 Modelo distribuido

Cada SP est conectado con cada IdP.

1.3. Arquitecturas de las federaciones de indentidad 3

Figura 1.2: Arquitectura distribuida

El descubrimiento se realizara en el SP.

1.3.3 Modelo Hub & Spoke

1.3. Arquitecturas de las federaciones de indentidad 4

Figura 1.3: Arquitectura Hub & Spoke

1.4 Tcnicas de federacin de aplicaciones

1.4.1 Federacin nativa.

1.4.2 Federacin basada en webservice

1.4. Tcnicas de federacin de aplicaciones 5

1.4.3 Federacin basada en authmemcookie

1.4. Tcnicas de federacin de aplicaciones 6

1.4.4 Federacin basada en REMOTE_USER / mod_shib

1.4. Tcnicas de federacin de aplicaciones 7

2.1 Entorno en Confa

Existen 3 entornos replicados en Confa:

2.2 Arquitectura de Confa

Figura 2.1: Entorno Confa

2.3 Entornos y servicios comunes desplegados en el CICA

Actualmente en el CICA se tienen desplegado lo siguiente:

Figura 2.2: Entornos y servicios desplegados en el CICA

2.4 Workflow de alta de IdP o Servicio (SP)

El proceso de incorporar un nuevo IdP o un nuevo SP en la infraestructura del Confa es la siguiente:

2.3. Entornos y servicios comunes desplegados en el CICA 9

2.4. Workflow de alta de IdP o Servicio (SP) 10

GESTIN DE LOS METADATOS

3.1 Modelos de gestin de metadatos

3.1.1 Modelo de agregacin

3.1.2 Modelo distribuido

3.1.3 Modelo centralizado utilizado en Confa

3.2 Los metadatos en simpleSAMLphp

3.2.1 Configurar los directorios que albergan los metadatos en simpleSAMLphp

Instalacin y configuracin del mdulo metarefresh

3.2. Los metadatos en simpleSAMLphp 12

sets => array(

Donde URL_DE_LA_FUENTE_DE_METADATOS es la URL de la fuente de metadatos SAML 2.0 en XML. En el

Habilitar y configurar mdulo cron y el crontab

Es necesario activar tambin el mdulo cron:

Y crear el fichero de configuracin config/module_cron.php:

3.2. Los metadatos en simpleSAMLphp 13

Donde HOST_SSP es el dominio de la mquina en la que est funcionando nuestro simpleSAMLphp.

Crear directorio que albergar los metadatos

Es posible consultar ms documentacin del mdulo metarefresh.

3.3 Gestor de metadatos en simpleSAMLphp - JANUS

maxCache => 606024, // 24 horas de lmite de cache