authentication and authorization · authentication authorization resource credentials " user...

© 2012 SWITCH

Authentication and Authorization Security in Large Scale Computing Infrastructures

Valéry Tschopp [email protected]

28 November 2012

© 2012 SWITCH 2

Outline

1.  Introduction 2.  Security fundamentals 3.  X.509 certificates 4.  Distributed Computing Infrastructure: Grid Computing 5.  Federated AAI and Grids 6.  Next Challenge: Cloud Computing 7.  Summary

Special thanks to Ake Edlund (KTH), Heinz Stockinger (SIB) and Christoph Witzig, Andres Aeschlimann (SWITCH) for re-using some of their slides

© 2012 SWITCH

Introduction • What is authentication?

– Ensuring a credential is valid – Identifies the person/entity that presents the credential

• What is authorization? – Checking that a person/entity has the rights to perform an operation – Authorization can be based on several criteria

q  Identity of the person q  Attributes provided about the person by a trusted third party

• What is security? – Secure, authenticable communication using encryption

3

© 2012 SWITCH

Institution

Institutional Model

Student Admin

Web Mail

e-Learning

Authorization User Administration Authentication Resource

Credentials

§  Users administration at the institution level

§  Some application not integrated

§  Authorization at the application

§  Authorization is often IP-based

§  Not allowed to export the users database

§  Trust within the institution

Strange App

4

© 2012 SWITCH

University A

Library B

University C

Distributed Model

Student Admin

Web Mail

e-Learning

Literature DB

e-Learning

Research DB

Authorization User Administration Authentication Resource

Credentials

e-Journals

§  Tedious user registration at all resources

§  Unreliable and outdated user data at resources

§  Different login processes

§  Many different passwords

§  Many resources not protected due to difficulties

§  Often IP-based authorization

§  Costly implementation of inter-institutional access

§  Trust is difficult

5

© 2012 SWITCH

University A

University C

Trusted Authority Model

Student Admin

Web Mail

e-Learning

e-Learning

Research DB

Authorization Authentication Resource Credentials

§ User registration process with CA

§ User has one credential to present to resources

§  authN and authZ at resource

§ User has to manage credential

§  Trust model (i.e. IGTF)

§ Delegation mechanism

Standardized Credentials (X.509, passports, …)

Trusted Issuer (CA)

X.509 credentials

6

© 2012 SWITCH

University A

Library B

University C

Federated Identity Management

Federated Model

Student Admin

Web Mail

e-Learning

Literature DB

e-Learning

Research DB

Authorization User Administration Authentication Resource Credentials

e-Journals

§  No user registration and user data maintenance at resource needed

§  Single login process for the users

§  Many new resources available for the users

§  Enlarged user communities for resources

§  Efficient implementation of inter-institutional access

§  Trust relies on X.509 infrastructure

7

© 2012 SWITCH

Security Models

• Different authentication/authorization models exist – Different technologies are used

• For Distributed Computing Infrastructure

– The identity of the user must be asserted – Authorization is not optional (accountability) – Trust is a key component

8

© 2012 SWITCH 9

Outline


© 2012 SWITCH

Security Fundamentals

• Privacy – A secure conversation should be private. In other words,

only the sender and the receiver should be able to understand the conversation. If someone eavesdrops on the communication, the eavesdropper should be unable to make any sense out of it.

• Solution – Use encryption/decryption algorithms

10

© 2012 SWITCH


• Privacy using symmetric encryption (shared secret)

• Problem? – Sharing the encryption key

11

&#/€(?%...

Alice Bob

abc.. abc..

&#/€(?%... ?

© 2012 SWITCH

Security Fundamentals • Public-key cryptography (e.g. RSA)

– Alice and Bob generate a private and a public key – They exchange their public key

• Encryption (Alice -> Bob)

– Alice uses Bob’s public key to encrypt the message – Bob uses Bob’s private key to decrypt the message – Only Bob can read it

• Signing (Alice -> Bob) – Alice uses Alice’s private key to encrypt the message – Bob uses Alice’s public key to decrypt the message – If Bob can read the message, he is sure that Alice sent it

12

© 2012 SWITCH


• Privacy using asymmetric encryption (public-key crypto)

• Problem? – Trusting each other public key

13

&#/€(?%...

Public key

Bob

abc.. abc..

&#/€(?%... ? Alice Private key

Public key

Private key

Bob’s Public key Alice Public key

© 2012 SWITCH


• Trusting other people’s public keys – How do you know that this is really Alice’s or Bob’s public key?

• Answer – Someone you trust must tell you that this is indeed the case! – Certificate Authority (CA)

14

© 2012 SWITCH


