Autorizaci n y Autenticaci n en gLite

1. Autorización y Autenticación en gLite Juan Eduardo Murrieta León DGSCA - UNAM Thirteenth EELA Tutorial La Antigua, 18.10.2007

2. 2 La Antigua, 13th EELA Tutorial, 18.10.2007 Glosario Cifrado Algoritmos Simétricos Algoritmos Asimétricos: PKI Certificados Firmas Digitales Certificados X509 Seguridad en Grid Conceptos básicos Infraestructura de Seguridad en Grid Certificados Proxy Interfaces en línea de comandos Organizaciones Virtuales Concepto de VO y autorización VOMS, LCAS, LCMAPS

3. 3 La Antigua, 13th EELA Tutorial, 18.10.2007 Principal Una entidad: un usuario, un programa, o una máquina Credenciales Algún dato que proporciona una prueba de identidad Autenticación Verificar la identidad de un principal Autorización Mapeo de una entidad hacia algún conjunto de privilegios Confidencialidad Cifrar el mensaje de manera que sólo el receptor pueda comprenderlo Integridad Garantizar que el mensaje no ha sido alterado en la transmisión No-repudio Imposibilidad de negar la autenticidad de una firma digital

4. 4 La Antigua, 13th EELA Tutorial, 18.10.2007

5. 5 La Antigua, 13th EELA Tutorial, 18.10.2007

6. 6 La Antigua, 13th EELA Tutorial, 18.10.2007

7. 7 La Antigua, 13th EELA Tutorial, 18.10.2007

8. 8 La Antigua, 13th EELA Tutorial, 18.10.2007 La firma digital de Pablo es segura si: La llave privada de Pablo no está comprometida Juan conoce la llave pública de Pablo ¿Cómo puede Juan estar seguro de que la llave pública de Pablo es realmente la llave pública de Pablo y no la de alguien más? Una tercera parte garantiza la correspondencia entre la llave pública y la identidad del propietario. Tanto A como B deben confiar en esta tercera parte. Dos modelos: X.509: organización jerárquica; PGP: “red de confianza”. Certificados Digitales

9. 9 La Antigua, 13th EELA Tutorial, 18.10.2007 PGP “red de confianza”

10. 10 La Antigua, 13th EELA Tutorial, 18.10.2007 La “tercera parte” es llamada Autoridad Certificadora (CA). Emite Certificados Digitales (que contienen la llave pública y la identidad de su propietario) para usuarios, programas y máquinas (firmados por la CA) Verifica la identidad y datos personales del solicitante Autoridades de Registro (RAs) hacen la validación actualmente Las CA’s periódicamente publican una lista de los certificados comprometidos Listas de Revocación de Certificados (CRL): contienen todos los certificados revocados aún por expirar Los certificados de las CAs son auto-firmados

11. 11 La Antigua, 13th EELA Tutorial, 18.10.2007

12. 12 La Antigua, 13th EELA Tutorial, 18.10.2007

13. 13 La Antigua, 13th EELA Tutorial, 18.10.2007

14. 14 La Antigua, 13th EELA Tutorial, 18.10.2007 Más sobre Autenticación En el mundo de la grid una sola CA usualmente cubre una región geográfica predefinida o dominio administrativo: Organización País Un conjunto de países Un dominio de confianza común para el cómputo en grid ha sido creado para unir las diversas autoridades de certificación existentes en un solo dominio de autenticación y así permitir compartir recursos de grid en el mundo. La Federación de Confianza Internacional en Grid (IGTF) ha sido creada para coordinar y administrar estos dominios de confianza. IGTF está dividida en tres Autoridades de Políticas de Administración (PMAs) que cubren el Asia del Pacífico, Europa y América.

15. 15 La Antigua, 13th EELA Tutorial, 18.10.2007 IGTF

16. 16 La Antigua, 13th EELA Tutorial, 18.10.2007 Perfil clásico de una CA Qué es: La CA firma y revoca certificados Estos son certificados de lago plazo (un año) La CA tiene RAs subordinadas que sólo desempeñan la tarea administrativa de verificar la identidad del sujeto en diferentes organizaciones o departamentos Ventajas: Es el perfil más conocido de una CA Existe una gran cantidad de “know-how” y soluciones La mayoría de las CAs operan usando el perfil clásico Es la más fácil de soportar entre dominios administrativos diferentes La SLCS (perfil para servicios de credenciales de corta duración) está aún en desarrollo Los requerimientos del perfil son estables y controlados por EUgridPMA

