curso para operadores de proveedores de servicio -...

Curso para operadores de Proveedoresde Servicio

1.0

Sixto Martin

November 23, 2012

ÍNDICE GENERAL

1. Introducción 21.1. ¿Que es “federar/domesticar” una aplicación? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2. Autenticación y autorización (AuthN & AuthZ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Arquitecturas de las federaciones de indentidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4. Técnicas de federación de aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Descripción de la arquitectura desplegada en Confía 82.1. Entorno en Confía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2. Arquitectura de Confía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3. Entornos y servicios comunes desplegados en el CICA . . . . . . . . . . . . . . . . . . . . . . . . . 92.4. Workflow de alta de IdP o Servicio (SP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3. Gestión de los metadatos 113.1. Modelos de gestión de metadatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2. Los metadatos en simpleSAMLphp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3. Gestor de metadatos en simpleSAMLphp - JANUS . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.4. PEER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4. Protocolo de resolución de incidencias en un entorno de federación de identidades 274.1. Errores más frecuentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2. Protocolo de gestión de errores actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5. Desplegar un SP con SimpleSAMLphp 295.1. Recursos de ayuda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.2. Instalación y configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.3. Configuración avanzada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6. Domesticación de aplicaciones con simpleSAMLphp 416.1. Repaso de la API de simpleSAMLphp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.2. Autenticación, autorización y provisionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.3. Ejemplo de aplicación federada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.4. Algunas cuestiones a tener en cuenta a la hora de “domesticar” una aplicación . . . . . . . . . . . . 446.5. Análisis de algunas “domesticaciones” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.6. Conflictos con las sesiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.7. Algunos problemas a resolver a la hora de domesticar aplicaciones . . . . . . . . . . . . . . . . . . 48

7. Domesticación de aplicaciones en otros lenguajes diferentes a PHP 507.1. SimpleSAMLphp+AuthMemCookie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507.2. ShibbolethSP+REMOTE USER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567.3. Aplicaciones Python/Django (PySAML2/djangosaml2) . . . . . . . . . . . . . . . . . . . . . . . . 63

I

7.4. Aplicaciones Java (SpringSecurity OIOSAML) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677.5. Librerias para otros lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

8. Referencias 728.1. Especificación SAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728.2. Implementaciones de SAML SP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728.3. Documentación de interés sobre “domesticaciones de aplicaciones” . . . . . . . . . . . . . . . . . . 728.4. Gestión centralizada de metadatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738.5. Otros conceptos avanzados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

9. Anexo A. Conceptos sobre federación de identidades 749.1. Qué es una federación de identidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749.2. Ventajas de la federación de identidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759.3. Ejemplos de federaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769.4. Conceptos (IdP, SP, AA, WAYF, atributos, bindings) . . . . . . . . . . . . . . . . . . . . . . . . . . 779.5. Protocolos (SAML PAPI, OpenId) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

10. Anexo B. Software existente para implementar federaciones de identidades 8210.1. Shibboleth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8210.2. simpleSAMLphp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8310.3. PySAML2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8310.4. OpenSSO / OpenAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8410.5. Lasso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8410.6. Solución recomendada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

11. Anexo C. Máquina virtual con las aplicaciones de ejemplo federadas 8511.1. Descarga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8511.2. Configuración previa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8511.3. CONTENIDO DE LA MÁQUINA VIRTUAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8611.4. URLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

II

Curso para operadores de Proveedores de Servicio, 1.0

Esta documentación pertenece al curso para operadores de Proveedores de Servicio que se celebra en Sevilla el X deX y en Granada el Y de Y de 2012.

ÍNDICE GENERAL 1

CAPÍTULO

ONE

INTRODUCCIÓN

1.1 ¿Que es “federar/domesticar” una aplicación?

“Federar/domesticar” una aplicación es una expresión coloquial que utilizamos para referirnos a la acción de integraruna aplicación en un entorno de federación de identidades. Existen diferentes grados de fedderar una aplicación, siendoel de mayor grado aquel que consigue que una aplicación posea:

Funcionalidad de SSO y SLO globales (con opción de conservar logout local).

Que los usuarios se creen/actualicen/inhabiliten/eliminen en función de la información que llega de la aserciónSAML.

Que los permisos locales de la aplicación se configuren según los datos de la aserción SAML.

1.2 Autenticación y autorización (AuthN & AuthZ)

Es importante diferenciar estos 2 conceptos.

La autenticación es el proceso de verificar la identidad de una persona mientras que la autorización es el proceso deverificación de que una persona ya identificada tiene la autoridad para realizar una cierta operación o para acceder aun 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 identificación.(autenticación)

4. El sistema valida según sus reglas si las credenciales aportadas son suficientes para dar acceso al usuario ono. (autorización)

En una federación de identidad:

La autenticación se realiza en el IdP.

La autorización se realiza en el SP o en la propia aplicación

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 federación deidentidades. Cada módelo tiene sus ventajas y desventajas por lo que dependiendo del entorno y contexto optaremospor 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 autenticación (auth backends) son Ldaps, BDs, etc dediferentes instituciones.

Si el IdP tiene soporte los SP podrían comunicarse en los diferentes protocolos de autenticación actualmenteexistentes: SAML2, sHibboleth, OpenId, PAPI

Los proveedores de identidad delegarían la petición del consentimiento en el único nodo posible: el IdP central.

Cada SP está directamente conectado con el IdP (no habría descubrimiento de IdP) siendo necesario especificarde alguna forma contra que backend de autenticación actuar.

El SP podría pasarle un parámetro al IdP o ser el IdP directamente el que decidiera a donde ir dependiendo dedonde le llegue la petición, 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 realizaría en cada uno de los IdPs.

1.3. Arquitecturas de las federaciones de indentidad 3

http://en.wikipedia.org/wiki/SAML_2.0

http://shibboleth.internet2.edu/

http://es.wikipedia.org/wiki/OpenID

http://papi.rediris.es/


Figura 1.2: Arquitectura distribuida

El descubrimiento se realizaría 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 comunicación puedan comunicarse haciendouso del nodo central que hará de puente (bridging) y traduzca las aserciones de un protocolo a otro.

Los IdPs delegarían la petición del consentimiento en el nodo central (aunque también puede haber un dobleconsentimiento y requerirse el consentimiento tanto en el IdP como en el nodo central).

El descubrimiento se realizaría en el nodo central. (Aunque existen federaciones con esta arquitectura querealizan un wayf embebido en la aplicación federada).

Ventajas del modelo Hub & Spoke

Desacople de los diferentes elementos, desacople tecnológico (al poder coexistir diferentes protocolos siempreque el nodo central sea compatible con los mismos y actue de bridge). Mejora escalabilidad.

Poder tener centralizados los servicios de la federación: consentimiento, descubrimiento (wayf), filtrosde atributos, validación de atributos, monitorización, estadísticas. Reduciendo costes y facilitando elmantenimiento.

Posibilidad de inter-federación. Conectando el nodo central con otro nodo central de otra federaciónconseguimos 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 Técnicas de federación de aplicaciones

1.4.1 Federación nativa.

Esta federación es posible cuando el software del SP y el software de la aplicación que se quiere federar utilizan lamisma tecnología y lenguaje. Desde la aplicación que se quiere federar se hará uso directo de las librerias del SP.

1.4.2 Federación basada en webservice

Se basa en que el software de la aplicación a federar posea un webservice con una serie de funciones de acceso yregistro (login, provisión, logout). Desde el SP se va haciendo uso de este webservice.

1.4. Técnicas de federación de aplicaciones 5


1.4.3 Federación basada en authmemcookie

Cuando el software del SP y el software de la aplicación a federar son de diferentes lenguajes y no puede realizarseuna integración nativa puede optarse por esta opción.

Consiste en que el SP almacene en el memcache datos del usuario que son leidos con el módulo Auth memCookie deApache que protege la aplicación a federar.

Una solución alternativa es no usar el módulo de Apache y directamente leer en la aplicación a federar los datos dememcache.


http://authmemcookie.sourceforge.net


1.4.4 Federación basada en REMOTE_USER / mod_shib

Cuando el software del SP y el software de la aplicación a federar son de diferentes lenguajes y no puede realizarseuna integración nativa puede optarse por esta opción.

Se basa en que el Apache proteja la aplicación a federar con la autenticación shibboleth (Shibboleth SP) habilitandoel mod_shib. El Apache le hara llegar los datos del usuario a la aplicación que queremos federar. El Apache utilizaralas cabeceras HTTP para hacerle llegar los datos del usuario a la aplicación que queremos federar.


CAPÍTULO

TWO

DESCRIPCIÓN DE LA ARQUITECTURADESPLEGADA EN CONFÍA

2.1 Entorno en Confía

Existen 3 entornos replicados en Confía:

Producción. Es el entorno oficial, el que utilizan los usuarios finales.

Pre-producción. Es utilizado como entorno de pruebas. Antes de pasar cualquier IdP o SP a producción debede validarse dicho elemento en este entorno.

Laboratorio. Es utilizado para desarrollar nuevos plugins y para probar nuevos servicios.

2.2 Arquitectura de Confía

La federación Confía está desplegada con una arquitectura Hub & Spoke.

Figura 2.1: Entorno Confía

8


En Confía es obligatorio que de cada IdP y de cada SP se ofrezcan 2 instancias: La instancia oficial y la instanciade pruebas sobre la que se harán 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 Confía es la siguiente:

1. Lo primero será realizar los “tramites burocráticos” para que se acepte la incorporación del servicio: Aceptaciónpor parte de la AUPA-TIC, ofrecer información del servicio al Comité, visto bueno técnico por parte del Comité.

2. Se desarrollará el IdP o el Servicio (SP) conectándolo con el entorno de laboratorio.

3. Una vez desarrollado el IdP o el Servicio y una vez pasados los “trámites burocráticos” se pasará al entorno depre-producción 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 producción. Y se conectará una instancia no oficial conel entorno de laboratorio para seguir mejorando el servicio o para cuando haya que hacer pruebas con nuevasversiones de software.

Por tanto:

En el entorno de producción únicamente habrá instancias de IdPs y SPS oficiales.

En el entorno de pre-producción habrá instancias de IdPs y SPs oficiales, e instancias que van a ser validadascomo oficiales.

En el entorno de laboratorio deberá de haber instancias de pruebas de los IdPs y SPs.

A efectos prácticos dar de alta en un determinado entorno no es más que registrar el correspondiente metadato de laentidad en el gestor de metadatos de dicho entorno.

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

CAPÍTULO

THREE

GESTIÓN DE LOS METADATOS

La gestión de los metadatos constituye una tarea esencial para el funcionamiento de las federaciones de identidadesbasadas en el protocolo SAML. Es imprescindible proporcionar metadatos confiables, disponibles y precisos a losparticipantes de la federación: la descripción de las entidades, sus responsables y sobre todo las url donde ofrecen lasfuncionalidades y las claves públicas.

Dentro de los metadatos se incluyen 2 atributos opcionales que hay que tener muy en cuenta a la hora de realizar lagestión de los metadatos:

validUntil: Indica en tiempo absoluto cuando caducan los metadatos

cacheDuration: Indica el máximo periodo de tiempo en el que las entidades deberían de confiar en esosmetadatos y albergarlos en su “cache” (en simpleSAMLphp la cache está basada en ficheros de sistema quese alojan dentro de la carpeta metadata).

También es importante ver como se llegó al consenso para que los entityIDs de las entidades coincidieran con las urlsdonde se alojan sus metadatos, lo cual facilita el trabajo de la gestión de los metadatos.

3.1 Modelos de gestión de metadatos

3.1.1 Modelo de agregación

La arquitectura de agregación permite actualizar los metadatos en el lado de la entidad que los va a consumir y debidoal simple modelo de confianza, los metadatos serán considerados válidos siempre que estos sean descargados de unafuente fiable (URL pre-acordada y los metadatos convenientemente firmados con una clave pública del publicador)

3.1.2 Modelo distribuido

En la arquitectura distribuida cada entidad es responsable de la gestión y publicación de sus propios metadatos. Coneste modelo los metadatos de un determinado punto pueden ser obtenidos bajo demanda sin la necesidad de la descargaperiódica de una colección de gran tamaño de metadatos. (Se realiza el descubrimiento dinámico de metadatos enfunción 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 Confía

Es una arquitectura que viene muy bien en federaciones Hub & Spoke, en el nodo bridge o en un nuevo nodo, sedespliega un sistema que será responsable de almacenar, monitorizar y verificar los metadatos de las entidades de unafederación.

11


Los metadatos de la federación son agregados periódicamente, almacenados y publicados como un archivo XMLconvenientemente firmado.

El sistema deberá de disponer de mecanismos para poder delegar las responsabilidades de gestión de un determinadometadato 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 parámetro ‘metadata.sources’ donde simpleSAMLphp va a buscar losficheros que contienen las fuentes de los diferentes metadatos.

Si queremos que además de en el directorio metadata/ (directorio en el que siempre por defecto se buscan losmetadatos) se busquen metadatos dentro del directorio example1

’metadata.sources’ => array(// Habilita los metadatos que se encuentren en los archivos del directorio metadataarray(’type’ => ’flatfile’),// Habilita los metadatos que se encuentren en los archivos del directorio metadata/example1array(’type’ => ’flatfile’, ’directory’ => ’metadata/example1’),

),

Además es posible configurar el tipo de fichero en el que simpleSAMLphp espera leer los metadatos. Las alternativasson 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 federación, es necesario especificarlos metadatos de las fuentes en las que se confía. En muchas federaciones es normal configurar una distribuciónautomatizada de los metadatos utilizando el formato de metadatos XML SAML 2.0. Generalmente una administracióno autoridad central proporciona una URL con un documento SAML 2.0 que incluye los metadatos de todas lasentidades de la federación.

Mediante el módulo metarefresh de simpleSAMLphp es posible obtener los metadatos remotos de una URL yalmacenarlos en un archivo.

Instalación y configuración del módulo metarefresh

El módulo metarefresh existe en la instalación básica de simpleSAMLphp por lo que únicamente tendremos quehabilitarlo:

touch <ruta hasta simplesamlphp>/simplesamlphp/modules/metarefresh/enable

Puesto que el módulo utiliza wget para realizar las descargas de los metadatos deberemos tener este software instaladoen la máquina:

yum install wget

El módulo tiene un archivo de configuración propio que debemos alojar en el directorio configdel simpleSAMLphp. El fichero config-metarefresh.php (podemos encontrar una plantilla ensimplesamlphp/modules/metarefresh/config-templates/config-metarefresh.php).El contenido del fichero sería 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 podría

tener los metadatos de los IdPs y de los SPs por separado. */’sources’ => array(

array(’src’ => ’URL_DE_LA_FUENTE_DE_METADATOS’,

),),// Tiempo en el que expiraran los metadatos descargados.’expireAfter’ => 60*60*24*4,/* Directorio en el que se crearan los ficheros saml20-idp-remote.php

y saml20-sp-remote.php */’outputDir’ => ’metadata/federation/’,// Formato en que se encuentran los metadatos’outputFormat’ => ’flatfile’,

),),

);