• Certificate Authority (CA) is a trusted third party • The role of the CA is manage the certificate life cycle:

create, store, renew, revoke

CA Trusted Third Party

Alice Bob

Alice? Yes!

Bob

Alice

Bob? Yes!

&#/€(?%...

15

© 2012 SWITCH 16

Outline

1.  Introduction 2.  Security fundamentals

3. X.509 certificates 4.  Distributed Computing Infrastructure: Grid Computing 5.  Federated AAI and Grids 6.  Next Challenge: Cloud Computing 7.  Summary

© 2012 SWITCH

X.509 alias ISO/IEC/ITU 9594-9

• X.509 is ITU Standard – ITU-T Recommendation X.509 (1997 E). Information technology -

Open Systems Interconnection - The Directory: Authentication Framework

– Defines a certificate format q  Latest standard: X.509 version 3 certificate format

• X.509 certificate includes – User identification (subject name) – Public key – Validity period – A “signature” from a Certificate Authority (CA) that:

q  Proves that the certificate came from the CA. q  Vouches for the subject name q  Vouches for the binding of the public key to the subject

17

© 2012 SWITCH

X.509 Certificates

• Server certificates – Identifies a server by its “fully qualified domain name” (FQDN) – Used to secure the connection on the transport level – It is the foundation of the HTTPS (TLS/SSL) protocol

• Personal certificates – Identifies a user/entity by its name (i.e. CN=John Doe) – Used to assert the identity of the user/entity – Client authentication in the HTTPS protocol (TLS/SSL)

18

© 2012 SWITCH

X.509 - How do I get a personal certificate?

1.  Create a key pair 2.  Send the public key to a Certificate Authority

1.  CA must also obtain personal information 2.  CA must perform an identity vetting (CP/CPS)

3.  CA issues certificate with a given lifetime (1-3 year)

4.  Note: 1.  CA may revoke your certificate (in case of abuse) 2.  Certificate must be renewed once it expires 3.  and ????

19

YOU MUST PROTECT YOUR PRIVATE KEY

© 2012 SWITCH

$ openssl x509 –text –in ~/.globus/usercert.pem!Certificate:! Data:! Version: 3 (0x2)! Serial Number:! 27:27:4c:ec:84:6c:fe:69:be:a1:2a:39:c1:c0:99:c8:79:11:da:cb! Signature Algorithm: sha1WithRSAEncryption! Issuer: C=BM, O=QuoVadis Limited, OU=Issuing Certification Authority, CN=QuoVadis Grid ICA! Validity! Not Before: May 2 10:57:51 2012 GMT! Not After : May 2 10:57:51 2013 GMT! Subject: DC=com, DC=quovadisglobal, DC=grid, DC=switch, DC=users, C=CH, O=SWITCH, CN=Valery Tschopp! Subject Public Key Info:! Public Key Algorithm: rsaEncryption! Public-Key: (2048 bit)! Modulus:! 00:c5:9c:8e:e9:86:a0:c3:91:3d:cf:5e:67:85:71:![...]!

X.509 Certificate Example

20

Issuing CA

Validity (1 year)

X.509 version 3 (with extensions)

User identity

Public key

© 2012 SWITCH

[...] ! X509v3 extensions:! X509v3 Subject Alternative Name: ! email:[email protected]! Authority Information Access: ! CA Issuers - URI:http://trust.quovadisglobal.com/qvgridg1.crt! X509v3 Key Usage: critical! Digital Signature, Key Encipherment, Data Encipherment! X509v3 Extended Key Usage: ! TLS Web Client Authentication, E-mail Protection! X509v3 Authority Key Identifier: ! keyid:9D:89:B2:E4:58:FC:3A:4E:92:39:CC:56:BB:55:25:96:C6:45:81:F5! X509v3 CRL Distribution Points: ! Full Name: URI:http://crl.quovadisglobal.com/qvgridg1.crl! X509v3 Subject Key Identifier: ! B9:CF:22:FC:34:E6:CE:66:D0:CA:22:F3:63:49:E2:9C:85:2F:ED:06! Signature Algorithm: sha1WithRSAEncryption! 6a:da:6f:63:fe:b1:89:1c:f4:76:a7:19:64:25:09:1a:58:6f:![...]!

X.509 Certificate Example (cont.)

21

Version 3 extensions

Key usage: client

Certificate revocation list

Issuing CA signature

© 2012 SWITCH

X.509 openssl Commands

• OpenSSL is the most used tool to handle X.509 certificates

• More examples on how to handle certificates?

– man openssl (read the manual)

– http://www.switch.ch/grid/certificates/openssl/

22

© 2012 SWITCH

Trusting the Certificate Authorities

• Nothing hinders you to set up your own CA and issue certificates

