62
5c.1 Security II – Grid Computing Security and Globus Security ITCS 4146/5146, UNC-Charlotte, B. Wilkinson, 2007 Feb 7, 2007

5c.1 Security II – Grid Computing Security and Globus Security ITCS 4146/5146, UNC-Charlotte, B. Wilkinson, 2007 Feb 7, 2007

  • View
    219

  • Download
    1

Embed Size (px)

Citation preview

5c.1

Security

II – Grid Computing Security

and

Globus Security

ITCS 4146/5146, UNC-Charlotte, B. Wilkinson, 2007 Feb 7, 2007

5c.2

Aspects

Grid computing involves setting up a virtual organization for the project:

• Setting up the resources that will be used.

• Identifying the users

• Creating a security policy across sites

• Dynamics -- Changing community roles, members

• Scaling -- Support for large numbers of resources and users

5c.3

Need to establish and enforce terms of sharing.

• VO-wide identification of users and services

• Authentication across administrative domains

• Authorization policy across administrative domains

• Trust across administrative domains

5c.4

Globus Grid Security Infrastructure (GSI)

• A set of tools, libraries, and protocols to allow users and applications to access resources securely in a grid computing environment.

5c.5

Globus Grid Security Infrastructure (GSI)

• Based upon public key infrastructure with certificate authorities and X509 certificates.

• GT 2 components use SSL for authentication and message protection.

• GT 4 can use WS-Security protocols – extensions to SOAP messaging for security

Data Management

SecurityCommonRuntime

Execution Management

Information Services

Web Services

Components

Non-WS

Components

Pre-WSAuthenticationAuthorization

GridFTP

GridResource

Allocation Mgmt(Pre-WS GRAM)

Monitoring& Discovery

System(MDS2)

C CommonLibraries

GT2

WSAuthenticationAuthorization

ReliableFile

Transfer

OGSA-DAI[Tech Preview]

GridResource

Allocation Mgmt(WS GRAM)

Monitoring& Discovery

System(MDS4)

Java WS Core

CommunityAuthorization

ServiceGT3

ReplicaLocationService

XIO

GT3

CredentialManagement

GT4

Python WS Core[contribution]

C WS Core

CommunitySchedulerFramework

[contribution]

DelegationService

GT4

Security

5c.7

Three important factors in grid computing are:

• Authorization– Process of deciding whether a particular

identity can access a particular resource• Authentication

– Process of deciding whether a particular identity is who he says he is (applies to humans and systems)

• Delegation (somewhat specific to grid computing)

– Process of giving authority to another identity (usually a computer/process) to act on your behalf.

5c.8

Authentication

Process of deciding whether a particular identity is who he says he is (applies to humans and systems)

5c.9

GSI AuthenticationEach user has set of credentials they use to prove their identity on the grid. Consists of:– X509 certificate and – private key

• Long-term private key kept encrypted with a pass phrase– Good for security, inconvenient for

repeated usage

5c.10

Certificate Authorities

• Grid computing group (virtual organization) requires one or more CAs to control access to their grid.

• Generally set up CA’s specifically for grid computing virtual organization.

5c.11

Certificate Authorityfor Grid Computing

• Usually a certificate authority is created for the specific grid computing environment.

• Globus has “simple” implementation called simpleCA.

5c.12

Grid Users

• After Certificate Authority established for grid, users have to register with grid CA.

• Users joining a grid from geographically dispersed locations must communicate with the CA system administrator to verify their identity and to get a signed certificate.

• Communication often done by email!

5c.13

Getting a certificate

3. Generate and sign

Request

Signed X509

Public key

Private Key

X509

CAUser

1. Create

2. Apply to CA

5c.14

Grid Security Infrastructure

From: “Introduction to Grid Computing with Globus,” IBM Redbooks,SG24-6895-012003, Fig. 3-3.

Globus Interaction with Certificate Authority

This step done by email or a more a secure way.

5c.15

grid-cert-request

• Globus command to run to get certificate.

• Requests a pass phrase.

• Can be used to get user certificates, host certificates and CA’s own certificate (chosen with grid-cert-request flags).

5c.16

Files held by user after using grid-cert-request

• Users usercert_request.pem – The certificate request, which you should send to your

CA. • Certificate: usercert.pem

– An empty file. When you receive your actual certificate from your CA, you should place it in this file.

• User’s private key: userkey.pem– Previously held (not transmitted), encrypted with pass

phrase used for grid-cert-request.

5c.17

Getting certificate from SimpleCA

Run:$GLOBUS_LOCATION/bin/grid-cert-request

Certificate request stored in:$HOME/.globus/usercert_request.pem

Email this request to certificate authority given in request. Save signed certificate that is returned.

SimpleCA uses the command grid-ca-sign to sign certificate.

5c.18

Grid Computers• Computers added to a grid (donors) preferably

need their identity verified in a similar fashion.

• Computers registered with certificate authority - only those machines will be allowed to participate in the grid activities.

• Computers might be used under a certain access rights.

5c.19

Components for Credential Generation

• Globus Certificate Service - An online service that issues low-quality GSI certificates to users who want to experiment with Grid software but don't have any other means to acquire certificates

– For testing only– Used in sticky note assignment

5c.20

SimpleCA

• CA available with Globus toolkit

• Simple to install

• A convenient method of issuing certificates for users and services that work with GSI and WS-Security

• For use with small projects with simple requirements.

• Used in this grid course

5c.21

Single or multiple CAs?

• Some grids have established a single CA for the virtual organization.

Example• UK e-Science grid has a centralized CA.

5c.22

Trans-European Research and Education Networking

Association

Provides a list of CAs with access to their certificates:

http://www.terena.nl/tech/task-forces/

tf-aace/tacar/certs.html

5c.23

Multiple CA’s in Fall 2005 Course grid

WCU

UNC-C

UNC-A

NCSU

ASU

UNC-W

CA

CA

CA

CACA

CA

5c.24

Users certified by a local CA

UNC-C

CA

5c.25

Configuring GT4 to Trust a Particular Certificate Authority

GT 4 can be configured to accept certificates from multiple CAs.

• Needs to know the CA’s to accept.

• Consists of loading two files describing each CA:

– cert_hash.0 The trusted CA certificate

– cert_hash.signing_policy

A configuration file defining the distinguished names of certificates signed by the CA

5c.26

CA’s with Mutual Trust

UNC-C

CA

UNC-W

CA

GT4

5c.27

Bridge CA’s

CA 2

Bridge CA

CA 3CA 1

Bridge providing trust

5c.28

Multiple CA’sWith multiple CA’s, users in virtual

organization need:

• Account on each computer system

and

• Access control policy set– An entry in each grid-map file of each

system if grid-maps used, see later.

5c.29

Grid Computers• Computers added to a grid (donors)

preferably need their identity verified in a similar fashion.

• Computers registered with certificate authority - only those machines will be allowed to participate in the grid activities.

• Computers might be used under a certain access rights.

5c.30

GSI Authentication

Originally based on SSL protocol where one passes an encrypted random number between parties

5c.31

B authenticating your certificate on A

• Host A send your certificate to Host B.

• Host B gets your public key and name from the certificate using CA’s public key.

• Host B creates a random number and sends it to Host A.

• Host A encrypts random number with your private key and sends it to host B.

• Host B decrypts number and checks number. If correct, Host B authenticates the certificate.

5c.32

From: “Introduction to Grid Computing with Globus,” IBM Redbooks,SG24-6895-012003, Fig. 3-4.

5c.33

Mutual Authentication

Two parties proving to each other that they are who they say they are.

Mutual authentication involves the previous process done both ways.

Both parties need to trust CAs that signed each other's certificates.

5c.34

GSI Mutual Authentication

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

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

5c.35

Mutual Authentication cont.To start the authentication process,:• A gives B his certificate.

• B will first make sure that certificate valid by checking CA's digital signature to make sure that the CA actually signed the certificate and that the certificate hasn't been tampered with. (This is where B must trust the CA that signed A's certificate.) Once B has checked out A's certificate, B must make sure that A really is the person identified in the certificate.

5c.36

Mutual Authentication cont.

• B generates a random message and sends it to A, asking A to encrypt it.

• A encrypts the message using his private key, and sends it back to B.

• B decrypts the message using A's public key.

• If this results in the original random message, then B knows that A is who he says he is.

5c.37

Mutual Authentication cont.

• Now that B trusts A's identity, the same operation must happen in reverse.

• B sends A her certificate, A validates the certificate and sends a challenge message to be encrypted.

• B encrypts the message and sends it back to A, and A decrypts it and compares it with the original.

• If it matches, then A knows that B is who she says she is.

At this point, A and B have established a connection to each other and are certain that they know each others' identities.

5c.38

Confidential Communication after Mutual Authentication

By default, GSI does not establish confidential (encrypted) communication between parties.

Communication can occur without the overhead of constant encryption and decryption.

GSI can easily be used to establish a shared key for encryption if confidential communication is desired.

5c.39

Communication integrity

Means that an eavesdropper may be able to read communication between two parties but is not able to modify the communication in any way.

GSI provides communication integrity by default. (It can be turned off if desired).

Communication integrity introduces some overhead in communication, but not as large as encryption.

5c.40

Authorization

Process of deciding whether a particular identity can access a particular resource and what fashion.

5c.41

GSI Authorization

Classical way of doing authorization is an access control list, listing the identities of those allowed and the type of access allowed.

• A grid could use a similar approach, using a grid-map file

5c.42

grid-map file

Globus installations can maintain a so-called grid-map file that contains a list of user DNs authorized for access, and their local username mappings.

Example

"/O=Grid/OU=GlobusTest/OU=simpleCA-myuniversity.edu/OU=myuniversity.edu/

CN=student0" student0

5c.43

Other ways of doing authorization Grid-map file a very primitive way which does not

scale well.

Other ways• SAML – Security Assertions Markup Language, a

OASIS standard– Allows communication of user authentication,

authorization and attribute information

• Communication Authorization Service (CAS)

5c.44

Community Authorization Service CAS

A service that allows resource providers to specify course-grained access control policies in terms of communities as a whole, delegating fine-grained access control policy management to the community itself.

To handle the situation of many users and many resources.

If each resource were to maintain access policies for each user, will not scale.

Delegate authorization to CAS to handle authorization for resources.

5c.45

5c.46

5c.47

A Typical CAS Request

2. CAS reply

CAS Server

What rights does the community

grant to this user?

User

1. CAS request,authenticated with

Resource Server

Does the policy statement authorize the

request?

3. Resource request

4. Resource reply

CAS-maintainedcommunity policy

database

User credential

Is this requestauthorized

for the community?

Local policyinformation

Policy statementsigned by

CAS server

User credentialPolicy statement

signed by CAS server

What local policy appliesto this user?

Resource grant

to community

5c.48

Other Components for Access Control and Authorization

• Shibboleth - A set of services that leverage existing user authentication and authorization systems at "home institutions" to give remote services the information they need to make authorization decisions.

• VOMS - A database-driven mechanism for central management of user role and capability data

5c.49

Delegation

• Process of giving authority to another identity (usually a computer/process) to act on your behalf.

• Single sign-on -- to enable user and it’s agents to acquire additional resources without repeated authentication (passwords).

5c.50

GSI Delegation

• Uses additional certificates passed between intermediate parties.

• Certificates called proxies.

• An extension to the standard SSL/TLS protocol.

5c.51

Proxy• Consists of a new certificate with new public,

private keys, and owner’s identify (/CN=proxy added to name).

• Certificate signed by owner (not CA)

• Proxy given limited lifetimes

• Proxy’s private key does not need to be kept as secure as owner’s private key - setting file permissions usually sufficient

5c.52

Use of proxy certificates• Single sign-on

• Create local proxy with say 12 hours lifetime.– Use proxy instead of your certificate– Password typing only once.– No password down wire.

• Delegation– Allows a remote entity to perform tasks on your behalf,

and access to your resources

• Mutual trust domains– All entities with proxies from same issuer will trust each

other

5c.53

• Proxies used to authenticate users and run user programs on grid.

• Proxy created with grid-proxy-init command.

• We shall see a use of this in assignment 2.

5c.54

Proxy Certificate

• Commands:– grid-proxy-init– grid-proxy-info– grid-proxy-destroy

• In GT:– User cert is password protected– Proxy cert is filesystem protected (/tmp)

5c.55

Delegation authority to another host

• Suppose host A wishes to delegate authority to host B to act on its behalf with host C.

• Rather a large number of internal steps.

5c.56

From: “Introduction to Grid Computing with Globus,”

IBM Redbooks,SG24-6895-012003, Fig. 3-5.

5c.57

Chain of trust

Continuing this process can have host B delegate authority to host C, host C delegate to host D, etc.

5c.58

Chain of trust

User is acting as a CA, acting within limits of their credentials. Cannot extend credentials

X509

X509

X509

CA

User

Proxy1

Proxy2

5c.59

Additional Proxies

From “Overview of the Grid Security Infrastructure”http://www.globus.org/security/overview.htm

5c.60

Mutual Authentication with Proxies

• Remote party receives owner’s certificate and owner’s proxy certificate.

Chain of trust• Owner’s public key from owner’s certificate used to

validate proxy signature on proxy certificate.

• Certificate authority (CA) public key used to validate owner’s signature on owner’s certificate

5c.61

• On grid, each party identifies itself with credentials.

• Credentials vulnerable to theft.

• No easy way of cancelling stolen credentials.

5c.62

MyProxy

• MyProxy is a Grid credential repository.

• A network service that stores user credentials so they can be accessed from other systems on the network

• Reduces risk of management of many copies of credentials.