autorización y autenticación en glite

FP6−2004−Infrastructures−6-SSA-026409

www.eu-eela.org

E-infrastructure shared between Europe and Latin America

Autorización y Autenticación en gLiteJuan Eduardo Murrieta LeónDGSCA - UNAMThirteenth EELA TutorialLa Antigua, 18.10.2007

2


La Antigua, 13th EELA Tutorial, 18.10.2007FP6−2004−Infrastructures−6-SSA-026409

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



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



• Algoritmos matemáticos proporcionan los bloques de construcción requeridos para la implementación de una infraestructura de seguridad

• Simbología

– Texto plano: M

– Texto cifrado: C

– Cifrado con la llave K1 : E K1(M) = C

– Descifrado con la llave K2 : D K2(C) = M

• Algoritmos

– SimétricosSimétricos: K1 = K2

– AsimétricosAsimétricos: K1 ≠ K2

K2K1

CifradoCifrado DescifradoDescifradoM C M

Criptografía

5



• La misma llave se usa para cifrar y descifrar

• Ventajas:– Rápido

• Desventajas:– ¿cómo distribuir las llaves?– El número de llaves es O(n2)

• Ejemplos:– DES– 3DES– Rijndael (AES)– Blowfish– Kerberos

María Pedro

hola

3$r hola

María Pedro

hola

3$r hola

3$r

3$r

Algoritmos Simétricos

6



• 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ública

privada

Pablo Juan

hola

3$r hola

Pablo Juan

hola

cy7 hola

3$r

cy7

Algoritmos de llave pública

7



• Pablo calcula el hashhash del mensaje (con una función hash inyectiva)

• Pablo cifra el hash usando su llave privadaprivada: el hash cifrado es la firma digitalfirma digital.

• Pablo envía el mensaje firmado a Juan.

• Juan calcula el hash del mensaje y lo verificaverifica con el hash descifrado de la firma digital utilizando la llave públicapú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ública privada

Hash(B)

Hash(A)

= ?

Firma Digital

8



• 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



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



X.509

La “tercera parte” es llamada Autoridad CertificadoraAutoridad Certificadora (CA).

• Emite Certificados Digitales Certificados Digitales (que contienen la llave pública y la identidad de su propietario) para usuarios, programas y máquinas (firmados por la CA)

• Verifica la identidad y datos personales del solicitante– Autoridades de Registro (RAs) hacen la validación actualmente

• Las CA’s periódicamente publican una lista de los certificados comprometidos– Listas de Revocación de Certificados (CRL): contienen todos los

certificados revocados aún por expirar

• Los certificados de las CAs son auto-firmados

11



• Un Certificado X.509 contiene:

– la llave pública del propietario;

– identidad del propietario;

– información sobre la CA;

– vigencia;

– número de serie;

– firma digital de la CA

Public keyPublic key

Subject:C=CH, O=CERN, Subject:C=CH, O=CERN, OU=GRID, CN=Andrea Sciaba OU=GRID, CN=Andrea Sciaba 89688968

Issuer: C=CH, O=CERN, Issuer: C=CH, O=CERN, OU=GRID, CN=CERN CAOU=GRID, CN=CERN CA

Expiration date: Aug 26 08:08:14 Expiration date: Aug 26 08:08:14 2005 GMT2005 GMT

Serial number: 625 (0x271)Serial number: 625 (0x271)

CA Digital signatureCA Digital signature

Estructura de un certificado X.509

Certificados X.509

12



•Población amplia y dinámica•Cuentas diferentes en sitios diferentes•Datos personales y confidenciales•Privilegios heterogéneos (roles)•Deseable el registro único (login)

UsuariosUsuarios

•“Agrupar” datos • Patrones de Acceso• Membresías

““Grupos”Grupos”

SitesSites• Recursos Heterogéneos• Patrones de Acceso• Políticas Locales• Membresía

GridGrid

Seguridad en GRID: los jugadores

13



• cada usuario/host/servicio tiene un certificado X.509;

• los certificados son firmados por CA’s confiables (para los sitios locales);

• cada transacción de Grid es mutuamente autenticada:

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

JuanJuan PabloPablocertificado de Juancertificado de Juan