– Getting others to trust you is the hard problem!

• Trust anchors: the CAs that we more or less trust unconditionally

– Granularity: 1 CA per country – Primarily used in production Grids for research purposes

• See http://www.igtf.net/

The Grid's Policy Management Authority Working to Establish World Wide Trust for Grids

23

© 2012 SWITCH

Where are those Grid certificates ?

• User certificate – $HOME/.globus/

q  usercert.pem, userkey.pem

• Server certificate – /etc/grid-security/

q  hostcert.pem, hostkey.pem

• Trust anchors (CAs bundle) – /etc/grid-security/certificates

q  IGTF bundle, many small files

24

© 2012 SWITCH

How to protect your private key ?

25

•  File permissions on the private key – Only readable by owner

•  Choose a “good” passphrase – Many characters (>14) – Use a sentence instead of a password

•  Keep track on which hosts you have put your private key

•  Don’t import it into browsers that you don’t use all the time •  IMPORTANT: Anybody with access to your private key can

impersonate you

© 2012 SWITCH 26

Outline


© 2012 SWITCH

Core Problem of Grid Security

The purpose of the Grid is to enable “coordinated resource sharing and problem solving in dynamic, multi-institutional virtual organizations

across administrative domains.”

Adapted from The Anatomy of the Grid

27

© 2012 SWITCH

Grid Security Essentials • Support multi-user collaboration

– Organized in one or more Virtual Organizations (VO) – May contain individuals acting alone – their home organization

administration do not need necessarily to know about all activities

• Access to shared services and resources – Cross-domain authentication – Authorization (execute, read/write files, …) – Accounting, billing, …

• Resource owner must always stay in control – Is responsible for the authentication/authorization

• The communications are secured (X.509, GSI, …)

28

© 2012 SWITCH

Institutional vs. Virtual Organization

29

© 2012 SWITCH

Virtual Organizations (VO’s)

“A VO is a group of researchers with similar interests and requirements, who are able to work collaboratively with other members and/or share resources (e.g. data, software, expertise, CPU, storage space) regardless of geographical location.” • Grid users are always member of a VO • VO may also add information to proxy certificates

– Group memberships – Roles

• De facto Standard: VOMS – Virtual Organization Membership Service (VOMS)

30

© 2012 SWITCH

Proxy Certificates

• Special type of X.509 certificate (RFC3820)

• Can contain an Attribute Certificate (AC) with the VO information

– Group memberships – Roles

• Used for authentication (user identity) • VO information used for authorization (groups and roles)

•  Is used for delegation…

31

© 2012 SWITCH

VO Information from VOMS

• Groups and roles information is issued as an signed Attribute Certificate (AC) from VOMS. It is put as an extension into the user’s proxy certificate

• AC contains list of “fully qualified attribute names“ (FQAN) – FQAN example:

q  /atlas/Role=administrator q  /atlas/analysis

– First FQAN is primary FQAN à special role in job handling

• All groups are listed, ordering matters • Role information is present only if the users requests it

32

© 2012 SWITCH

•  Grid jobs require access to multiple resources •  Delegation = remote creation of a (second level) proxy

credential –  Brokers and services act on behalf of users –  with (a subset of) their rights –  This leads to a push model with proxies

q you don’t know beforehand where your task will end up •  Allows remote process to authenticate on behalf of the user

–  Remote process “impersonates” the user

33

Delegation and Limited Proxy Proxy Delegation

© 2012 SWITCH

Proxy Delegation (cont.)

Note: private key never leaves the host

34

© 2012 SWITCH

Proxy Renewal

• Proxy has limited lifetime (default is 12 h) – Bad idea to have longer proxy

• However, a Grid job might need to use a proxy for a much longer time

– Grid jobs in HEP Data Challenges on LCG last up to 2 days

• A dedicated service can renew automatically the proxy

35

© 2012 SWITCH

Obtaining a Proxy Certificate

• Requirement – A valid X.509 user certificate – Being registered in VOMS in a VO

• Request a proxy from the VOMS server 1.  Creates key pair for proxy certificate 2.  Contacts VOMS server for VO to obtain AC 3.  Creates proxy certificate with VOMS AC and signs it using the

user’s private key Use command: voms-proxy-init –voms <VO>

36

© 2012 SWITCH

Obtaining a Proxy Certificate (Example)

• Valid X.509 user certificate: $ openssl x509 -subject -issuer -noout -in ~/.globus/usercert.pem subject= /DC=ch/DC=switch/DC=slcs/O=SWITCH/CN=Valery Tschopp 9FEE5EE3 issuer= /C=CH/O=SWITCH/CN=SWITCHslcs CA!

