Grid Security
The information in this presentation is based on GT4
Andrew Fitzgerald Dilip Garg Aric Schorr
GSI
OpenID
Myprox
Shibboleth
x509
VOMS
Key Security Concepts
• Main Goals of Security– Confidentiality
• Only the two parties can understand the contents of the messages/transmissions
– Authentication• Each party is able to prove their identity
– Integrity• Each party is able to discover if any changes in a
message has occurred
Public Key Cryptography
• Alice has a public and private key for– Private operation D(x)– Public operation E(x)
• Provides Confidentiality– Bob encrypts E(m)– Alice can decrypt D(E(m))
• Provides Authentication– Alice signs D(m)– Anyone verifies E(D(m))
ex. RSA
Public Key Encryption1. Sender uses Receiver’s public
key to encrypt the message2. Sends E(m)
3. Receiver applies private key/operation to E(m)
4. m = D(E(m))
Public Key Digital Signatures1. Sender &
Receiver apply hash to the message to produce a digest
2. Sender encrypts the digest using his private key
3. Receiver decrypts the digest using the sender’s public key
This is proves the identity of the sender because the receiver uses the “sender’s” public key. If someone were attempting to pose as the ‘sender’ they would not have the private key to perform the correct encryption of the message digest.
Public Key Infrastructure
• Certificate Authority – trusted by everyone– CA signs user’s certificate that contains user’s
identity and public verification & encryption key
• Web of Trust (PGP) – users sign each other’s certificates
http://xkcd.com/364
Basic Security: More Info
• http://gdp.globus.org/gt4-tutorial/multiplehtml/ch09.html – This tutorial is only a few ‘slides’ in length and provides a very
good overview with nice images.
The Globus Toolkit
• These security components are based on GSI
Grid Security Infrastructure
• Key motivations for GSI:– Need for secure communication– Need for support security across organizational boundaries– Need to support “single sign-on”
• Uses public key (AKA: asymmetric) cryptography• Features:
– Transport and Message level security• 3 schemes
– Authentication through X.509 and proxy certificates– Multiple authorization schemes– Credential delegation & single sign-on– Security levels: container, service, resource
GSI: WS Security• Transport-level security
• Message-level security
• Quick SOAP reminder… – Simple Object Access Protocol– Allows programs to communicate via the internet
• XML sent, usually, over HTTP
– Abstraction layer on which others can be built
GSI: WS Security
• Two message level security mechanisms
1. WS Security standard• Security for individual SOAP messages
– IE, on a per message basis without any existing pretext between sender and receiver
2. WS Secure Conversation• Initial message exchange to establish security context• Subsequent messages require less overhead for security
during the session
GSI: WS Security
• Transport level VS Message levels
GSI Secure Conversation
GSI Secure MessageGSI
Transport
Technology WS-SecureConversation WS-Security TLS
Privacy (Encrypted) YES YES YES
Integrity (Signed) YES YES YES
Anonymous authentication
YES NO YES
Delegation YES NO NO
PerformanceGood if sending many
messagesGood if sending few
messagesBest
The Globus Toolkit: GSI
• Authentication and Authorization
Authentication
• Verification of the identity of an entity through the presentation of a token that can not be forged
• Important for:– Access control– Confidentiality– User (organization) accountability
Authentication
• Anonymous Authentication– Essentially means unauthenticated– Examples: Using > 1 security scheme
• GSI Secure conversation (authenticated with X.509 cert.) and anonymous GSI transport
• Username & pass again with anonymous GSI transport
• Username and password– Supports rudimentary WS apps– No access to advanced features, such as…
• Delegation, confidentiality, integrity, replay prevention
• x.509 certificates
Authentication
• X.509 “… profiles the format and semantics of certificates and certificate revocation lists …”
• This defines the syntax of how a Certificate Authority can sign and authenticate who is whom in an asymmetric (public key) based crypto world
• Used by … who who and whom
X.509 Certificate Fields
Field Description
Version Version of X.509 (current is v3)
Serial Number Assigned by CA and unique to each certificate
Signature Algorithm identifier used by the CA to sign the certificate
Issuer Identifies the CA that issued and signed the certificate
Validity Start and end dates that determine the validity
Subject Identifies the entity associated with the public key
Subject Public Key Info Identifies the public key and algorithm
Subject/Issuer IDs Unique ID that identifies subject/issuer (not recommended)
Extensions (v3 only) Defined method for associating additional attributes
X.509 Certificate ExampleCertificate:
Data:
Version: 1 (0x0)
Serial Number: 7829 (0x1e95)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division,
CN=Thawte Server CA/[email protected]
Validity: Not Before: Jul 9 16:04:02 1998 GMT
Not After : Jul 9 16:04:02 1999 GMT
Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
OU=FreeSoft, CN=www.freesoft.org/[email protected]
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit): (1024 bits of data … )
Exponent: 65537 (0x10001)
Signature Algorithm: md5WithRSAEncryption (signature data … )
Authorization
• Determining what actions (tasks) are permitted for an entity
1. Custom• Ex. Creating authorization methods to
interface GSI with an existing legacy system
2. Server-side
3. Client-side
Authorization
• Server-side authorization modes:
1. None -> No authorization2. Self -> Authorized if client identity==service identity3. Gridmap -> Authorized user list (~ACL)4. Identity Authorization -> Identity must match
programmed identity5. Host Authorization -> Only allow requests from a
particular host specified in the given credential6. SAML Callout Authorization -> Authorization
decision delegated to OSGA Authorization-compliant authorization service.
Authorization
– Client-side authorization– Allows the client to decide when a client is allowed
to be invoked
– Modes:1. None -> No authorization
2. Self -> Authorized if client identity==service identity
3. Identity Authorization -> Identity must match programmed identity
4. Host -> Authorized if client has a host credential– Client must be able to resolve hostname address
Authorization
• Problem– Not feasible to administer authorization
information on a site by site basis• Users normally administer only their own local site,
not the sites of other entities
• Solution– VOMS
VOMS
• Virtual Organization Membership Service– “… system for managing authorization data
within multi-institutional collaborations. VOMS provides a database of user roles and capabilities … to generate Grid credentials for users when needed.” – Globus Alliance
• Developed by European DataGrid Project
VOMS
• Authorization based on policies and agreements between Virtual Organizations (VO) and Resource Providers (RP)
• Users in a VO must present credentials to an RP in order to gain access to the resources
• VOMS allows VO administrators to add users and their roles and capabilities to an authorization database
VOMS
VOMS AuthDB
Client
Request
Authentication
pseudocert
Proxy Certificate
pseudocert
To RP
1. User and server authenticate each other using certificates via the standard globus API
2. User sends a signed request to VOMS server
3. VOMS server verifies user identity and sends back the VOMS “pseudo-certificate” or “attribute certificate”
4. User creates proxy certificate containing pseudo-certificate as a non-critical extension
5. The RP extracts the authorization information and makes a decision using the Local Credential Authorization Service (LCAS)
VOMS Database Security
• Scenario – malicious user grants access rights to any service through compromised database
• User can still not impersonate another user since the pseudo-certificate is embedded in a user-self-signed proxy certificate
• Scenario – Denial of Service Proxy Certificate
pseudocert
The Globus Toolkit: GSI
• Delegation and single sign-on
Delegation
• x.509 proxy certificates– Based on WS-Trust specification
The Globus Toolkit: GSI
• Community Authorization Service
Community Authorization Service (CAS)
• A service that allows resource providers to specify access policies to a community as a whole
• Fine-grained access controlled by the community itself
• How CAS works ………………………..
Community Authorization Service (CAS)
• How it works…
1. CAS server initiated for a community– Community rep acquires a GSI credential (1) for
the whole community– Same rep runs the CAS server using the
received GSI credential
Community Authorization Service (CAS)
• How it works…
2. Resource providers grant privileges to the community– Each resource provider verifies…
1. Credential holder represents the community
2. Community policies are compatible with its own
– Trust relationship established– Rights granted to the community identity
Community Authorization Service (CAS)
• How it works…
3. Community rep(s) use CAS to manage community's trust relationships and grant access to resources– Users and resource providers can be enrolled
into the community– Privileged community members can administrate
the community– Ex. Add new members, manage groups, grant
permissions
Community Authorization Service (CAS)
• How it works…
4. When a user wants access to CAS served resources…1. The user makes a request to the CAS server2. CAS server verifies that the user has the
appropriate privileges by checking its DB3. CAS server issues the user a GSI restricted
proxy credential– Credential contains policy giving user rights to perform
the requested actions
Community Authorization Service (CAS)
• How it works…
5. User may then use the issued credential to access the resource using any Globus tool– Resource applies its local policies to determine
access available to the community– Resource further restricts a users access IF the
credentials given to the user by the CAS dictate
GSI: Credential Management
• Problem– Grid Portals do not integrate cleanly with
existing Grid security systems, such as GSI– Reason: Lack of delegation capabilities in
Web security mechanisms
• Possible solution– MyProxy
MyProxy
• Cover MyProxy here?
OpenID
• “An open, decentralized, free framework for user-centric digital identity”
• Who uses OpenID– AOL, Blogger, Flockr, WordPress,
Yahoo(beta), …
OpenID• Two Architectural Implementations
1. Address-based Identity– Public or private digital address dereferenced to discover/invoke identity
services– Could be either…
– OpenID-enabled URL– XRI i-name (Ex.: xri//=example.user)
– Persistent, protocol-independent, privacy-protected– Supports cross-reference authority for P2P addressing
2. Card-based Identity– Digital token containing references to attributes identifies the user– Contains information necessary to accomplish identity based transaction
– Neither are exclusive– Ex.: Card could reference address or Address could reference card
OpenID: Protocol Flow
References• Novotny, J., Tuecke, S., & Welch, V. (2001). An Online Credential Repository for the
Grid: MyProxy. Paper presented at the Proceedings of the Tenth International Symposium on High Performance Distributed Computing (HPDC-10), IEEE.
• Alfieri, R., Cecchini, R., Ciaschini, V., Frohner, Á., Gianoli, A., Lőrentey, K., & Spataro, F. (2003). An Authorization System for Virtual Organizations. Paper presented at the In Proceedings of the 1st European Across Grids Conference, Santiago de Compostela.
• Sotomayor, B. The Globus Toolkit 4 Programmer's Tutorial: Chapter 10. GSI: Grid Security Infrastructure.
• Welch, V., Siebenlist, F., Foster, I., Bresnahan, J., Czajkowski, K., & Gawor, J., et al. (2003). Security for Grid services. High Performance Distributed Computing, 2003. Proceedings. 12th IEEE International Symposium on, 48-57.
• Zhao, S., Aggarwal, A., & Kent, R. D. (2007). PKI-Based Authentication Mechanisms in Grid Systems. Networking, Architecture, and Storage, 2007. NAS 2007. International Conference on, 83-90.
• Welch, V., Siebenlist, F., Foster, I., Gawor, J., Kesselman, C., & Meder, S., et al. (2004). X.509 Proxy Certificates for Dynamic Delegation. 3rd Annual PKI R&D Workshop.
References (cont.)
• Welch, V. Globus Toolkit Version 4 Grid Security Infrastructure: A Standards
Perspective 2005 • Inproceedings (1179532)
Recordon, D. & Reed, D.OpenID 2.0: a platform for user-centric identity managementDIM '06: Proceedings of the second ACM workshop on Digital identity management, ACM, 2006, 11-16