Transcript Grid Security

Grid Security
Andrew Fitzgerald
Dilip Garg
GSI
OpenID
MyProxy
Shibboleth
Aric Schorr
x509
VOMS
The information in this presentation is based on GT4
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 Encryption
1. Sender uses Receiver’s public
key to encrypt the message
2. Sends E(m)
3. Receiver applies private
key/operation to E(m)
4. m = D(E(m))
Public Key Digital Signatures
1. 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 Message
GSI
Transport
WS-SecureConversation
WS-Security
TLS
Privacy (Encrypted)
YES
YES
YES
Integrity (Signed)
YES
YES
YES
Anonymous
authentication*
YES
NO
YES
Delegation
YES
NO
NO
Good if sending many
messages
Good if sending few
messages
Best
Technology
Performance
* Basically, unauthenticated communication
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
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 Example
Certificate:
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.
2.
3.
4.
None -> No authorization
Self -> Authorized if client identity==service identity
Gridmap -> Authorized user list (~ACL)
Identity Authorization -> Identity must match
programmed identity
5. Host Authorization -> Only allow requests from a
particular host specified in the given credential
6. SAML Callout Authorization -> Authorization
decision delegated to OSGA Authorizationcompliant 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
VO Roles
• Applicant:
– An experimenter who belongs to one of the VO institutions
and possesses a certificate from one of the VO-approved
Certificate Authorities. An applicant has submitted a VO
registration form but has not yet been approved.
• Member:
– An applicant who has been approved. A member can submit
jobs to the Grid. By default a member is assigned to an
experiment wide group.
• VO administrator:
– A designated VO member who is in charge of registration and
has access to all information collected by the VO. He is
responsible for assigning administrative roles.
VO Roles
• Institutional VO representative:
– Responsible for the identity of an applicant.
– Upon registration a member can select a representative from the list of
known representatives. The selected representative does not
necessarily belong to the member’s institution.
• Grid site administrator:
– Assigns/revokes the role of System Administrator or Local Resource
Provider to/from the VO members affiliated with the site
– Administers authorization of VO member to the site. The details are site
specific and depends on regulations and policies of each particular site.
• Local resource provider:
– Administers authorization a member to use the grid resource (this could
include addition of this member to the gridmapfile, mapping member to
local account, etc)
Registration Flow
Institution
notify
approve
VO Central Node
Representative
synchronize
Applicant
Member
EDG VOMS
Proxy Server
VOMRS
register
query
notify
approve
Grid Site
notify
approve
Grid Site
notify
approve
notify
approve
Site Admin
Site Admin
LRPS
LRPS
VOMS
1.
2.
User and server authenticate
each other using certificates
via the standard globus API
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 noncritical extension
5.
The RP extracts the
authorization information and
makes a decision using the
Local Credential
Authorization Service
(LCAS)
Authentication
Request
Client
pseudocert
VOMS
Auth
DB
pseudocert
Proxy
Certificate
To RP
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
pseudocert
Certificate
The Globus Toolkit: GSI
• Delegation
and single
sign-on
Delegation
• Problem scenario:
• Solution
– x.509 proxy certificates
• Based on WS-Trust specification
– Delegation empowers Bob to act on behalf of Alice
without Alice giving out her private key
Delegation
•
How the proxy certificate is created
1.
2.
3.
4.
5.
–
Validation is almost identical to that of a regular certificate
–
–
Bob creates public & private keys for the certificate
Bob uses the keys to generate the certificate request
As long as Alice agrees to the delegation to Bob, the certificate is
signed by Alice
Alice returns the signed certificate to Bob
The certificate can now be used by Bob to act on behalf of Alice
The only difference is that the proxy certificate is signed by Alice
instead of a certificate authority
The proxy certificate is usually time limited for security
Delegation
• A bonus feature allowed by proxy certificates is single
sign-on
– In secured transactions, the private key would have to be
accessed often for authentication
– Accessing the private key usually would require the user to
authenticate by password
– Single sign-on allows the user to create the proxy certificate
once, then its used for subsequent transactions
OpenID
• “An open, decentralized, free framework for usercentric digital identity”
• In short, OpenID is
offering single sign-on for
many services with one
login
• Who uses OpenID
– AOL, Blogger, Flickr,
WordPress, Yahoo (beta),
SourceForge, …
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
1. End user enters OpenID
2. XRDS(Yadis) Document
<xrds:XRDS xmlns:xrds="xri://$xrds"
xmlns="xri://$xrd*($v*2.0)"
xmlns:openid="http://openid.net/xmlns/1.0">
<XRD>
<Service>
<Type>http://openid.net/signon/1.0</Type>
<URI>http://pip.verisignlabs.com/server/open
id</URI>
</Service>
</XRD>
</xrds:XRDS>
6. User can select information to
reveal to the relying party
End User
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 server
2. CAS server verifies that the user has the
appropriate privileges by checking its DB
3. 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
• An Online Credential Repository
• Basic idea
– Issues short term credentials upon request,
on behalf of a user request. Thus avoiding
multiple user interactions
Public Key Infrastructure
• Public Key Cryptography
• Digital Signatures
PKI (Contd.)
• Digital Certificates (Credentials)
– The sender needs to be sure that the public
key used for encryption, actually belongs to
the intended recipient, not to an imposter.
Proxy Credentials
• In the Grid environment, a user may need to
authenticate themselves multiple times in a relatively
short period of time
• Two possible approaches
– User repeatedly enters the password - inconvenient , insecure
– Store the password physically and use it for later use – though
convenient, more insecure as the password is exposed for
longer periods
• GSI solves this problem with proxy credentials
– Short term credential created by the user, in place long term
– Has its own private key and certificate, and is signed using the
user’s long term credential
MyProxy Credential Repository System
1. Delegation to the Repository
A user would start by using the
myproxy-init client program along
with their permanent credentials to
contact
the
repository
and
delegate a set of proxy credentials
to
the
server
along
with
authentication information and
retrieval restrictions
MyProxy (Contd.)
2. Retrieval of the credential
from Repository
At a later time, the user, or a
service acting on behalf of
the user, uses the myproxyget-delegation program to
contact the server and request
a delegation of the user’s
credentials
MyProxy (Contd.)
3. Using the MyProxy Repository with a Grid Portal
Command Line example
• http://wiki.egeesee.org/index.php/Delegation_of_Credenti
als_Using_MyProxy
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.
David Recordon and Drummond Reed. Openid 2.0: a platform for user-centric identity
management. In DIM ’06: Proceedings of the second ACM workshop on Digital identity
management, pages 11-16, New York, NY, USA, 2006. ACM.
Von Welch. Globus toolkit version 4: Grid Security Infrastructure: A Standards Perspective.
September 2005.
Alfieri, R., Cecchini, R., Ciaschini, V., dell'Agnello, L., Frohner, Á., o, K. L\H., & Spataro, F. (2005).
From gridmap-file to VOMS: managing authorization in a Grid environment. Future Gener.
Comput. Syst., 21(4), 549-558.
http://grid-auth.infn.it/
http://www.ietf.org/rfc/rfc2459.txt