Tecnologia dei Servizi Grid e cloud computing - Lezione 005b 0 Lezione 5B - 18 Novembre 2009 Il...

Tecnologia dei Servizi “Grid e cloud computing” - Lezione 005b 1

Lezione 5B - 18 Novembre 2009

Il materiale didattico usato in questo corso è stato mutuato da quello utilizzato da Paolo Veronesi per il corso di Griglie Computazionali per la Laurea Specialistica in Informatica tenuto nell’anno accademico 2008/09 presso l’Università degli Studi di Ferrara.

Paolo [email protected], [email protected]://www.cnaf.infn.it/~pveronesi/unife/

Università degli Studi di Bari – Corso di Laurea Specialistica in Informatica

“Tecnologia dei Servizi “Grid e cloud computing” A.A. 2009/2010

Giorgio Pietro Maggi [email protected], http://www.ba.infn.it/~maggi


Securing the Channel

GSI and the Mutual Authentication

Authorization

Federated Trusts

Overview


Securing the Channel


Techniques

Transport Level Security (TLS) Creation of a secure point-to-point connection between the client

and server Use of a Secure Sockets Layer (SSL) implementation

Message Level Security (MLS) SOAP messages are signed/encrypted over a non-secure

socket connection Use of emerging WS standards such as WS-Security,

WSSecureConversation, XML Signatures


Transport-Layer Security

TLS: Pros and Cons Pros

SSL has been an internet standard for years Fast implementations available

Cons Implemented at the socket layer - difficult to propagate

security related information (e.g. client’s DN, security assertions, etc) to higher levels in the software stack

Due to the secure point-to-point nature of the socket connection, it doesn’t work for multi-hop connections, e.g. in the presence of firewalls, intermediaries, etc.


Message-Level Security

MLS: Pros and Cons Pros

No need for a secure point-to-point connection – works well for multi-hop connections

Since it is done at the message level, portions of messages can be encrypted - useful if messages can contain a mixture of sensitive and non-sensitive information

Authorization information (e.g. assertions) can propagated easily to higher levels in the software stack

Cons Performance


OGSA Basic Security Profile 1.0 Based on:

WS-I Basic Security Profile HTTP Over TLS TLS 1.0

Focus: Mutual Authentication. The Profile mandates the use of a secure

transport layer protocol to ensure mutual authentication of both ends of a Web service communication

Integrity. The Profile mandates the use of a secure transport layer protocol to ensure data integrity while communicating with Web services

Confidentiality. The Profile mandates the use of a secure transport layer protocol to ensure confidentiality of a Web service communication.


Mutual Authentication


Mutual Authentication

If two parties have certificates, and if both parties trust the CAs that signed each other's certificates, then the two parties can prove to each other that they are who they say they are. this is known as mutual authentication.

GSI (Grid Security Infrastructure) uses the TLS for its mutual authentication protocol Standard secure transport for pre-WS services in Grids

Before mutual authentication can occur, the parties involved must first trust the CAs that signed each other's certificates.

In practice, this means that they must have copies of the CAs‘ certificates--which contain the CAs' public keys--and that they must trust that these certificates really belong to the CAs.


The Grid Security Infrastructure (GSI)

every user/host/service has an X.509 certificate;

certificates are signed by trusted (by the local sites) CA’s;

every Grid transaction is mutually authenticated:

1. John sends his certificate;2. Paul verifies signature in John’s certificate;3. Paul sends to John a challenge string;4. John encrypts the challenge string with his

private key;5. John sends encrypted challenge to Paul6. Paul uses John’s public key to decrypt the

challenge.7. Paul compares the decrypted string with the

original challenge8. If they match, Paul verified John’s identity and

John can not repudiate it. Now that Paul trusts John's identity, the

same operation must happen in reverse.

JohnJohn PaulPaulJohn’s certificateJohn’s certificate

Verify CA signatureVerify CA signature

Random phraseRandom phrase

Encrypy with J.’ s private keyEncrypy with J.’ s private key

Encrypted phraseEncrypted phrase

Decrypt with J.’ s public keyDecrypt with J.’ s public key

Compare with original phraseCompare with original phrase

Based on X.509 PKI:


Authorization


What Can I Do?

Identity established through authentication No info on user permissions/rights/privilege A separate infrastructure is needed to manage user

privilege

Authorisation is an ongoing research area with many solutions Most solutions involve integrating many separate

technologiesAnd often many AuthZ techs


Access Control Lists (ACLs)

Lets start with the simplest scenario: Once a user has authenticated they are checked against a local list of

users Simple to understand and works well for mini-grids Grid-map file

But.. What if access to a resource is needed for a different purpose by the

same person? Multiple entries or multiple lists?