Verifica la firma de la CAVerifica la firma de la CA

frase aleatoriafrase aleatoria

Cifrar con la llave privada de J.Cifrar con la llave privada de J.

frase cifradafrase cifrada

Descifrar con la llave pública de J.Descifrar con la llave pública de J.

Comparar con la frase originalComparar con la frase original

Basada en PKI X.509:

MUY IMPORTANTEMUY IMPORTANTE

Las llaves privadasLas llaves privadas

deben almacenarse sólo:

en lugares protegidosprotegidos

YY

en forma cifradacifrada

Infraestructura de Seguridad en Grid (GSI)

14



Más sobre Autenticación

• En el mundo de la grid una sola CA usualmente cubre una región geográfica predefinida o dominio administrativo:– Organización– País– Un conjunto de países

• Un dominio de confianza común para el cómputo en grid ha sido creado para unir las diversas autoridades de certificación existentes en un solo dominio de autenticación y así permitir compartir recursos de grid en el mundo. – La Federación de Confianza Internacional en Grid (IGTF) ha sido

creada para coordinar y administrar estos dominios de confianza.

– IGTF está dividida en tres Autoridades de Políticas de Administración (PMAs) que cubren el Asia del Pacífico, Europa y América.

15



IGTF

International Grid Trust Federation

(Working to Establish Worldwide Trust for Grids)www.gridpma.org

APGridPMA TAGPMA

LIP CA PortugalCERN CA SwitzerlandArmeSFO ArmeniaCNRS Grid FranceCyGrid CyprusCESNET Czech DutchGrid NetherlandsGermanGrid GermanyHellasGrid GreeceGridIreland IrelandINFN CA ItalyBelnet BelgiumGrid-PK PakistanSIGNET SloveniaEstonianGrid EstoniaAustrianGrid AustriaNIIF/HungarNet HungaryIHEP ChinaBalticGrid EuropeTR-Grid Turkey

NorduGrid Nordic countriesPolishGrid PolandRussian Datagrid RussiaSlovakGrid SlovakiaDataGrid-ES SpainUK e-Science United KingdomBelnetGrid BelgiumGrid-PK PakistanFNAL Grid USAGridCanada CanadaDOEGrids USAArmeSFo ArmeniaIUCC IsraelASCCG TaiwanSeeGrid EuropeRMKI HungarySWITCH SwitzerlandDFN GermanyRDIG Russia

EELADartmouth CollegeTexas High Energy GridFNAL USASDSC CentreTeraGridOpen Science GridDOEGridsCANARIE

AIST JapanAPAC AustraliaASGCC TaiwanSDG ChinaIHEP ChinaKISTI KoreaNaregi JapanBMG SingaporeCMSD IndiaHKU Hong KongNCHC TaiwanOsaka U. JapanUSM Malaysia

International Grid Trust Federation

16



Perfil clásico de una CA

• Qué es:– La CA firma y revoca certificados– Estos son certificados de lago plazo (un año)– La CA tiene RAs subordinadas que sólo desempeñan la tarea

administrativa de verificar la identidad del sujeto en diferentes organizaciones o departamentos

• Ventajas:– Es el perfil más conocido de una CA– Existe una gran cantidad de “know-how” y soluciones– La mayoría de las CAs operan usando el perfil clásico– Es la más fácil de soportar entre dominios administrativos diferentes– La SLCS (perfil para servicios de credenciales de corta duración) está

aún en desarrollo– Los requerimientos del perfil son estables y controlados por

EUgridPMA

17




• 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

RA

RA RA RA RARARA

Univ A Univ B Univ C Univ D Univ E Univ F Univ G

18




• Cómo obtener un certificado:

El certificado es emitidopor la CA

El certificado se utilizacomo una llave para acceder a la grid

Se realiza una solicitud de certificado

La identidad del solicitantees confirmada por la RA

19



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 llaveprivada se mantiene del lado del usuario

2. Se verifica la identidad por una RA

6. Descarga del

certificado

Servidor CA

Llave privadade la CA

3. Transferenciamanual

de la solicitud

4. Firma de la CA

5. Transferencia manual del certificado