17. 17 La Antigua, 13th EELA Tutorial, 18.10.2007 Perfil clásico de una CA Se necesita de una red de RAs subordinadas para realizar la verificación de la identidad de los sujetos Las RAs serán creadas a nivel de organizaciones o a nivel de departamentos: Operando a nivel de centro de investigación o universidad (más difícil) Operando a nivel de departamento o grupo La CA puede también operar una RA pero sin olvidar que la presencia física de los individuos es necesaria para la verificación de identidad Es bueno tener más de una RA por universidad o centro de investigación si están operando para departamentos diferentes Las RAs deben ser creadas sólo bajo solicitud, su creación se determina por las necesidades de los usuarios.

18. 18 La Antigua, 13th EELA Tutorial, 18.10.2007 Perfil clásico de una CA Cómo obtener un certificado:

19. 19 La Antigua, 13th EELA Tutorial, 18.10.2007 Emisión de certificados en más detalle

20. 20 La Antigua, 13th EELA Tutorial, 18.10.2007 Listas de Revocación Las CAs tienen la obligación de emitir Listas de Revocación de Certificados (CRL) Las CRLs contienen: una lista de los certificados revocados la fecha de cuándo fueron emitidos su fecha de expiración Las CRLs son firmadas con la llave privada de la CA Las CRLs deben ser publicadas de manera que las partes involucradas puedan verificar la validez de los certificados Usualmente a través de http://

21. 21 La Antigua, 13th EELA Tutorial, 18.10.2007 Perfil clásico de una CA Debe existir una única Autoridad Certificadora (CA) por país, una región amplia u organización internacional. Proporciona un número pequeño y estable de CAs Las CAs deben ser operadas con un compromiso a largo plazo Deben permanecer en operación después del final del proyecto Una red de Autoridades de Registro (RA) por cada CA es responsable de las peticiones de autenticación La CA deberá manejar la tarea de: emitir CRLs firmar Certificados/CRLs revocar Certificados

22. 22 La Antigua, 13th EELA Tutorial, 18.10.2007 Perfil de la CA: identidad Cualquier Nombre Distinguido (DN) de un sujeto debe estar ligado una entidad única. DNs deben ser únicos En todo el tiempo de vida de la CA un DN no debe estar ligado a ninguna otra entidad Una entidad puede tener mas de un nombre de sujeto para usos de llave diferentes Un usuario puede tener más de un certificado Un servidor puede tener más de un certificado Los certificados no deben ser compartidos entre entidades finales Un certificado no puede ser compartido con otros usuarios Las CAs y RAs deben revocar estos certificados inmediatamente cuando una violación del CP/CPS (Política de Certificados/Declaración de Prácticas de Certificados) es detectada.