• Request a VOMS proxy from VO dteam: $ voms-proxy-init -voms dteam !Enter GRID pass phrase:!Your identity: /DC=ch/DC=switch/DC=slcs/O=SWITCH/CN=Valery Tschopp 9FEE5EE3!Creating temporary proxy ................................. Done!Contacting voms.hellasgrid.gr:15004 [/C=GR/O=HellasGrid/OU=hellasgrid.gr/CN=voms.hellasgrid.gr] "dteam" Done!Creating proxy ................................. Done!

Your proxy is valid until Wed Nov 28 08:26:46 2012!

37

© 2012 SWITCH

Obtaining a Proxy Certificate (Example) • Show the VO information: $ voms-proxy-info -all!subject : /DC=ch/DC=switch/DC=slcs/O=SWITCH/CN=Valery Tschopp 9FEE5EE3/CN=proxy!

issuer : /DC=ch/DC=switch/DC=slcs/O=SWITCH/CN=Valery Tschopp 9FEE5EE3!identity : /DC=ch/DC=switch/DC=slcs/O=SWITCH/CN=Valery Tschopp 9FEE5EE3!type : proxy!strength : 1024 bits!path : /tmp/x509up_u959!timeleft : 11:58:48!

key usage : Digital Signature, Key Encipherment!=== VO dteam extension information ===!VO : dteam!subject : /DC=ch/DC=switch/DC=slcs/O=SWITCH/CN=Valery Tschopp 9FEE5EE3!issuer : /C=GR/O=HellasGrid/OU=hellasgrid.gr/CN=voms.hellasgrid.gr!attribute : /dteam/Role=NULL/Capability=NULL!

attribute : /dteam/NGI_CH/Role=NULL/Capability=NULL!timeleft : 11:58:47!uri : voms.hellasgrid.gr:15004

38

© 2012 SWITCH

Problem with X.509 Certificates

• Personal certificates have their drawbacks: – Provisioning certificates to the users is cumbersome – Certificates require a lot of knowledge from the user – Private keys must be properly secured

• Conclusion from a usability point of view

The easiest is to hide the certificate from the user !

40

© 2012 SWITCH

SWITCHaai – Swiss Authentication and Authorization Infrastructure

• SWITCHaai provides every user of the Swiss academic community an identity that is backed by the user’s home organization (i.e. his/her university)

• Every university of Switzerland is member of AAI

• Based on Shibboleth – Open source – Federated Identity – Security Assertion Markup Language (SAML) – Trust based on X.509

41

© 2012 SWITCH

Issuing Certificates based on AAI • As every student of Switzerland already has an AAI

credential, issue certificates based on the user’s SAML attributes

– Identity vetting is already been done by the university

• User friendly way to obtain X.509 Grid certificate – No special identity vetting needed – Certificates simply expire once they are no longer used (short lived)

• Short-Lived Credential Service (SLCS)

– Issues Grid certificates to a member of SWITCHaai based upon successful authentication at his/her home organization

42

© 2012 SWITCH 43

SLCS Certificates • Online CA issuing short-lived X.509 certificates based upon

authentication at AAI Identity Provider

• SAML attributes used in X.509 name

•  In production and accredited by EuGridPMA (IGTF Trust)

© 2012 SWITCH

SLCS Certificates based on AAI

• Certificate lifetime < 1 mio sec (~ 11 days) • Easy generation from the command line based on the AAI

authentication • Certificates simply expire after 11 days and can reissued

many times à easy to use for the user • SLCS service is operated by SWITCH

– http://www.switch.ch/grid/slcs

44

© 2012 SWITCH

Next Challenge: Cloud Computing

• Cloud Computing Today – Multitude of players – Heterogeneous system – Vendor specific – No real standardization yet

• Authentication and authorization mainly based on the institutional model

– Full control of the users (authentication and trust) – But does not cross the domain boundaries!

46

© 2012 SWITCH

Federated Cloud Computing

•  Interoperability and Portability – No vendor lock-in – Standardized API – Distributed, cross-domain authentication/authorization

• Different authentication technologies used in different Clouds

– Security Token Service (STS) to transform credentials

• Will certainly require other technologies than X.509… – SAML for authentication (federated identities) – XACML for authorization

47

© 2012 SWITCH

Summary

• Security Fundamentals (public-key crypto) – X.509 certificates

• Grid security is mainly based on X.509 – Cross-domain authentication based on trust (CAs) – Delegation mechanism

• VO Information – Groups and roles – Issued as attribute certificate (AC) – Used for authorization

• Federated Cloud is not yet a reality – Where is something to learn from Grid Computing…

49

authentication and authorization · authentication authorization resource credentials " user...

Documents