Solicitud con

llave pública

20



Listas de Revocación

• Las CAs tienen la obligación de emitir Listas de Revocación de Certificados (CRL)

• Las CRLs contienen:– una lista de los certificados revocados– la fecha de cuándo fueron emitidos– su fecha de expiración

• Las CRLs son firmadas con la llave privada de la CA• Las CRLs deben ser publicadas de manera que las

partes involucradas puedan verificar la validez de los certificados– Usualmente a través de http://

21




• 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



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



Perfil de la CA: CP/CPS Identificación

• Cada CA debe tener una Política de Certificación y Declaración de Prácticas de Certificados

• Para nuevas CAs los documentos de la CP/CPS deben estar estructuradas como se definen en RFC 3647– Este es un nuevo formato. La mayoría de las CP/CPS fueron escritas

en el RFC 2527– Ejemplos:

PkirisGrid AustrianGrid

• Los mayores cambios al CP/CPS deben ser:– Anunciados a la PMA acreditada– Aprobados antes de firmar cualquier certificado bajo el nuevo CP/CPS

• Todas las CP/CPS bajo las cuales se expiden certificados válidos deben estar disponibles en la web (muchos ejemplos se pueden encontrar en http://www.eugridpma.org/members y http://www.tagpma.org/members)

24



Operación de la RA

• La operación de las RAs debe ser:– de acuerdo con la CA CP/CPS– definida en un documento para cada RA

• La operación de la RA en general:– Cada RA debe tener una persona responsable (administrador)

Un director es aconsejable

– El administrador puede nombrar uno o mas operadores– Tanto el administrador como los operadores pueden autorizar solicitudes– Todo el personal de la RA debe estar entrenado en las operaciones y

seguridad de la CA/RA– El método de selección del personal debe estar definido– La CA debe ser informada oficialmente de cualquier cambio en el personal de

la RA (por ejemplo una carta firmada y sellada)– El primer administrador debe estar identificado en persona por la CA– Cada RA debe tener un único espacio de nombres (prefijo en el nombre del

sujeto del DN) para evitar colisiones de nombre en el DN– La comunidad soportada por la RA debe estar bien definida– El método usado para identificar a los sujetos debe estar totalmente descrita

incluyendo el refuerzo de cualquier requerimiento adicional impuesto por la CA o por la RA (por ejemplo: relación con la organización)

25



Espacio de nombres de la CA/RA

• La definición del espacio de nombres es responsabilidad de la CA, sin embargo dependiendo de esta definición la RA puede también estar involucrada (por ejemplo el espacio de nombres de la LIP CA…)– /C=PT/O=LIPCA/

El prefijo de la CA debe ser único entre las CAs

– /C=PT/O=LIPCA/O=UMINHO La segunda /O= designa la organización del sujeto y también de la

RA

– /C=PT/O=LIPCA/O=UMINHO/OU=DI La /OU=DI en el caso de LIP es opcional y puede ser usado para

identificar un departamento en una organización Se utiliza para designar una RA dentro de una organización cuando

una organización tiene múltiples RAs

26



Espacio de nombres de la CA/RA

• Acerca del CN y el DN completo:– /C=PT/O=LIPCA/O=UMINHO/OU=DI/CN=Jose A Sousa

cada DN debe ser único:• Lo suficientemente largo para evitar colisiones• Agregar algo (número,... ) cuando se encuentran duplicados• Posiblemente usar el nombre completo de la persona es la mejor

opción cada DN debe estar limitado al mismo sujeto para todo el tiempo de

vida de la CA El CN debe tener una relación clara y directa con el DN No olvidar que los certificados son para el cómputo en grid, no

deben crearse nombres (o extensiones) que puedan crear problemas al middleware.

No usar acentos Algunos caracteres pueden tener significados especiales para las

aplicaciones (como el “-” que globus utiliza como comodín) Algunos caracteres no son permitidos (por ejemplo “/” and “.” en los

certificados de usuario)

27



Renovación

• Dos tipos de renovación:– Renovación de certificados de entidades finales– Renovación de certificados de CA

• Entidades Finales:– El tiempo de vida máximo de un cerificado es 1 año + 1mes– La idea es que al final del año (12º mes) un nuevo certificado sea

emitido.– El usuario (EE) debe ser avisado acerca de la próxima expiración y

necesidad de renovación de su certificado– Dado que el nuevo certificado será emitido al final del 12º mes (o

inicios del 13º) habrá un traslape de dos certificados: Esto se utiliza para evitar una situación en donde el certificado expira

dejando al usuario sin acceso a la grid. No hay que olvidar que hay usuarios que someten trabajos que pueden

tomar días o semanas. Durante este período habrá dos certificados con el mismo nombre (DN) No revocar un certificado para emitir uno nuevo a menos que el certificado

haya sido comprometido o el usuario haya cesado su actividad o relación con las entidades que le dan derecho a un certificado.

28



Renovación

• Entidades Finales:– Durante una renovación no es necesario hacer que la entidad final (EE)

pase a través del proceso de identificación: Esto es una gran ventaja tanto para la EE como para la RA Sin embargo, un número máximo de renovaciones sin identificación es

recomendable (por ejemplo: cada dos años la EE debe pasar por el proceso de identificación de nuevo)

Sin embargo, la relación con la organización debe mantenerse (si este requerimiento se va a utilizar)

– Para no pasar por el proceso de identificación la solicitud de renovación debe estar firmada con el certificado del usuario, ejemplos:

Correo firmado con el certificado del usuario Interfaz Web de la CA/RA que pueda identificar el certificado del usuario

– Si el certificado del usuario expira antes de la renovación el procedimiento de solicitud de un nuevo certificado debe seguirse.

29



Solicitud de un certificado personal para trabajar en EELA

• La CA “Catch-all” de EELA está por ser terminada.

• Cualquier usuario de Grid en LA será capaz de solicitar un certificado si su institución cuenta con una RA.

31



Certificado Proxy X.509

• La extensión GSI de los Certificados de Identidad X.509– Firmados por la entidad final (o por otro proxy).

• Permite el registro único o “single sign-on”• Soporta algunas características importantes

– Delegación– Autenticación Mutua

• Tiene un tiempo de vida limitado (minimiza los riesgos de “compromiso de credenciales”)

• Es creado por el comando grid-proxy-init:% grid-proxy-initEnter PEM pass phrase: ******– Opciones del grid-proxy-init:

-hours <lifetime of credential> -bits <length of key> -help

32



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

Llave Privada(cifrada)Palabra

clave

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



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



• 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



Proxy de larga duración• Un Proxy tiene un tiempo de vida limitado (12 h por omisión)

– Es mala idea tener proxys de mayor duración• Sin embargo, una tarea de grid puede requerir el uso de un proxy por un tiempo

más largo– Los trabajos de Grid en los “HEP Data Challenges” sobre LCG tardaron hasta 2

días• Servidor myproxy:

– Permite crear y almacenar un certificado de larga duración:– myproxy-init -s <host_name>

-s: <host_name> especifica el nombre del servidor de myproxy– myproxy-info

Obtiene información sobre proxy’s de larga duración almacenados– myproxy-get-delegation

Obtienen un nuevo proxy del servidor de MyProxy– myproxy-destroy

Elimina un proxy de larga duración almacenado en el servidor MyProxy• Un servicio dedicado en el RB puede ser renovado automáticamente por el proxy• Los servicios de transferencia de archivos en gLite validan las peticiones de los

usuarios y eventualmente renuevan proxies– Contactando al servidor myproxy

36



UI

LocalWS

MyProxyServer

GENIUSServer

(UI)

myproxy-init

any grid service

myproxy-get-delegation

outputthe Grid

execution

WEB Browser

Autenticación en Grid con MyProxy

37



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

Gridmapfilesen servicios de Grid

GSI

VO service

Actualización diaria

CA

38



• 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



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



• 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 gildaCannot find file or dir: /home/giorgio/.glite/vomsesYour identity: /C=IT/O=GILDA/OU=Personal Certificate/L=INFN/CN=Emidio Giorgio/[email protected] GRID pass phrase:Your proxy is valid until Mon Jan 30 23:35:51 2006Creating temporary proxy.................................DoneContacting voms.ct.infn.it:15001 [/C=IT/O=GILDA/OU=Host/L=INFN Catania/CN=voms.ct.infn.it/[email protected]] "gilda"Creating proxy ...................................... DoneYour proxy is valid until Mon Jan 30 23:35:51 2006

VOMS: conceptos

41



VOMS - componentes

Authz DB es un RDBMS (actualmente MySQL y Oracle están soportados).

42



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 USER VOMS SERVER

43



EELA VO Reglas de Uso(http://roc.eu-eela.org/eela_aup.php)

44



EELA VOMS(https://voms.lip.pt:8443/voms/EELA/)

Nuevos registros ent: https://voms.lip.pt:8443/voms/EELA/webui/request/user/create

45



EELA Registro (1/6)(https://voms.lip.pt:8443/voms/eela/webui/request/user/create)

46



EELA Registro (2/6)

47



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&reqid=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 : 21Confirmation cookie: xlqi8oy6fudv0wod

48



EELA Registro (4/6)

49



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

50



EELA Registro (6/6)

Welcome to the eela VO!

Dear Scardaci, Diego,

Your request (21) for the eela VO has been accepted and allowed by the VO Administrator.

From this point you can use the voms-proxy-init command to acquire the VO specific credentials, which will enable you to use the resources of this VO.

Good Luck,VO Registration

51



• Abreviación de “Fully Qualified Attribute Name”, es lo que VOMS usa para expresar membresía y otra información de autorización

• Grupos de membresías, roles y capacidades pueden estar expresados en un formato que los agrupe<group>/Role=[<role>][/Capability=<capability>]

• FQAN están incluidos en un Atributo del Certificado• Los Atributos de Certificados son usados para ligar un conjunto de

atributos (como membresía, roles, autorización, información, etc) con una identidad

• Los AC están firmados digitalmente• VOMS usa AC para incluir los atributos de un usuario en un certificado

proxy

[glite-tutor] /home/giorgio > voms-proxy-info -fqan

/gilda/Role=NULL/Capability=NULL

/gilda/tutors/Role=NULL/Capability=NULL

FQAN y AC

52



• 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 -allsubject : /C=IT/O=GILDA/OU=Personal Certificate/L=INFN/CN=Emidio Giorgio/[email protected]/CN=proxyissuer : /C=IT/O=GILDA/OU=Personal Certificate/L=INFN/CN=Emidio Giorgio/[email protected] : /C=IT/O=GILDA/OU=Personal Certificate/L=INFN/CN=Emidio Giorgio/[email protected] : proxystrength : 512 bitspath : /tmp/x509up_u513timeleft : 11:59:52=== VO gilda extension information ===VO : gildasubject : /C=IT/O=GILDA/OU=Personal Certificate/L=INFN/CN=Emidio Giorgio/[email protected] : /C=IT/O=GILDA/OU=Host/L=INFN Catania/CN=voms.ct.infn.it/[email protected] : /gilda/tutors/Role=NULL/Capability=NULLattribute : /gilda/Role=NULL/Capability=NULLtimeleft : 11:59:45

VOMS y AC

53



Grupos

• El número de usuarios de una VO puede ser muy alto:– Por ejemplo. el experimento ATLAS tiene 2000 miembros

• Hacer una VO manejable organizando a los usuarios en grupos:Ejemplos:– VO GILDA

Group Catania • INFN

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



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



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

57



• GridGrid– Seguridad LCG: http://proj-lcg-security.web.cern.ch/proj-lcg-security/ – Registro VOMS EELA:

https://voms.lip.pt:8443/voms/EELA/webui/request/user/create – EELA ROC: http://roc.eu-eela.org – Globus Security Infrastructure: http://www.globus.org/security/ – VOMS: http://infnforge.cnaf.infn.it/projects/voms – CA: http://www.tagpma.org/

• BackgroundBackground– Seguridad GGF: http://www.gridforum.org/security/ – Estatutos IETF PKIX: http://www.ietf.org/html.charters/pkix-charter.html – PKCS: http://www.rsasecurity.com/rsalabs/pkcs/index.html

Referencias

autorización y autenticación en glite

Documents