What if we want HUNDREDS of users? BUSY, BUSY sys admins!!


Problems:

Very coarse-grained authorization: Remote users are mapped directly to UNIX users. Classification of users into categories must be done

on a local farm basis without input from the VO (may result in the same user having very different privileges in different farms).

No support for groups or roles Grid-mapfile authorization is not flexible.


A better way…

Just a straight list of users is too difficult to maintain and is not flexible enough for Grids

What defines a persons permissions on a resource usually? What kind of jobs do people have?

Doctor, Nurse, Student, Lecturer, Director, CEO, SysAdmin, PhD People come and go but job descriptions generally are static

Any exceptions should be easy to manage Can you see where this may be going..?


Role Based Access Control

Access to a resource should be granted according to a user’s ROLE within the VO Multiple Roles may be held by a user

Different levels of AuthZ may be enforced Role hierarchies may be supported

Access may be granted by Role only If anonymous access is required

No policy changes required as users come and go Happy sys admins! Just grant them the necessary role when they join the VO

and they will have access.. So how do we grant roles to users?


Privilege Management Infrastructures (PMIs)

We can utilise the secure infrastructure provided by X.509 certificates to assign roles to users We need an extension to the X.509 specification to support

PRIVILEGE ATTRIBUTES

So as well as the normal info in their certificate, a user may be assigned one or more ATTRIBUTE CERTIFICATES which contain a signed assertion of their role within the VO

Many similarities to PKIs…


PKI and PMI A PMI is to authorisation what a PKI is to authentication –

hence similar concepts

Concept PKI Entity PMI Entity

Certificate Public Key Certificate (PKC) Attribute Certificate (AC)

Certificate Issuer Certification Authority (CA) Attribute Authority (AA)

Certificate User Subject Holder

Certificate Binding Subject’s name to Public Key

Holder’s Name to Privilege Attribute(s)

Revocation Certificate Revocation List (CRL)

Attribute Certificate Revocation List (ACRL)

Root of trust Root Certification Authority or Trust Anchor

Source of Authority (SOA)

Subordinate authority Subordinate Certification Authority

Attribute Authority (AA)


PMI in Grid

The PMI is defined by a standard body In Grid systems ,the most successful Privilege

Attribute management system is VOMS VOMS has many concepts close to PMI and are

applied to Proxy Certificates Another emerging approach is GridShib


VO ManagementVOMS: Virtual Organization

Membership Service


What is VOMS

The most successful privilege attributes manager available today to Grid VO’s

VOMS is an X.509 Attribute Authority with special support for grids. Adds groups and roles Adds Attribute Certificates (ACs) directly in the user proxy Used via voms-proxy-init command Compatible with grid-proxy-init


VOMS Objectives and requirements

To provide a secure system for Virtual Organizations (VOs) to organize users into groups and/or roles and to disseminate this information. A VO is a collection of users and resources working together on

a common project Membership in a VO is a restricted information

Extensibility Users should be able to specify how much information they want

to publish Backwards compatibility with the Globus Toolkit Should not invalidate established GT-based work mechanisms Should minimize software requirements other than GSI libraries

in the core components


VOMS Solution

Grant authorization at the VO level Each VO has its own VOMS server Contains (group / role / capabilities) triples for each member of

the VO Also support for “forced groups” (for negative permissions)

Insert these information in a well-defined non critical extension of the user proxy

All client-server communication is secure and authenticated

Authorization info must be processed by the local sites


VOMS: Client-Server Interaction1) Mutual authentication between client

and server• Secure communication channel via

Globus GSI2) The client sends a signed request to

server3) The server checks the identity of the

user and the syntactic correctness of the request

4) The server signs the authorization information and returns it back

5) The client checks the consistency and validity of the information returned

6) Steps 1-6 may be repeated for any number of servers

7) The client creates a proxy certificate that includes the information returned by the VOMS servers

8) Finally, the client may decide to include also additional information provided by the user (e.g. Kerberos tickets)

Query

Authentication

Request

AuthDB

C=IT/O=INFN /L=CNAF/CN=Pinco Palla/CN=proxy

VOMSpseudo-cert

VOMSpseudo-cert


Pseudo Certificate Format This Pseudo

Certificate is included into a non critical extension of the user’s proxy

OID:1.3.6.1.4.1.8005.100.100.1

Conversion to a true attribute certificate already started

There will be one such certificate for each VOMS server contacted

/C=IT/O=INFN/L=CNAF/CN=Vincenzo Ciaschini/[email protected]/C= IT/O=INFN/CN=INFN CA

/C=IT/O=INFN/OU=gatekeeper/L=PR /CN=gridce.pr.infn.it/[email protected]/C=IT/O=INFN/CN=INFN CAVO: CMS URI: http://vomscms.cern.ch:15000

