FILTROS Y ATRIBUTOS LDAP en la UV
Es posible atorizar o no la conexión con PAPI dependiendo de los datos del usuario almacenados en el LDAP corporativo.
Se le puede decir al AS que pase al mod_papi cualquiera de las variables LDAP; luego se puede comprobar esa variable y filtrar por su valor en la configuración del apache o en el propio programa.
Ejemplo
proteger baul/papiprot para que sólo entren los PDI/PAS:
Configuración en el AS
En el AS, /usr/local/PAPI/AS/etc/UVsites.src contendrá una línea (separada para mejorar la legibilidad):
site
::papiprot
::TEST papiprot mod_papi-uv
::https://baul.uv.es::/cookie_handler.cgi
::7200
::papiprot
::/cgi-bin/papiprot
::/index.sh
::username=<papi var="PAPIuid"/>,
LDAPgecos=<papi var="LDAPgecos"/>,
LDAPusergroups=<papi var="LDAPusergroups"/>
LDAPemployeeType=<papi var="LDAPemployeeType"/>
El último campo son las "assertions", serie de "atributos" separados por ",". A cada atributo le das el nombre que quieras (será el que luego verá el mod_papi) y le defines un valor en función de una variable PAPI.
El PAPI, si le pides una variable que empieze por "LDAP..." buscará su valor en el campo correspondiente del LDAP del usuario. P.e.: LDAPgecos contiendrá el "gecos" del LDAP.
En nuestro caso, el que te interesa es el último:
LDAPemployeeType=<papi var="LDAPemployeeType"/>
Filtro y recogida de atributos por la aplicación desde el mod_papi
El mod_papi, una vez validado, recibe la asertion con todos los atributos seguiditos:
username=hmr,LDAPgecos=Hector Miguel Rulot Segovia;P/FA11;;,LDAPemployeeType=P@UVAS,LDAPusergroups=bdartev-l|bdartev-w|britan-l|br...
y puedes comprobarlos poniendo en la configuración del apache unos "filtros". Se aplican uno tras otro sobre toda la assertion, en el orden. En nuestro caso ponemos:
# Filtro, para personal p.e.
PAPIFilter LDAPemployeeType=P accept
PAPIFilter .* reject
El primer argumento del filtro es una EXPRESION REGULAR, el segundo es "accept" o "reject".
Si no quieres comprobarlo en el apache, puedes comprobarlo en la aplicación: una vez validado, ésta recibe en las variables de entorno los atributos:
HTTP_X_PAPIATTR_LDAPEMPLOYEETYPE=P
HTTP_X_PAPIATTR_LDAPGECOS=Hector Miguel Rulot Segovia;P/FA11;;
HTTP_X_PAPIATTR_USERNAME=hmr
Variables multivaluadas
En el caso de variables LDAP multivaluadas los valores están separados por ";". Por ejemplo, la lista de vinculaciones:
vinculacion=<papi var="LDAPorganizationalStatusUV"/>
llega al CGI como:
HTTP_X_PAPIATTR_VINCULACION=R8;S;A
Caso aparte es la la lista de grupos a los que pertenece el usuario. En este caso los valores están separados por "|".
HTTP_X_PAPIATTR_LDAPUSERGROUPS=bdartev-l|bdartev-w|britan-l|britan-w|clubcafe-e|clubcafe-l|cpd-l|difusos-l
NOTA 2019: Actualmente la implementación de los clientes PAPI utiliza cookies para almacenar los atributos de una sesión. Esto limita la longitud/cantidad total de atributos que puede tener un usuario (unos 3000 caracteres). En concreto NO FUNCIONA y trunca si se pasan los grupos y el usuario pertenece a más de unos 200 grupos.
Atributo "SELGROUPS"
Para evitar el problema del truncado de listas de grupos muy largas el AS-PAPI soporta definir el atributo especial en la ASSERTION. Por ejemplo:
SELGROUPS=;*.filtros-l;rojos-l;siuv-l;glug*;
El AS devuelve entonces al SP el atributo "SELGROUPS" con valor la lista de grupos que "matchean" con los grupos indicados, pudiéndose usar el "*" como patrón de un grupo cualquiera de caracteres.
Esto permite limitar la lista de grupos enviados al SP a un conjunto reducido y asegurar así que no se trunque.
El inconveniente es que hay que definir "a priori" en el AS los grupos que se quieren consultar.
P.e. en el caso de un analista del SIUV y con el SELGROUP indicado el mod_papi podría devolver:
HTTP_X_PAPIATTR_SELGROUPS=;siuv-l;glugS033-S;glugS033-l;permisiuv.filtros-l;
Observar que los valoreses del atributo SELGROUPS van separados por como es habitual por ";" y que SELGROUPS siempre empieza y termina con ";", esto para facilitar el matching sin tener en cuenta el principio y/o final de la cadena.
Autorización en base al GRUPO
Utilizando el atributo SELGROUPS se pueden usar los grupos para autorizar varios sitios a distintos usuarios dentro de una misma aplicación sin tener que definir cada sitio en el AS como un SP PAPI distinto.
Es decir, aparte de REMOTE_USER una aplicación puede comprobar la variable de entorno HTTP_X_PAPIATTR_SELGROUPS para autorizar o no el acceso a un sitio o partes de una aplicación, aplicando distintos criterios (grupos) en cada parte.
Autorización en base a grupo desde Apache
En casos sencillo, no es necesario modificar la aplicación para que compruebe HTTP_X_PAPIATTR_SELGROUPS; se puede configurar el Apache para que controle directamente el acceso a distintos URL's en función de grupos BDUSU.
Se protege por usuario con el mod_PAPI una Location y DENTRO de ella (para que valga la misma protección por usuario) se definen sub-locations protegidas además según grupos BDUSU que se han pasado desde el AS en el atributo SELGROUPS. Se filtra usando mod_rewrite.
Sigue un ejemplo donde mod_papi protege /prot y queremos que (dentro) a /prot/admin sólo pueda acceder el grupo de usuarios "permisiuv.filtros-l" :
<Location /prot>
AuthType PAPI
PAPIServiceID miapp
PAPIDomain miapp.midom.uv.es
PAPIAS UVAS https://as.uv.es/cgi-bin/AuthServer Universitat de Valencia
PAPILkey 1bfsdda6ebdssa21ee96365e2b545ab
PAPIRemoteUserAttribute username
PAPIWAYF built-in
PAPIAuthLocation /cookie_handler.cgi
Require valid-user
Allow from all
# Para customizar el mensaje de rechazo
ErrorDocument 403 /unauthorized.html
# ... Proteccion de /prot/admin : prohibido si no
# eres de permisiuv.filtros-l
# Para usar el mod_rewrite con mod_papi recordar
# que lo que pone el mod_papi son CABECERAS (que
# luego se pasan como variables de entorno al CGI).
# [F] es "403 Forbidden"
RewriteEngine On
RewriteCond expr "! %{HTTP:X-PAPIATTR-SELGROUPS} =~ /;permisiuv\.filtros-l;/"
RewriteRule /prot/admin "-" [F]
</Location>
Proxy de validación
Se puede utilizar un Apache+mod_papi como proxy para proteger a otra aplicación para evitar que ésta tenga que ocuparse de validar y mantener la sesión de un usuario.
En este caso, el Apache estará configurado como un proxy y pasará las peticiones en uno y otro sentido desde el cliente a la aplicación y viceversa, encargándose él de mantener la sesión y validar todas las peticiones.
Con esta configuración y al igual que en en el caso anterior (la aplicación era un cgi-bin - ejecutable llamado directamente por el Apache), la aplicación no tiene que hacer nada más que confiar en la autenticación realizada en el proxy apache. Como es probable que aparte de autenticar se necesite algún atributo de la persona que ha accedido (mínimamente el "usuario/cuenta" para personalizar la aplicación) el proxy pasa estos datos en cabeceras HTTP. Podemos configurar el IDP para que envíe casi cualquiera de los atributos asociados a una cuenta en nuestro LDAP (mail, nombre, apellidos,...). El nombre de estas cabeceras empieza por "X-PAPIAttr-". Por ejemplo, dos atributos usuales son:
X-PAPIAttr-username:peper
X-PAPIAttr-LDAPmail:pepe.peralon@uv.es
Por compatibilidad también se puede pasar la cabecera de autorización:
Authorization:Basic cGVwZXI6WFhYWA==
que en principio lleva el usuario y una contraseña "nula" (p.e. XXX), para que aplicaciones que funcionen con autenticación básica (REMOTE_USER) puedan funcionar simplemente ignorando la contraseña.
