Authentication and Authorization in gLite Carlos Fuentes Bermejo IRIS-CERT/RedIRIS Tutorial de EGEE-III, Sevilla 1-5 de Febrero de 2010.

Presentación del tema: "Authentication and Authorization in gLite Carlos Fuentes Bermejo IRIS-CERT/RedIRIS Tutorial de EGEE-III, Sevilla 1-5 de Febrero de 2010."— Transcripción de la presentación:

1 Authentication and Authorization in gLite Carlos Fuentes Bermejo IRIS-CERT/RedIRIS Tutorial de EGEE-III, Sevilla 1-5 de Febrero de 2010

2 2 Introducción Encriptamiento  Algoritmos Simetricos  Algoritmos Asimetricos: PKI (public-key) Certificados  Firma Digital  Certificados X509 Seguridad del Grid  Certificados Proxy  Instrucciones de la Linea de Comandos Organizaciones Virtuales  Conceptos de VO y autorización Agenda

3 3 Principal  An entity: a user, a program, or a machine Credentials  Some data providing a proof of identity Authentication  Verify the identity of a principal Authorization  Map an entity to some set of privileges Confidentiality  Encrypt the message so that only the recipient can understand it Integrity  Ensure that the message has not been altered in the transmission Non-repudiation  Impossibility of denying the authenticity of a digital signature Glosario

4 What is Grid security? The Grid problem is to enable “coordinated resource sharing and problem solving in dynamic, multiinstitutional virtual organizations” From ”The Anatomy of the Grid” by Ian Foster et al. So Grid Security is security to enable VOs What is needed in terms of security for a VO? 4

5 Virtual Organization Concept VO for each application, workload or community Carve out and configure resources for a particular use and set of users The more dynamic the better… 5

6 Security Concerns How can communication endpoints be identified?  Authentication How can a secure channel established between two partners?  Encryption  Non-repudiation  Integrity Authorisation  Who is allowed to access a Virtual Organisation's resources  What are VO members allowed to do? 6 User Grid Service

7 Grid Security Infrastructure Security at network level: Public key infrastructure (PKI) 7

8 8 Un algoritmo criptográfico es una función matemática que combina texto simple u otra información inteligible con una cadena de dígitos, llamada llave o clave, para producir texto codificado ininteligible. La llave y el algoritmo usados son cruciales para el encriptamiento Simbología Texto en Claro: M Texto Cifrado: C Cifrado con clave K 1 : E K 1 (M) = C Descifrado con clave K 2 : D K 2 (C) = M Algoritmos: Simétrios Simétrios: K 1 = K 2 Asimétricos Asimétricos: K 1 ≠ K 2 K2K2 K1K1 Encryption Decryption MCM Pablo Juan Criptografía

9 9 Principal característica:  La misma clave es usada para cifrar y descifrar Ventajas  Rapidez Desventajas:  Como se distribuyen las claves??? Ejemplos:  DES  3DES  Rijndael (AES)  Blowfish  Kerberos MaríaPedro ciao3$rciao MaríaPedro ciao3$rciao3$r Algoritmos Simétricos

10 10 También conocidos como Algoritmos de Clave Pública/Public Key Algorithms. Algunas características:  Cada usuario tiene un par de claves: 1 privada y 1 pública Es imposible obtener la clave privada usando la clave pública Un mensaje cifrado con una de las claves sólo es descifrado por su pareja  No es necesario intercambiar las claves privadas El emisor del mensaje lo cifra usando la clave pública del receptor El receptor descifra el mensaje usando su clave privada Ejemplos:  Diffie-Helmann (1977)  RSA (1978)  DSA  ElGamal Juan keys public private Pablo keys publicprivate PabloJuan ciao3$rciao PabloJuan ciaocy7ciao 3$r cy7 Algoritmos Asimétricos

