Instalación y configuración de una arquitectura PAPI

Transcripción

1 Instalación y configuración de una arquitectura PAPI Jaime Pérez Crespo <jaime.perez@urjc.es> 24 de febrero de 2006 Resumen Este documento cubre la instalación y configuración de una arquitectura PAPI de servicios web. A lo largo del mismo se utilizarán ejemplos y casos reales de la implantación de PAPI en la Universidad Rey Juan Carlos. 1. Introducción PAPI es un sistema que permite la autenticación y autorización de usuarios a través de una red de servicios web. Sus principales bazas, en las que nos centraremos aquí, son la implementación del concepto single-sign-on (sólo es necesario autenticarse una vez para acceder a todos los servicios ofrecidos) y la capacidad de actuar como proxy de reescritura transparente al usuario, de forma que permite anteponerse a políticas de acceso de filtrado por IP de origen mediante una autenticación previa. La arquitectura de PAPI utiliza una serie de conceptos que es necesario tener claros en todo momento a la hora de implantar un servicio con él. 1. Servidor de autenticación o AS. Es el encargado de autenticar a los usuarios en un único punto de la red, de la forma que se desee, y recolectar información sobre los mismos para proporcionársela a los puntos de acceso. Emite aserciones con la información necesaria para verificar la identidad de los usuarios. Por lo general, consulta un fichero con usuarios, una base de datos, o un LDAP para autenticar. 2. Puntos de acceso o PoA. Son los encargados de proteger el acceso a un recurso concreto. Utilizan las aserciones de los servidores de autenticación en los que confían para verificar la identidad de sus usuarios y obtener información adicional sobre los mismos. Un punto de acceso garantizará el acceso al recurso que protege siempre y cuando algún servidor de autenticación en el que confía le proporcione una aserción indicando que ha autenticado previamente al usuario, y utilizando la información adicional que éste le puede disponer para 1

2 1 INTRODUCCIÓN 2 autorización. Los PoA pueden funcionar de múltiples formas, dependiendo de los requisitos de la aplicación que se quiere proteger: a) PoA convencional. Escrito en Perl, se integra directamente con el servidor web Apache (versiones 1.x, la rama 2.x no está soportada hasta la fecha). Este tipo de PoA permite usar los mecanismos propios del servidor web para permitir el acceso a la aplicación que sirve el mismo o denegarla utilizando una simple página de error HTTP 403 Forbidden. b) PoA en modo proxy de reescritura. En este caso, el PoA protege el acceso a una aplicación remota que no se encuentra en su mismo servidor web. El PoA actúa como un proxy web convencional, editando los contenidos HTML que sirve para que los enlaces hagan referencia a él mismo en lugar de al servicio final que se protege. Su principal uso consiste en dar acceso autenticado a aplicaciones con filtrado por IP de origen, por ejemplo, páginas con recursos bibliográficos a las que se puede acceder únicamente desde direcciones IP suscritas. c) PoA con autocompletado de formularios. En caso de un PoA que, actuando como proxy de reescritura, necesite un nivel de autenticación más impuesto por la aplicación protegida (típicamente, nombre de usuario y contraseña), el autocompletado de formularios permite obtener la información necesaria de las aserciones realizadas por el AS, pudiendo así rellenar de forma automática y transparente los formularios necesarios. Útil en casos en los que se desea proteger una aplicación remota con el proxy de reescritura, a la que no se tiene acceso para integrar directamente con PAPI, y que requiere al usuario identificarse de alguna manera adicional. d) PoA en PHP. Una versión reducida de un punto de acceso, que permite autenticar a un usuario mediante la arquitectura PAPI, desde una aplicación escrita en PHP y mediante una simple llamada a una función. Su uso más generalizado consiste en la delegación (no tiene por qué ser exclusiva) de la autenticación en PAPI en lugar de la propia aplicación. 3. Agrupaciones de puntos de acceso o GPoA. Se trata de un PoA que no protege ningún recurso en concreto, y en su lugar da acceso a un grupo de PoAs con características comunes de validación. Permite personalizar la cantidad de información del usuario que se proporciona a los PoA, interponiéndose entre éstos y el AS, de forma que cada PoA reciba exclusivamente la información necesaria para su autenticación y autorización. Para información más detallada sobre PAPI, el protocolo subyacente e instalación y configuración del sistema, se recomienda consultar el sitio web que RedIris dispone a tal efecto en