TIME1: 020710134823ZTIME2: 020711134822ZGROUP: montecarloROLE: administratorCAP: “100 GB disk”

SIGNATURE:.........L...B]....3H.......=".h.r...;C'..S......o.g.=.n8S'x..\..A~.t5....90'Q.V.I..../.Z*V*{.e.RP.....X.r.......qEbb...A...

user’s identity

server identity

vomsdvomsd


Groups and Roles in VOMS Every user in a VO belongs to at least one group:

E.g: /infngrid And may also belong to some subgroups:

E.g: /infngrid/g1, /infngrid/g2, meaning subgroups g1 and g2 of /infngrid There are also Roles:

E.g: /Role=VO-Admin Roles make sense only in the contest of a group:

E.g: /Role=VO-Admin in the group /infngrid.

Compact way of describing it: (FQAN) /infngrid/Role=VO-Admin

Holding the role of VO-Admin in the group /infngrid


Federated Trusts


SAML Security Assertion Markup Language

Framework based on XML for the exchange of assertionsabout authentication and authorization

Defined by OASIS Security Services Technical Commitee Standard for managing identities

A bit of history Nov 2002: SAML v1.0. Set 2003: SAML v1.1. Many projects adopt SAML for managing the access to

Web resources Mar 2005: SAML v2.0

convergence of SAML 1.1, Liberty Alliance ID-FF 1.2, Shibboleth 1.3


SAML: Principali Componenti


Federated Trust

The best entity to authenticate a person is their home institution/company Info will be up to date They will always know a person better than a remote site Remote site may not know if user is still valid or not

Can we utilise a user’s home credentials to access remote resources?


Shibboleth Internet2 project Standards-based (SAML) Allows for Identity Federation

Identity == Identifier + Attributes Identifier may or may not be a persistent Name. Allows for pseudonymity via temporary, meaningless identifiers called

‘Handles’ Allows for inter-institutional sharing of Web resources (via browsers)

Provides attributes for authorization between institutions Being extended to non-web resources


Federated Authentication system using SAML for secure conversation

Enables Single-Sign On to Web Pages and Portals Authentication is done by the user’s home institution

Identity Provider (Origin) Authorisation (and access) is done by the resource

Service Provider (Target)


User Grid Portal

Home Institution

Service ProviderIdentity Provider

WAYF

Application

FederationAuthz


User Grid Portal

Home Institution

WAYF

Application

FederationAuthz

Point browser to portal


User Grid Portal

Home Institution


WAYF

Application

FederationAuthz

Shibboleth redirects userto W.A.Y.F service


User Grid Portal

Home Institution


WAYF

Application

FederationAuthz

User selects theirhome institution


User Grid Portal

Home Institution


WAYF

Application

FederationAuthz

AUTHENTICATE

Home confirms userID in local LDAP andpushes attributes tothe service provider

LDAP


User Grid Portal

Home Institution


WAYF

Application

FederationAuthz

Portal logs user in andpresents attributesto authorisation function


User Grid Portal

Home Institution


WAYF

Application

FederationAuthz

AUTHORISEPortal passes

attributesto AuthZ function tomake final accesscontrol decision


GridShib

GridShib enables secure attribute sharing between Grid virtual organizations and higher-educational institutions

The goal of GridShib is to integrate the Globus Toolkit® with Shibboleth®

GridShib adds attribute-based authorization to Globus Toolkit


Tale of Two Technologies

GridClient

GlobusToolkit

Shibboleth

X.509

SAMLGrid Security Infrastructure

Shibboleth FederationBridging Grid/X.509

with Shib/SAML


Operation Modes Pull

after the client has been authenticated, the Grid SP requests attributes from the client's own administrative domain via a back-channel exchange

Push the client provides the

attributes up front, obtaining and pushing those attributes to the Grid SP at the time of initial request

In either case, the Grid SP obtains the user attributes it needs to make an informed access control decision (authorization)


Riferimenti Lezione 5

GT 4.0 Security: Key Concepts; Globus Toolkit Version 4 Grid Security Infrastructure: A

Standards Perspective.; Identity Federation and Attribute-based Authorization

through the Globus Toolkit, Shibboleth, GridShib, and MyProxy.;

EGEE Project and gLite Middleware GILDA Infrastructure gLite userGuide Cap 1; 2; 3.3.1; 3.3.2; 4;

Tecnologia dei Servizi Grid e cloud computing - Lezione 005b 0 Lezione 5B - 18 Novembre 2009 Il...

Documents

Transcript of Tecnologia dei Servizi Grid e cloud computing - Lezione 005b 0 Lezione 5B - 18 Novembre 2009 Il...