Guía de actualización del SP a la version 1.10.0

Pasos

Vamos a actualizar la versión del SP para que utilice simplesamlphp 1.10.0

Fuentes

Supongamos que tenemos la siguiente estructura:

# directorio de simplesamlphp
/var/www/simplesamlphp

Descargamos del subversion la nueva versión de simplesamlphp

cd /var/www
svn co http://simplesamlphp.googlecode.com/svn/tags/simplesamlphp-1.10.0 simplesamlphp1.10

Desde la versión 1.8 se han añadido numerosas funcionalidades y mejoras y corregidos fallos de seguridad. Podemos ver un resumen en el changelog de simpleSAMLphp. Destacamos la corrección de ataques XSS en la 1.8.2, evitar ataques contra el cifrado PKCS 1.5 de las aserciones en las versiones 1.9.1 y 1.9.2. También destacar que los SP de shibboleth 2.4.3 requiren un IdP de simpleSAMLphp 1.10.

Varias cosas que tenemos que tener en cuenta:

  • Desde la versión 1.6.0 de simplesamlphp se requiere una versión de php > 5.2.0 , recomendamos la 5.2.12. (Al actualizar la versión de php tener en cuenta que el resto del software que utilizáis sea compatible con dicha versión, se dió el caso de que moodle 1.9 no era compatible con ciertas versiones de php 5.3.X.
  • Desde la versión 1.6.0 de simplesamlphp se utilizan archivos json para las traducciones lo cual significa que si tenemos módulos propios que hacen uso de diccionarios deberemos construir los archivos json correspondientes.
  • Ha habido cambios en el archivo de configuración de simplesamlphp (config.php). Algunas de las variables del fichero config.php han cambiado. Por ahora los cambios son compatibles hacia atrás pero conviene tener en cuenta:
  • Desde la 1.7 se tiene la variable ‘session.cookie.lifetime’ para especificar cuando deben caducar las cookies.
  • Para obligar que los accesos sean HTTPS desde la 1.7 hacemos uso de: ‘session.cookie.secure’ y ‘session.phpsession.httponly’.
  • La variable ‘session.phpsession.limitedpath’ ha dejado de utilizarse desde la 1.7 y ahora se hace uso de ‘session.cookie.path’.
  • La variable ‘session.handler’ desde la 1.7 ha sido substituida por ‘store.type’ y se ha añadido el backend sql para poder guardar las sesiones en base de datos. En el caso de establecer el ‘store.type’ al valor ‘sql’ hay que establecer el valor de las variables: ‘store.sql.dsn’, ‘store.sql.username’, ‘store.sql.password’ y ‘store.sql.prefix’.
  • Desde la 1.8 se dispone de la variable ‘proxy’ para poder especificar un proxy. (Ojo porque antiguamente los que necesitaban salir con un proxy utilizaban otra variable llamada ‘saml_proxy’ proveniente de un parche implementado en CONFIA).

Configuración

Deberemos de copiar las configuraciones del antiguo simplesamlphp, los metadatos y el certificado

# Ojo cuando se copien archivos simbólicos que puede haber problemas
cp -a /var/www/simplesamlphp/cert/* /var/www/simplesamlphp1.10/cert
cp -R /var/www/simplesamlphp/metadata/* /var/www/simplesamlphp1.10/metadata
cp /var/www/simplesamlphp/config/* /var/www/simplesamlphp1.10/config

Habilitamos los permisos de los directorios metadata y log para que el apache pueda escribir sobre dichos directorios (mirar permisos del antiguo simplesamlphp y ponerle los mismos). Ejemplo:

# En máquinas debian usar www-data:www-data en lugar de apache:apache
chown -R apache:apache /var/www/simplesamlphp/log
chown -R apache:apache /var/www/simplesamlphp/metadata

Editamos el fichero de configuración de simplesamlphp (/var/www/simplesamlphp1.10/config/config.php) y comprobamos el valor de los siguientes parámetros:

'session.cookie.lifetime' => 0,         // Si queremos que no caduque la cookie
'session.cookie.secure' => TRUE,        // 'TRUE' si queremos 'cifrar las cookies' (solo se cifran si estamos en HTTPS), en otro caso 'FALSE'
'session.phpsession.httponly' => FALSE, // Con valor a 'TRUE' evita que APIs non-HTTP como por ejemplo el javascript acceda a las cookies.

'store.type' => 'phpsession',    // o 'memcache' o 'sql', dependiendo de como queremos guardar la sesión
                                 // (antiguamente el parametro se llamaba 'session.handler')

Nota: Se ha comprobado que se producen errores si en el config.php se especifican las variables ‘session.cookie.path’ y ‘session.phpsession.limitedpath’ a la vez. La variable ‘session.phpsession.limitedpath’ está deprecada desde la versión 1.8 y debe ser eliminada si queremos hacer uso de la variable ‘session.cookie.path’.

Es importante indicar los datos de la organización y el contacto. Debemos editar el archivo con los metadatos de nuestro IdP y rellenar convenientemente los siguientes atributos en el fichero /var/www/simplesamlphp1.10/config/authsources.php:

'OrganizationName' => array(
    'en' => 'Test-SP CONFIA',
    'es' => 'SP-Pruebas CONFIA',
),
'OrganizationDisplayName' => array(
    'en' => 'Test-SP of CONFIA',
    'es' => 'SP de Pruebas de CONFIA',
),
'OrganizationURL' => array(
    'en' => 'http://confia.aupa.info/',
    'es' => 'http://confia.aupa.info/',
),

Los datos del contacto del administrador del Proveedor de Servicio se especifican en el /var/www/simplesamlphp1.10/config/config.php (‘technicalcontact_name’, ‘technicalcontact_email’). Es importante que sean correctos y que se correspondan a los encargados de dichas entidades.

Módulos

Ahora lo que nos queda es comprobar que módulos estaban habilitados en el anterior simplesamlphp que debemos habilitar en este. Si el directorio estaba subversionado rápidamente podremos observarlo ejecutando el comando:

cd /var/www/simplesamlphp
svn st

y viendo que temas son específicos de nuestra instancia y cuales están activados.

Como mínimo deberemos habilitar metarefresh, cron:

touch /var/www/simplesamlphp1.10/modules/metarefresh/enable
touch /var/www/simplesamlphp1.10/modules/cron/enable

Es posible que tengamos que hacer también uso de ciertos módulos de temas, filtros, o conectores. Para ello habrá que añadirlos dentro de la carpeta modules y asegurarnos que están habilitados (existe fichero enable o tienen un default-enable)

Parches

Tenemos que aplicar una serie de parches a esta versión de simpleSAMLphp, los descargamos del repositorio en una carpeta:

svn co https://confia.aupa.info/svn/confia/trunk/ssp/updates/

Creamos un directorio ‘patches’ en el directorio temporal y copiamos ahí los parches correspondientes a la version de simplesamlphp1.10:

mkdir /tmp/patches
cp updates/simplesamlphp1.10/patches/*.diff /tmp/patches

Aplicamos todos los parches sobre el simplesamlphp1.10

cd /var/www/simplesamlphp1.10
for patch in  /tmp/patches/*.diff; do patch -p0 < $patch; done

Sustitución

Una vez realizado todo lo anterior ya podemos sustituir la nueva instancia por la antigua:

mv /var/www/simplesamlphp/ /var/www/simplesamlphp_old/
mv /var/www/simplesamlphp1.10 /var/www/simplesamlphp/

Y comprobaríamos si todo funciona correctamente. Si no funciona siempre podremos volver a la anterior versión deshaciendo el anterior renombrado de directorios

Puede que algún filtro o algún módulo especifico que se implementara ajeno a CONFIA no funcione con la nueva versión de simplesamlphp por lo que habrá que hacer un testeo exhaustivo de que todo funciona correctamente.

Actualización del certificado en el SP

Desde la versión 1.7 se da soporte a que simplesamlphp trabaje a la vez con 2 certificados, para evitar que durante el periodo de propagación del nuevo certificado por la federación se deje de dar servicio.

El proceso sería el siguiente:

Primero editamos el archivo con los metadatos de nuestro SP, que será config/authsources.php en la declaración de la fuente de autenticación SP:SAML, añadiendole 2 nuevos atributos:

'new_privatekey' => 'new.pem',
'new_certificate' => 'new.crt',

donde ‘new.pem’ y ‘new_crt’ corresponden a los ficheros alojados en el directorio cert que poseen el nuevo certificado y la nueva key.

Una vez realizado esto, el SP pasará a exportar 2 metadatos válidos. Los metadatos la próxima vez que el gestor de metadatos se conecten a ellos serán leidos, almacenados y posteriormente distribuidos al resto de elementos de la federación.

En un plazo de 4 horas podremos estar seguro de que los elementos han sido distribuidos a todos los elementos del sistema por lo que podremos volver a configurar los datos de nuestro SP para que ahora únicamente utilice el nuevo certificado y la nueva key. Para ello volvemos a editar los metadatos de nuestro SP, alojados en config/authsources.php, y eliminaremos la entrada que añadimos antes:

'new_privatekey' => 'new.pem',
'new_certificate' => 'new.crt',

Y cambiaremos la entrada correspondiente con los antiguos certificado y clave:

'privatekey' => 'old.pem',
'certificate' => 'old.crt',

por los nuevos:

'privatekey' => 'new.pem',
'certificate' => 'new.crt',

Fuente original de la documentación del cambio de certificado