fp62004infrastructures6-ssa-026409 e-infrastructure shared between europe and latin america...

55
FP6−2004−Infrastructures−6-SSA-026409 www.eu-eela.org E-infrastructure shared between Europe and Latin America Autorización y Autenticación en gLite Juan Eduardo Murrieta León DGSCA - UNAM Tutorial para Usuarios Ciudad de México, 23.10.2007

Upload: bernardo-fermin

Post on 14-Apr-2015

3 views

Category:

Documents


0 download

TRANSCRIPT

  • Diapositiva 1
  • FP62004Infrastructures6-SSA-026409 www.eu-eela.org E-infrastructure shared between Europe and Latin America Autorizacin y Autenticacin en gLite Juan Eduardo Murrieta Len DGSCA - UNAM Tutorial para Usuarios Ciudad de Mxico, 23.10.2007
  • Diapositiva 2
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 2 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Agenda Glosario Cifrado Algoritmos Simtricos Algoritmos Asimtricos: PKI Certificados Firmas Digitales Certificados X509 Seguridad en Grid Conceptos bsicos Infraestructura de Seguridad en Grid Certificados Proxy Interfaces en lnea de comandos Organizaciones Virtuales Concepto de VO y autorizacin VOMS, LCAS, LCMAPS
  • Diapositiva 3
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 3 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Glosario Principal Una entidad: un usuario, un programa, o una mquina Credenciales Algn dato que proporciona una prueba de identidad Autenticacin Verificar la identidad de un principal Autorizacin Mapeo de una entidad hacia algn conjunto de privilegios Confidencialidad Cifrar el mensaje de manera que slo el receptor pueda comprenderlo Integridad Garantizar que el mensaje no ha sido alterado en la transmisin No-repudio Imposibilidad de negar la autenticidad de una firma digital
  • Diapositiva 4
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 4 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Algoritmos matemticos proporcionan los bloques de construccin requeridos para la implementacin de una infraestructura de seguridad Simbologa Texto plano: M Texto cifrado: C Cifrado con la llave K 1 : E K 1 (M) = C Descifrado con la llave K 2 : D K 2 (C) = M Algoritmos Simtricos Simtricos: K 1 = K 2 Asimtricos Asimtricos: K 1 K 2 K2K2 K1K1 Cifrado Descifrado MCM Criptografa
  • Diapositiva 5
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 5 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 La misma llave se usa para cifrar y descifrar Ventajas: Rpido Desventajas: cmo distribuir las llaves? El nmero de llaves es O(n 2 ) Ejemplos: DES 3DES Rijndael (AES) Blowfish Kerberos MaraPedro hola3$rhola MaraPedro hola3$rhola3$r Algoritmos Simtricos
  • Diapositiva 6
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 6 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Cada usuario tiene dos llaves: una privada y una pblica: es imposible derivar la llave privada de la llave pblica; Un mensaje cifrado con una llave slo puede ser descifrado por la otra. No es necesario el intercambio de secretos El remitente cifra usando la llave pblica del destinatario; El receptor descifra usando su llave privada; El nmero de llaves es O(n). Ejemplos: Diffie-Helmann (1977) RSA (1978) Llaves Juan pblica privada Llaves Pablo pblicaprivada PabloJuan hola3$rhola PabloJuan holacy7hola 3$r cy7 Algoritmos de llave pblica
  • Diapositiva 7
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 7 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Pablo calcula el h hh hash del mensaje (con una funcin hash inyectiva) Pablo cifra el hash usando su llave p pp privada: el hash cifrado es la f ff firma digital. Pablo enva el mensaje firmado a Juan. Juan calcula el hash del mensaje y lo v vv verifica con el hash descifrado de la firma digital utilizando la llave pblica de Pablo. Si los dos hashe son iguales: el mensaje no fue modificado; Pablo no puede repudiarlo. Juan Este es algn mensaje Firma Digital Pablo Este es algn mensaje Firma Digital Este es algn mensaje Firma Digital Hash(A) Llaves Pablo pblicaprivada Hash(B) Hash(A) = ? Firma Digital
  • Diapositiva 8
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 8 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 La firma digital de Pablo es segura si: 1. La llave privada de Pablo no est comprometida 2. Juan conoce la llave pblica de Pablo Cmo puede Juan estar seguro de que la llave pblica de Pablo es realmente la llave pblica de Pablo y no la de alguien ms? Una tercera parte garantiza la correspondencia entre la llave pblica y la identidad del propietario. Tanto A como B deben confiar en esta tercera parte. Dos modelos: X.509: organizacin jerrquica; PGP: red de confianza. Certificados Digitales
  • Diapositiva 9
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 9 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 PGP red de confianza A B C D E F 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.
  • Diapositiva 10
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 10 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 X.509 Autoridad Certificadora La tercera parte es llamada Autoridad Certificadora (CA). Certificados DigitalesEmite Certificados Digitales (que contienen la llave pblica y la identidad de su propietario) para usuarios, programas y mquinas (firmados por la CA) Verifica la identidad y datos personales del solicitante Autoridades de Registro (RAs) hacen la validacin actualmente Las CAs peridicamente publican una lista de los certificados comprometidos Listas de Revocacin de Certificados (CRL): contienen todos los certificados revocados an por expirar Los certificados de las CAs son auto-firmados
  • Diapositiva 11
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 11 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Un Certificado X.509 contiene: lla llave pblica del propietario; iidentidad del propietario; iinformacin sobre la CA; vvigencia; nnmero de serie; ffirma digital de la CA 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 Estructura de un certificado X.509 Certificados X.509
  • Diapositiva 12
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 12 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Poblacin amplia y dinmica Cuentas diferentes en sitios diferentes Datos personales y confidenciales Privilegios heterogneos (roles) Deseable el registro nico (login) Usuarios Agrupar datos Patrones de Acceso Membresas Grupos Sites Recursos Heterogneos Patrones de Acceso Polticas Locales Membresa Grid Seguridad en GRID: los jugadores
  • Diapositiva 13
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 13 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 cada usuario/host/servicio tiene un certificado X.509; los certificados son firmados por CAs confiables (para los sitios locales); cada transaccin de Grid es mutuamente autenticada: 1. Juan enva su certificado; 2. Pablo verifica la firma en el certificado de Juan; 3. Pablo enva a Juan una cadena de prueba; 4. Juan cifra la cadena de prueba con su llave privada; 5. Juan enva la cadena cifrada a Pablo 6. Pablo usa la llave pblica de Juan para descifrar la cadena. 7. Pablo compara la cadena cifrada con la cadena original. 8. Si son iguales, Pablo verifica la identidad de Juan y Juan no puede repudiarlo. Juan Pablo certificado de Juan Verifica la firma de la CA frase aleatoria Cifrar con la llave privada de J. frase cifrada Descifrar con la llave pblica de J. Comparar con la frase original Basada en PKI X.509: MUY IMPORTANTE Las llaves privadas deben almacenarse slo: protegidos en lugares protegidosY cifrada en forma cifrada Infraestructura de Seguridad en Grid (GSI)
  • Diapositiva 14
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 14 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Ms sobre Autenticacin En el mundo de la grid una sola CA usualmente cubre una regin geogrfica predefinida o dominio administrativo: Organizacin Pas Un conjunto de pases Un dominio de confianza comn para el cmputo en grid ha sido creado para unir las diversas autoridades de certificacin existentes en un solo dominio de autenticacin y as permitir compartir recursos de grid en el mundo. La Federacin de Confianza Internacional en Grid (IGTF) ha sido creada para coordinar y administrar estos dominios de confianza. IGTF est dividida en tres Autoridades de Polticas de Administracin (PMAs) que cubren el Asia del Pacfico, Europa y Amrica.
  • Diapositiva 15
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 15 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 IGTF International Grid Trust Federation (Working to Establish Worldwide Trust for Grids) www.gridpma.org APGridPMATAGPMA 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 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 EELA Dartmouth College Texas High Energy Grid FNAL USA SDSC Centre TeraGrid Open Science Grid DOEGrids CANARIE 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 International Grid Trust Federation
  • Diapositiva 16
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 16 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Perfil clsico de una CA Qu es: La CA firma y revoca certificados Estos son certificados de lago plazo (un ao) La CA tiene RAs subordinadas que slo desempean la tarea administrativa de verificar la identidad del sujeto en diferentes organizaciones o departamentos Ventajas: Es el perfil ms conocido de una CA Existe una gran cantidad de know-how y soluciones La mayora de las CAs operan usando el perfil clsico Es la ms fcil de soportar entre dominios administrativos diferentes La SLCS (perfil para servicios de credenciales de corta duracin) est an en desarrollo Los requerimientos del perfil son estables y controlados por EUgridPMA
  • Diapositiva 17
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 17 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Perfil clsico de una CA Se necesita de una red de RAs subordinadas para realizar la verificacin de la identidad de los sujetos Las RAs sern creadas a nivel de organizaciones o a nivel de departamentos: Operando a nivel de centro de investigacin o universidad (ms difcil) Operando a nivel de departamento o grupo La CA puede tambin operar una RA pero sin olvidar que la presencia fsica de los individuos es necesaria para la verificacin de identidad Es bueno tener ms de una RA por universidad o centro de investigacin si estn operando para departamentos diferentes Las RAs deben ser creadas slo bajo solicitud, su creacin se determina por las necesidades de los usuarios. CA RA Univ AUniv BUniv CUniv DUniv EUniv FUniv G
  • Diapositiva 18
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 18 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Perfil clsico de una CA Cmo obtener un certificado: El certificado es emitido por la CA El certificado se utiliza como una llave para acceder a la grid Se realiza una solicitud de certificado La identidad del solicitante es confirmada por la RA
  • Diapositiva 19
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 19 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Emisin de certificados en ms detalle Mquina de firmado (fuera de lnea) 1. Solicitud del usuario, un par de llaves Privada/Pblica es generada. La llave privada se mantiene del lado del usuario 2. Se verifica la identidad por una RA 6. Descarga del certificado Servidor CA Llave privada de la CA 3. Transferencia manual de la solicitud 4. Firma de la CA 5. Transferencia manual del certificado Solicitud con llave pblica
  • Diapositiva 20
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 20 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Listas de Revocacin Las CAs tienen la obligacin de emitir Listas de Revocacin de Certificados (CRL) Las CRLs contienen: una lista de los certificados revocados la fecha de cundo fueron emitidos su fecha de expiracin 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 travs de http://
  • Diapositiva 21
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 21 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Perfil clsico de una CA Debe existir una nica Autoridad Certificadora (CA) por pas, una regin amplia u organizacin internacional. Proporciona un nmero pequeo y estable de CAs Las CAs deben ser operadas con un compromiso a largo plazo Deben permanecer en operacin despus del final del proyecto Una red de Autoridades de Registro (RA) por cada CA es responsable de las peticiones de autenticacin La CA deber manejar la tarea de: emitir CRLs firmar Certificados/CRLs revocar Certificados
  • Diapositiva 22
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 22 Ciudad de Mxico, Tutorial para Usuarios, 23.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 ms de un certificado Un servidor puede tener ms 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 violacin del CP/CPS (Poltica de Certificados/Declaracin de Prcticas de Certificados) es detectada.
  • Diapositiva 23
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 23 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Perfil de la CA: CP/CPS Identificacin Cada CA debe tener una Poltica de Certificacin y Declaracin de Prcticas 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 mayora 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 vlidos deben estar disponibles en la web (muchos ejemplos se pueden encontrar en http://www.eugridpma.org/members y http://www.tagpma.org/members)http://www.eugridpma.org/members http://www.tagpma.org/members
  • Diapositiva 24
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 24 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Operacin de la RA La operacin de las RAs debe ser: de acuerdo con la CA CP/CPS definida en un documento para cada RA La operacin 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 mtodo de seleccin 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 mtodo 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: relacin con la organizacin)
  • Diapositiva 25
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 25 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Espacio de nombres de la CA/RA La definicin del espacio de nombres es responsabilidad de la CA, sin embargo dependiendo de esta definicin la RA puede tambin 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 organizacin del sujeto y tambin 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 organizacin Se utiliza para designar una RA dentro de una organizacin cuando una organizacin tiene mltiples RAs
  • Diapositiva 26
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 26 Ciudad de Mxico, Tutorial para Usuarios, 23.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 (nmero,... ) cuando se encuentran duplicados Posiblemente usar el nombre completo de la persona es la mejor opcin cada DN debe estar limitado al mismo sujeto para todo el tiempo de vida de la CA El CN debe tener una relacin clara y directa con el DN No olvidar que los certificados son para el cmputo 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 comodn) Algunos caracteres no son permitidos (por ejemplo / and. en los certificados de usuario)
  • Diapositiva 27
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 27 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Renovacin Dos tipos de renovacin: Renovacin de certificados de entidades finales Renovacin de certificados de CA Entidades Finales: El tiempo de vida mximo de un cerificado es 1 ao + 1mes La idea es que al final del ao (12 mes) un nuevo certificado sea emitido. El usuario (EE) debe ser avisado acerca de la prxima expiracin y necesidad de renovacin 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 situacin 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 das o semanas. Durante este perodo 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 relacin con las entidades que le dan derecho a un certificado.
  • Diapositiva 28
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 28 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Renovacin Entidades Finales: Durante una renovacin no es necesario hacer que la entidad final (EE) pase a travs del proceso de identificacin: Esto es una gran ventaja tanto para la EE como para la RA Sin embargo, un nmero mximo de renovaciones sin identificacin es recomendable (por ejemplo: cada dos aos la EE debe pasar por el proceso de identificacin de nuevo) Sin embargo, la relacin con la organizacin debe mantenerse (si este requerimiento se va a utilizar) Para no pasar por el proceso de identificacin la solicitud de renovacin 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 renovacin el procedimiento de solicitud de un nuevo certificado debe seguirse.
  • Diapositiva 29
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 29 Ciudad de Mxico, Tutorial para Usuarios, 23.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 institucin cuenta con una RA.
  • Diapositiva 30
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 30 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Administracin 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
  • Diapositiva 31
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 31 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Certificado Proxy X.509 La extensin 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 caractersticas importantes Delegacin Autenticacin 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 -bits -help
  • Diapositiva 32
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 32 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 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 pblica y privada. La llave privada del usuario no se expone despus 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 slo por el propietario; El tiempo de vida del proxy es corta (tpicamente 12 h) para minimizar riesgos de seguridad. NOTA: No hay ningn trfico de red ! grid-proxy-init
  • Diapositiva 33
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 33 Ciudad de Mxico, Tutorial para Usuarios, 23.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 informacin acerca del proxy: grid-proxy-info Opciones para imprimir informacin del proxy -subject-issuer -type-timeleft -strength-help
  • Diapositiva 34
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 34 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Delegacin = creacin 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 autenticacin de procesos remotos en nombre del usuario Los procesos remotos imitan al usuario Delegacin
  • Diapositiva 35
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 35 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Proxy de larga duracin Un Proxy tiene un tiempo de vida limitado (12 h por omisin) Es mala idea tener proxys de mayor duracin Sin embargo, una tarea de grid puede requerir el uso de un proxy por un tiempo ms largo Los trabajos de Grid en los HEP Data Challenges sobre LCG tardaron hasta 2 das Servidor myproxy: Permite crear y almacenar un certificado de larga duracin: myproxy-init -s -s: especifica el nombre del servidor de myproxy myproxy-info Obtiene informacin sobre proxys de larga duracin almacenados myproxy-get-delegation Obtienen un nuevo proxy del servidor de MyProxy myproxy-destroy Elimina un proxy de larga duracin almacenado en el servidor MyProxy Un servicio dedicado en el RB puede ser renovado automticamente 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
  • Diapositiva 36
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 36 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 UI Local WS MyProxy Server GENIUS Server (UI) myproxy-init any grid service myproxy-get-delegation output the Grid execution WEB Browser Autenticacin en Grid con MyProxy
  • Diapositiva 37
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 37 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Autenticacin, Autorizacin: pre-VOMS Autenticacin 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 mquinas Autorizacin EL usuario se une a una Organizacin Virtual (VO) La VO negocia el acceso a los nodos y recursos de Grid Autorizacin verificada por el CE gridmapfile asocia usuarios a cuentas locales UI AUP VO mgr Personal/ una vez VO database Gridmapfiles en servicios de Grid GSI VO service Actualizacin diaria CA
  • Diapositiva 38
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 38 Ciudad de Mxico, Tutorial para Usuarios, 23.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 notificacin) Las VOs mantienen una lista de sus miembros en un servidor LDAP La lista es descargada por mquinas 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... VOs y autorizacin
  • Diapositiva 39
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 39 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Evolucin en la administracin 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 administracin 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 mltiples VOs Permisos adicionales Una VO puede tener grupos Permisos diferentes para cada Grupo de experimentos diferentes Grupos anidados VO tiene roles Asignados a propsitos especficos p.e. administrador de sistemas Cundo asumir este rol El certificado Proxy porta los atributos adicionales voms-proxy-init
  • Diapositiva 40
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 40 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Servicio de Membresa de Organizacin Virtual Extiende el proxy con informacin sobre membresa, grupo, roles de la VO Totalmente compatible con el Globus Toolkit Cada VO tiene una base de datos que contiene un grupo de membresas, roles y capacidades de cada usuario El usuario contacta al servidor voms solicitando su autorizacin El servidor enva informacin de la autorizacin 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 protected] 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 protected]] "gilda" Creating proxy...................................... Done Your proxy is valid until Mon Jan 30 23:35:51 2006 VOMS: conceptos
  • Diapositiva 41
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 41 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 VOMS - componentes Authz DB es un RDBMS (actualmente MySQL y Oracle estn soportados).
  • Diapositiva 42
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 42 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Proceso de registro Peticin de confirmacin va correo electrnico Solicitud de membresa va interfaz Web VO ADMIN Confirmacin de la direccin de correo Peticin de notificacin aceptado / negado va interfaz web crear usuario (si es aceptado) Notificacin de aceptado/negado VO USERVOMS SERVER
  • Diapositiva 43
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 43 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 EELA VO Reglas de Uso (http://roc.eu-eela.org/eela_aup.php)
  • Diapositiva 44
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 44 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 EELA VOMS (https://voms.lip.pt:8443/voms/EELA/) Nuevos registros ent: https://voms.lip.pt:8443/voms/EELA/webui/request/user/createhttps://voms.lip.pt:8443/voms/EELA/webui/request/user/create
  • Diapositiva 45
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 45 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 EELA Registro (1/6) (https://voms.lip.pt:8443/voms/eela/webui/request/user/create)
  • Diapositiva 46
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 46 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 EELA Registro (2/6)
  • Diapositiva 47
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 47 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 EELA Registro (3/6) E-mail address confirmation for VO eela A 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&r eqid=21 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 https://voms.lip.pt:8443/voms/eela/webui/request/user/confirm?cookie=xlqi8oy6fudv0wod&r eqid=21
  • Diapositiva 48
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 48 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 EELA Registro (4/6)
  • Diapositiva 49
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 49 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 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
  • Diapositiva 50
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 50 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 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
  • Diapositiva 51
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 51 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Abreviacin de Fully Qualified Attribute Name, es lo que VOMS usa para expresar membresa y otra informacin de autorizacin Grupos de membresas, roles y capacidades pueden estar expresados en un formato que los agrupe /Role=[ ][/Capability= ] FQAN estn incluidos en un Atributo del Certificado Los Atributos de Certificados son usados para ligar un conjunto de atributos (como membresa, roles, autorizacin, informacin, etc) con una identidad Los AC estn 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 FQAN y AC
  • Diapositiva 52
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 52 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 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 extensin bien-definida, no crtica, 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 Giorgio/[email protected]/CN=proxy issuer : /C=IT/O=GILDA/OU=Personal Certificate/L=INFN/CN=Emidio Giorgio/[email protected] identity : /C=IT/O=GILDA/OU=Personal Certificate/L=INFN/CN=Emidio Giorgio/[email protected] 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 Giorgio/[email protected] issuer : /C=IT/O=GILDA/OU=Host/L=INFN Catania/CN=voms.ct.infn.it/[email protected] attribute : /gilda/tutors/Role=NULL/Capability=NULL attribute : /gilda/Role=NULL/Capability=NULL timeleft : 11:59:45 VOMS y AC
  • Diapositiva 53
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 53 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Grupos El nmero 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 oGroup Barbera University Group Padua VO GILDA /GILDA/TUTORS puede escribir en almacenamiento normal /GILDA/STUDENT slo puede escribir en espacio voltil Los Grupos pueden tener una estructura jerrquica, indefinidamente profunda
  • Diapositiva 54
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 54 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 Roles Los Roles son atributos especficos 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 jerrquica no hay sub-roles Los Roles no se usan en una operacin normal No se agregan al proxy por omisin cuando se ejecuta el voms-proxy-init Pueden ser agregados al proxy para propsitos especiales cuando se ejecuta el voms-proxy-init Ejemplo: Usuario Emidio tiene las siguientes membresas VO=gilda, Group=tutors, Role=SoftwareManager Durante una operacin 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.
  • Diapositiva 55
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 55 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 LCAS & LCMAPS A nivel de recursos, la informacin de autorizacin se extrae del proxy y se procesa por LCAS y LCMAPS Servicio de Autorizacin 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 tambin 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 LCAS & LCMAPS
  • Diapositiva 56
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 56 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 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 ) 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 pblicas de servidor Voms $X509_VOMS_DIR (default: /etc/grid-security/vomsdir )
  • Diapositiva 57
  • E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA-026409 57 Ciudad de Mxico, Tutorial para Usuarios, 23.10.2007 GridGrid Seguridad LCG: http://proj-lcg-security.web.cern.ch/proj-lcg-security/http://proj-lcg-security.web.cern.ch/proj-lcg-security/ Registro VOMS EELA: https://voms.lip.pt:8443/voms/EELA/webui/request/user/create https://voms.lip.pt:8443/voms/EELA/webui/request/user/create EELA ROC: http://roc.eu-eela.orghttp://roc.eu-eela.org Globus Security Infrastructure: http://www.globus.org/security/http://www.globus.org/security/ VOMS: http://infnforge.cnaf.infn.it/projects/vomshttp://infnforge.cnaf.infn.it/projects/voms CA: http://www.tagpma.org/http://www.tagpma.org/ BackgroundBackground Seguridad GGF: http://www.gridforum.org/security/http://www.gridforum.org/security/ Estatutos IETF PKIX: http://www.ietf.org/html.charters/pkix-charter.htmlhttp://www.ietf.org/html.charters/pkix-charter.html PKCS: http://www.rsasecurity.com/rsalabs/pkcs/index.htmlhttp://www.rsasecurity.com/rsalabs/pkcs/index.html Referencias