11 11 Método criptográfico que nos permite asociar la identidad de una persona o máquina al mensaje o documento Asegurar la integridad del documento o mensaje Como funciona:  Pablo calcula el hash del mensaje  Pablo cifra el has usando su clave privada: el hash cifrado es la firma digital  Pablo envia el mensaje firmado a Juan  Juan calcula el hash(B) del mensaje y verifica que el hash(A), descifrado con la clave pública de Pablo  Si los hashes son iguales: Mensaje no fue modificado Pablo no puede repudiarlo Juan This is some message Digital Signature Pablo This is some message Digital Signature This is some message Digital Signature Hash(A) Hash(B) Hash(A) = ? Firma Digital Claves de Pablo públicaprivad a

12 12 La firma digital de Pablo se considera segura si: 1.La clave privada de Pablo no ha sido comprometida 2.Juan conoce la clave pública de pablo Como puede Juan estar seguro que la clave pública de Pablo is realmente suya y no de otra persona?  Existencia de una tercera parte que certifica la correspondencia entre la clave pública y la identidad del propietario  Ambos deben confiar en esta tercera parte Dos modelos existentes para establecer la confianza:  X.509  Organización jerárquica (usada en Grid)  PGP  De persona a persona Certificados Digitales

13 13 La “Tercera Parte” es llamada Autoridad de Certificación/Certification Authority (CA) Responsabilidades de una CA: Emisión de Certificados Digitales (contiene la clave pública y la identidad del usuario) para usuarios, programas o maquinas Verificar la identidad y los datos personales del solicitante  Autoridades del Registro/Registration Authorities (Ras) hacen actualmente esa verificación Revocan el ceritficado en caso de que haya sido comprometido Renovación de certificados cuando estos vayan a expirar Periodicamente publica una lista de certificados revocados en su página web  Certificate Revocation Lists (CRL): contiene todos los certificados revocados X.509 y Autoridades de Certificación

14 14 Autoridades de Certificación How to obtain a certificate: The certificate is issued by the CA The certificate is used as a key to access the grid A certificate request is performed The user identify is confirmed by the RA

15 15 An X.509 Certificate contains: Private key is stored in encrypted file – protected by a passphrase Private key is created by the grid user owner’s public key; identity of the owner; info on the CA; time of validity; Serial number; digital signature of the 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 Structure of a X.509 certificate X.509 Certificates

16 16 Certificates are signed by the CA’s; Each transaction in the Grid is mutually authentificated: 1.Pedro sends his certificate. 2.Sara verifies the signature in Pedro’s certificate. 3.Sara sends to Pedro a random number. 4.Pedro encrypts it using his private key. 5.Pedro sends the encrypted number to Sara. 6.Sara uses Pedro’s public key to decrypt the number. 7.Sara compares the decrypted number with the original. 8.If they are equal, Sara verifies Pedro’s identity. Pedro Pedro Service Pedro’s certificatePedro’s certificate Verifies CA signatureVerifies CA signature Random numberRandom number Encrypts with his private keyEncrypts with his private key Encrypted numberEncrypted number Decrypt with public key of PedroDecrypt with public key of Pedro Compares the number with the originalCompares the number with the original Based in X.509 PKI: Secure Socket Layer (SSL)

17 17 Renewal The certificates maximum lifetime is 1 year + 1 month The idea is that at the end of the year (12 th month) a new certificate is issued Users should be warned about the coming expiration and the need to renew Don’t revoke a certificate to issue a new one unless the certificate has been compromised or the user has ceased his activity which entitles him to have a certificate

18 18 Renewal During a renewal it is not required to make the user to pass through the identification procedure:  This is a big advantage for both the users and the RA  However a maximum renewal number without identification is advisable (for instance: every two years the EE must pass through the identification again) In order not to pass through the identification the renewal request must be signed with the user certificate, examples:  Email signed with user certificate  CA/RA Web interface that would identify the user certificate If the user certificate expires before renewal the procedure for a new certificate must be followed

