1 / 55

Autorización y Autenticación en gLite

Autorización y Autenticación en gLite . Juan Eduardo Murrieta León DGSCA - UNAM Thirteenth EELA Tutorial La Antigua, 18.10.2007. Agenda. Glosario Cifrado Algoritmos Simétricos Algoritmos Asimétricos: PKI Certificados Firmas Digitales Certificados X509 Seguridad en Grid

deanne
Download Presentation

Autorización y Autenticación en gLite

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Agenda • 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 La Antigua, 13th EELA Tutorial, 18.10.2007

  3. Glosario • 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 La Antigua, 13th EELA Tutorial, 18.10.2007

  4. K1 K2 Cifrado Descifrado M C M Criptografía • Algoritmos matemáticos proporcionan los bloques de construcción requeridos para la implementación de una infraestructura de seguridad • Simbología • Texto plano: M • Texto cifrado: C • Cifrado con la llave K1: E K1(M) = C • Descifrado con la llave K2: D K2(C) = M • Algoritmos • Simétricos: K1 = K2 • Asimétricos: K1 ≠ K2 La Antigua, 13th EELA Tutorial, 18.10.2007

  5. Algoritmos Simétricos • La misma llave se usa para cifrar y descifrar • Ventajas: • Rápido • Desventajas: • ¿cómo distribuir las llaves? • El número de llaves es O(n2) • Ejemplos: • DES • 3DES • Rijndael (AES) • Blowfish • Kerberos María Pedro hola 3$r 3$r hola María Pedro hola 3$r 3$r hola La Antigua, 13th EELA Tutorial, 18.10.2007

  6. Pablo Juan hola 3$r 3$r hola Pablo Juan pública hola cy7 cy7 hola Llaves Pablo Llaves Juan pública privada privada Algoritmos de llave pública • Cada usuario tiene dos llaves: una privada y una pública: • es imposible derivar la llave privada de la llave pública; • Un mensaje cifrado con una llave sólo puede ser descifrado por la otra. • No es necesario el intercambio de secretos • El remitente cifra usando la llave pública del destinatario; • El receptor descifra usando su llave privada; • El número de llaves es O(n). • Ejemplos: • Diffie-Helmann (1977) • RSA (1978) La Antigua, 13th EELA Tutorial, 18.10.2007

  7. Este es algún mensaje Firma Digital Este es algún mensaje Llaves Pablo = ? Firma Digital pública privada Firma Digital Pablo • Pablo calcula el hash del mensaje (con una función hash inyectiva) • Pablo cifra el hash usando su llave privada: el hash cifrado es la firma digital. • Pablo envía el mensaje firmado a Juan. • Juan calcula el hash del mensaje y lo verifica con el hash descifrado de la firma digital utilizando la llave públicade Pablo. • Si los dos hashe son iguales: el mensaje no fue modificado; Pablo no puede repudiarlo. Este es algún mensaje Hash(A) Firma Digital Juan Hash(B) Hash(A) La Antigua, 13th EELA Tutorial, 18.10.2007

  8. Certificados Digitales • 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”. La Antigua, 13th EELA Tutorial, 18.10.2007

  9. PGP “red de confianza” D B F C E A • F conoce D y E, quien conoce A y C, quien conoce A y B. • F está razonablemente segura de que la llave de Aes realmente deA. La Antigua, 13th EELA Tutorial, 18.10.2007

  10. X.509 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 La Antigua, 13th EELA Tutorial, 18.10.2007

  11. Certificados X.509 • Un Certificado X.509 contiene: • la llave pública del propietario; • identidad del propietario; • información sobre la CA; • vigencia; • número de serie; • firma digital de la CA Estructura de un certificado X.509 Public key Subject:C=CH, O=CERN, OU=GRID, CN=Andrea Sciaba 8968 Issuer: C=CH, O=CERN, OU=GRID, CN=CERN CA Expiration date: Aug 26 08:08:14 2005 GMT Serial number: 625 (0x271) CA Digital signature La Antigua, 13th EELA Tutorial, 18.10.2007

  12. Seguridad en GRID: los jugadores Usuarios • Población amplia y dinámica • Cuentas diferentes en sitios diferentes • Datos personales y confidenciales • Privilegios heterogéneos (roles) • Deseable el registro único (login) “Grupos” “Agrupar” datos Patrones de Acceso Membresías Grid Recursos Heterogéneos Patrones de Acceso Políticas Locales Membresía Sites La Antigua, 13th EELA Tutorial, 18.10.2007

  13. Infraestructura de Seguridad en Grid (GSI) certificado de Juan frase aleatoria frase cifrada Comparar con la frase original Basada en PKI X.509: Juan Pablo • cada usuario/host/servicio tiene un certificado X.509; • los certificados son firmados por CA’s confiables (para los sitios locales); • cada transacción de Grid es mutuamente autenticada: • Juan envía su certificado; • Pablo verifica la firma en el certificado de Juan; • Pablo envía a Juan una cadena de prueba; • Juan cifra la cadena de prueba con su llave privada; • Juan envía la cadena cifrada a Pablo • Pablo usa la llave pública de Juan para descifrar la cadena. • Pablo compara la cadena cifrada con la cadena original. • Si son iguales, Pablo verifica la identidad de Juan y Juan no puede repudiarlo. MUY IMPORTANTE Las llaves privadas deben almacenarse sólo: en lugares protegidos Y en forma cifrada Verifica la firma de la CA Cifrar con la llave privada de J. Descifrar con la llave pública de J. La Antigua, 13th EELA Tutorial, 18.10.2007

  14. 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. La Antigua, 13th EELA Tutorial, 18.10.2007

  15. IGTF International Grid Trust Federation (Working to Establish Worldwide Trust for Grids) www.gridpma.org International Grid Trust Federation APGridPMA TAGPMA AIST Japan APAC Australia ASGCC Taiwan SDG China IHEP China KISTI Korea Naregi Japan BMG Singapore CMSD India HKU Hong Kong NCHC Taiwan Osaka U. Japan USM Malaysia NorduGrid Nordic countries PolishGrid Poland Russian Datagrid Russia SlovakGrid Slovakia DataGrid-ES Spain UK e-Science United Kingdom BelnetGrid Belgium Grid-PK Pakistan FNAL Grid USA GridCanada Canada DOEGrids USA ArmeSFo Armenia IUCC Israel ASCCG Taiwan SeeGrid Europe RMKI Hungary SWITCH Switzerland DFN Germany RDIG Russia LIP CA Portugal CERN CA Switzerland ArmeSFO Armenia CNRS Grid France CyGrid Cyprus CESNET Czech DutchGrid Netherlands GermanGrid Germany HellasGrid Greece GridIreland Ireland INFN CA Italy Belnet Belgium Grid-PK Pakistan SIGNET Slovenia EstonianGrid Estonia AustrianGrid Austria NIIF/HungarNet Hungary IHEP China BalticGrid Europe TR-Grid Turkey EELA Dartmouth College Texas High Energy Grid FNAL USA SDSC Centre TeraGrid Open Science Grid DOEGrids CANARIE La Antigua, 13th EELA Tutorial, 18.10.2007

  16. 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 La Antigua, 13th EELA Tutorial, 18.10.2007

  17. 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. CA Univ A Univ B Univ C Univ D Univ E Univ F Univ G RA RA RA RA RA RA RA RA La Antigua, 13th EELA Tutorial, 18.10.2007

  18. Perfil clásico de una CA • Cómo obtener un certificado: Request Se realiza una solicitud de certificado La identidad del solicitante es confirmada por la RA El certificado se utiliza como una llave para acceder a la grid El certificado es emitido por la CA La Antigua, 13th EELA Tutorial, 18.10.2007

  19. Emisión de certificados en más detalle Solicitud con llave pública 3.Transferencia manual de la solicitud 1. Solicitud del usuario, un par de llaves Privada/Pública es generada. La llave privada se mantiene del lado del usuario 5.Transferencia manual del certificado Servidor CA 2.Se verifica la identidad por una RA 6.Descarga del certificado Llave privada de la CA 4.Firma de la CA Máquina de firmado (fuera de línea) La Antigua, 13th EELA Tutorial, 18.10.2007

  20. 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:// La Antigua, 13th EELA Tutorial, 18.10.2007

  21. 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 La Antigua, 13th EELA Tutorial, 18.10.2007

  22. 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. La Antigua, 13th EELA Tutorial, 18.10.2007

  23. 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) La Antigua, 13th EELA Tutorial, 18.10.2007

  24. 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) La Antigua, 13th EELA Tutorial, 18.10.2007

  25. 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 La Antigua, 13th EELA Tutorial, 18.10.2007

  26. 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) La Antigua, 13th EELA Tutorial, 18.10.2007

  27. 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. La Antigua, 13th EELA Tutorial, 18.10.2007

  28. 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. La Antigua, 13th EELA Tutorial, 18.10.2007

  29. 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. La Antigua, 13th EELA Tutorial, 18.10.2007

  30. Certificado Proxy X.509 • 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 La Antigua, 13th EELA Tutorial, 18.10.2007

  31. Certificado del usuario Certificado Proxy del usuario Llave Privada (cifrada) Palabra clave grid-proxy-init • El usuario introduce una palabra clave, que se utiliza para descifrar la llave privada. • La llave privada se utiliza para firmar un certificado proxy con su propio nuevo par de llaves pública y privada. • La llave privada del usuario no se expone después de que el proxy a sido firmado • El archivo con el certificado se coloca en /tmp • La llave privada del Proxy no está cifrada: • almacenada en un archivo local: debe ser legible sólo por el propietario; • El tiempo de vida del proxy es corta (típicamente 12 h) para minimizar riesgos de seguridad. • NOTA: ¡No hay ningún tráfico de red ! La Antigua, 13th EELA Tutorial, 18.10.2007

  32. 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 La Antigua, 13th EELA Tutorial, 18.10.2007

  33. Delegación • Delegación = creación remota (segundo nivel) de una credencial proxy • Se genera un par de llaves en el servidor remoto • El cliente firma el certificado proxy y lo retorna • Permite el proceso de autenticación de procesos remotos en nombre del usuario • Los procesos remotos “imitan” al usuario La Antigua, 13th EELA Tutorial, 18.10.2007

  34. Proxy de larga duración • 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 La Antigua, 13th EELA Tutorial, 18.10.2007

  35. UI MyProxy Server myproxy-init myproxy-get-delegation GENIUS Server (UI) WEB Browser execution Local WS output the Grid any grid service Autenticación en Grid con MyProxy La Antigua, 13th EELA Tutorial, 18.10.2007

  36. 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 UI Autenticación, Autorización: pre-VOMS CA Personal/ una vez AUP VO mgr VO service VO database GSI Actualización diaria Gridmapfilesen servicios de Grid La Antigua, 13th EELA Tutorial, 18.10.2007

  37. VOs y autorización • 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 ... "/C=CH/O=CERN/OU=GRID/CN=Simone Campana 7461" .dteam "/C=CH/O=CERN/OU=GRID/CN=Andrea Sciaba 8968" .cms "/C=CH/O=CERN/OU=GRID/CN=Patricia Mendez Lorenzo-ALICE" .alice ... La Antigua, 13th EELA Tutorial, 18.10.2007

  38. 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 Evolución en la administración de VOs La Antigua, 13th EELA Tutorial, 18.10.2007

  39. VOMS: conceptos • Servicio de Membresía de Organización Virtual • Extiende el proxy con información sobre membresía, grupo, roles de la VO • Totalmente compatible con el Globus Toolkit • Cada VO tiene una base de datos que contiene un grupo de membresías, roles y capacidades de cada usuario • El usuario contacta al servidor voms solicitando su autorización • El servidor envía información de la autorización al cliente, el cual la incluye en su certificado proxy. [glite-tutor] /home/giorgio > voms-proxy-init --voms gilda Cannot find file or dir: /home/giorgio/.glite/vomses Your identity: /C=IT/O=GILDA/OU=Personal Certificate/L=INFN/CN=Emidio Giorgio/Email=emidio.giorgio@ct.infn.it Enter GRID pass phrase: Your proxy is valid until Mon Jan 30 23:35:51 2006 Creating temporary proxy.................................Done Contacting voms.ct.infn.it:15001 [/C=IT/O=GILDA/OU=Host/L=INFN Catania/CN=voms.ct.infn.it/Email=emidio.giorgio@ct.infn.it] "gilda" Creating proxy ...................................... Done Your proxy is valid until Mon Jan 30 23:35:51 2006 La Antigua, 13th EELA Tutorial, 18.10.2007

  40. VOMS - componentes • Authz DB es un RDBMS (actualmente MySQL y Oracle están soportados). La Antigua, 13th EELA Tutorial, 18.10.2007

  41. VO USER VOMS SERVER VO ADMIN Solicitud de membresía vía interfaz Web Petición de confirmación vía correo electrónico Confirmación de la dirección de correo Petición de notificación aceptado / negado vía interfaz web crear usuario (si es aceptado) Notificación de aceptado/negado Proceso de registro La Antigua, 13th EELA Tutorial, 18.10.2007

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

  43. EELA VOMS(https://voms.lip.pt:8443/voms/EELA/) Nuevos registros ent: https://voms.lip.pt:8443/voms/EELA/webui/request/user/create La Antigua, 13th EELA Tutorial, 18.10.2007

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

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

  46. EELA Registro (3/6) E-mail address confirmation for VO eelaA request for a VO membership on eela has been made using this email address.If you have not made this request please ignore this message. It would be helpful if you would contact the VO registrar and tell us about this bogus request.If the request was made by you, please click on the following URL to confirm this email address, https://voms.lip.pt:8443/voms/eela/webui/request/user/confirm?cookie=xlqi8oy6fudv0wod&reqid=21Make sure you have your client certificate loaded in your browser.One way to ensure this is to copy and paste the above URL into the same browser that you used to submit the request.If you wish to confirm the request another way, then you need the following information:Request number : 21Confirmation cookie: xlqi8oy6fudv0wod La Antigua, 13th EELA Tutorial, 18.10.2007

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

  48. EELA Registro (5/6) Dear Scardaci, Diego,Thank you for confirming your email address. Your request for an account on VO eela has been sent to the VO administrators.A VO administrator will probably contact you to confirm account creation.If you find any problems regarding the account registration, then please contact the VO registrar.Thank You,VO Registration La Antigua, 13th EELA Tutorial, 18.10.2007

  49. EELA Registro (6/6) Welcome to the eela VO!Dear Scardaci, Diego,Your request (21) for the eela VO has been accepted and allowed by the VO Administrator.From this point you can use the voms-proxy-init command to acquire the VO specific credentials, which will enable you to use the resources of this VO.Good Luck,VO Registration La Antigua, 13th EELA Tutorial, 18.10.2007

  50. FQAN y AC • Abreviación de “Fully Qualified Attribute Name”, es lo que VOMS usa para expresar membresía y otra información de autorización • Grupos de membresías, roles y capacidades pueden estar expresados en un formato que los agrupe<group>/Role=[<role>][/Capability=<capability>] • FQAN están incluidos en un Atributo del Certificado • Los Atributos de Certificados son usados para ligar un conjunto de atributos (como membresía, roles, autorización, información, etc) con una identidad • Los AC están firmados digitalmente • VOMS usa AC para incluir los atributos de un usuario en un certificado proxy [glite-tutor] /home/giorgio > voms-proxy-info -fqan /gilda/Role=NULL/Capability=NULL /gilda/tutors/Role=NULL/Capability=NULL La Antigua, 13th EELA Tutorial, 18.10.2007

More Related