23. 23 La Antigua, 13th EELA Tutorial, 18.10.2007 Perfil de la CA: CP/CPS Identificación Cada CA debe tener una Política de Certificación y Declaración de Prácticas de Certificados Para nuevas CAs los documentos de la CP/CPS deben estar estructuradas como se definen en RFC 3647 Este es un nuevo formato. La mayoría de las CP/CPS fueron escritas en el RFC 2527 Ejemplos: PkirisGrid AustrianGrid Los mayores cambios al CP/CPS deben ser: Anunciados a la PMA acreditada Aprobados antes de firmar cualquier certificado bajo el nuevo CP/CPS Todas las CP/CPS bajo las cuales se expiden certificados válidos deben estar disponibles en la web (muchos ejemplos se pueden encontrar en http://www.eugridpma.org/members y http://www.tagpma.org/members)

24. 24 La Antigua, 13th EELA Tutorial, 18.10.2007 Operación de la RA La operación de las RAs debe ser: de acuerdo con la CA CP/CPS definida en un documento para cada RA La operación de la RA en general: Cada RA debe tener una persona responsable (administrador) Un director es aconsejable El administrador puede nombrar uno o mas operadores Tanto el administrador como los operadores pueden autorizar solicitudes Todo el personal de la RA debe estar entrenado en las operaciones y seguridad de la CA/RA El método de selección del personal debe estar definido La CA debe ser informada oficialmente de cualquier cambio en el personal de la RA (por ejemplo una carta firmada y sellada) El primer administrador debe estar identificado en persona por la CA Cada RA debe tener un único espacio de nombres (prefijo en el nombre del sujeto del DN) para evitar colisiones de nombre en el DN La comunidad soportada por la RA debe estar bien definida El método usado para identificar a los sujetos debe estar totalmente descrita incluyendo el refuerzo de cualquier requerimiento adicional impuesto por la CA o por la RA (por ejemplo: relación con la organización)

25. 25 La Antigua, 13th EELA Tutorial, 18.10.2007 Espacio de nombres de la CA/RA La definición del espacio de nombres es responsabilidad de la CA, sin embargo dependiendo de esta definición la RA puede también estar involucrada (por ejemplo el espacio de nombres de la LIP CA…) /C=PT/O=LIPCA/ El prefijo de la CA debe ser único entre las CAs /C=PT/O=LIPCA/O=UMINHO La segunda /O= designa la organización del sujeto y también de la RA /C=PT/O=LIPCA/O=UMINHO/OU=DI La /OU=DI en el caso de LIP es opcional y puede ser usado para identificar un departamento en una organización Se utiliza para designar una RA dentro de una organización cuando una organización tiene múltiples RAs

26. 26 La Antigua, 13th EELA Tutorial, 18.10.2007 Espacio de nombres de la CA/RA Acerca del CN y el DN completo: /C=PT/O=LIPCA/O=UMINHO/OU=DI/CN=Jose A Sousa cada DN debe ser único: Lo suficientemente largo para evitar colisiones Agregar algo (número,... ) cuando se encuentran duplicados Posiblemente usar el nombre completo de la persona es la mejor opción cada DN debe estar limitado al mismo sujeto para todo el tiempo de vida de la CA El CN debe tener una relación clara y directa con el DN No olvidar que los certificados son para el cómputo en grid, no deben crearse nombres (o extensiones) que puedan crear problemas al middleware. No usar acentos Algunos caracteres pueden tener significados especiales para las aplicaciones (como el “-” que globus utiliza como comodín) Algunos caracteres no son permitidos (por ejemplo “/” and “.” en los certificados de usuario)

27. 27 La Antigua, 13th EELA Tutorial, 18.10.2007 Renovación Dos tipos de renovación: Renovación de certificados de entidades finales Renovación de certificados de CA Entidades Finales: El tiempo de vida máximo de un cerificado es 1 año + 1mes La idea es que al final del año (12º mes) un nuevo certificado sea emitido. El usuario (EE) debe ser avisado acerca de la próxima expiración y necesidad de renovación de su certificado Dado que el nuevo certificado será emitido al final del 12º mes (o inicios del 13º) habrá un traslape de dos certificados: Esto se utiliza para evitar una situación en donde el certificado expira dejando al usuario sin acceso a la grid. No hay que olvidar que hay usuarios que someten trabajos que pueden tomar días o semanas. Durante este período habrá dos certificados con el mismo nombre (DN) No revocar un certificado para emitir uno nuevo a menos que el certificado haya sido comprometido o el usuario haya cesado su actividad o relación con las entidades que le dan derecho a un certificado.

28. 28 La Antigua, 13th EELA Tutorial, 18.10.2007 Renovación Entidades Finales: Durante una renovación no es necesario hacer que la entidad final (EE) pase a través del proceso de identificación: Esto es una gran ventaja tanto para la EE como para la RA Sin embargo, un número máximo de renovaciones sin identificación es recomendable (por ejemplo: cada dos años la EE debe pasar por el proceso de identificación de nuevo) Sin embargo, la relación con la organización debe mantenerse (si este requerimiento se va a utilizar) Para no pasar por el proceso de identificación la solicitud de renovación debe estar firmada con el certificado del usuario, ejemplos: Correo firmado con el certificado del usuario Interfaz Web de la CA/RA que pueda identificar el certificado del usuario Si el certificado del usuario expira antes de la renovación el procedimiento de solicitud de un nuevo certificado debe seguirse.

29. 29 La Antigua, 13th EELA Tutorial, 18.10.2007 Solicitud de un certificado personal para trabajar en EELA La CA “Catch-all” de EELA está por ser terminada. Cualquier usuario de Grid en LA será capaz de solicitar un certificado si su institución cuenta con una RA.

30. 30 La Antigua, 13th EELA Tutorial, 18.10.2007 Importar el certificado en el navegador Si se recibe un certificado .pem es necesario convertirlo a PKCS12 Usando el comando openssl (disponible en cada UI) openssl pkcs12 –export –in usercert.pem –inkey userkey.pem –out my_cert.p12 –name ’Mi Nombre’ GILDA (y otras VOs, entre ellas EELA): Se recibe un certificado PKCS12 (que puede importarse directamente en el navegador web) Para uso futuro, se necesitará un usercert.pem y un userkey.pem en el directorio ~/.globus de la UI Copie el certificado PKCS12 a un directorio local de la UI y use de nuevo el comando openssl: openssl pkcs12 -nocerts -in my_cert.p12 -out userkey.pem openssl pkcs12 -clcerts -nokeys -in my_cert.p12 -out usercert.pem

31. 31 La Antigua, 13th EELA Tutorial, 18.10.2007 La extensión GSI de los Certificados de Identidad X.509 Firmados por la entidad final (o por otro proxy). Permite el registro único o “single sign-on” Soporta algunas características importantes Delegación Autenticación Mutua Tiene un tiempo de vida limitado (minimiza los riesgos de “compromiso de credenciales”) Es creado por el comando grid-proxy-init: % grid-proxy-init Enter PEM pass phrase: ****** Opciones del grid-proxy-init: -hours <lifetime of credential> -bits <length of key> -help

32. 32 La Antigua, 13th EELA Tutorial, 18.10.2007

33. 33 La Antigua, 13th EELA Tutorial, 18.10.2007 Proxy de nuevo … grid-proxy-init = “registro (login) en la Grid” Para “salir (logout)” se debe destruir el proxy: grid-proxy-destroy Esto no destruye cualquier proxy que haya sido delegado de este proxy. No se puede revocar un proxy remoto Usualmente se crean proxys con tiempos de vida cortos Para colectar información acerca del proxy: grid-proxy-info Opciones para imprimir información del proxy-subject -issuer-type -timeleft-strength -help

34. 34 La Antigua, 13th EELA Tutorial, 18.10.2007

35. 35 La Antigua, 13th EELA Tutorial, 18.10.2007 Un Proxy tiene un tiempo de vida limitado (12 h por omisión) Es mala idea tener proxys de mayor duración Sin embargo, una tarea de grid puede requerir el uso de un proxy por un tiempo más largo Los trabajos de Grid en los “HEP Data Challenges” sobre LCG tardaron hasta 2 días Servidor myproxy: Permite crear y almacenar un certificado de larga duración: myproxy-init -s <host_name> -s: <host_name> especifica el nombre del servidor de myproxy myproxy-info Obtiene información sobre proxy’s de larga duración almacenados myproxy-get-delegation Obtienen un nuevo proxy del servidor de MyProxy myproxy-destroy Elimina un proxy de larga duración almacenado en el servidor MyProxy Un servicio dedicado en el RB puede ser renovado automáticamente por el proxy Los servicios de transferencia de archivos en gLite validan las peticiones de los usuarios y eventualmente renuevan proxies Contactando al servidor myproxy

36. 36 La Antigua, 13th EELA Tutorial, 18.10.2007

37. 37 La Antigua, 13th EELA Tutorial, 18.10.2007 Autenticación, Autorización: pre-VOMS Autenticación El usuario recibe un certificado firmado por la CA Se conecta a una “UI” por ssh Descarga el certificado Se registra en la Grid -creando un proxy- entonces la Infraestructura de Seguridad Grid identifica al usuario en otras máquinas Autorización EL usuario se une a una Organización Virtual (VO) La VO negocia el acceso a los nodos y recursos de Grid Autorización verificada por el CE gridmapfile asocia usuarios a cuentas locales

38. 38 La Antigua, 13th EELA Tutorial, 18.10.2007 Los usuarios de Grid DEBEN pertenecer a organizaciones virtuales Lo que anteriormente se llamó “grupos” Conjuntos de usuarios pertenecientes a un equipo de trabajo El usuario debe firmar las reglas de uso de la VO Esperar a ser registrado en el servidor de la VO (esperar notificación) Las VOs mantienen una lista de sus miembros en un servidor LDAP La lista es descargada por máquinas de la grid para asociar sujetos de un certificado de usuario en un “pool” de cuentas locales. /etc/grid-security/grid-mapfile Cada sitio decide qué VOs aceptar

39. 39 La Antigua, 13th EELA Tutorial, 18.10.2007 Evolución en la administración de VOs Antes VOMS El Usuario es autorizado como un miembro de una única VO Todos los miembros de una VO tienen los mismos permisos Los gridmapfiles son actualizados por el software de administración de la VO: asocia el DN del usuario a una cuenta local grid-proxy-init – crea un proxy de un certificado – el “single sign-on a la grid” VOMS Un Usuario puede estar en múltiples VOs Permisos adicionales Una VO puede tener grupos Permisos diferentes para cada Grupo de experimentos diferentes … Grupos anidados VO tiene roles Asignados a propósitos específicos p.e. administrador de sistemas Cuándo asumir este rol El certificado Proxy porta los atributos adicionales voms-proxy-init VOMS: roles are supported in VO, proxy contains VO information unlike in GSI “blahp” another q manager. Jobs come via torgu Now gLite 1.1 IN gLite 1.2, from ~22 July (?) R-GMA only, not BDII (slow with updates), R-GMA better w realtime VOMS: roles are supported in VO, proxy contains VO information unlike in GSI “blahp” another q manager. Jobs come via torgu Now gLite 1.1 IN gLite 1.2, from ~22 July (?) R-GMA only, not BDII (slow with updates), R-GMA better w realtime

40. 40 La Antigua, 13th EELA Tutorial, 18.10.2007

41. 41 La Antigua, 13th EELA Tutorial, 18.10.2007 VOMS - componentes

42. 42 La Antigua, 13th EELA Tutorial, 18.10.2007 Proceso de registro

43. 43 La Antigua, 13th EELA Tutorial, 18.10.2007 EELA VO Reglas de Uso(http://roc.eu-eela.org/eela_aup.php)

44. 44 La Antigua, 13th EELA Tutorial, 18.10.2007 EELA VOMS(https://voms.lip.pt:8443/voms/EELA/)

45. 45 La Antigua, 13th EELA Tutorial, 18.10.2007 EELA Registro (1/6)(https://voms.lip.pt:8443/voms/eela/webui/request/user/create)

46. 46 La Antigua, 13th EELA Tutorial, 18.10.2007 EELA Registro (2/6)

47. 47 La Antigua, 13th EELA Tutorial, 18.10.2007 EELA Registro (3/6)

48. 48 La Antigua, 13th EELA Tutorial, 18.10.2007 EELA Registro (4/6)

49. 49 La Antigua, 13th EELA Tutorial, 18.10.2007 EELA Registro (5/6)

50. 50 La Antigua, 13th EELA Tutorial, 18.10.2007 EELA Registro (6/6)

51. 51 La Antigua, 13th EELA Tutorial, 18.10.2007

52. 52 La Antigua, 13th EELA Tutorial, 18.10.2007

53. 53 La Antigua, 13th EELA Tutorial, 18.10.2007 Grupos El número de usuarios de una VO puede ser muy alto: Por ejemplo. el experimento ATLAS tiene 2000 miembros Hacer una VO manejable organizando a los usuarios en grupos: Ejemplos: VO GILDA Group Catania INFN Group Barbera University Group Padua VO GILDA /GILDA/TUTORS puede escribir en almacenamiento normal /GILDA/STUDENT sólo puede escribir en espacio volátil Los Grupos pueden tener una estructura jerárquica, indefinidamente profunda

54. 54 La Antigua, 13th EELA Tutorial, 18.10.2007 Roles Los Roles son atributos específicos que un usuario tiene y que lo distingue de otros en su grupo: Administrador de Software Administrador-VO Diferencia entre roles y grupos: Los Roles no tienen una estructura jerárquica – no hay sub-roles Los Roles no se usan en una ‘operación normal’ No se agregan al proxy por omisión cuando se ejecuta el voms-proxy-init Pueden ser agregados al proxy para propósitos especiales cuando se ejecuta el voms-proxy-init Ejemplo: Usuario Emidio tiene las siguientes membresías VO=gilda, Group=tutors, Role=SoftwareManager Durante una operación normal el role no se toma en cuenta, Emidio puede trabajar como un usuario normal. Para casos especiales el puede obtener el role de “Software Manager”.

55. 55 La Antigua, 13th EELA Tutorial, 18.10.2007

56. 56 La Antigua, 13th EELA Tutorial, 18.10.2007 Certificados de usuario: Certificado: $X509_USER_CERT (default: $HOME/.globus/usercert.pem) Llave privada: $X509_USER_KEY (default: $HOME/.globus/userkey.pem) Proxy: $X509_USER_PROXY (default: /tmp/x509up_u<id>) Archivos de certificado de Host: Certificado $X509_HOST_CERT (default: /etc/grid-security/hostcert.pem) Llave privada $X509_HOST_KEY (default: /etc/grid-security/hostkey.pem) Certificados de Autoridad confiables: $X509_CERT_DIR (default: /etc/grid-security/certificates) Llaves públicas de servidor Voms $X509_VOMS_DIR (default: /etc/grid-security/vomsdir)

57. 57 La Antigua, 13th EELA Tutorial, 18.10.2007 Grid Seguridad LCG: http://proj-lcg-security.web.cern.ch/proj-lcg-security/ Registro VOMS EELA: https://voms.lip.pt:8443/voms/EELA/webui/request/user/create EELA ROC: http://roc.eu-eela.org Globus Security Infrastructure: http://www.globus.org/security/ VOMS: http://infnforge.cnaf.infn.it/projects/voms CA: http://www.tagpma.org/ Background Seguridad GGF: http://www.gridforum.org/security/ Estatutos IETF PKIX: http://www.ietf.org/html.charters/pkix-charter.html PKCS: http://www.rsasecurity.com/rsalabs/pkcs/index.html