Autorización y Autenticación en gLite

Presentación del tema: "Autorización y Autenticación en gLite"— Transcripción de la presentación:

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

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,

3 Glosario Principal Credenciales Autenticación Autorización
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,

4 Criptografía K1 Cifrado Descifrado
M C 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,

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,

6 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) Llaves Juan pública privada Llaves Pablo Pablo Juan hola 3$r cy7 La Antigua, 13th EELA Tutorial,

7 Firma Digital 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ública de Pablo. Si los dos hashe son iguales: el mensaje no fue modificado; Pablo no puede repudiarlo. Pablo Este es algún mensaje Firma Digital Este es algún mensaje Hash(A) Firma Digital Juan Este es algún mensaje Firma Digital Hash(B) = ? Hash(A) Llaves Pablo pública privada La Antigua, 13th EELA Tutorial,

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,

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 A es realmente de A. La Antigua, 13th EELA Tutorial,

10 La “tercera parte” es llamada Autoridad Certificadora (CA).
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,

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: GMT Serial number: 625 (0x271) CA Digital signature La Antigua, 13th EELA Tutorial,

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,

13 deben almacenarse sólo:
Infraestructura de Seguridad en Grid (GSI) 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. certificado de Juan MUY IMPORTANTE Las llaves privadas deben almacenarse sólo: en lugares protegidos Y en forma cifrada Verifica la firma de la CA frase aleatoria Cifrar con la llave privada de J. frase cifrada Descifrar con la llave pública de J. Comparar con la frase original La Antigua, 13th EELA Tutorial,

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,

15 (Working to Establish Worldwide Trust for Grids)
IGTF International Grid Trust Federation (Working to Establish Worldwide Trust for Grids) 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,

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,

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 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,

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 Servidor CA 5. Transferencia manual del certificado 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,

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

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,

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,

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 y La Antigua, 13th EELA Tutorial,

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,

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,

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,

27 Renovación Dos tipos de renovación: Entidades Finales:
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,

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,

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,

30 Administración de Certificados
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 La Antigua, 13th EELA Tutorial,

31 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,

32 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 Certificado del usuario Llave Privada (cifrada) Palabra clave Certificado Proxy del usuario 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,

33 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,

34 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,

35 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,

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

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

38 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,

39 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 La Antigua, 13th EELA Tutorial,

40 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 Enter GRID pass phrase: Your proxy is valid until Mon Jan 30 23:35: Creating temporary proxy Done Contacting voms.ct.infn.it:15001 [/C=IT/O=GILDA/OU=Host/L=INFN "gilda" Creating proxy Done La Antigua, 13th EELA Tutorial,

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

42 Proceso de registro VO ADMIN VO USER VOMS SERVER
Petición de confirmación vía correo electrónico Solicitud de membresía vía interfaz Web VO ADMIN 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 VO USER VOMS SERVER La Antigua, 13th EELA Tutorial,

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

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

45 EELA Registro (1/6) (https://voms. lip
La Antigua, 13th EELA Tutorial,

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

47 EELA Registro (3/6) address confirmation for VO eela A request for a VO membership on eela has been made using this 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 address, Make 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 : 21 Confirmation cookie: xlqi8oy6fudv0wod La Antigua, 13th EELA Tutorial,

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

49 EELA Registro (5/6) Dear Scardaci, Diego, Thank you for confirming your 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,

50 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,

51 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,

52 VOMS y AC El Servidor crea y firma un AC que contiene el FQAN solicitado por el usuario, si aplica. El AC es incluido por el cliente en una extensión bien-definida, no crítica, garantizando la compatibilidad con el mecanismo basado en el GT /home/giorgio > voms-proxy-info -all subject : /C=IT/O=GILDA/OU=Personal Certificate/L=INFN/CN=Emidio issuer : /C=IT/O=GILDA/OU=Personal Certificate/L=INFN/CN=Emidio identity : /C=IT/O=GILDA/OU=Personal Certificate/L=INFN/CN=Emidio type : proxy strength : 512 bits path : /tmp/x509up_u513 timeleft : 11:59:52 === VO gilda extension information === VO : gilda subject : /C=IT/O=GILDA/OU=Personal Certificate/L=INFN/CN=Emidio issuer : /C=IT/O=GILDA/OU=Host/L=INFN attribute : /gilda/tutors/Role=NULL/Capability=NULL attribute : /gilda/Role=NULL/Capability=NULL timeleft : 11:59:45 La Antigua, 13th EELA Tutorial,

53 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 /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 La Antigua, 13th EELA Tutorial,

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

55 LCAS & LCMAPS LCAS & LCMAPS
A nivel de recursos, la información de autorización se extrae del proxy y se procesa por LCAS y LCMAPS Servicio de Autorización Local Central (LCAS) Verifica si el usuario está autorizado (usando el grid-mapfile) Verifica si el usuario está boletinado en el sitio Verifica si en ese momento el sitio acepta trabajos Servicio de Manejo de Credenciales Local (LCMAPS) Asocia las credenciales de grid a credenciales locales (en UNIX uid/gid, en AFS tokens, etc.) Asocia también el grupo VOMS y los roles (soporte total de FQAN) "/VO=cms/GROUP=/cms" cms "/VO=cms/GROUP=/cms/prod" cmsprod "/VO=cms/GROUP=/cms/prod/ROLE=manager" .cmsprodman La Antigua, 13th EELA Tutorial,

56 Variables de ambiente GSI
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) La Antigua, 13th EELA Tutorial,

57 Referencias Grid Seguridad LCG: Registro VOMS EELA: EELA ROC: Globus Security Infrastructure: VOMS: CA: Background Seguridad GGF: Estatutos IETF PKIX: PKCS: La Antigua, 13th EELA Tutorial,