Donde URL_DE_LA_FUENTE_DE_METADATOS es la URL de la fuente de metadatos SAML 2.0 en XML. En elarray cron hay que especificar alguna de las perioricidades que defina el módulo de cron (en este caso ‘hourly’). Estose explica más abajo.

A continuación hay que crear el directorio donde se guardarán los metadatos descargados, tal y como se especifica enel atributo outputDir del fichero anterior:

mkdir simplesamlphp/metadata/federation

Es muy importante que este directorio tenga permisos de escritura para el usuario con el que se ejecuta el servidor web(y por tanto, el intérprete de PHP). En el caso de máquinas con RedHat? o Centos este usuario se llama apache, en elcaso de máquinas basadas en Debian, el usuario es www-data.

chown -R apache:apache <ruta-al-simplesamlphp>/simplesamlphp/metadata/federation

Para que metarefresh funcione correctamente, es necesario configurar el módulo sanitycheck para lo cual simplementecopiamos a la carpeta config de simpleSAMLphp la plantilla config-sanitycheck.php y configuramos loscron_tag que queramos.

Habilitar y configurar módulo cron y el crontab

Es necesario activar también el módulo cron:

touch <ruta hasta simplesamlphp>/modules/cron/enable

Y crear el fichero de configuración config/module_cron.php:

<?php/** Configuration for the Cron module.

** $Id: $

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 envío de correos, que puede llegar a ser intensivo, poniendo ‘sendemail’ =>FALSE,. En el array ‘allowed_tags’ hay que definir frecuencias a las que se puedan enganchar los distintos módulos.En nuestro caso, metarefresh lo hace con ‘hourly’.

Estas tags no son más que cadenas arbitrarias. Quien decide con qué frecuencia se ejecuta cada tag es el propio cron,bien con scripts en los directorios /etc/cron.[hourly|daily|weekly...] o en ficheros crontab en /etc/cron.d. Para que sedescarguen periódicamente los metadatos, hay que colocar un fichero crontab en /etc/cron.d con una línea para cadatag definida. En nuestro caso, necesitamos una línea que se ejecute diariamente, otra cada hora y otra “frecuentemente”(cada minuto, por ejemplo):

0 0 * * * root wget --quiet -O /dev/null --no-check-certificate"https://HOST_SSP/simplesaml/module.php/cron/cron.php?key=secret&tag=daily"

0 * * * * root wget --quiet -O /dev/null --no-check-certificate"https://HOST_SSP/simplesaml/module.php/cron/cron.php?key=secret&tag=hourly"

* * * * * root wget --quiet -O /dev/null --no-check-certificate"https://HOST_SSP/simplesaml/module.php/cron/cron.php?key=secret&tag=frequent"

Donde HOST_SSP es el dominio de la máquina en la que está funcionando nuestro simpleSAMLphp.

Por último es necesario copiar el fichero config-sanitycheck.php de modules/sanitycheck/config-templates/ a config/.

Crear directorio que albergará los metadatos

Por último, es necesario configurar simpleSAMLphp para que, además de utilizar los ficheros de metadatos generales(los ficheros de metadata/), utilice también los que Metarefresh dejará en el directorio metadata/federation/. Para ellohay que editar el fichero config/config.php, concretamente la opción metadata.sources, para añadirle nuestra nuevafuente de metadatos:

’metadata.sources’ => array(array(’type’ => ’flatfile’),array(’type’ => ’flatfile’, ’directory’ => ’metadata/federation’),

),

Es posible consultar más documentación del módulo metarefresh.

3.3 Gestor de metadatos en simpleSAMLphp - JANUS

En simpleSAMLphp existe un módulo llamado Janus que permite: * Gestionar los metadatos de IdPs y SPs (Poseediferentes niveles de permisos para los usuarios) * Publicar subconjuntos de los metadatos registrados. * GestionarARPs 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

http://simplesamlphp.org/docs/trunk/simplesamlphp-automated_metadata

http://code.google.com/p/janus-ssp/wiki/WhatIsJANUS


3.3.1 Instalación

JANUS no es más que un módulo de simpleSAMLphp. En una federación de identidades Hub & Spoke podemosdesplegar el gestor de metadatos dentro de la instancia del “nodo bridge” o en una instancia nueva. (Explicamos comose desplegaría en una nueva instancia.

Al servicio Janus lo protegeremos con una fuente de autenticación local en la que habilitemos los diferentesadministradores que van a gestionar los metadatos. Lo ideal sería que el Janus estuviese protegido de forma federada,pero se puede dar el caso de que un administrador no pudiera acceder al servicio Janus a través de su Proveedor deIdentidad precisamente porque los metadatos del mismo son los que necesitan ser actualizados.

Lo primero que debemos hacer es obtener el código del software Janus el cual obtendremos ejecutando:

svn co http://janus-ssp.googlecode.com/svn/tags/v.1.11.0 janus

Una vez realizado esto copiamos el directorio janus dentro del directorio modules y lo activamos:

touch /var/www/janus/simplesamlphp/modules/janus/enable

En Janus, los diferentes metadatos van a ser almacenados en una base de datos por tanto deberemos tener acceso a unsistema de base de datos.

Configuración de Apache

Se debe crear un fichero de configuración para el VirtualHost de janus.example.com.conf en el directorio/etc/httpd/conf.d/ con el siguiente contenido:

<VirtualHost *:80>ServerName janus.example.comDocumentRoot /var/www/janus/simplesamlphp/wwwSSLProxyEngine OnProxyPreserveHost OnAlias /simplesaml /var/www/janus/simplesamlphp/www<Location />

ProxyPass https://localhost</Location>

</VirtualHost>

<VirtualHost *:443>ServerName janus.example.comDocumentRoot /var/www/janus/simplesamlphp/wwwAlias /simplesaml /var/www/janus/simplesamlphp/wwwSSLEngine onSSLCertificateFile /etc/httpd/ssl/janus.example.com/crt/janus.example.com.crtSSLCertificateKeyFile /etc/httpd/ssl/janus.example.com/key/janus.example.com.key

</VirtualHost>

Además es necesario crear los certificados (autogenerados) que se han especificado en la configuracion del VirtualHostpara https. Se deberán seguir las siguientes instrucciones:

1. Crear el directorio donde alojar los certificados, en este caso, /etc/httpd/ssl/janus.example.com/

mkdir -p /etc/httpd/ssl/janus.example.com/crt /etc/httpd/ssl/janus.example.com/key

2. Cambiar el directorio actual por /etc/httpd/ssl/janus.example.com/

cd /etc/httpd/ssl/janus.example.com/

3. Creación de la clave sin contraseña y con una encriptación 1024



openssl genrsa -out key/janus.example.com.key 1024

4. Generar el fichero CSR (solicitud de certificado)

openssl req -new -key key/janus.example.com.key -out janus.example.com.csr

5. Generar el certificado autofirmado:

openssl x509 -req -days 1825 -in janus.example.com.csr -signkey key/janus.example.com.key-out crt/janus.example.com.crt

Por último, es necesario reiniciar el servicio httpd para que la nueva configuración sea aplicada

service httpd restart

Certificado (janus.example.com.crt) y clave (janus.example.com.key) deberemos también de tenerlos accesibles en lacarpeta cert del simpleSAMLphp para que sean usados en el firmado y cifrado de aserciones. Para ello lo mejor escrear enlaces simbólicos

ln -s /etc/httpd/ssl/janus.example.com/key/janus.example.com.key/var/www/janus/simplesamlphp/cert/janus.example.com.key

ln -s /etc/httpd/ssl/janus.example.com/crt/janus.example.com.crt/var/www/janus/simplesamlphp/cert/janus.example.com.crt

Creación de la base de datos y configuración

Una vez reiniciado el servidor apache podremos acceder a un script que posee Janus para crear la base de datos y lastablas 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 pormotivos de seguridad:

rm -rf /var/www/janus/simplesamlphp/modules/janus/install

A continuación copiaremos la plantilla de configuración de janus del janus/config-templates/module_janus.php aldirectorio de configuración de simplesamlphp config/ :

cp /var/www/janus/simplesamlphp/modules/janus/config-templates/module_janus.php/var/www/janus/simplesamlphp/config/module_janus.php

Y editaremos el archivo convenientemente con la configuración que más nos interese. A continuación vamos a irdetallando los diferentes parámetros y el valor que recomendamos darles.

Configuración de datos del administrador:

// Nombre del administrador de Janus’admin.name’ => ’JANUS admin’,

// Email del administrador de Janus, aparecerá como contacto de la aplicación,’admin.email’ => ’[email protected]’,

Configuración de la base de datos Janus:

’store’ => array(// Configuración de conexión con la base de datos.’dsn’ => ’mysql:host=localhost;dbname=janus_db’,’username’ => ’janus’, // Usuario de la base de datos



’password’ => ’’, // Password para acceder a la base de datos’prefix’ => ’janus__’, // Prefijo utilizado en las tablas, si lo hubiera

),

Configuración de cron:

/* Habilita un cron que se ejecutará y refrescará los metadatos de cada una delas entidades */

’metadata_refresh_cron_tags’ => array(’janus’),

/* Hay otras 2 tareas que son importantes ejecutar periodicamente que sehabilitan con estos 2 parámetros, básicamente validan que los certificadosy los metadatos sean correctos, en caso contrario se puede activar elsendMail para que se envien correos al administrador */

’validate_entity_certificate_cron_tags’ => array(’daily’),’validate_entity_endpoints_cron_tags’ => array(’daily’),

/* Si habilitamos la validación de certificados es necesario indicar la rutadonde se encuentren las CAs */

’ca_bundle_file’ => ’/etc/pki/tls/certs/ca-bundle.crt’,

Configuración de acceso al Janus:

/* Crearemos en el authsources una fuente de autenticación del tipo exampleauth conla lista de usuarios de janus */

’auth’ => ’janus-users’,

/* Este atributo del usuario es el que va a ser comparado con el identificadorde 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 sise ha autenticado correctamente */

’user.autocreate’ => false,

Configuración visual de Janus:

// Permite paginar la pestaña INBOX de Janus’dashboard.inbox.paginate_by’ => 20,

/* Metadato de la entidad que será utilizado en la vista de conexión para la identificaciónvisual de la entidad. Se puede usar el ’entityid’ o el ’name’ (este ultimo, si essuficientemente representativo y existe en todas las entidades) */

’entity.prettyname’ => ’entityid’,

Configuración de uso:

// Lo habitual en una federación con nodos simpleSAMLphp es habilitar IdPs y SPs del tipo SAML 2.0’enable.saml20-sp’ => true,’enable.saml20-idp’ => true,’enable.shib13-sp’ => false,’enable.shib13-idp’ => false,

// Indica el estado al que se va a asociar a una entidad cuando se registre.’workflowstate.default’ => ’testaccepted’,

Configuración del sistema Janus:

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



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’

Configuración de ARPs:

/* Cuando asociamos una ARP a un SP, se añadiran a los metadatos una serie de etiquetasRequestedAttribute. En simpleSAMLphp, en el caso de que esté definido un filtroattributelimit y una ARP para un SP, se tomarán esos atributos definidos en el ARPpara filtrar los atributos que se liberan desde el IdP */

/* Permite configurar una lista con los atributos que conformarán la ARPque se asociará a los SPs que no tengan una ARP asociada. Si no queremosestablecer 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’,),

),

Configuración de la exportación de metadatos:

// Este atributo define el formato posible para las publicaciones de metadatos’mdexport.allowed_mime’ => array(

1 => ’application/xml’,2 => ’application/samlmetadata+xml’,3 => ’application/simplesamlphp+text’, // SSP flat file format

),

/* Este atributo define un conjunto de opciones por defecto con el que se publicaránlos metadatos de las entidades */

’mdexport.default_options’ => array(’entitiesDescriptorName’ => ’Federation’, // Nombre del set de entidades’mime’ => ’application/xml’, // Formato de salida

’maxCache’ => 60*60*24, // 24 horas de límite de cache’maxDuration’ => 60*60*24*5, // 5 días de para que caduquen los metadatos de la entidad

/* Si queremos que los metadatos se firmen, de ser así posteriormente podrán sercomprobados en el modulo metarefreh */’sign.enable’ => FALSE,// Datos del certificado con el que se firmará la publicación, en caso de que se habilite

’sign.privatekey’ => ’janus.example.com.key’,’sign.privatekey_pass’ => NULL,’sign.certificate’ => ’janus.example.com.crt’,

),

Configuración de los feeds de publicaciones:

’mdexport.feeds’ => array(// Este feed publica bajo firma 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’ => ’janus.example.com.key’,’sign.privatekey_pass’ => ’’,’sign.certificate’ => ’janus.example.com.crt’,

),