19 19 Request a Personal Certificate If you are Italian go to:  https://security.fi.infn.it/CA/en/RA/ https://security.fi.infn.it/CA/en/RA/ If you are Portuguese go to:  http://ca.lip.pt/ http://ca.lip.pt/ If you are Spanish go to:  http://www.irisgrid.es/pki/ http://www.irisgrid.es/pki/ If you are not any of the above go to:  http://igc.services.cnrs.fr/GRID- FR/?lang=en&cmd=certificates&type=usercert http://igc.services.cnrs.fr/GRID- FR/?lang=en&cmd=certificates&type=usercert Status to be updated since there are now 4 Certification Authorities in the Latin America

20 20 Request a Certificate to the GRID-FR CA (http://igc.services.cnrs.fr/GRID- FR/?lang=en&cmd=certificates&type=usercert) Working RA’s are: 1.ICN-UNAM 2.REUNA 3.UFF 4.UFRJ 5.ULA If you DO NOT belong to any of the EELA partners mentioned above, a new RA must be created in your site. This operation starts sending an email to Jorge Gomes (jorge@lip.pt) and asking him to create a new RA.jorge@lip.pt

21 21 Import your certificate in your browser  If you received a.pem certificate you need to convert it to PKCS12  Use openssl command line (available in each UI)  openssl pkcs12 –export –in usercert.pem –inkey userkey.pem –out my_cert.p12 –name ’My Name’ GILDA (and other VOs, among which EELA):  You receive already a PKCS12 certificate (can import it directly into the web browser)  For future use, you will need usercert.pem and userkey.pem in a directory ~/.globus on your UI  Export the PKCS12 cert to a local dir on UI and use again openssl:  openssl pkcs12 -nocerts -in my_cert.p12 -out userkey.pem  openssl pkcs12 -clcerts -nokeys -in my_cert.p12 -out usercert.pem Certificate Management

22 Grid Security Infrastructure Security at VO level 22

23 23 It would be dangerous to transfer your certificate through the Grid Proxy Certificates  signed by the normal end entity cert (or by another proxy).  Support some important features  Delegation  Have a limited lifetime (minimized risk of “compromised credentials”) Proxy certificates are created by the grid- proxy-init command: % grid-proxy-init Enter PEM pass phrase: ******  Options for grid-proxy-init:  -hours  -bits  -help X.509 Proxy Certificate

24 24 User enters pass phrase, which is used to decrypt private key. Private key is used to sign a proxy certificate with its own, new public/private key pair. User’s private key not exposed after proxy has been signed User certificate file Private Key (Encrypted) Pass Phrase User Proxy certificate file Proxy the private key of the Proxy is not encrypted stored in local file: must be readable only by the owner lifetime is short (typically 12 h) to minimize security risks. Grid-proxy-init

25 25 Proxy again … grid-proxy-init ≡ “login to the Grid” To “logout” you have to destroy your proxy:  grid-proxy-destroy To gather information about your proxy:  grid-proxy-info  Options for printing proxy information -subject-issuer -type-timeleft -strength-help

26 26 Delegation = remote creation of a (second level) proxy credential New key pair generated remotely on server Client signs proxy cert and returns it Allows remote process to authenticate on behalf of the user Remote process “impersonates” the user Delegation

27 27 Proxy has limited lifetime (default is 12 h)  Bad idea to have longer proxy However, a grid task might need to use a proxy for a much longer time  Grid jobs in HEP Data Challenges on LCG last up to 2 days MyProxy server:  Allows to create and store a long term proxy certificate:  myproxy-init -s  -s: specifies the hostname of the myproxy server  myproxy-info  Get information about stored long living proxy  myproxy-get-delegation  Get a new proxy from the MyProxy server  myproxy-destroy File transfer services in gLite validates user request and eventually renew proxies  contacting myproxy server Long Term Proxy  MyProxy

28 28 Grid users MUST belong to virtual organizations  Sets of users belonging to a collaboration  User must sign the usage guidelines for the VO VOs maintain a list of their members on a LDAP Server  The list is downloaded by grid machines to map user certificate subjects to local “pool” accounts... "/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 and authorization

29 VOMS Service. 29 Virtual Organization Members Service –Extend information in the proxies members of the VO, groups, roles. –Absolutely compatible with Globus Toolkit. –Every VO has a database which contains information about the members of the group, roles and capacities of each user. –Users contact with voms server requesting their information of authorization –Server sends the information of authorization to the client, who includes it in a proxy certificate. –$voms-proxy-init –-voms gilda  Creates a certificate and extends it with the voms server information. – $ voms-proxy-info –all  Shows information of the certificate together with voms extension.

30 FQAN and AC short for Fully Qualified Attribute Name, is what VOMS uses to express membership and other authorization info Groups membership, roles and capabilities may be expressed in a format that bounds them together /Role=[ ][/Capability= ] FQAN are included in an Attribute Certificate Attribute Certificates are used to bind a set of attributes (like membership, roles, authorization info etc) with an identity ACs are digitally signed VOMS uses AC to include the attributes of a user in a proxy certificate 30 [carlos@ui ~]$ voms-proxy-info -fqan /dteam/Role=NULL/Capability=NULL /dteam/swe/Role=NULL/Capability=NULL

31 VOMS and AC Server creates and signs an AC containing the FQAN requested by the user, if applicable AC is included by the client in a well-defined, non critical, extension assuring compatibility with GT-based mechanism 31 [carlos@ui ~]$ voms-proxy-info --all subject : /DC=es/DC=irisgrid/O=rediris/CN=carlos.fuentes/CN=proxy issuer : /DC=es/DC=irisgrid/O=rediris/CN=carlos.fuentes identity : /DC=es/DC=irisgrid/O=rediris/CN=carlos.fuentes type : proxy strength : 1024 bits path : /tmp/x509up_u502 timeleft : 11:59:53 === VO dteam extension information === VO : dteam subject : /DC=es/DC=irisgrid/O=rediris/CN=carlos.fuentes issuer : /DC=ch/DC=cern/OU=computers/CN=lcg-voms.cern.ch attribute : /dteam/Role=NULL/Capability=NULL attribute : /dteam/swe/Role=NULL/Capability=NULL attribute : /dteam/swe/ifae/Role=NULL/Capability=NULL timeleft : 11:59:53 uri : lcg-voms.cern.ch:15004

32 LCAS & LCMAPS At resources level, authorization info is extracted from the proxy and processed by LCAS and LCMAPS Local Centre Authorization Service (LCAS)  Checks if the user is authorized (currently using the grid-mapfile)  Checks if the user is banned at the site  Checks if at that time the site accepts jobs Local Credential Mapping Service (LCMAPS)  Maps grid credentials to local credentials (eg. UNIX uid/gid, AFS tokens, etc.)  Map also VOMS group and roles (full support of FQAN) 32 "/VO=dteam/GROUP=/dteam" dteam "/VO=eumed/GROUP=/eumed/ROLE=SoftwareManager" eumed "/VO=eumed/GROUP=/eumed" eumed

33 Remember… You need a digital certificate and be member of a VO. ¡¡Keep your private key safe!! Proxy commands voms-*  To manage proxies Myproxy commands myproxy-*  To delegate proxies 33

34 34 Grid Grid  LCG Security: http://proj-lcg-security.web.cern.ch/proj-lcg- security/http://proj-lcg-security.web.cern.ch/proj-lcg- security/  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/ Background Background  GGF Security: http://www.gridforum.org/security/http://www.gridforum.org/security/  IETF PKIX charter: 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 References

35 Edificio Bronce Plaza Manuel Gómez Moreno s/n 28020 Madrid. España Tel.: 91 212 76 20 / 25 Fax: 91 212 76 35 www.red.es 35 Gracias por su atención