3 2 INSTALACIÓN Y CONFIGURACIÓN 3 2. Instalación y configuración A continuación se proporcionan algunas consideraciones básicas para la instalación de todos los elementos que componen un servicio PAPI. Como convención, los comandos se indicarán precedidos del prompt del usuario root () Servidor de autenticación En primer lugar configuramos un servidor web en el que instalaremos nuestro servidor de autenticación. Lo mejor es redirigir todas las peticiones que reciba dicho servidor web a la URL del AS y utilizar SSL. En nuestro caso vamos a utilizar un virtual host de apache, que configuraremos de la siguiente manera: NameVirtualHost :80 NameVirtualHost :443 <VirtualHost :80> ServerName RedirectMatch (.*) <VirtualHost :443> ServerName ErrorDocument RedirectMatch /index.html <IfModule mod ssl.c> SSLEngine on SSLCertificateFile /etc/apache/ssl.crt/server.crt SSLCertificateKeyFile /etc/apache/ssl.key/server.key SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown </IfModule> Descargamos y descomprimimos el código fuente de la última versión del servidor de autenticación: cd /root wget ftp://ftp.rediris.es/rediris/papi/papi-as tar.gz tar xzvf PAPI-AS tar.gz cd PAPI-1.4.0

4 2 INSTALACIÓN Y CONFIGURACIÓN 4 Procedemos a compilar e instalar el servidor. Antes de nada debemos asegurarnos de que tenemos los siguientes prerrequisitos (e instalarlos si no cumplimos alguno): 1. Perl >= openssl >= (recomendado openssl >= 0.9.6g) 3. Perl Convert::ASN1 4. Perl DB File 5. Perl Digest::MD5 6. Perl MIME::Base64 7. Perl URI::Escape 8. Perl CGI::Lite apt-get install perl openssl libssl0.9.7 libssl-dev apt get install libconvert-asn1-perl liburi-perl apt get install libmd5-perl libmime-perl libdb-file-lock-perl cd /usr/share/perl/5.8.4/cgi/ wget cd /root/papi-1.4.0/ perl Makefile.PL You must provide a location for installing the PAPI Authentication Server software. It must be a directory configured to hold CGI programs in your Apache installation [/usr/local/apache/cgi-bin] /usr/lib/cgi-bin The Authentication Server CGI will be in /usr/lib/cgi-bin/authserver The configuration file will be /usr/lib/cgi-bin/authserver.cf Other data files will be installed under /usr/lib/cgi-bin/etc/ [...] The program was not able to determine a location for your OpenSSL installation, required to build PAPI. Please type the full path to the OpenSSL directory [/usr/local/ssl] /usr/lib/ssl [...] make make install mkdir -p /usr/local/papi/as cp -r AS/etc /usr/local/papi/as/

5 2 INSTALACIÓN Y CONFIGURACIÓN 5 Una vez hecho esto tendremos instalado el servidor de autenticación en /usr/lib/cgibin/authserver y su fichero de configuración en /usr/lib/cgi-bin/authserver.cf. Procedemos por tanto a configurarlo: This is the PAPI AS configuration file, a Perl source file that essentially contains asignments to a hash named PAPI::AuthServer::cfgVar. use LWP::UserAgent; Include here the modules referenced by the elements inside the configuration use PAPI::BasicAuth; use PAPI::POPAuth; use PAPI::IMAPAuth; use PAPI::LDAPAuth; use PAPI::CertAuth; Just convenience $cfg = \ %PAPI::AuthServer::cfgVar; The definition of the working directory should be the first configuration assignment $$cfg{workingdirectory} = /usr/local/papi/as/etc ; This variable will allow the selection of the authentication methods Uncomment for using basic PAPI authentication my $authtype = "basic"; Uncomment for using POP-based authentication my $authtype = "pop"; Uncomment for using IMAP-based authentication my $authtype = "imap"; Uncomment for using LDAP-based authentication my $authtype = "ldap"; Uncomment for using X509 certificate authentication my $authtype = "cert"; Admin data (included in the HTML templates) $$cfg{admincontact} = <b>papi@urjc.es</b> ;