// Este feed publica bajo firma todas los proveedores de identidad del tipo SAML 2.0



’idp-prod’ => array(’types’ => array(’saml20-idp’),’states’ => array(’prodaccepted’),’mime’ => ’application/samlmetadata+xml’,’exclude’ => array(),’postprocessor’ => NULL,’entitiesDescriptorName’ => ’IdPs del SINED’,’filename’ => ’idp_sined.xml’,’maxCache’ => 60*60*48, // 24 hour cache time’maxDuration’ => 60*60*24*7, // Maximum 5 days duration on ValidUntil.’sign.enable’ => TRUE,’sign.privatekey’ => ’janus.example.com.key’,’sign.privatekey_pass’ => ’’,’sign.certificate’ => ’janus.example.com.crt’,

),

/* Este feed publica bajo firma todas los proveedores de identidad y de servicio del tipoSAML 2.0 (salvo los del nodo bridge) */

’idpsp-prod’ => array(’types’ => array(’saml20-idp’,’saml20-sp’),’states’ => array(’prodaccepted’),’mime’ => ’application/samlmetadata+xml’,’exclude’ => array(

’https://wayf.example.com/simplesaml/saml2/idp/metadata.php’,’https://wayf.example.com/simplesaml/module.php/saml/sp/metadata.php/saml’

),’postprocessor’ => NULL,’entitiesDescriptorName’ => ’IDPs & SPs del SINED’,’filename’ => ’idpsp_sined.xml’,’maxCache’ => 60*60*48, // 24 hour cache time’maxDuration’ => 60*60*24*7, // Maximum 5 days duration on ValidUntil.’sign.enable’ => TRUE,’sign.privatekey’ => ’janus.example.com.key’,’sign.privatekey_pass’ => ’’,’sign.certificate’ => ’janus.example.com.crt’,

),),

Otros parametros:

’entity.useblacklist’ => true, /* 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 más información sobre documentación de cada uno de estos atributos.

Importante. El cron que vamos a asociar al Janus para que automáticamente actualice los metadatos delas entidades haciendo uso de la URL donde dichos metadatos están publicados por la entidad (atributo‘metadata_refresh_cron_tags’ del archivo de configuración Janus) debe de estár dado de alta como tag válido en elmodule_cron.php. Además tenemos que crear una entrada en el servicio de cron para que se ejecute con la periocidadque deseemos.

3.3.2 Funcionamiento

A continuación se describen las principales vistas del software Janus. También puede consultar una serie de videos enla web de Janus para entender su funcionamiento.


http://code.google.com/p/janus-ssp/wiki/configurationfile



Panel de administración de usuarios

Desde esta vista podremos crear, editar o eliminar usuarios. Cada usuario tendrá asociado un tipo y será identificadopor el ID de usuario. Una funcionalidad a destacar es que Janus permite tener usuarios inactivos, siempre será mejoresta opción que la de borrarlo en el caso de que tengamos dudas sobre la cuenta.

Panel de administración de entidades

Desde esta vista podremos crear, deshabilitar o eliminar entidades, así como visualizar y editar los permisos de losusuarios sobre las entidades. Si un usuario tiene permiso sobre una entidad, le aparecerá en su vista de listado deentidades.



Listado de entidades

En esta vista veremos un listado de las entidades que el usuario administra. Podremos ver el estado de cada una de lasentidades (se usan diferentes colores para cada estado y para saber si está habilitado o no. Estos colores se definen enel archivo de configuración de Janus).

Además en esta vista podremos dar de crear nuevas entidades especificando el tipo de la entidad (IdP / SP) y el entityIDde la misma.

Exportador de entidades

En esta vista podremos exportar los metadatos de las entidades probando diferentes configuraciones. En esta vistapodremos simular posibles “feeds de entidades” que luego podremos configurar en el archivo de configuración dejanus, en el atributo ‘mdexport.feeds’



Edición de ARPs

En esta vista podremos administrar las diferentes ARPs de Janus. Por cada ARP se le asigna un nombre, unadescripción y el conjunto de atributos que la componen. Además se puede establecer una determinada ARP paraque sea la ARP por defecto que se asocie a una entidad. Si una entidad no tiene ARP, Janus le asociará la ARP quetenga configurada en el atributo ‘entity.defaultarp’ (Si no queremos que se asocie ARP dejaremos este atributo vacioy no definiremos ARP en la entidad.

Si seleccionamos una determinada ARP, además de editarla se nos mostrará el conjunto de entidades que la estánutilizando en ese momento.

Panel de administración de una entidad

En esta vista se nos presenta información relacionada con la entidad:

Connection ID. Que es el entityID de la entidad

Metadata URL. Que es la dirección en la que se encuentran disponibles los metadatos de la entidad, y que esla URL que es utilizada para que JANUS actualice automáticamente sus metadatos

ARP. Define la ARP asociada a la entidad

Revision note. Indica algún comentario asociado a la actual reversión de datos de la entidad

Parent revision. Indica cual es la revisión que precede a la actual.

State. Estado actual en el que se encuentra la entidad. El Workflow por el que pasan las entidades viene definidoen el archivo de configuración de Janus

Type. Tipo de entidad.



Desde esta vista podemos acceder a diferentes vistas:

Metadata. Vista de edición de los metadatos

Import metadata. Vista de importación de los metadatos

History. Vista del historico. Desde esta vista podremos volver a una revisión anterior de los datos de la entidad.

Validate. VIsta de validación. Desde esta vista podremos validar los metadatos de la entidad. Hay que tener encuenta que si los certificados son autofirmados siempre se devolvera un error en la vista de validación.

Export. Vista de exportación de metadatos

Importador de metadatos de una entidad

Desde esta vista podremos importar los metadatos de una entidad. Se permiten varias formas:

Importar metadatos publicados en una URL.

Importar metadatos copiando su XML.

Importar metadatos copiando su JSON.



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 están publicando de una determinada entidad. Se muestranvarios formatos: XML, “flatfile”

3.4 PEER

PEER es un proyecto para desarrollar un directorio de metadatos de los diferentes Proveedores de Identidad yProveedores de Servicio existentes en la actualidad. Los administradores de cada entidad pueden darla de alta enel sistema trás la verificación de que ese administrador controla dicha entidad. Este directorio es capaz de publicarcolecciones de metadatos por lo que puede ser utilizado como servicio fuente fiable de metadatos.

3.4. PEER 26

https://spaces.internet2.edu/display/PEER/PEER+Project+Plan+and+Proposal

CAPÍTULO

FOUR

PROTOCOLO DE RESOLUCIÓN DEINCIDENCIAS EN UN ENTORNO DE

FEDERACIÓN DE IDENTIDADES

4.1 Errores más frecuentes

Los errores más frecuentes que se dan en nuestra federación son:

Problemas en las conexiones a las fuentes de atributos como servidores de bases de datos o directorios. Enocasiones el servidor de base de datos funciona correctamente pero lo que se queda bloqueado es el conectordel IdP a esa base de datos.

Usuarios que no tienen los atributos obligatorios. En este caso el nodo Hub es capaz de detectar este problemae informa de esto al usuario.

Usuarios que no tienen el atributo eduPersonPrincipalName. Se produce una excepción ya que ese atributo esrequerido por simpleSAMLphp para funcionar correctamente ya que es el atributo que está establecido comoidentificador del usuario.

Que las correspondencias de asignaturas en los LMS no sean correctas.

Si en el flujo de autenticación el usuario le da al botón de atrás del navegador, o se corta la conexión u otrofallo inesperado, se pierde la sesión y es necesario que cierre el navegador y vuelva a empezar. El error que sevisualiza en este caso es “Lost state”.

Si el usuario hace click dos veces seguidas en el botón de autenticar se produce el error “Duplicated assertionsent”.

4.2 Protocolo de gestión 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 están disponibles, se le presentauna pantalla al usuario y se le informa de esta circunstancia indicandole que se ponga en contacto con el administradorde su IdP. En esta caso se obtiene el IdP concreto a partir del atributo eduPersonPrincipalName.

Sin embargo, si uno de los atributos que faltan es el propio eduPersonPrincipalName se produce una excepción y entreotras cosas el sistema no sabe qué IdP debe indicarle para solucionar el problema. En este caso se envía un correo alos operadores de la federación con los atributos del usuario de los que se dispone. Los operadores examinan estosatributos para ver si es posible averiguar el IdP de orígen de dicho usuario para informar a su administrador. Si el

27


usuario está utilizando la dirección de correo institucional, la tarea de obtener su IdP de orígen suele ser fácil. Sinembargo, en muchas ocasiones, los usuarios utilizan correos de proveedores externos como Hotmail, GMail, etc. y portanto, no es posible obtener el IdP a partir de la dirección de correo.

4.2.2 Excepciones

Si se produce cualquier otro de los errores frecuentes anteriormente citados se le presenta al usuario una pantalla enla que se le permite al usuario “reportar el error”. Ese correo se envía al operador de la federación en el caso de quese produzca en el nodo hub (y si está bien configurado el IdP también debe llegar al administrador del proveedor deidentidad).

4.2.3 ¿Que pasa si el problema persiste?

Actualmente si el problema persiste, el operador de la federación accede a la cuenta de correo de contacto deconfia.aupa.info y desde esa cuenta informa al usuario el motivo de por qué se está produciendo dicho error y lepropone una solución: Borrar las cookies del navegador, tener cuidado en la navegación o ponerse en contacto con elCAU de su universidad.

4.2. Protocolo de gestión de errores actual 28

CAPÍTULO

FIVE

DESPLEGAR UN SP CONSIMPLESAMLPHP

5.1 Recursos de ayuda

Documentación de instalación de simpleSAMLphp

Documentación de como configurar simpleSAMLphp como un SP

Docuemntación de la wiki de Confía (y como actualizar de una version a otra)

5.2 Instalación y configuración

5.2.1 Instalación y dependencias

Vamos a explicar como instalar SimpleSAMLphp en una distribución CentOS 6.3, la cual está disponible para sudescarga desde http://isoredirect.centos.org/centos/6/isos/x86_64/

Una vez se encuentre el sistema operativo instalado, se debe proceder a la instalación de las dependencias desimpleSAMLphp:

yum install php pcre httpd zlib openssl mod_ssl php-mbstring php-mcrypt php-pdo

Es posible comprobar que los módulos se encuentra activos creando un fichero index.php en el directorio depublicación de Apache2 con el siguiente código:

<?php phpinfo(); ?>

5.2.2 Instalación de SimpleSAMLphp

Una vez resueltas todas las dependencias, la instalación de SimpleSAMLphp es realmente sencilla, solamente esnecesario descargar el código fuente en un directorio del sistema, por ejemplo en el directorio /var/www/sp/

yum install subversionmkdir /var/www/spsvn co http://simplesamlphp.googlecode.com/svn/branches/simplesamlphp-1.10 simplesamlphp /var/www/sp/simplesamlphp

29

http://simplesamlphp.org/docs/stable/simplesamlphp-install

http://simplesamlphp.org/docs/stable/simplesamlphp-sp

http://confia.aupa.info/trac/wiki/Documentacion/GuiaSP

http://confia.aupa.info/trac/wiki/Documentacion/ActualizacionSP


Estructura general

|--cert Directorio donde alojar el certificado y la clave que serán usados para firmar/cifrar las aserciones|--config Directorio con los ficheros de configuración de simpleSAMLphp|--config-templates Directorio con plantillas de los ficheros de configuración|--metadata Directorio donde alojar ficheros con los metadatos de los IdPs remotos en los que se confiará.|--metadata-templates Directorio con plantillas de los ficheros de metadatos|--modules Directorio con los diferentes módulos de simpleSAMLphp|--lib Directorio con las librerias de simpleSAMLphp|--www Directorio con la lógica web de simpleSAMLphp|--templates Directorio con las plantillas web de simpleSAMLphp|--dictionaries Directorio con las traducciones de simpleSAMLphp|--docs Directorio con dcd ocumentación|--log Directorio donde alojar los logs de simpleSAMLphp (Requiere configurar el config.php para que se guarden aquí.|--attributemap Directorio con ficheros con lógica 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.

Configuración general

Los ficheros de configuración de simpleSAMLphp se localizan dentro del directorio config donde se hayainstalado simpleSAMLphp. En el directorio config-templates se encuentran plantillas de los principales ficherosde configuración que se pueden necesitar en simpleSAMLphp. Es bastante útil partir de una de estas plantillas ymodificarla a conveniencia en lugar de crear el fichero de configuración correspondiente desde cero, lo cuál suele sermucho más 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 configuración de simpleSAMLphp es un fichero PHP con las reglas de sintáxis de estelenguaje. Un comando útil que debemos ejecutar siempre que hagamos modificaciones a este fichero es php -l ya quenos 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 continuación se detallan las partes más habituales del fichero config.php que hay que modificar:

Contraseña de administración de simpleSAMLphp

’auth.adminpassword’ => ’admin’,

Es importante cambiar esta contraseña porque además de ser un problema de seguridad si se deja tal cual,simpleSAMLphp lo detectará y dará un error.

Sal aleatoria y secreta:

’secretsalt’ => ’defaultsecretsalt’,

Para generar este valor se puede utilizar el siguiente comando:

tr -c -d ’0123456789abcdefghijklmnopqrstuvwxyz’ </dev/urandom| dd bs=32 count=1 2>/dev/null;echo

1zpz5ztl1w5hnqhx8969thxab68us5og

Nombre y dirección de correo del administrador de este simpleSAMLphp:

5.2. Instalación y configuración 30


’technicalcontact_name’ => ’Administrator’,’technicalcontact_email’ => ’[email protected]’,

Zona horaria:

’timezone’ => NULL,

Un valor de ejemplo para este parámetro es ‘Europe/Madrid’

Idioma predeterminado:

’language.default’ => ’en’,

Lo más habitual es poner el valor ‘es’ para que la interfaz de simpleSAMLphp salga en español.

Hay muchas más opciones de configuración pero estás son las más básicas y necesarias de modificar. Los comentariosen el fichero config.php explican bastante bien para qué sirve cada uno de los parámetros de configuración.

Configuración 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 (

’en’ => ’Example organization’,’es’ => ’Organizacion de ejemplo’,

),’OrganizationURL’ => array (

’en’ => ’http://sp.example.com’,’es’ => ’http://sp.example.com’,

),

),);

?>

A continuación se detallan los principales parámetros que hay que configurar:

host Nombre del host de esta máquina 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 (pública y privada) del certificado usado en el SP. Estos ficheros debenencontrarse en el directorio cert del directorio raíz de simpleSAMLphp a no ser que se haya cambiado esaubicación en el fichero config.php

redirect.sign TRUE Si la petición de autenticación, petición de log out y respuesta de log out enviadas desde este SPa cualquier IdP deben de estar firmadas. Por defecto False.

redirect.validate TRUE si la petición de autenticación, petición de logout o la respuesta de logout recibidas en esteSP deben de ser validadas. Por defecto False

assertion.encryption Este parámetro deben estar a TRUE si obligamos a que las aserciones recibidas en este SPprovenientes de cualquier IdP esten cifradas. Por defecto False.

5.2.3 Configuración 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 ficherosaml20-idp-remote.php. A continuación 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’ => ’MIICQTCCAaoCCQCOMxLGB244ZzANBgkqhkiG9w0BAQUFADBlMQswCQYDVQQGEwJFUzESMBAGA1UECBMJQW5kYWx1Y2lhMRAwDgYDVQQHEwdTZXZpbGxhMRYwFAYDVQQKEw1ZYWNvIFN

pc3RlbWFzMRgwFgYDVQQDEw9pZHAuZXhhbXBsZS5jb20wHhcNMTEwNDE4MDg1NDQ2WhcNMTYwNDE2MDg1NDQ2WjBlMQswCQYDVQQGEwJFUzESMBAGA1UECBMJQW5kYWx1Y2lhMRAwDgYDVQQHEwdTZXZpbGxhMRYwFAYDVQQKEw1ZYWNvIFNpc3RlbWFzMRgwFgYDVQQDEw9pZHAuZXhhbXBsZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAK9gW0M87vOu4zhYbzoSgahBggvVPhmKROi0ajlAfVQ1YPwjpDstkK19Dhi99diw+ipJ6q44AEanpc8x/h0f1r2FJfBlF1HYKA76vMe36/A05G6+lg7Si4tHIlEfEG1RsuxK5FE9cLOdPTa9haX8HhtRngcNXbFtvbyngJTvZt91AgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAYdYYFxKibC32nm4E9RZCVk74Xcx6LahnbDvCQCMUL+zNeWetfq6hSlvX2AVl9yY5D5+fnL1hfaukmcJNTDGU+R+80bIs9zXNPgyweSujcP54IVBH0qBSFJCmPdZc+0uasi4KClwOMjVIq3WpVvycA/sHl7kH1jYTtNea8rr1vSw=’,

’NameIDFormat’ => ’urn:oasis:names:tc:SAML:2.0:nameid-format:transient’,’OrganizationName’ =>

array (’en’ => ’Example organization’,’es’ => ’Organizacion de ejemplo’,

),’OrganizationDisplayName’ =>

array (’en’ => ’Example organization’,’es’ => ’Organizacion de ejemplo’,

),’OrganizationURL’ =>

array (’en’ => ’http://idp.example.com’,’es’ => ’http://idp.example.com’,

),);

?>

.. _sp_configuracion_apache:



5.2.4 Configuración de Apache

Se debe crear un fichero de configuración para el VirtualHost de sp.example.com.conf en el directorio/etc/httpd/conf.d/ con el siguiente contenido:

<VirtualHost *:80>ServerName sp.example.comDocumentRoot /var/demo-federation/sp/simplesamlphp/wwwSSLProxyEngine OnProxyPreserveHost OnAlias /simplesaml /var/demo-federation/sp/simplesamlphp/www<Location />

ProxyPass https://localhost</Location>

</VirtualHost>

<VirtualHost *:443>ServerName sp.example.comDocumentRoot /var/demo-federation/sp/simplesamlphp/wwwAlias /simplesaml /var/demo-federation/sp/simplesamlphp/wwwSSLEngine onSSLCertificateFile /etc/httpd/ssl/sp.example.com/crt/sp.example.com.crtSSLCertificateKeyFile /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 *:80NameVirtualHost *:443

Además es necesario crear los certificados (autogenerados) que se han especificado en la configuracion del VirtualHostpara https. Se deberán 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. Creación de la clave sin contraseña y con una encriptación 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 autenticación con los Proveedores de Identidad

En este punto ya es posible realizar una prueba de autenticación con alguno de los IdP registrados en los metadatosde este SP. Para ello hay que ir a la pestaña Autenticación de la interfaz web de simpleSAMLphp y pinchar



en el enlace Probar las fuentes para la autentificación ya configuradas. Después hay queseleccionar el nombre de la fuente en la que se ha configurado el SP. En el ejemplo anterior sería saml.

Si todo funciona correctamente, debería aparecer un listado de IdPs y tras seleccionar uno de ellos y autenticarsecorrectamente en él debería aparecer una pantalla con el los atributos que este IdP ha enviado de vuelta al SP.

5.3 Configuración 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 puedencolocar dentro de dos parámetros:

En ‘authproc.idp’, lo cual hará que se ejecuten los filtros en la parte IdP para todas las entidades alojadas.

En ‘authproc.sp’, lo cual hará que se ejecuten los filtros en la parte SP para todas las entidades alojadas.

Los siguientes filtros se ejecutan de manera local y se definen en la array ‘authproc’:

En un SP:

En config/authsources.php, lo cual afectará al propio SP.

En saml20-idp-remote.php, lo cual afectará a un IdP remoto concreto.

En un IdP:

En saml20-idp-hosted.php, lo cual afectará al propio IdP.

En saml20-sp-remote.php, lo cual afectará a un SP remoto concreto.

Es importante en que orden se ejecutan los filtros ya que el resultado final puede ser diferente. Por ello es importanteobservar que todos los filtros definidos tengan el orden correcto que viene indicado por el número del índice del array(los números más bajos se ejeutan antes).

Existe documentación detallada sobre los filtros de atributos implementados en simpleSAMLphp.

Generación de atributos

ePTI: Implementado como filtro core:AttributeAlter

<?php

10 => array(

’class’ => ’core:AttributeAlter’,’subject’ => ’eduPersonTargetedID’,’pattern’ => ’/^(.*)$/’,’replacement’ => ’\1@<dominio>’

),

Comprobación de atributos

Filtro DNI: Implementado como filtro core:PHP

5.3. Configuración avanzada 34

http://simplesamlphp.org/docs/stable/simplesamlphp-authproc

http://simplesamlphp.org/docs/stable/core:authproc_attributealter

http://simplesamlphp.org/docs/stable/core:authproc_php


11 => array(’class’ => ’core:PHP’,’code’ => ’

if(isset($attributes["schacPersonalUniqueID"])) {foreach($attributes["schacPersonalUniqueID"] as $i => $personaluniqueid) {$regex = "/urn:mace:terena.org:schac:personalUniqueID:es:(.*):([0-9]{8})$/";if(preg_match($regex, $personaluniqueid, $values)) {$dni = $values[2];$letraNif= substr("TRWAGMYFPDXBNJZSQVHLCKE",$dni%23,1);$attributes["schacPersonalUniqueID"][$i] .= $letraNif;

}}

}’,

),

Eliminación de atributos

Filtro contraseña: Implementado como filtro core:AttributeAdd

12 => array(’class’ => ’core:AttributeAdd’,’%replace’,’userPassword’ => ’’,

),

Fitro limitador de atributos (sólo deja pasar los atributos aquí definidos): Implementado comocore: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’,

),


http://simplesamlphp.org/docs/stable/core:authproc_attributeadd

http://simplesamlphp.org/docs/stable/core:authproc_attributelimit


Ejemplo de creación de datos con core:PHP

Creación de datos de un usuario para realizar tests

60 => array(’class’ => ’core:PHP’,’code’ => ’

if(isset($attributes["eduPersonPrincipalName"]) &&strpos($attributes["eduPersonPrincipalName"][0], "confiatest@") !== false) {

$scope_university = "university.es";

$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:DNI:0000000T");

$attributes["schacUserStatus"] = array();$base_course = "urn:mace:terena.org:schac:userStatus:es:campusandaluzvirtual.es:";$attributes["schacUserStatus"][] = $base_course."98705999:2009-10:student:active";$attributes["schacUserStatus"][] = $base_course."98706999:2009-10:student:active";$attributes["schacUserStatus"][] = $base_course."98708999:2009-10:student:active";$attributes["schacUserStatus"][] = $base_course."98711999:2009-10:student:active";$attributes["schacUserStatus"][] = $base_course."98717999:2009-10:student:active";$attributes["schacUserStatus"][] = $base_course."98748999:2009-10:student:active";$attributes["schacUserStatus"][] = $base_course."98749999:2009-10:student:active";$attributes["schacUserStatus"][] = $base_course."98750999:2009-10:student:active";$attributes["schacUserStatus"][] = $base_course."98758999:2009-10:student:active";$attributes["schacUserStatus"][] = $base_course."98763999:2009-10:student:active";$attributes["schacUserStatus"][] = $base_course."99999999:2009-10:student:active";

}’,

),

AttributeValueFilter

El filtro AttributeValueFilter elimina determinados valores de los atributos basándose en patrones definidos.

Parámetros:

class: La clase del filtro, que es siempre: ‘coursefilter:CourseFilter’.

attributename: El nombre del campo de los atributos que queremos filtrar

spmapping: Contiene el mapeo entity_id <–> patrón de busqueda (y opcionalmente el valor a remplazar)

Ejemplo


https://forja.rediris.es/plugins/scmsvn/viewcvs.php/attributevaluefilter/trunk/?root=confia


<?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 nodosde un cluster al no necesitar de un almacenamiento persistente como una base de datos relacional. El “nodo bridge”que generalmente alberga más funcionalidad que los nodos periféricos (consentimiento, descubrimiento, validación,estadísticas, monitorización, gestión de metadatos) si que requerirá de un poco más de planificación para ponerlo enalta disponibilidad.

En los IdPs y SPs lo único que es importante compartir entre los nodos de SimpleSAMLPHP es la sesión de losusuarios. En este sentido es muy cómodo utilizar el soporte para Memcached disponible en SimpleSAMLphp paraque las sesiones entre varias instancias se compartan.

Otra alternativa menos recomendable, es que las sesiones esten almacenadas en una instancia diferente a las instanciasque se quieren poner en alta disponibilidad, por ejemplo en una base de datos. Para lo cual habría que configurar queel manejador de sesiones de simpleSAMLphp sea del tipo database.

Y por ultimo nos quedaría montar un sistema de ficheros compartido entre las diferentes instancas y que el manejadorde sesiones sea del tipo files.

La ventaja de utilizar memcache es que es un sistema robusto con el que conseguiremos tener un sistema de failoverde las sesiones. A continuación explicamos como se configuraría.

En SimpleSAMLPHP la configuración de los servidores Memcached se realiza por grupos. Cada elemento deinformación se almacena en todos los grupos por motivos de redundancia. Cada grupo está compuesto por variosservidores Memcached pero cada elemento de información se almacena en uno sólo de ellos. En este caso el tenervarios servidores se hace para conseguir un mayor rendimiento.

Lo más importante de todo es que SimpleSAMLPHP se encarga de gestionar todo esto de forma automática. Lo únicoque hay que decirle es las direcciones de los servidores Memcached.

Instalación 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" # 512MBOPTIONS=""

A continuación añadimos el servicio de memcache en el arranque del sistema y lo iniciamos:

chkconfig memcached onservice 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

Configuración de memcached en simpleSAMLphp

Para conseguir la configuración mostrada en la siguiente figura



tendríamos que añadir esta información al fichero config/config.php de SimpleSAMLPHP

’store.type’ => ’memcache’,

’memcache_store.servers’ => array(array(array(’hostname’ => ’1A’),array(’hostname’ => ’1B’),array(’hostname’ => ’1C’),

),array(array(’hostname’ => ’2A’),array(’hostname’ => ’2B’),array(’hostname’ => ’2C’),

),array(array(’hostname’ => ’3A’),array(’hostname’ => ’3B’),array(’hostname’ => ’3C’),

),),



Cada grupo de servidores es un array de servidores. Cada servidor es un array con las siguientes claves:

hostname. Nombre del servidor o dirección IP del servidor Memcache. Es la única opción obligatoria.

port. Número del puerto del servidor Memcache. Por defecto es 11211.

weight. Peso de este servidor dentro de su grupo. Influye en la probabilidad de que se elija este servidor en latarea de balanceo de carga interna que se realiza para guardar cada sesión.

timeout. Tiempo que se espera a que el servidor responda. Por defecto es 3 segundos.

Con esta configuración se podrían perder los tres servidores del grupo 1, 2 ó 3 sin que se perdiera ninguno dato desesión. Si se pierden los tres servidores etiquetados como A, B o C entonces sí habría perdida de información.


CAPÍTULO

SIX

DOMESTICACIÓN DE APLICACIONESCON SIMPLESAMLPHP

En el apartado anterior hemos visto como Desplegar un SP con SimpleSAMLphp En este apartado veremos como sefederara una aplicación php haciendo uso de esa instancia SP.

Básicamente la aplicación php a la que llamaremos a partir de ahora “aplicación local” cargará las librerías de la APIde simpleSAMLphp para iniciar el proceso de login, obtener los atributos del usuario, cerrar sesión, etc.

6.1 Repaso de la API de simpleSAMLphp

Existe documentación sobre como utilizar la librería de simpleSAMLphp desde una aplicación php

En resumen las funciones a utilizar son:

Inicialización 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 Autenticación, autorización y provisionamiento

A la hora de “domesticar una aplicación” lo podemos hacer con mayor o menor profundidad.

41

http://simplesamlphp.org/docs/stable/simplesamlphp-sp-api


6.2.1 Domesticación básica

La domesticación básica consistiría en añadir soporte a la aplicación local para permitir autenticar usuarios que yaexistieran en la aplicación local a través de un IdP haciendo uso del protocolo SAML, con lo que se conseguiría a lavez la funcionalidad del SSO.

Adicionalmente al SSO podría implementarse o no la funcionalidad de SLO (Single Log Out) que podría a su vezcohabitar o no con el logout local de la aplicación (Ojo con la usabilidad).

6.2.2 Domesticación básica + provisión

La domesticación media consistiría en añadir soporte de SSO y de provisión automática del usuario. Seimplementaría la lógica necesaria para que con los datos que llegan en la aserción SAML fuera posiblecrear/modificar/desactivar/eliminar una cuenta de usuario.

6.2.3 Domesticación media

En este escenario además de autenticación y provisionamiento se implementa toda la lógica necesaria para que laautorización en la aplicación a domesticar dependa de los atributos que le llegan de la aserción SAML. Aquí entraríatodo el tema de manejo de roles, permisos y grupos.

6.2.4 Domesticación avanzada

Es la más compleja. A la autenticación, autorización y provisionamiento just-in-time se le añadiría la capacidad deque cuando un dato fuera modificado en el IdP, automáticamente se modificara en la aplicación local haciendo uso delprotocolo SAML.

Podemos ver aqui varios ejemplos: * Provision asíncrona por lotes * Provisión asíncrona de un usuario en variasaplicaciones

El código está dispible en github: Asynchronous-provisioning based on simpleSAMLphp

6.3 Ejemplo de aplicación federada

Tenemos una aplicación example_php con la siguiente estructura:

-config.php Que contiene los parametros de configuración SAML-index.php Que es la pantalla principal de la aplicación-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 imágenes

6.3.1 Fichero de configuración [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 aplicación federada 42

http://www.youtube.com/watch?v=jj3-zJ8HXFE&feature=relmfu

http://www.youtube.com/watch?v=sKZlheDoLjw&feature=relmfu

http://www.youtube.com/watch?v=sKZlheDoLjw&feature=relmfu

https://github.com/Yaco-Sistemas/asynchronous-provisioning


$source = ’example-php’; # Fuente de autenticación definida en el authsources del SP

?>

Definimos donde se encuentra el archivo que carga las librerías de simpleSAMLphp Cargamos la librería Definimosla url base de nuestra aplicación Definimos la fuente de autenticación SAML que queremos utilizar y que tenemosdefinida en el config/authsources.php del SP simpleSAMLphp.

6.3.2 Fichero principal [index.php]

<html><head><title>Aplicación PHP de ejemplo federada usando simpleSAMLphp</title><link href="resources/css/bootstrap.min.css" rel="stylesheet" media="screen"></head><body>

<?phprequire_once(’config.php’);

$as = new SimpleSAML_Auth_Simple($source); # Se pasa como parametro la fuente de autenticación

echo ’<h3>Aplicación 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 sesión</a></p>’;}

?>

</body></html>

En esta vista si el usuario no se ha autenticado aún, le ofrecemos el enlace para hacerlo, a la vista login.php. En casode que ya se haya autenticado, le mostramos sus atributos si se ha recibido alguno y le damos opción a que cierre lasesión.

6.3. Ejemplo de aplicación federada 43


En el código vemos que primero cargamos el fichero de configuración para disponer de las variables alli definidas.Luego instanciamos la clase de la fuente simpleSAMLphp pasandole como parámetro la fuente que queremos. Luegocomprobamos si el usuario está o no autenticado con la función isAuthenticated() y en caso de que lo estéobtenemos sus datos con la función getAttributes().

6.3.3 Fichero para inicio de sesión [login.php]


$as = new SimpleSAML_Auth_Simple($source); # Se pasa como parametro la fuente de autenticación

$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 sesión [logout.php]


$as = new SimpleSAML_Auth_Simple($source); # Se pasa como parametro la fuente de autenticación definida en el authsources del SP.if ($as->isAuthenticated()) {

$as->logout($aplication_base_url . ’index.php’); # Se puede pasar como parametro a donde redireccionar tras el logout}else {

header(’Location: ’.$aplication_base_url . ’index.php’); # Si no estaba autenticado vuelvo a la pantalla principal}

?>

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 ejecutaría el headerLocation, 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 aplicación en el apache, lo haremos bajo HTTPs por lo que lo meteremos enel 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 aplicación

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 aplicación 44


¿Está la aplicación preparada para trabajar sin la necesidad de que un usuario no posea password?

Analizar el Workflow de creación de una cuenta de usuario. También el de acceso del usuario y el termino de lasesión.

¿Posee panel de administración para poder configurar parametros vía web? ¿Posee fichero de configuración?

¿Existe una API de autenticación? ¿Existén plugins de autenticación o toda la lógica de autenticación se realizaen un mismo fichero?

Ver como maneja las sesiones

Analizar la vista de login y ver como integrar la autenticación SAML

6.5 Análisis 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-federación:

Existe panel de administración.

Posee el concepto de plugin de autenticación 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 lasfunciones de autenticación.

Existe una plantilla para el formulario de login templates/modules/mod-login_box.tpl y hay unfichero 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 parámetros SAML identificamos los ficheros necesarios:

lib/prefs/auth.php En el que creamos un nuevo tipo de autenticación

lib/prefs/ssp.php En el que definimos los parámetros que hay que configurar

En este commit se puede apreciar los cambios que fueron necesarios realizar para dar soporte SAML a dichaaplicación:

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 queahora es mucho más: Reproductor/Visualizador/Gestor de calendario/etc.



Posee el concepto de plugin de autenticación y en general, cada componente (lo llaman app) que se integralo hace en forma de plugin. Además cada app debe de cumplir una estructura. Y todas las aplicaciones seencuentran en la carpeta apps. No hay una clase base de autenticación.

Posee una clase base de usuario que puede ser extendida

Al igual que en el caso de Tiki Wiki, las funciones relacionadas con la autenticación forman parte de la

Posee una serie de hooks que fueron utilizados para añadir el soporte SAML

6.5. Análisis de algunas “domesticaciones” 45

https://github.com/pitbulk/tiki-saml/commit/01df62e2613b4a7f2e4ea83b721f5043bfa0c447

http://owncloud.org/dev/apps/getting-started/

https://github.com/owncloud/core/blob/master/lib/user.php

http://owncloud.org/dev/apps/hooks/

https://github.com/pitbulk/apps/blob/master/user_saml/lib/hooks.php


Plugin disponible en: https://github.com/pitbulk/apps/tree/master/user_saml

6.5.3 Ejemplo Moodle



Posee el concepto de plugin de autenticación, existe una clase base definida lib/authlib.php. Todos los plugin deautenticación 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 interacción desde el plugin de autenticación

Permite multiples maneras de almacenar sesiones (fichero, base de datos, etc). Posee su propia librería paramanejar 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 Colisión de la sesión de la aplicación local con la sesión de SSP

En el la aplicación ejemplo example-php que mostramos anteriormente podemos ver que no existe una sesión local enla que se guarde si el usuario está logado o no, sino que unicamente se trabaja con la sesión SAML.

En el mundo real, las aplicaciones que vayamos a “domesticar” dispondrán de su propia sesión local en la que seguarde entre otras cosas, la información del usuario, información de acceso, etc. Tendremos que prevenir que la sesiónlocal y la sesión SAML no entren en conflicto y que la carga de librerías o las llamadas a funciones de la aplicaciónlocal o de la aplicación SAML no provocan efectos colaterales en las sesiones.

La forma rápida de prevenir posibles colisiones con las sesiones es la de hacer que el tipo de almacenamiento de lassesión local y de la sesión SAML sea siempre diferente. Esto se consigue configurando diferentes manejadores desesión. Existe files (por defecto), sqlite, memcached pero también es posible definir tu propio manejador.

El tipo de manejador que se utiliza en la aplicación local puede definirse en el propio código de la aplicación conla función session_set_save_handler pero si no se define se utilizará el que venga declarado en el php.ini en el valorsession.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 parámetro‘store.type’ del archivo de configuración config.php. Los valores posibles son sql, memcache o phpsession (loque estuviera definido en el php.ini).

La otra alternativa es estudiar muy bien el código de la aplicación local, ver que código hace falta añadir paraimplementar el soporte SAML, encontrar los puntos de conflicto y tratar de eliminarlos por ejemplo cambiando elorden en el que se cargan y llaman las librerías de uno y otro (siempre que esto no afecte a la lógica inicial y elresultado 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 aplicaciónque provoquen conflictos con las sesiones de simpleSAMLphp.

Fichero para cierre de sesión [logout.php]

6.6. Conflictos con las sesiones 46

https://github.com/pitbulk/apps/tree/master/user_saml

https://github.com/moodle/moodle/blob/master/lib/authlib.php

https://github.com/moodle/moodle/blob/master/lib/moodlelib.php

https://github.com/moodle/moodle/blob/master/login/index_form.html

https://github.com/moodle/moodle/blob/master/lib/sessionlib.php

https://forja.rediris.es/svn/confia/moodle/trunk/v2.2.3/auth/saml/

http://php.net/manual/en/class.sessionhandler.php

http://php.net/manual/en/class.sessionhandler.php

http://php.net/manual/en/session.customhandler.php

http://www.php.net/manual/en/function.session-set-save-handler.php

http://www.php.net/manual/en/session.configuration.php#ini.session.save-handler


Fichero principal [index.php]

<html><head><title>Aplicación 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>


$as = new SimpleSAML_Auth_Simple($source);

echo ’<h3>Aplicación PHP de ejemplo federada usando simpleSAMLphp con problemas con las sesiones</h3>’;

include_once(’applib.php’); ### Nueva linea que añadimos

if(!$as->isAuthenticated()) {echo ’<p><a class="btn" href="login.php">Login</a></p>’;

}else {

echo ’<h4>Atributos del usuario:</h4>’;



}else {



echo implode(’<br>’,$values);echo ’</td></tr>’;}

echo ’</table>’;}

echo ’<p><a class="btn" href="logout.php">Cerrar sesión</a></p>’;}

?>

</body></html>

Librerias de aplicación 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 sessionsession_start();

// delete previous possible valuessession_unset();

// add some values$_SESSION[’lang’] = ’es’;

}

?>

Colocamos ambos ficheros en el directorio www/apps/example_php-session-fail

Y servimos la aplicación en el apache, lo haremos bajo HTTPs por lo que lo meteremos en el mismo virtualhost dondetengamos desplegado el simpleSAMLphp:

Alias /example-php-session-fail /var/www/apps/example_php-session-fail

Y reiniciar el apache:


Si accedemos a la aplicación, veremos que la federación deja de funcionar debido a un conflicto con las sesiones

6.6.2 Error de lectura de la sesión de SSP

Otro problema relacionado con las sesiones ocurre cuando no tenemos acceso desde la aplicación final a la sesióndel 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 sesión que hay que tener en consideración:

’session.cookie.name’ => ’SimpleSAMLSessionID’, # Nombre para la cookie de sesión’session.cookie.path’ => ’/’, # Sirve para limitar las cookies para un subdirectorio especifico. Por ejemplo ’/simplesaml/’’session.cookie.domain’ => ’’, # Para especificar un dominio concreto para la sesión. Por ejemplo ’.example.com’’session.cookie.secure’ => FALSE, # TRUE si el usuario únicamente va a acceder vía HTTPs’enable.http_post’ => FALSE, # Activado, permite evitar que el navegador muestre un mensaje de error cuando pasemos de HTTP a HTTPs

# pero el IdP deberá ser accesible tanto vía HTTP como HTTPs’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 domesticación, la autenticación SAML es la única que queremos dejar habilitada para nuestros usuarios,¿Que pasa si la federación falla o si hemos configurado mal los parametros?.

Es siempre recomendable dejar una autenticación 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 autenticación SAML, a la hora decrear la cuenta no disponemos del password de dicho usuario y por tanto no puede almacenarse un valor válido enla aplicación local, por tanto ese usuario, a menos que exista la funcionalidad de “resetear contraseña” o que en elproceso de registro automático se le pida una clave, no podrá acceder a la aplicación a través de las autenticacionestradicionales de user/pass (base de datos, ldap, fichero de claves, AuthBasic) que hubiera habilitadas en la aplicación.

6.7.3 El problema de la duplicidad de cuentas

Es importante que si tenemos habilitadas en una aplicación diferentes fuentes de autenticación con la capacidad decrear automaticamente cuentas, todas ellas devuelvan el mismo valor para el identificador de usuario que se utiliza enla aplicación a “domesticar”. De lo contrario se estarían 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 elespacio de nombres, compatibilizar los valores, priorizar las fuentes de datos, etc

Si tenemos habilitadas en una aplicación diferentes fuentes de autenticación con la capacidad de crear/modificarautomaticamente cuentas de usuario podemos encontrarnos con conflictos graves como el que se describe acontinuación:

Imaginemos que permitimos el acceso a nuestra aplicación a través de Gmail y que tenemos la cuenta de gmail relacionada con la cuentade la aplicación a través del email. Si en el IdP tenemos almacenado otro valor para el atributo email, tras el acceso vía IdP por elprovisionamiento automatico el valor del email se actualizaría y dejaríamos de poder acceder a la aplicación a través de gmail.

O nos podemos encontrar en que fuentes menos fiables sobreescriban en la aplicación final valores que una fuente másfiable había registrado.

6.7. Algunos problemas a resolver a la hora de domesticar aplicaciones 49

CAPÍTULO

SEVEN

DOMESTICACIÓN DE APLICACIONESEN OTROS LENGUAJES DIFERENTES

A PHP

Cuando el lenguaje de la aplicación que queremos federar no es php no podemos realizar una federación nativa consimpleSAMLphp (SP en php).

La solución pasa por:

Recurrir a diferentes mecanismos de federación como la basada en webservice, la basada en el REMOTE_USERo en la basada en authmemcookie)

Utilizar un SP implementado en el lenguaje nativo de la aplicación: python (pySAML2), en java (OIOSAML,SprintSecurity), etc.

7.1 SimpleSAMLphp+AuthMemCookie

Cuando el software del SP y el software de la aplicación a federar son de diferentes lenguajes y no puede realizarseuna integración nativa puede optarse por está situación.

Consiste en que el SP almacene en el memcache datos del usuario que son leidos en el módulo Auth memCookie deApache que protege la aplicación a federar.

Existe una documentación sobre configuración de autenticación basada en authmemcookie disponible en simple-SAMLphp

En Debian existe el paquete libapache2-mod-auth-memcookie por lo que es muy fácil instalar el móduloauthmemcookie.

En CentOS no existe paquete y hay que compilar varias librerias obsoletas, que suelen dar problemas segúnlas versiones. En lugar del mod_authmemcookie recomendamos hacer uso de mod_perl y de la libreriaApache::Auth::AuthMemCookie que dan el mismo rendimiento.

A continuación vamos a explicar como se desplegaría y configuraría este modulo mod_perl, el Apache y elsimpleSAMLphp para que todo funcione:

Instalamos las librerias necesarias desde el repositorio:

yum install libevent memcached php-pecl-memcache python-memcachedyum install mod_perl perl-CPAN

Abrimos una shell perl:

50

http://authmemcookie.sourceforge.net/

http://authmemcookie.sourceforge.net/

http://simplesamlphp.org/docs/stable/simplesamlphp-advancedfeatures#section_5

http://packages.debian.org/search?keywords=libapache2-mod-auth-memcookie

http://pietercvdmlinux.blogspot.com.es/2012_07_01_archive.html

http://pietercvdmlinux.blogspot.com.es/2012_07_01_archive.html

http://search.cpan.org/~piers/Apache-Auth-AuthMemCookie-0.02/lib/Apache/Auth/AuthMemCookie.pm


perl -MCPAN -e shell

E instalamos el modulo:

install Apache::Auth::AuthMemCookie

Añadimos el servicio memcached para que esté siempre activo y lo activamos:

service memcached startchkconfig memcached on

Lo siguiente que hay que hacer es habilitar en simpleSAMLphp el uso de AuthMemCookie, para ello lo primero eseditar el archivo de configuración global de simpleSAMLphp config/config.php:

’enable.authmemcookie’ => true,

Lo siguiente es crear el fichero de configuración 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/authmemcookie’,

// 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 podríamos crear nuestra aplicación a federar que leyera los datos de las cabeceras que le envía el servidorApache

A continuación vamos a enseñar 2 ejemplos de aplicaciones federadas haciendo uso de ésta técnica.

Las alojaremos en una carpeta contenedora en /var/www/apps/authmemcookie/

7.1. SimpleSAMLphp+AuthMemCookie 51


En dicha carpeta vamos a colocar 2 archivos estáticos:

index.html: Para enlazar a cada una de las aplicaciones.

logout.html: Cuando las aplicaciones cierren la sesión, dirigiremos al usuario a ésta página.

Nota: Como el Apache va a proteger toda la carpeta que contiene el código delas aplicaciones federadas (va a requerir identificación), necesitamos queestos 2 ficheros estén en sitios desprotegidos para que puedan ser mostradosal usuario, por eso los hemos colocado en una instancia superior.

7.1.1 Ejemplo de como federar una aplicación PHP con esta técnica

Creamos un directorio contenedor que albergará el ejemplo de la aplicación 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 opción a cerrarsesión.

lib.php Librería auxiliar que lee los datos de la variable server y los devuelve con la misma estructura a comosueles devolverlos simpleSAMLphp

[index.php]

<html><head><title>Aplicación PHP de ejemplo federada usando authmemCookie</title><link href="//sp.cursosaml.org/example-php/resources/css/bootstrap.min.css" rel="stylesheet" media="screen"></head><body>

<h3>Aplicación 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 implode(’<br>’,$values);echo ’</td></tr>’;

}echo ’</table>’;

}

?></table>



<p><a class="btn" href="https://sp.cursosaml.org/simplesaml/module.php/core/as_logout.php?AuthId=authmemcookie&ReturnTo=https://sp.cursosaml.org/example-authmemcookie/logout.html">Cerrar sesión</a>

</p>

</body></html>

[lib.php]

<?php

function get_attributes_from_apache() {$attributes = array();

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 aplicación y envíe los datos del usuario en la cabecera:

perlModule Apache::Auth::AuthMemCookiePerlAuthenHandler Apache::Auth::AuthMemCookie::authen_handlerPerlSetVar AuthMemCookie "AuthMemCookie"PerlSetVar AuthMemServers "127.0.0.1:11211"# if you want to debug set to 1PerlSetVar AuthMemDebug 0# use headers instead of ENV varsPerlSetVar AuthMemAttrsInHeaders 1



Alias /example-authmemcookie /var/www/apps/authmemcookieAlias /example-authmemcookie-php /var/www/apps/authmemcookie/example_php

<Directory /var/www/apps/authmemcookie/example_php>AuthType CookieAuthName "Auth Memcookie - PHP"Require valid-userErrorDocument 401 "/simplesaml/authmemcookie.php"

</Directory>

Nota: Si habilitamos esta protección y no tenemos el servidor memcached corriendo, al tratar de acceder al recursoentraremos en un blucle de redirecciones infinito.

Y reiniciamos el apache


Federando aplicaciones php remotas

Si tuvieramos la instancia de simpleSAMLphp en una máquina y quisieramos federar un software php que está en otramáquina, podríamos hacerlo haciendo uso de Authmemcookie.

Lo que haríamos es configurar un servidor de memcached (accesible desde la otra máquina) en la máquina que tuvierael simpleSAMLphp.

Se crea un archivo php que esté protegido por el apache y cuyo contenido sea redirigir a la aplicación que tenemos enla otra máquina.

En otra máquina, en la aplicación php a federar lo que deberemos de hacer es leer los datos del usuario del servidormemcache, conociendo el cookiename y el sessionID. De no existir reenviaríamos a la anterior vista protegida.

7.1.2 Ejemplo de como federar una aplicación Python con esta técnica

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 aún 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.py:

from os import path # Añadimos esto en la cabecera del ficheroBASEDIR = path.dirname(path.abspath(__file__))

DATABASES = {’default’: {

’ENGINE’: ’django.db.backends.sqlite3’, # Add ’postgresql_psycopg2’, ’postgresql’, ’mysql’, ’sqlite3’ or ’oracle’.’NAME’: ’/var/www/apps/authmemcookie/example_django/example_django/example_django.sql3’, # Or path to database file if using sqlite3.’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 pathBASEDIR = path.dirname(path.abspath(__file__))

TEMPLATE_DIRS = (path.join(BASEDIR, ’templates’),

)

Creamos el fichero que contendrá la vista en la que mostremos los atributos que hemos obtenido del servidor Apachewww/apps/authmemcookie/example_django/example_django/views.py:

import string

from django.shortcuts import render_to_responsefrom django.template import RequestContext

def echo_attributes(request,template=’echo_attributes.html’):

"""Example view that echo the attributes of an user serverby 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>Aplicación Python/Django de ejemplo federada usando AuthMemCookie</title><link href="https://sp.cursosaml.org/example-php/resources/css/bootstrap.min.css" rel="stylesheet" media="screen"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>

</head><body>



<h3>Aplicación Python/Django de ejemplo federada usando AuthMemCookie</h3>

<h4>Atributos del usuario:</h4><table class="table table-bordered table-striped">{% 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=authmemcookie&ReturnTo=https://sp.cursosaml.org/example-authmemcookie/logout.html">Cerrar sesión</a></p></body>

</html>

Configuramos las urls de la demo en /var/www/apps/authmemcookie/example_django/example_django/urls.pyincluyendole 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 añadimos la siguiente entrada en el apache, como la queremos servir por HTTPs lo colocamos en el mismoVirtualhost que ya utilizamos anteriormente para servir el simpleSAMLphp

WSGIScriptAlias /example-authmemcookie-django /var/www/apps/authmemcookie/example_django/example_django/wsgi.py

Y tenemos que colocar fuera del virtualhost la siguiente instrucción para que se utilice el PythonPath adecuado:

WSGIPythonPath /var/www/apps/authmemcookie/example_django

(Si ya tenemos otro habría que poner–> WSGIPythonPath <path_1>:<path_2>

Y proteger la vista:

<Location /example-authmemcookie-django>AuthType CookieAuthName "Auth Memcookie - Python"Require valid-userErrorDocument 401 "/simplesaml/authmemcookie.php"

</Location>



7.2 ShibbolethSP+REMOTE USER

Cuando el software del SP y el software de la aplicación a federar son de diferentes lenguajes y no puede realizarseuna integración nativa puede optarse por está opción.

7.2. ShibbolethSP+REMOTE USER 56


Se basa en que el Apache proteja la aplicación a federar con la autenticación shibboleth (Shibboleth SP) habilitandoel mod_shib. El Apache le hara llegar los datos del usuario a la aplicación que queremos federar. El Apache utilizaralas cabeceras HTTP para hacerle llegar los datos del usuario a la aplicación que queremos federar.

Existe una documentación sobre instalación y configuración de autenticación shibboleth basada en RemoteUser.

Lo primero que hace falta es instalar shibboleth y sus dependencias por lo que tenemos que añadir el repositorio alyum.

cd /etc/yum.repos.dwget http://download.opensuse.org/repositories/security://shibboleth/CentOS_CentOS-6/security:shibboleth.repoyum updateyum install shibboleth

Tras esto ya tendremos todo lo necesario en el sistema.

Los archivos de configuración de shibboleth se encuentran en /etc/shibboleth

Lo primero que haremos será sustitutir los ficheros que contienen los certificados por unos válidos, estas son las rutasdonde 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/shibboleth/idp.xml

Lo siguiente que hay que hacer es editar el archivo de configuración de shibboleth, shibboleth2.xml en el quese configuran parámetros globales pero también los parámetros de cada SP que se quiera desplegar. Veamos ahora losparámetros 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 producción deberemos de añadirle un acl=”127.0.0.1” si queremos que sólo se pueda consultarel estado desde la máquina local

Contacto:


https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPLinuxInstall

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPConfiguration

<Errors supportContact="[email protected]"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 elarchivo /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:basic" id="eduPersonPrincipalName"/><Attribute name="eduPersonAffiliation" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" id="eduPersonAffiliation"/><Attribute name="displayName" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" id="displayName"/><Attribute name="givenName" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" id="givenName"/><Attribute name="schacSn1" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" id="schacSn1"/><Attribute name="schacSn2" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" id="schacSn2"/><Attribute name="irisMailMainAddress" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" id="irisMailMainAddress"/><Attribute name="schacUserStatus" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" id="schacUserStatus"/>

Cuando lo tengamos todo listo habra que iniciar el demonio de shibboleth y añadirlo para que se inicie en el arranque.

service shibd startchkconfig shibd on

Añadimos 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 nuestroservicio 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 están enhttps://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 aplicación PHP con esta técnica

Creamos un directorio contenedor que albergará el ejemplo de la aplicación 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 opción a cerrarsesión.

lib.php Librería auxiliar que lee los datos de la variable server y los devuelve con la misma estructura a comosueles devolverlos simpleSAMLphp

[index.php]

<html><head><title>Aplicación PHP de ejemplo federada usando Shibboleth</title><link href="//sp.cursosaml.org/example-php/resources/css/bootstrap.min.css" rel="stylesheet" media="screen"></head><body>

<h3>Aplicación PHP de ejemplo federada usando Shibboleth</h3>

<h4>Atributos del usuario:</h4>

<table class="table table-bordered table-striped"><?php

include_once("lib.php");$attributes = get_attributes_from_remote_user();


}else {


foreach($attributes as $key => $values) {echo ’<tr><td>’ . $key . ’</td><td>’;echo implode(’<br>’,$values);echo ’</td></tr>’;

}echo ’</table>’;


https://shib.cursosaml.org/Shibboleth.sso/Status

https://shib.cursosaml.org/Shibboleth.sso/Metadata


}

?></table>

<p><a class="btn" href="https://shib.cursosaml.org/Shibboleth.sso/Logout">Cerrar sesión</a></p>

</body></html>

[lib.php]

<?php

function get_attributes_from_remote_user() {$attributes = array();

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 aplicación y envíe los datos del usuario en la cabecera:

Alias /php /var/www/apps/shibboleth/example_php

<Location /php>AuthType shibbolethShibRequestSetting applicationId defaultShibRequestSetting requireSession 1require valid-user

</Location>

Y lo reiniciamos:


7.2.2 Ejemplo de como federar una aplicación Python/Django con esta técnica

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 aún 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/settings.py:



’ENGINE’: ’django.db.backends.sqlite3’, # Add ’postgresql_psycopg2’, ’postgresql’, ’mysql’, ’sqlite3’ or ’oracle’.’NAME’: ’/var/www/apps/shibboleth/example_django/example_django_shib/example_django_shib.sql3’, # Or path to database file if using sqlite3.’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.

}}



)

Creamos el fichero que contendrá la vista en la que mostremos los atributos que hemos obtenido del servidor Apachewww/apps/shibboleth/example_django_shib/example_django_shib/views.py:

import string

from django.shortcuts import render_to_responsefrom django.template import RequestContext



def echo_attributes(request,template=’echo_attributes.html’):

"""Example view that echo the attributes of an user serverby 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.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>Aplicación Python/Django de ejemplo federada usando Shibboleth</title><link href="https://sp.cursosaml.org/example-php/resources/css/bootstrap.min.css" rel="stylesheet" media="screen"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>

</head><body>

<h3>Aplicación Python/Django de ejemplo federada usando Shibboleth</h3>

<h4>Atributos del usuario:</h4><table class="table table-bordered table-striped">{% 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 sesión</a></p></body>

</html>

Configuramos las urls de la demo en /var/www/apps/shibboleth/example_django_shib/example_django_shib/urls.pyincluyendole la url de la vista que habiamos creado



urlpatterns = patterns((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 habría que poner–> WSGIPythonPath <path_1>:<path_2>

Y protegemos la vista:

<Location /django>AuthType shibbolethShibRequestSetting applicationId defaultShibRequestSetting requireSession 1require valid-user

</Location>

7.3 Aplicaciones Python/Django (PySAML2/djangosaml2)

7.3.1 El entorno

Imaginemos que queremos desplegar una aplicación django en el sistema a la que queremos añadir soporte SAML.

Lo primero que haremos será comprobar que disponemos en el sistema de python. Posteriormente instalamos unautilidad que facilita la instalación de paquetes de python

yum install python-setuptools

A continuación instalamos el framework django si no lo estuviera.

easy_install django

Instalamos el modulo mod_wsgi para desplegar la aplicación 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 repositorioepel

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

http://dl.fedoraproject.org/pub/epel

http://dl.fedoraproject.org/pub/epel


yum install http://dl.fedoraproject.org/pub/epel/6/x86_64/xmlsec1-1.2.16-2.el6.x86_64.rpmyum 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 configuración de una aplicación 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:



’ENGINE’: ’django.db.backends.sqlite3’, # Add ’postgresql_psycopg2’, ’postgresql’, ’mysql’, ’sqlite3’ or ’oracle’.’NAME’: ’/var/www/apps/django_saml2_demo/django_saml2_demo/djangosaml2demo.sql3’, # Or path to database file if using sqlite3.’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.

}}

TEMPLATE_LOADERS = (’django.template.loaders.filesystem.Loader’,’django.template.loaders.app_directories.Loader’,’django.template.loaders.eggs.Loader’, # Debe de estar descomentado!

)



)

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 logoutSESSION_EXPIRE_AT_BROWSER_CLOSE = True # parametro para definir si queremos que la sesion expire al cerrar el navegador

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.pyincluyendole las urls de la librería djangosaml2

urlpatterns = patterns(

# ...

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

(r’^saml2/’, include(’djangosaml2.urls’)),

# ...)

Creamos el fichero pysaml2_settings.py con la configuración:

from os import pathimport saml2

BASEDIR = path.dirname(path.abspath(__file__))

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/SSOService.php’,

},’single_logout_service’: {

saml2.BINDING_HTTP_REDIRECT: ’https:/idp.cursosaml.org/simplesaml/saml2/idp/SingleLogoutService.php’,},

},},

},# 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’: ’[email protected]’,’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_demomkdir saml2cd saml2openssl genrsa -out djangosaml2demo.pem 1024openssl req -new -key djangosaml2demo.pem -out djangosaml2demo.csropenssl x509 -req -days 1825 -in djangosaml2.csr -signkey djangosaml2demo.pem -out djangosaml2demo.crt

Y copiamos los metadatos del idp accesibles en https://idp.cursosaml.org/simplesaml/saml2/idp/metadata.php?output=xhtmldentro 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/ oen 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 Instalación 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

http://bazaar.launchpad.net/~pysaml2maint/pysaml2/main/files/head:/src/saml2/attributemaps/


yum install java-1.7.0-openjdk java-1.7.0-openjdk-devel tomcat6 tomcat6-admin-webapps tomcat6-webappsservice

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 añadimos 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 añadiendole 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.zipunzip apache-maven-3.0.4-bin.zipmv apache-maven-3.0.4 /usr/local/apache-mavenexport M2_HOME=/usr/local/apache-mavenexport M2=/usr/local/apache-maven/binexport 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/jreJAVA_OPTS="-Xmx768m -XX:PermSize=256m -XX:MaxPermSize=512m"

M2_HOME=/usr/local/apache-mavenM2=/usr/local/apache-maven/binMAVEN_OPTS="-Xms256m -Xmx512m"

PATH=/usr/local/bin:/bin:/root/bin:/usr/bin:/usr/local/apache-maven/bin:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/bin

7.4.2 Instalación y configuración de la aplicación de ejemplo SpringSecurity

Vamos a analizar el ejemplo de federación usando SpringSecutiry. Para ello descargamos el repositorio git la extensiónSAML de Spring Security

yum install gitcd /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 aplicación de ejemplo ejecutando en el directorio saml2-sample

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


https://github.com/SpringSource/spring-security-saml

https://github.com/SpringSource/spring-security-saml


La aplicación estará accesible en http://sp.cursosaml.org:8080/spring-security-saml2-samplepero aún 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/generate:

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 pestaña 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 también que actualizar el fichero de configuración de la aplicación spring con la config-uración 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"/>


http://sp.cursosaml.org:8080/spring-security-saml2-sample/saml/metadata/alias/springsecurity

http://sp.cursosaml.org:8080/spring-security-saml2-sample

<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>

<property name="hostedSPName" value="springsecurity"/><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/apps/spring-security-saml/saml2-sample/src/main/resources/security/idp.xml

Redespliegue la aplicación 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-samplemvn tomcat:redeploy

Y ya podrá probar el login contra el IdP elegido accediendo a http://sp.cursosaml.org:8080/spring-security-saml2-sample

7.4.3 OIOSAML.JAVA

OIOSAML.JAVA es otra libreria que podemos utilizar para añadir soporte SAML a nuestras aplicaciones Java.

Podemos descargarnos la ultima versión 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 información de como instalarlo yconfigurarlo

7.4.4 Otras librerias JAVA

LASSO Java SP


http://digitaliser.dk/resource/2298008/artefact/oiosaml.java-9918.zip

http://digitaliser.dk/resource/2298008/artefact/oiosaml.java-9918.zip

https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/index.html


http://lasso.entrouvert.org/documentation/writing-a-java-sp.html


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

http://digitaliser.dk/resource/2318997

http://www.componentspace.com/saml

http://www.atp-inc.net/saml.net/

http://rubygems.org/gems/saml2ruby

http://rubygems.org/gems/saml-sp

https://github.com/PracticallyGreen/omniauth-saml

http://rubygems.org/gems/ruby-saml

http://www.zxid.org/html/zxid-perl.html

http://search.cpan.org/~chrisa/Net-SAML2-0.15/lib/Net/SAML2.pm

http://lasso.entrouvert.org/documentation/writing-a-c-sp.html

https://wiki.shibboleth.net/confluence/display/OpenSAML/Home

CAPÍTULO

EIGHT

REFERENCIAS

8.1 Especificación 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) (código_ssp)

Shibboleth (doc_shib) (código_shib)

pySAML2) (doc_pysaml2)

djangosaml2

Lasso

OpenSAML

OIOSAML .NET .JAVA

ESOE

ZXID

8.3 Documentación de interés sobre “domesticaciones de aplica-ciones”

SimpleSAMLphp SP API

Authmemcookie + simpleSAMLphp

mod_perl + simpleSAMLphp

72

http://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf

http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf

http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf

http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf

http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf

http://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf

http://simplesamlphp.org/

http://simplesamlphp.org/docs/

http://code.google.com/p/simplesamlphp/source/checkout

http://shibboleth.net/

https://wiki.shibboleth.net/confluence/display/SHIB2/Home

http://shibboleth.internet2.edu/downloads/shibboleth/

http://pypi.python.org/pypi/pysaml2/

http://packages.python.org/pysaml2/

http://pypi.python.org/pypi/djangosaml2/

http://lasso.entrouvert.org/

https://wiki.shibboleth.net/confluence/display/OpenSAML/Home

http://digitaliser.dk/resource/2318997


http://www.esoeproject.org/

http://www.zxid.org

http://simplesamlphp.org/docs/stable/simplesamlphp-advancedfeatures#section_5

https://www.assembla.com/spaces/liftweb/wiki/SSO_and_SAML_with_Lift_howto/print


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 Gestión centralizada de metadatos

Metadata administraition as selfservice

Documentación de Janus

SAML Metadata Management for eduID.cz

Proyecto PEER

Basic Metadata Aggregation Profile

Otras referencias

Gestión de metadatos en SimpleSAMLphp

8.5 Otros conceptos avanzados

Filtros en simpleSAMLphp

8.4. Gestión centralizada de metadatos 73

https://spaces.internet2.edu/display/ShibInstallFest/Shibboleth+Workshop+Series+-+Linux+Service+Provider+%28CentOS+6.2%29

https://wiki.surfnetlabs.nl/display/surfconextdev/My+First+SP+-+Shibboleth

https://wiki.surfnetlabs.nl/display/surfconextdev/My+First+SP+-+.NET

http://blog.wayf.dk/?p=8


http://www.ces.net/events/2008/conference/prog/paper/23.pdf

https://spaces.internet2.edu/display/PEER/Home

http://dl.dropbox.com/u/2381403/SAML/BasicMetadataAggregationProfile-0.4.pdf

https://rnd.feide.no/2010/07/13/working_with_metadata/

http://simplesamlphp.org/docs/trunk/simplesamlphp-automated_metadata

http://simplesamlphp.org/docs/trunk/simplesamlphp-authproc

CAPÍTULO

NINE

ANEXO A. CONCEPTOS SOBREFEDERACIÓN DE IDENTIDADES

9.1 Qué es una federación de identidades

Una federación de identidades es un grupo o conjunto de entidades que comparten la técnología, estandares y casosde uso que permiten transmitir información de identidad de un usuario de manera segura facilitando la autenticación yautorización entre diferentes dominios.

En una federación de identidades se establece un círculo de confianza que permite que un usuario autenticado en unorganismo de la federación acceda a recursos de otro organismo de la misma federación. La idetificación se realiza enlos Proveedores de Identidad (abrev. ingl. IdP). El Proveedor de Servicio (abrev. ingl. SP) al que accede el usuarioconfía en los datos del usuario que le son suministrados por el IdP y en función de los mismos autoriza al usuario ahacer uso de los recursos.

En una federación de identidades los servicios perciben al usuario como una entidad homogenea y no como un conjuntode porciones de información sin relación entre ellas. Se denomina identificador opaco al identificador único quemantiene la privacidad del usuario y que representa la asociación entre la cuenta del usuario en un Proveedor deServicio y la que posee en el Proveedor de Identidad.

Figura 9.1: Esquema federación

Es tarea del operador de la federación de identidades:

74


Decidir y gestionar la integración de los miembros (tanto proveedores de identidad como de servicio) a lafederación.

Gestionar las políticas de liberación de atributos (ARPs) y velar porque estás se cumplan.

Definir los esquemas de datos que van a utilizar los diferentes miembros con el fin de homogeneizar atributos.

Actuar como intermediario e incluso poder gestionar el consentimiento de cesión de datos para servicio queaccede el usuario.

Velar por el correcto funcionamiento de la federación.

Gestionar la interoperabilidad con otras federaciones formando confederaciones de identidades.

9.2 Ventajas de la federación de identidades

Ventajas para los usuarios:

Identidad única para todos los servicios federados: Una única clave que le da acceso a todos los servicios.

Single Sign ON (SSO) Web. Una vez identificado el usuario en un sistema federado tendrá acceso al resto deservicios hasta que se finalice la sesión (log out) sin tener que volver a introducir sus credenciales de acceso.

Single Log Out (SLO). Al cerrar sesión de una aplicación se cerrará la sesión de todas las aplicacionesfederadas, mejorando así la seguridad del sistema.

Fiable, fácil y rápido. Al usuario se le presentá un único sistema de autenticación que conoce.

Ventajas para administradores de sistemas:

Facilita los procedimientos. Se despliega un escenario controlado en el que los accesos estánmonitorizados y todos el procesos controlados.

Menor número de incidencias:

Al existir una clave única los administradores dejan de atender a incidencias relacionadas conpérdidas y reseteos de claves.

Los datos de los usuarios pasan a estar en un punto común verificados y actualizados por lo que sereducen las duplicidades de cuentas y los conflictos.

Mayor control de los datos del usuario. Mediante la definición de ARPs (Attribute ReleasePolicies) adecuadas el administrador puede decidir, dentro del conjunto de datos que posee de cadausuario, cuáles enviar a un servicio concreto.

Ventajas para las organizaciones:

Ahorro en costes. Se ha demostrado que su uso reduce considerablemente sus costes de mantenimiento.

Mayor interoperabilidad / productividad. Fácil integración con multitud de sistemas heterogéneos. latecnología SAML2 se erige como el futuro de los sistemas de federación de identidades. Un ejemplo son losexitodos sistemas de acceso unificado de Facebook o Google, que permiten acceder a todos sus servicios bajoel protocolo SAML2.

Reducción de riesgos de seguridad. Las comunicaciones que envían información del usuario siempre vancifradas incluso cuando se accede por protocolos no seguros como HTTP. La contraseña del usuario nuncaviaja entre los distintos nodos de la federación. Se utiliza tecnología PKI para todo este proceso de cifrado decomunicaciones.

9.2. Ventajas de la federación de identidades 75


9.3 Ejemplos de federaciones

En la actualidad podemos identificar muchas federaciones de identidad basadas en la tecnología SAML:

Europeas:

Españolas:

En Andalucía existe Confía que es una federación de identidades de las universidades andaluzas.

En España tenemos el Servicio de dentidad de SIR operado por REDIRIS

En Dinamarca tienen la federación de identidades WAYF operado por el WAYF-secretariat.

En Reino Unido tienen la JANET(UK) operada por JISC y EDINA

En Finlandia tienen HAKA operada por

En Holanda tienen la SURFfederatie operada por SURFnet

En Norugega tienen FEIDE operada por Uninett

En la República Checa tienen SWITCHaai operada por SWITCH

Existe una confederación de los paises nórdicos denominada Kalmar Union

Existe una federación para la educación superior y la investigación europea llamada Edugate

También a nivel europeo destacamos el proyecto STORK que trata de proveer una plataforma de interoperabili-dad de identidades.

9.3. Ejemplos de federaciones 76

http://confia.aupa.info/

http://www.rediris.es/sir/

http://www.rediris.es/

http://www.wayf.dk

http://www.ukfederation.org.uk/

http://www.jisc.ac.uk/

http://edina.ac.uk/

https://haka.funet.fi/shibboleth/help.php

http://www.surf.nl/en/oversurf/Pages/Introductie.aspx

http://www.feide.no/

http://www.uninett.no/

http://www.switch.ch/aai/index.html

http://www.switch.ch/

http://www.kalmar2.org/

http://www.edugate.ie/

https://www.eid-stork.eu/


No europeas:

En Australia tienen la AFF

En USA tienen la InCommon Federation

En Brasil tienen la federación CAFe

En Canada tienen la federación CAF-CANARIE

En China tienen federación CARSI

En Japón tienen la federación GakuNin

Se puede consultar más información sobre federaciones en una wiki de Terena.

9.4 Conceptos (IdP, SP, AA, WAYF, atributos, bindings)

IdP Proveedor de Identidad. Organización que provee la autenticación del usuario y devuelve los datos del usuarioque el SP requiere para autorizar su acceso al recurso o servicio.

SP Proveedor de Servicio. Cualquier organismo o institución registrado en la federación que provee acceso al usuariofinal a algún servicio y recurso basandose en una serie de atributos que satisfacen sus requerimientos de autorización.

WAYF Cuando un SP está conectado a varios proveedores de identidad surge la necesidad de que el usuario seleccioneen 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

http://www.aaf.edu.au/

http://www.incommonfederation.org/

http://www1.rnp.br/en/services/cafe.html

http://www.canarie.ca/en/caf-service/about

http://www.carsi.edu.cn/

https://www.gakunin.jp

https://refeds.terena.org/index.php/FederationsTable


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 lafederación (IdPs y SPs). Dichos metadatos deberán de estar actualizados periódicamente. Además opcionalmentepuede validar los metadatos, clasificarlos, validar los certificados de los metadatos o gestionar las ARPs.

Scoping Indica al IdP el ambito de la petición. De que SP surgió y con que contexto.

Binding Mapeo de una petición SAML o de una aserción de respuesta con un protocolo específico de transporte.(HTTP-Redirect, HTTP-POST, Artifact o SOAP)

Descubrimiento En terminos de federación se hace referencia al descubrimiento como la acción de obtener la lista deproveedores de identidad.

Metadatos Conjunto de datos que conforman la información necesaria para que una entidad se comunique con otraentidad de la federación. En el protocolo SAML distinguimos los metadatos de los IdPs y de los SPs.

Entity ID Dentro de los metadatos de una entidad se define el entity id como el identificador que unívocamente al SPo IdP. La última tendencia es la de utilizar como entity id la url en la que se publican los metadatos de dicha entidad.

ARP Política de liberación de atributos. Política que rige la distribución de los atributos del usuario a los diferentesSPs.

Atributo Parte sencilla de los datos de un usuario (como por ejemplo el nombre, apellido, email, etc). Pueden sergenerales o personales. Uno o la agrupación de varios atributos identifican univocamente al usuario.

Esquema de atributos Compendio de nombres de atributos estandarizado. Surge de la necesidad de definir un vocablocomún que defina un nombre para los diferentes atributos que forman parte de la información del usuario que van atransferirse entre los elementos de la federación de identidades.

Identificador opaco Identificador persistente que puede ser usado para conectar cuentas de usuario conservando laprivacidad.

Consentimiento En términos de federación se hace referencia al consentimiento como a la acción en la que el usuarioacepta que los atributos que posee un IdP se transfieran a un SP (cumpliendo la ARP y de forma segura).

SAML Es el lenguaje de marcado para las aserciones de seguridad. Un estandar definido y mantenido por OASIS.Está basado en XML y diseñado para el intercambio de información sensible de forma segura.

XML Encryption Un estandar W3C para cifrar un documento XML. Es usado en SAML para cifrar la AserciónSAML con el fin de dificultar que una entidad o individuo que no pertenezca a la federación pueda obtener los datosdel usuario.

XML Signature Un estandar W3C para firmar un documento XML. Es usado en SAML para autenticar al organismoque firmo el documento permitiendo establecer una relación de confianza.

Profile Reglas que definen como integrar las aserciones SAML y como extraerlas de otros protocolos para poderhabilitar el SSO y el SLO. Define también el flujo de peticiones y respuestas SAML que se efectuan en un determinadocaso de uso.

SSO Single Sign On. Procedimiento de autenticación que habilita al usuario para acceder a varios sistemas con unasola instancia de identificación. En una federación de identidades el SSO habilita al usuario a acceder a cada uno delos SP (previa autorización en el mismo) una vez se haya identificado en un IdP.

SLO Single Log Out. Procedimiento por el cual el usuario deja de estar identificado en el conjunto deaplicaciones/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

http://www.oasis-open.org/

http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf


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 informaciónde autorización y autenticación entre dominios de forma segura. Fue creado por la empresa OASIS

Básicamente define como debe de hacerse de forma segura la tránsmisión de los diferentes tipos de aserciones SAMLentre 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 año 2001. Permite desplegar una infraestructura deautenticación y autorización y un sistema de Single Sign-On fácilmente.

Los componentes principales del sistema son: El servidor de autenticación (AS) y los puntos de acceso (PoA).

Un PoA se encarga de interceptar los accesos a recursos o servicios forzando la auntenticación del usuario en unAS (cada PoA puede estar conectado a uno o varios AS),La autenticación se produce contra alguno de los backendsconfigurados en el AS (Ldap, BD, etc) y tras producirse se genera una aserción que se transmite al POA, y que contienedatos del usuario autenticado.

Existe un elemento especial que se denomina GPoA que se conecta con varios PoAs y a un AS, que se comporta comosi fuera un AS para sus PoAs, estableciendo una relación de confianza con ellos y suya a su vez con el AS.

9.5. Protocolos (SAML PAPI, OpenId) 79

http://www.oasis-open.org/

http://identitymeme.org/doc/draft-hodges-learning-saml-00.html

http://papi.rediris.es/


Si el PoA no puede integrarse con la aplicación a federar (diferente tecnologia, diferente entorno) se hace uso de unelemento conocido como Proxy PAPI.

El funcionamiento de PAPI es bastante similar al Browser Post Profile de Liberty/SAML 2.0: la aserción es transmitidamediante el método POST de HTTP desde un proveedor de autenticación hasta los proveedores de servicio, solo quedicha aserción no es SAML (ni siquiera XML).

Puede obtener más información sobre el protocolo en la wiki del proyecto PAPI

9.5.3 OpenID

OpenID es un sistema de identificación digital descentralizado, con el que un usuario puede identificarse en unaaplicación web a través de una URL (o un XRI en la versión actual) y ser verificado por cualquier servidor que soporteel protocolo.

En los aplicaciones web que soportan OpenID, los usuarios no requieren tener una cuenta de acceso. En su lugar, solonecesitan disponer de un identificador creado en un servidor que verifique OpenID, llamado proveedor de identidad oIdP.


http://www.papisoftware.net/doku.php

http://openid.net/

CAPÍTULO

TEN

ANEXO B. SOFTWARE EXISTENTEPARA IMPLEMENTAR FEDERACIONES

DE IDENTIDADES

Dentro del abanico de software que implemetan federaciones de identidades nos centraremos en aquellas queimplementan el estandar SAML2 y son software libre.

10.1 Shibboleth

El software Shibboleth es un proyecto de la asociación internet2 basado en estandares y software libre.

Shibboleth es un producto final que mantiene la compatibilidad hacia atrás. Dispone de IdP, de SP y de DS (serviciode 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 autenticación: Ldap, SQL, Kerberos.

Los atributos pueden ser recogidos de la fuente o ser generados manualmente. Permitiendo posteriormenterealizar la transformación 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 otrosservidores web.

Puede funcionar automáticamente o bajo demanda.

Permite proteger el mismo los recursos o delegar en las aplicaciones para que manejen la autorización.(Clusterizable)

82

http://shibboleth.internet2.edu/

http://www.internet2.edu/


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 configuración son de gran tamaño y a veces es fácil perderse en ellos.

La implementación 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 aplicación que dependiendo de como sea configurada actúa 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 fácilmente añadir funcionalidad extra.

Permite mediante cambios en la configuración que el producto functione como un WAYF.

Posee un gestor de metadatos y de ARPs (añadiendole el módulo Janus)

Soporta gran cantidad de backends de autenticación: 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 fácil perderse configurando entornos complejos.

No es totalmente un producto final, le faltan cosas. Por ejemplo el sistema de detección de errores yautodiagnostico está aún verde.

10.3 PySAML2

pySAML2 es una librería desarrollada en python que implementa IdPs y SPs basados en protocolo SAML2.

Existe una librería llamada djangosaml2 que hace uso de la librería pySAML2 y sirve para federar fácilmenteaplicaciones desarrolladas con el framework django.

10.2. simpleSAMLphp 83

https://wiki.shibboleth.net/confluence/display/SHIB2/ShibEnabled


http://uninett.no/

https://rnd.feide.no/federated-software/

http://pypi.python.org/pypi/djangosaml2/


10.3.1 Ventajas

Permite federar de forma nativa aplicaciones desarrolladas en python.

10.3.2 Desventajas

Es una librería joven:

Escasa comunidad

Aún le queda bastante desarrollo, falta mucho por implementar del estandar.

10.4 OpenSSO / OpenAM

OpenSSO es un producto Java de federación de identidad que desde el 2010 se conoce con el nombre de OpenAM yestá soportado por la empresa ForgeRock.

10.5 Lasso

Lasso es una librería C que implementa los estandars de la Liberty Alliance. Utiliza SWIG para que se pueda usar lalibreria desde python, perl, java y .net en multiples plataformas. Soporta tanto funcionalidad de SP como de IdP.

10.6 Solución recomendada

No existe una solución ideal genérica. Dependiendo del tipo de integración que se haya elegido utilizaremos unsoftware u otro.

Lo que si recomendamos es que en la medida de lo posible el software elegido para los diferentes componentes queformen la federación de sistemas sea lo más homogeneo posible para facilitar el mantenimiento. Hay que evaluarsiempre que se vaya a integrar una aplicación en la federación de sistemas si el ahorro de esfuerzo de federar unaaplicación con un determinado software diferente al utilizado en la federación luego no va a conllevar un coste elevadode mantenimiento.

Por lo general nosotros recomendamos que la infraestructura de la federación se realice basandose en el softwaresimpleSAMLphp debido a que es muy flexible, dispone de todos los componentes que podremos necesitar, tiene unagran comunidad detrás que lo soporta y está escrito en php por lo que podremos realizar una “integración de lenguajenativo” para la gran variedad de aplicaciones escritas en php. Y utilizar authmemcookie para domesticar aplicacionesdesarrolladas en otros lenguajes.

10.4. OpenSSO / OpenAM 84

http://java.net/projects/opensso/

http://forgerock.com/what-we-offer/open-identity-stack/openam/

http://lasso.entrouvert.org/

http://www.swig.org/


CAPÍTULO

ELEVEN

ANEXO C. MÁQUINA VIRTUAL CONLAS APLICACIONES DE EJEMPLO

FEDERADAS

Junto con la documentación se va a facilitar una máquina virtual con las aplicaciones de ejemplo federadas que se hanido explicando durante el curso.

11.1 Descarga

Las máquinas virtuales estarán disponibles en http://files.confia.aupa.info en varios formatos:

.vdmk Formato para VMWare.

.vdi Formato para Virtualbox.

11.2 Configuración previa

11.2.1 NAT y Anfitrión

Hace falta configurar 2 adaptadores de red:

Adaptador anfitrion vboxnet1

NAT con la dirección MAC 52:54:00:88:83:ba

11.2.2 HOSTS

Hace falta añadir las siguientes entradas en el hosts del anfitrion:

#curso saml192.168.122.108 docs.cursosaml.org192.168.122.109 idp.cursosaml.org192.168.122.110 sp.cursosaml.org192.168.122.111 shib.cursosaml.org

85

http://files.confia.aupa.info


11.2.3 CREDENCIALES

Se ha utilizado la misma contrasera para acceder a la máquina como root y en general para cada uno de loscomponentes: ‘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 modulogestor de cuentas del IdP

11.3 CONTENIDO DE LA MÁQUINA VIRTUAL

Documentacion: /var/www/docs

Configuración 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 Documentación

http://docs.cursosaml.org

11.4.2 Proveedor de Identidad

SimpleSAMLphp: https://idp.cursosaml.org/simplesaml

phpLdapAdmin: https://idp.cursosaml.org/phpldapadmin/

Módulo gestor de cuentas: https://idp.cursosaml.org/simplesaml/module.php/userregistration/index.php

11.3. CONTENIDO DE LA MÁQUINA VIRTUAL 86

http://docs.cursosaml.org

https://idp.cursosaml.org/simplesaml

https://idp.cursosaml.org/phpldapadmin/

https://idp.cursosaml.org/simplesaml/module.php/userregistration/index.php


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

https://sp.cursosaml.org/simplesaml

https://shib.cursosaml.org/Shibboleth.sso/Status

http://sp.cursosaml.org:8080/spring-security-saml2-sample/

https://sp.cursosaml.org/example-django

https://sp.cursosaml.org/example-php

https://sp.cursosaml.org/example-php-session-fail

https://sp.cursosaml.org/example-authmemcookie

https://sp.cursosaml.org/example-authmemcookie-php

https://sp.cursosaml.org/example-authmemcookie-django

https://shib.cursosaml.org/

https://shib.cursosaml.org/php

https://shib.cursosaml.org/django

curso para operadores de proveedores de servicio -...

Documents