La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

FP62004Infrastructures6-SSA-026409 www.eu-eela.org E-infrastructure shared between Europe and Latin America Autorización y Autenticación en gLite Juan.

Presentaciones similares


Presentación del tema: "FP62004Infrastructures6-SSA-026409 www.eu-eela.org E-infrastructure shared between Europe and Latin America Autorización y Autenticación en gLite Juan."— Transcripción de la presentación:

1 FP62004Infrastructures6-SSA E-infrastructure shared between Europe and Latin America Autorización y Autenticación en gLite Juan Eduardo Murrieta León DGSCA - UNAM Thirteenth EELA Tutorial La Antigua,

2 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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

3 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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

4 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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 K 1 : E K 1 (M) = C –Descifrado con la llave K 2 : D K 2 (C) = M Algoritmos –Simétricos –Simétricos: K 1 = K 2 –Asimétricos –Asimétricos: K 1 K 2 K2K2 K1K1 Cifrado Descifrado MCM Criptografía

5 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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(n 2 ) Ejemplos: –DES –3DES –Rijndael (AES) –Blowfish –Kerberos MaríaPedro hola3$rhola MaríaPedro hola3$rhola3$r Algoritmos Simétricos

6 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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 públicaprivada PabloJuan hola3$rhola PabloJuan holacy7hola 3$r cy7 Algoritmos de llave pública

7 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, Pablo calcula el h hh hash del mensaje (con una función hash inyectiva) Pablo cifra el hash usando su llave p pp privada: el hash cifrado es la f ff firma digital. Pablo envía 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 pública de Pablo. Si los dos hashe son iguales: el mensaje no fue modificado; Pablo no puede repudiarlo. Juan Este es algún mensaje Firma Digital Pablo Este es algún mensaje Firma Digital Este es algún mensaje Firma Digital Hash(A) Llaves Pablo públicaprivada Hash(B) Hash(A) = ? Firma Digital

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

9 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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.

10 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, X.509 Autoridad Certificadora La tercera parte es llamada Autoridad Certificadora (CA). Certificados DigitalesEmite 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 CAs periódicamente publican una lista de los certificados comprometidos –Listas de Revocación de Certificados (CRL): contienen todos los certificados revocados aún por expirar Los certificados de las CAs son auto-firmados

11 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, Un Certificado X.509 contiene: –l–la llave pública del propietario; –i–identidad del propietario; –i–información sobre la CA; –v–vigencia; –n–número de serie; –f–firma 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: GMT Serial number: 625 (0x271) CA Digital signature Estructura de un certificado X.509 Certificados X.509

12 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, Población amplia y dinámica Cuentas diferentes en sitios diferentes Datos personales y confidenciales Privilegios heterogéneos (roles) Deseable el registro único (login) Usuarios Agrupar datos Patrones de Acceso Membresías Grupos Sites Recursos Heterogéneos Patrones de Acceso Políticas Locales Membresía Grid Seguridad en GRID: los jugadores

13 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, cada usuario/host/servicio tiene un certificado X.509; los certificados son firmados por CAs confiables (para los sitios locales); cada transacción de Grid es mutuamente autenticada: 1. Juan envía su certificado; 2. Pablo verifica la firma en el certificado de Juan; 3. Pablo envía a Juan una cadena de prueba; 4. Juan cifra la cadena de prueba con su llave privada; 5. Juan envía la cadena cifrada a Pablo 6. Pablo usa la llave pública 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 pública de J. Comparar con la frase original Basada en PKI X.509: MUY IMPORTANTE Las llaves privadas deben almacenarse sólo: protegidos en lugares protegidosY cifrada en forma cifrada Infraestructura de Seguridad en Grid (GSI)

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

15 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, IGTF International Grid Trust Federation (Working to Establish Worldwide Trust for Grids) 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

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

17 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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 RA Univ AUniv BUniv CUniv DUniv EUniv FUniv G

18 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, Perfil clásico de una CA Cómo 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

19 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, Emisión de certificados en más detalle Máquina de firmado (fuera de línea) 1. Solicitud del usuario, un par de llaves Privada/Pública 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 pública

20 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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

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

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

23 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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

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

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

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

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

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

29 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, Solicitud de un certificado personal para trabajar en EELA La CA Catch-all de EELA está por ser terminada. Cualquier usuario de Grid en LA será capaz de solicitar un certificado si su institución cuenta con una RA.

30 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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

31 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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 -bits -help

32 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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 ! grid-proxy-init

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

34 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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 Delegación

35 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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 -s: especifica el nombre del servidor de myproxy –myproxy-info Obtiene información sobre proxys de larga duración almacenados –myproxy-get-delegation Obtienen un nuevo proxy del servidor de MyProxy –myproxy-destroy Elimina un proxy de larga duración almacenado en el servidor MyProxy Un servicio dedicado en el RB puede ser renovado automáticamente por el proxy Los servicios de transferencia de archivos en gLite validan las peticiones de los usuarios y eventualmente renuevan proxies –Contactando al servidor myproxy

36 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, UI Local WS MyProxy Server GENIUS Server (UI) myproxy-init any grid service myproxy-get-delegation output the Grid execution WEB Browser Autenticación en Grid con MyProxy

37 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, Autenticación, Autorización: pre-VOMS Autenticación –El usuario recibe un certificado firmado por la CA –Se conecta a una UI por ssh –Descarga el certificado –Se registra en la Grid -creando un proxy- entonces la Infraestructura de Seguridad Grid identifica al usuario en otras máquinas Autorización –EL usuario se une a una Organización Virtual (VO) –La VO negocia el acceso a los nodos y recursos de Grid –Autorización verificada por el CE –gridmapfile asocia usuarios a cuentas locales UI AUP VO mgr Personal/ una vez VO database Gridmapfiles en servicios de Grid GSI VO service Actualización diaria CA

38 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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... VOs y autorización

39 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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

40 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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 Your proxy is valid until Mon Jan 30 23:35: VOMS: conceptos

41 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, VOMS - componentes Authz DB es un RDBMS (actualmente MySQL y Oracle están soportados).

42 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, Proceso de registro 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 USERVOMS SERVER

43 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, EELA VO Reglas de Uso (http://roc.eu-eela.org/eela_aup.php)

44 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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

45 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, EELA Registro (1/6) (https://voms.lip.pt:8443/voms/eela/webui/request/user/create)

46 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, EELA Registro (2/6)

47 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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, 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

48 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, EELA Registro (4/6)

49 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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

50 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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

51 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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 /Role=[ ][/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 FQAN y AC

52 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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 VOMS y AC

53 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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 oGroup Barbera University Group Padua – VO GILDA /GILDA/TUTORS puede escribir en almacenamiento normal /GILDA/STUDENT sólo puede escribir en espacio volátil Los Grupos pueden tener una estructura jerárquica, indefinidamente profunda

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

55 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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 LCAS & LCMAPS

56 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, 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 públicas de servidor Voms –$X509_VOMS_DIR (default: /etc/grid-security/vomsdir )

57 E-infrastructure shared between Europe and Latin America FP62004Infrastructures6-SSA La Antigua, 13th EELA Tutorial, GridGrid –Seguridad LCG: –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: –Globus Security Infrastructure: –VOMS: –CA: BackgroundBackground –Seguridad GGF: –Estatutos IETF PKIX: –PKCS: Referencias


Descargar ppt "FP62004Infrastructures6-SSA-026409 www.eu-eela.org E-infrastructure shared between Europe and Latin America Autorización y Autenticación en gLite Juan."

Presentaciones similares


Anuncios Google