6 2 INSTALACIÓN Y CONFIGURACIÓN 6 HTML templates $$cfg{logintemplate} = fromfile("login.html"); $$cfg{accepttemplate} = fromfile("accept.html"); $$cfg{testtemplate} = fromfile("test.html"); $$cfg{logouttemplate} = fromfile("logout.html"); $$cfg{rejecttemplate} = fromfile("reject.html"); $$cfg{siteinfotemplate} = <tr> <td>*</td> <td><a href="<papi var="poa"/><papi var="location"/> <papi var="accessuri"/>" target="<papi var="service"/>"> <strong><papi var="desc"/></strong></a> </td> </tr> ; Properties of this AS, to be sent to the PoA(s) $$cfg{aslocation} = ; $$cfg{serverid} = URJCAS ; $$cfg{privatekey} = privkey.pem ; $$cfg{publickey} = pubkey.pem ; Comment these if you do not require split (thus SSL-capable) mode $$cfg{splitmodeurl} = ; $$cfg{splitmodeparamlist} = ; These parameters make PoAs redirect accept/reject responses to locally controlled URLs $$cfg{accepturl} = ; $$cfg{rejecturl} = ; Values for the authentication cookie Comment them if you do not require its use $$cfg{authcookie} = PAPIuid,username,password ; $$cfg{authcookiedb} = /usr/local/papi/as/etc/papiauthencookies ; $$cfg{authcookietimetolive} = 7200;

