Introducción
En cualquier institución, las ventajas de tener almacenados los datos de sus usuarios en un directorio LDAP entran en conflicto con su derecho a la privacidad, recogido en la LOPD: no todo el mundo acepta ver algunos de sus datos (por ej. teléfono, fax, correo electrónico) expuestos públicamente.
Una alternativa es confiar a las aplicaciones desarrolladas por la institución el control sobre lo que se muestra. Otra, más drástica, consiste en cerrar el accceso exterior al directorio, pero está claro que no son soluciones aceptables si queremos fomentar el uso de aplicaciones y servicios colaborativos entre las instituciones afiliadas.
Se hace necesario disponer de algún mecanismo que permita mostrar los atributos cuando el propio interesado da su permiso, dándole así la posibilidad de controlar, desde el principio, cuáles de ellos se hacen públicos. Lógicamente, este control no afecta en ningún caso a datos internos y reservados por principio sino solamente a los datos que habitualmente se suelen publicar, como teléfono, fax, correo electrónico, o cargo.
Definición de irisUserPrivateAttribute
RedIRIS ha definido el atributo irisUserPrivateAttribute, dentro del esquema iris, que resuelve este problema. Este atributo es usado para la denegación de acceso a los datos de una entrada. La organización define un conjunto de atributos privados a los que se puede denegar el acceso y el usuario decide los que desea ocultar escribiendo sus nombres en este campo. Junto con unas reglas adecuadas en la lista de control de acceso del servidor LDAP, es posible mantener desde el mismo directorio LDAP la privacidad de tales datos sin perjudicar la necesaria comunicación con otros servicios o aplicaciones.
Una lista de valores posibles puede ser:
- telephoneNumber
- facsimileTelephoneNumber
- mobile
- postalAddress
- postalCode
- homePhone
- homePostalAddress
- labeledURI
- title
- description
- jpegPhoto
Además existen dos valores especiales
- all - Para denegar el acceso a TODOS los atributos opcionales, especificados en lista anterior
- entry - Para denegar el acceso a toda la entrada
La definición del atributo dentro del esquema iris es:
attributetype ( 1.3.6.1.4.1.7547.4.3.2.11 NAME 'irisUserPrivateAttribute'
DESC 'Set of denied access attributes'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
Ejemplos de uso
Los atributos mail y telephoneNumber no serán devueltos por el servidor
irisUserPrivateAttribute: mail irisUserPrivateAttribute: telephoneNumber
No se devolverá ningún atributo de la lista de atributos opcionales
irisUserPrivateAttribute: all
La entrada no será devuelta por el servidor
irisUserPrivateAttribute: entry
Ejemplo de listas de control de acceso (ACL)
Se muestran dos ejemplos de ACL, una para el personal de la universidad (PDI y PAS) y otra para los alumnos. En el primer caso, el profesor tiene la posibilidad de decidir qué atributos son visibles entre los establecidos por la institución. En el segundo, los alumnos tienen menos posibilidades ya que sus datos están protegidos por principio.
Ejemplo 1 - Utilización de irisUserPrivateAttribute con los datos del personal
- entry - para denegar el acceso a toda la entrada (regla 1)
- all - para denegar el acceso a TODOS los atributos que se hayan establecido como opcionales (definidos en attrs en las reglas 4 y 5)
- lista attr. - una lista de atributos a los que impedir el acceso utilizando una regla para denegar cada atributo (reglas 2 y 3)
[1] access to * filter="(irisUserPrivateAttribute=entry)"
by * none
[2] access to * filter="(irisUserPrivateAttribute=mail)"
attrs=mail
by * none
[3] access to * filter="(irisUserPrivateAttribute=telephoneNumber)"
attrs=telephoneNumber
by * none
[4] access to * filter="(irisUserPrivateAttribute=all)"
attrs=mail,telephoneNumber
by * none
[5] access to *
by * read
Por tanto, irisUserPrivateAttribute=entry podría hacer la misma función que redirisViewControl y su uso estaría reservado sobre todo a los administradores del directorio.
Las reglas 2, 3 y 4 recogen los atributos cuya visualización estará controlada por el usuario. Las reglas 2 y 3 controlan un atributo cada una. En la regla 4 (penúltima) se relacionan en attrs los atributos anteriores, para denegar su acceso si irisUserPrivateAttribute=all. Aunque sólo se muestran dos, lógicamente, podrían ser otros cualesquiera de la lista definida en el esquema.
La posición de la regla 5 (última) es importante ya que permite el acceso a todos los atributos cuando la evaluación de la ACL no se haya detenido en alguna de las reglas anteriores. Por tanto, si se van a controlar más atributos (digamos, mobile o homePhone), las reglas correspondientes deben ir siempre antes de la última.
En el ejemplo de los alumnos se utiliza también irisUserPrivateAttribute aunque con algunas diferencias.
La principal es que las entradas LDAP de los alumnos, por principio, sólo se muestran a través de aplicaciones web, que deben hacer un bind previo como usuarios de sistema autorizados y con los privilegios adecuados (como el usuario de ejemplo ou=sys.readonly, idnc=sys, dc=uxyz, dc=es de la regla 8).
La elección de los alumnos en cuanto a irisUserPrivateAttribute consiste sólo en decidir si permiten a tales aplicaciones mostrar los datos de contacto (teléfono, etc), en cuyo caso irisUserPrivateAttribute no existirá, o no, y en tal caso será irisUserPrivateAttribute=all.
El filtro eduPersonAffiliation=student permite limitar el ámbito de estas tres reglas a las entradas de alumnos. En la primera, el filtro irisUserPrivateAttribute=all bloquea el acceso a los atributos listados en attrs, mientras que la segunda permite su visualización.
Ejemplo 2 - Utilización de irisUserPrivateAttribute con los datos de Alumnos
irisUserPrivateAttribute puede contener el valor all para denegar el acceso a TODOS los atributos que se establezcan como opcionales (definidos en attrs), o quedar vacío.
En el primer caso, la primera regla deniega el acceso a tales atributos; en el segundo, los visualiza.
El resto de los atributos tiene el acceso denegado por defecto, por tanto, sólo se puede acceder a esta rama y filtro mediante aplicaciones web con bind previo de usuarios de sistema autorizados
[6] access to * filter="(&(eduPersonAffiliation=student)
(irisUserPrivateAttribute=all))"
attrs=cn,displayName,mail,telephoneNumber
by * none
[7] access to * filter="(eduPersonAffiliation=student)"
attrs=cn,displayName,mail,telephoneNumber
by * read
[8] access to * filter="(eduPersonAffiliation=student)"
by dn="ou=sys.readonly, idnc=sys, dc=uxyz, dc=es" read
by * none
Lógicamente, estos ejemplos son solo una muestra y la configuración final puede ser diferente según la organización del resto del directorio. Por ejemplo, los permisos de los usuarios de sistema, que son globales, podrían definirse al principio de la ACL, para evitar tener que repetirlos en distintas reglas posteriores.
Enlaces y presentaciones
- Managing privacy constraints in directories -
PDF
TERENA EuroCAMP, Porto - 07/11/2005 - Privacidad en el servicio de directorio -
PDF |
Video
RedIRIS, jt2005 - 27/10/2005 - Privacy enabled directory services -
PDF
TERENA Networking Conference, 2005 - 09/06/2005 - Servicios de directorio y privacidad. Usando irisUserPrivateAttribute -
PDF
RedIRIS, gt2005 - 26/05/2005 - Privacy enabled Directory Services -
PDF
Terena, Eurocamp - 02/03/2005
Agradecimientos
A la Universidad de Málaga por su colaboración en la definición del atributo irisUserPrivateAttribute y a Fujitsu por su apoyo en la expansión del esquema ldap iris, patrocinando las camisetas irisUserPrivateAttribute en las Jornadas Técnicas RedIRIS 2004.
Imagen gráfica de irisUserPrivateAttribute
 Victoriano Giralt (uma.es) |
 Diego R. Lopez (rediris.es) |
 Klass Wierenga (surfnet.nl) |