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