7 2 INSTALACIÓN Y CONFIGURACIÓN 7 Value of the AS symmetric key Used in split mode and for en-/de-crypting the authentication cookie It is highly advisable that you change this value $$cfg{symkey} = ca a25b12a14ca121516e26180 ; The connection variable holding user id (for TEST and LOGOUT) $$cfg{uidvar} = username ; Default values for the PoA(s) $$cfg{deftimetolive} = 7200; $$cfg{deflocation} = / ; $$cfg{defservice}= ; $$cfg{defpoa} = ; $$cfg{defdescription} = ; $$cfg{defauthuri} = /cookie handler.cgi ; $$cfg{defaccessuri} = ; Default assertion about users to be sent to PoA(s) $$cfg{defassertion} = ; Hooks and hook config. By default, "basic" authentication is used if ($authtype eq "pop") { [...] elsif ($authtype eq "imap") { [...] elsif ($authtype eq "ldap") { $$cfg{authenticationhook} = \&PAPI::LDAPAuth::VerifyUser; $$cfg{credentialhook} = \&PAPI::LDAPAuth::UserCredentials; $$cfg{attrrequesthook} = \&PAPI::LDAPAuth::UserAttributes; $$cfg{ldapserver} = "dagobah.urjc.es"; $$cfg{ldapport} = 389; $$cfg{ldapusertemplate} = uid=<papi var="username"/> ; $$cfg{ldapauthsearchbase} = ou=gente,dc=urjc,dc=es ; $$cfg{ldapauthscope} = sub ; $$cfg{ldapsearchbase} = ou=papisite,dc=urjc,dc=es ; Uncomment these to use simple authentication when binding to the LDAP server $$cfg{ldapbinddn} = uid=managerid,ou=admin,dc=urjc,dc=es ;

8 2 INSTALACIÓN Y CONFIGURACIÓN 8 $$cfg{ldapbindpassword} = contraseña ; Uncomment these to use a TLS connection and verify server identity $$cfg{ldaps} = 1; $$cfg{ldapsverify} = require ; $$cfg{ldapscafile} = /etc/papi/cas/myroot.pem ; } elsif ($authtype eq "cert") { [...] else { [...] $$cfg{loghook} = undef; [...] Una vez configurado el servidor de autenticación, generamos su par de claves asimétricas /usr/local/papi/as/etc/pubkey.pem y /usr/local/papi/as/etc/privkey.pem, referenciadas en la configuración: cd /usr/local/papi/as/etc openssl genrsa out privkey.pem openssl rsa -in privkey.pem -pubout -out pubkey.pem Editamos además las plantillas HTML indicadas en la configuración, para que se adecúen a nuestras necesidades, en el directorio /usr/local/papi/as/etc. Podemos modificar las plantillas de ejemplo: accept.html login.html logout.html reject.html test.html Hecho esto disponemos de nuestro servidor de autenticación configurado, a falta de incluir puntos de acceso y su configuración asociada Puntos de acceso convencionales La configuración aquí seguida implica que tanto el AS como los PoAs perl que actúan en modo proxy se instalan en el mismo servidor, al igual que los GPoAs. De este modo, nuestros PoAs serán hosts virtuales del servidor. Lo mejor en este caso es crear un archivo separado de configuración para los puntos de acceso, por ejemplo, /etc/apache/conf.d/papi. Dicho fichero debe ir encabezado por la configuración general de PAPI para sus puntos de acceso:

9 2 INSTALACIÓN Y CONFIGURACIÓN 9 Configuración general de PAPI PerlModule PAPI::Conf <PAPI Main> Service ID poa generico HKEY File /usr/local/papi/poa/hkey LKEY File /usr/local/papi/poa/lkey Lcook Timeout CRC Timeout 1800 URL Timeout 1800 Debug 0 Auth Location /cookie handler.cgi en caso de utilizar el mecanismo de las bolitas, debemos descomentar las siguientes líneas Accept File /usr/local/papi/poa/yes.gif Reject File /usr/local/papi/poa/no.gif Pubkeys Path /usr/local/papi/poa/keys Hcook DB /usr/local/papi/poa/hcook.db PAPI AS URJCAS AuthServer URJC </PAPI Main> Descargamos y descomprimimos el código fuente de la última versión del servidor de autenticación: cd /root wget ftp://ftp.rediris.es/rediris/papi/papi-poa tar.gz tar xzvf PAPI-PoA tar.gz Compilamos e instalamos el punto de acceso. Nos aseguramos de que tenemos los siguientes prerrequisitos (y los instalamos si no cumplimos alguno): 1. mod perl >= apache >= Perl SSL 4. Perl MLDBM 5. Perl MLDBM::Sync 6. Perl URI::URL 7. Perl HTML::TokeParser

10 2 INSTALACIÓN Y CONFIGURACIÓN Perl 9. Perl Data::Dumper 10. Perl Perl Net::LDAP apt-get install libapache-mod-perl apache apt get install libio-socket-ssl-perl libmldbm-perl apt get install liburi-perl libmldbm-sync-perl apt-get install libhtml-tokeparser-simple-perl apt-get install libapache-authcookie-perl apt-get install libdata-dumper-simple-perl apt-get install libnet-ldap-perl cd wget tar xzvf HTTP-Request-Form tar.gz cd HTTP-Request-Form perl Makefile.PL make make install Una vez cumplidos los prerrequisitos, instalamos el PoA: cd /root/papi perl Makefile.PL You must provide a location for installing the PAPI Authentication Server software. It must be a directory configured to hold CGI programs in your Apache installation [/usr/local/apache/cgi-bin] /usr/lib/cgi-bin The Authentication Server CGI will be in /usr/lib/cgi-bin/authserver The configuration file will be /usr/lib/cgi-bin/authserver.cf Other data files will be installed under /usr/lib/cgi-bin/etc/ [...] The program was not able to determine a location for your OpenSSL installation, required to build PAPI. Please type the full path to the OpenSSL directory [/usr/local/ssl] /usr/lib/ssl [...] make make install

11 2 INSTALACIÓN Y CONFIGURACIÓN 11 Estando el PoA instalado, podemos incluir la configuración general de PAPI ya expuesta en la configuración de Apache, y proceder a configurar los puntos de acceso que necesitemos. Lo más sencillo es utilizar virtual hosts para cada uno. En nuestro caso, queremos que los accesos se hagan siempre mediante conexiones seguras, por lo que redirigimos todo el tráfico para utilizar SSL: <VirtualHost :80> ServerName poa.papi.urjc.es ErrorDocument <VirtualHost :443> ServerName poa.papi.urjc.es ErrorDocument <Location /app> PerlSendHeader On PerlAccessHandler PAPI::Main <PAPI Local> Service ID poa Req DB /usr/local/papi/poa/req poa GPoA URL wayf:built-in </PAPI Local> </Location> Este punto de acceso funciona de la forma más simple posible, en nuestro caso, protegiendo todos los accesos que se hagan a Si un usuario trata de acceder a cualquier URL que comience por /app, será redireccionado a una conexión segura, y una vez hecho esto se comprobará si tiene las credenciales de PAPI en orden. En caso afirmativo se le garantizará acceso, y en caso contrario se le redirigirá al AS para que se autentique. Si el acceso se realiza a otra URL que no está bajo la protección del punto de acceso, PAPI no intervendrá de ningún modo Puntos de acceso en modo proxy de reescritura Los puntos de acceso en modo proxy se configuran exactamente igual que cualquier otro punto de acceso, con la particularidad de que debemos indicar la URL o el dominio al que redirigir las peticiones entrantes. Por ejemplo: <VirtualHost :80> ServerName proxy.papi.urjc.es RedirectMatch /index.html ErrorDocument 404

12 2 INSTALACIÓN Y CONFIGURACIÓN 12 <VirtualHost :443> ServerName proxy.papi.urjc.es ErrorDocument <Location /> PerlSendHeader On PerlAccessHandler PAPI::Main <PAPI Local> Service ID proxy Req DB /usr/local/papi/poa/req proxy GPoA URL wayf:built-in Remote URL Eval Proxy Redirects 1 </PAPI Local> </Location> De esta forma el punto de acceso en vez de proteger una localización concreta del propio servidor, lo hace respecto a una URL externa comportándose como un proxy. Si en vez de utilizar la directiva Remote URL utilizamos Remote Domain acompañada de un nombre de dominio, todas las peticiones recibidas de la forma /host/pagina se traducirán en peticiones a Para conseguir esto es conveniente usar también la directiva Strip Location con el valor 1. De este modo las peticiones /host/pagina se traducen en /pagina en la URL remota especificada con Remote URL. Por último, podemos utilizar las directivas PAPI Redirect, Rewrite URL y Redirect All para definir las sustituciones de URLs en los documentos HTML servidos, hacerlo incluso en contenidos no HTML (como código javascript) y evaluar todas las URLs encontradas en el documento en modo agresivo, respectivamente. Para información detallada sobre todas estas y otras directivas adicionales es conveniente consultar la guía para principiantes de PAPI Autocompletado de formularios El autocompletado de formularios es una vuelta de tuerca sobre la configuración de un PoA en modo proxy. Básicamente consiste en utilizar la directiva From Processor para configurar el módulo de PAPI que se encargará de los formularios. Por ejemplo: <VirtualHost :80> ServerName proxy.papi.urjc.es RedirectMatch (.*)

13 2 INSTALACIÓN Y CONFIGURACIÓN 13 <VirtualHost :443> ServerName proxy.papi.urjc.es <Location /> PerlSendHeader On PerlAccessHandler PAPI::Main <PAPI Local> Service ID proxy Req DB /usr/local/papi/poa/req proxy GPoA URL wayf:built-in Remote URL Redirect All 1 PAPI Redirect proxy.papi.urjc.es$1 Eval Proxy Redirects 1 Form Processor urle=>ˆ/.* \ form=>login buttonname=>action login \ field=>(password,$r->notes( PAPIAttr-password )) \ field=>(usuario,$r->notes( PAPIAttr-username )) </PAPI Local> </Location> La directiva Form Processor se compone de los siguientes atributos: urle: una expresión regular que define la URL o URLs en las que se encuentra el formulario que queremos completar automáticamente. form: el nombre del formulario, en caso de que haya más de uno. Si no se indica este atributo o no existe ningún formulario con el nombre indicado, se elegirá el primer formulario de la página. buttonname: el nombre del botón de envío del formulario. field: un campo del formulario, definido por una tupla (nombre, valor), donde nombre es el nombre del campo en el formulario y valor el valor con el que queremos rellenarlo. Incluiremos este atributo tantas veces como campos necesitemos enviar, incluyendo aquellos ocultos. Podemos utilizar valores fijos o incluso variables de PAPI para rellenar un campo con, por ejemplo, el nombre de usuario o la contraseña del mismo. Para esto debemos activar la directiva Eval Proxy Redirects, que permite que Perl evalúe los valores especificados en la configuración. De esta forma, cuando queramos obtener un campo de la aserción de PAPI utilizaremos la sintaxis $r->notes( PAPIAttr-nombre ), donde nombre es el nombre del campo en la propia aserción. Esto implica que previamente debemos modificar el formato de la aserción de la siguiente forma: variable1=valor1,variable2=valor2. Esto lo haremos en la propia configuración del

14 2 INSTALACIÓN Y CONFIGURACIÓN 14 punto de acceso en el atributo papiassertion del LDAP. Por ejemplo, si queremos que la aserción del PoA sea usuario=valor,password=valor, configuraremos papiassertion de la siguiente forma: usuario=<papi attr= login />, password=<papi var= password />, donde attr especifica que login es un atributo localizado en el perfil del usuario en el LDAP, y var indica que password es una variable del formulario de autenticación del AS (y que deberá propagarse en la aserción del mismo) Puntos de acceso PHP En primer lugar debemos descargar la última versión del phppoa del sitio FTP de RedIris: ftp://ftp.rediris.es/rediris/papi/. Descomprimimos el archivo a algún lugar en nuestro sistema, por ejemplo, /usr/local/phppoa: cd /usr/local wget ftp://ftp.rediris.es/rediris/papi/phppoa.1.1.tar.gz tar -xzvf phppoa.1.1.tar.gz Así, en /usr/local/phppoa tendremos los contenidos siguientes: doc etc php samples LICENSE README la documentación de la versión del phppoa instalada. la configuración del phppoa. Esto incluye un archivo con extensión ini, ficheros html de error, y un directorio para las claves criptográficas utilizadas. el phppoa propiamente dicho y su librería criptográfica asociada. ejemplos de uso del phppoa. la licencia de distribución. una descripción de los contenidos como ésta. Debemos asegurarnos de que la instalación de PHP encuentre el script del PoA, por lo que incluiremos la ruta completa en el fichero php.ini, en debian típicamente /etc/php4/apache/php.ini. Buscamos la sección de rutas y directorios, y añadimos las siguientes lineas: include path = ".:/usr/share/php:/usr/local/phppoa/php" phppoa ini file = "/usr/local/phppoa/etc/phppoa.ini" Dado que PAPI utiliza métodos criptográficos que no suelen venir instalados por defecto, deberemos asegurarnos de tener instalada la librería mcrypt. De no estarlo, la instalamos: apt-get install php4-mcrypt

15 2 INSTALACIÓN Y CONFIGURACIÓN 15 Reiniciamos Apache y colocamos alguno de los ejemplos del directorio samples en el directorio raíz de Apache para comprobar que el PoA está funcionando correctamente. La configuración del PoA se realiza en el archivo phppoa.ini. En dicho archivo indicaremos las opciones necesarias para la autenticación y autorización de los usuarios en la aplicación o aplicaciones que proteja este PoA. La sección [PAPI Main] es obligatoria y define la configuración global para todas las aplicaciones. Aparte, es posible definir nuevas secciones que redefinan el comportamiento de PAPI para aplicaciones concretas. Por ejemplo: [PAPI Main] Lcook Timeout = ; localización de la base de datos de peticiones ; el directorio DB debe ser propiedad del usuario ; que ejecuta apache y tener permisos de escritura Request DB = /usr/local/phppoa/var/db/request db.db4 DB Type = db4 ; al igual que el directorio DB, el directorio logs ; debe tener permisos suficientes para que el usuario ; de apache pueda escribir en él error log = /usr/local/phppoa/var/logs/papi error.log ; si se usa el modo automático, se debe proporcionar ; la url de los posibles documentos de error Not Auth Error File = Cookie Error File = System Error File = ; definición de aserciones que se permiten PAPI Filter accept = ".*" ; definición de aserciones que se deniegan PAPI Filter reject = ".*" ; Cookie Domain is Optional Cookie Domain = papi.urjc.es ; clave compartida con el GPoA LKEY File = /usr/local/phppoa/keys/lkey ; clave pública del GPoA GPoA Pub Key = /usr/local/phppoa/keys/ GPoA pubkey.pem ; la url completa del GPoA, debe coincidir con la ; definida por la directiva Auth Location en el GPoA GPoA URL = handler.cgi [admin] Location = /papi/admin ; Cookie Domain is Optional Cookie Domain = papi.urjc.es LKEY File = /usr/local/phppoa/keys/lkey

16 2 INSTALACIÓN Y CONFIGURACIÓN 16 GPoA Pub Key = /usr/local/phppoa/keys/ GPoA pubkey.pem GPoA URL = handler.cgi PAPI Filter accept = ".*" PAPI Filter reject = ".*" Lcook Timeout = Request DB = /usr/local/phppoa/var/db/request db.db4 DB Type = db4 error log = /usr/local/phppoa/var/logs/papi error.log Not Auth Error File = Cookie Error File = System Error File = En particular, debemos tener en cuenta las siguientes consideraciones a la hora de tocar el fichero de configuración: 1. El PoA necesita escribir en dos lugares concretos, tanto una base de datos de peticiones, como un archivo de log. El proceso Apache debe tener los permisos necesarios para escribir en ambos sitios. 2. El modo automático redirige al usuario directamente a los documentos de error cuando la autenticación no ha sido correcta. Esto es interesante cuando queremos utilizar PAPI como única alternativa de autenticación y autorización. Si por contra es un método adicional, y queremos presentar al usuario alternativas (por ejemplo, un formulario en el que introducir nombre de usuario y contraseña) en caso de que PAPI no pueda autenticar, debemos desactivar el modo automático y controlar el valor devuelto por la llamada a check Access(). 3. phppoa no implementa un PoA completo. Por eso es necesario instalar y configurar un GPoA al que el phppoa pedirá información. Por tanto en la configuración hay que indicar la URL del mismo, incluyendo la ruta absoluta indicada en la directiva Auth Location del GPoA. 4. Los filtros permiten determinar la autorización de acceso al PoA para usuarios que el GPoA define como autenticados. Por ello se especifican filtros mediante expresiones regulares de Perl que definan qué aserciones se aceptan y cuáles se deniegan. Lo habitual es denegar todas salvo aquellas que cumplan cierta propiedad (por ejemplo, que el usuario pertenezca a un grupo concreto). Si estamos utilizando PAPI con el mecanismo de autenticación mediante bolitas, podemos conseguir que las entradas en la página del AS para PoAs en PHP también tengan su imagen asociada (y que indique correctamente el estado de las credenciales en dicha aplicación), mediante un sencillo script en PHP: <?php

17 2 INSTALACIÓN Y CONFIGURACIÓN 17 $AS = " $BASE = " $YES = $BASE."yes.gif"; $NO = $BASE."no.gif"; $ SERVER[ HTTPS ] = "on"; // only if we use https include( PoA.php ); // check PAPI auth $auto = 0; // do not use papi auto mode $poa = new PoA( scheme,$auto); list($res,$userassertion) = $poa->check Access(); // show image according to auth status if ($res == 0) // GPoA doesn t know user header("location: $NO"); else header("location: $YES");?> Guardamos el fichero en el directorio raiz de Apache y configuramos el AS para que consulte la URL correspondiente al script en nuestro phppoa Agrupaciones de puntos de acceso La configuración de un grupo de puntos de acceso o GPoA es idéntica al de un PoA convencional, salvo por la inclusión de algunas directivas propias del GPoA. A continuación se muestra una posible configuración con hosts virtuales de Apache de un GPoA: <VirtualHost :80> ServerName gpoa.papi.urjc.es RedirectMatch (.*) <VirtualHost :443> ServerName gpoa.papi.urjc.es ErrorDocument DocumentRoot /var/www/gpoa/ <Location /> PerlSendHeader On PerlAccessHandler PAPI::Main <PAPI Local>

18 3 INTEGRACIÓN CON APLICACIONES 18 Service ID gpoa Req DB /usr/local/papi/poa/req gpoa GPoA Priv Key /usr/local/papi/as/etc/privkey.pem GPoA Hash User Data 0 GPoA URL wayf:built-in </PAPI Local> </Location> La directiva GPoA Priv Key indica al GPoA dónde localizar la clave privada con la que encriptar los datos asociados a sus respuestas, mientras que la directiva GPoA Hash User Data indica si el GPoA debe aplicar una función hash sobre los datos del usuario antes de enviarlos. En caso de activarse (1) los datos jamás se enviarán en claro, y por tanto los puntos de acceso finales no podrán acceder a ellos, mientras que manteniéndola desactivada (0) nos aseguramos de que los clientes puedan acceder a dichos datos (lo cual puede suponer un riesgo de seguridad). Adicionalmente, y mediante la directiva GPoA Rewrite, podemos controlar la información que enviamos a cada PoA subordinado. La directiva recibe tres parámetros. El primero, una expresión regular que se comparará con el nombre del PoA, el segundo una expresión regular que se aplicará a la aserción emitida por el GPoA, y el tercero el patrón con el que se debe sobreescribir dicha aserción. Por último, si queremos que el GPoA no aparezca como opción en la lista de PoAs disponibles para un usuario, bastará con que modifiquemos su configuración en el LDAP, dejando el campo papisiteservice vacío (con uno o más espacios). 3. Integración con aplicaciones A continuación se encuentran detalladas las implementaciones concretas para cada aplicación integrada en el sistema PAPI de la universidad Safari (publicaciones online) Safari es un servicio online de O Reilly mediante el cual se pueden consultar publicaciones desde cualquier dirección IP de la universidad. Nuestra intención es poder utilizar dicho servicio desde cualquier ubicación (no sólo desde la universidad) mediante una autenticación previa. Para ello instalamos un servidor que actuará como proxy PoA, y lo configuramos de la siguiente manera: <VirtualHost :80> ServerName safari.papi.urjc.es RedirectMatch /index.html

19 3 INTEGRACIÓN CON APLICACIONES 19 ErrorDocument <VirtualHost :443> ServerName safari.papi.urjc.es ErrorDocument <Location /> PerlSendHeader On PerlAccessHandler PAPI::Main <PAPI Local> Service ID safari Req DB /usr/local/papi/poa/req safari GPoA URL wayf:built-in Remote URL </PAPI Local> </Location> 3.2. LAPA (aplicación de comunicaciones) En esta aplicación el método de autenticación consistía en un usuario y contraseña con los que se creaba una sesión que se comprobaba el resto del tiempo. En su lugar, crearemos un index.php que compruebe las credenciales de PAPI y haga lo necesario para autenticar al usuario en caso de que no lo esté ya (en este caso, redirigirle al GPoA asociado). Cuando las credenciales sean las esperadas, se le creará una sesión que servirá para identificarle hasta que cierre la aplicación, de modo que no es necesario tocar ningún código de la misma, sino que basta con incluir un index.php similar al que sigue: <?php $AS = " session start(); include( /var/www/include/dbconnectv2.php ); include( /var/www/clases/c log.php ); include PoA.php ; //logs $log->seccion = "autenticacion"; $log->operador = $correo; $poa = new PoA( lapa ); list($res, $userassertion) = $poa->check Access();

20 3 INTEGRACIÓN CON APLICACIONES 20 if ($res == 0) { // el GPoA no autentica header("location: $AS"); exit; } list($mail,$set) = split(",",$userassertion,2); list($login,$domain) = split("@",$mail,2); $consulta = mysql query("select * from operadores where login= $login "); if (mysql num rows($consulta) == 0) { //No esta en la tabla de operadores header("location: $AS"); exit; } // autenticado con éxito por PAPI, y es operador if (session is registered("session")) session unregister("session"); session register("session"); $SESSION["login"] = $login; $log->descripcion = "Exito en la autenticacion"; $log->putlog(); header("location: /main.php"); exit;?> En este ejemplo se incluye código que se utilizaba en el antiguo sistema de autenticación para crear la sesión y guardar un histórico de accesos. En negrita se encuentra el código más importante desde nuestro punto de vista, que se encarga de consultar al PoA las credenciales del usuario, y redirigirle, bien al AS, bien a otro fichero PHP previa creación de una sesión, en función de las mismas HORDE (correo web) Horde es el sistema de correo web utilizado en la universidad. Permite la utilización de diferentes servidores IMAP y por tanto dar acceso a varios dominios de correo. Partiendo de la base de que tenemos Horde configurado y que utilizamos IMP para la autenticación, lo único que tenemos que hacer es sustituir el fichero index.php de Horde por uno ligeramente modificado. Encontraremos el original en /usr/share/horde3/index.php. Realizamos una copia de seguridad y editamos su contenido: