Grid Security

1. Grid Security The information in this presentation is based on GT4

2. 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

3. 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

4. Public Key Encryption • Sender uses Receiver’s public key to encrypt the message • Sends E(m) Receiver applies private key/operation to E(m) m = D(E(m))

5. Public Key Digital Signatures • Sender & Receiver apply hash to the message to produce a digest • Sender encrypts the digest using his private key • 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.

6. 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

7. 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.

8. These security components are based on GSI The Globus Toolkit

9. 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

10. 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

11. GSI: WS Security • Two message level security mechanisms • WS Security standard • Security for individual SOAP messages • IE, on a per message basis without any existing pretext between sender and receiver • WS Secure Conversation • Initial message exchange to establish security context • Subsequent messages require less overhead for security during the session

12. GSI: WS Security • Transport level VS Message levels * Basically, unauthenticated communication

13. Authentication and Authorization The Globus Toolkit: GSI

14. 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

15. 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

16. 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 Authentication

17. X.509 Certificate Fields

18. 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/emailAddress=server-certs@thawte.com 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/emailAddress=baccala@freesoft.org 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 … )

19. Determining what actions (tasks) are permitted for an entity Custom Ex. Creating authorization methods to interface GSI with an existing legacy system Server-side Client-side Authorization

20. Authorization • Server-side authorization modes: • None -> No authorization • Self -> Authorized if client identity==service identity • Gridmap -> Authorized user list (~ACL) • Identity Authorization -> Identity must match programmed identity • Host Authorization -> Only allow requests from a particular host specified in the given credential • SAML Callout Authorization -> Authorization decision delegated to OSGA Authorization-compliant authorization service.

21. Authorization • Client-side authorization • Allows the client to decide when a client is allowed to be invoked • Modes: • None -> No authorization • Self -> Authorized if client identity==service identity • Identity Authorization -> Identity must match programmed identity • Host -> Authorized if client has a host credential • Client must be able to resolve hostname address

22. 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 Authorization

23. 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

24. 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

25. 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.

26. 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)

27. Institution notify approve Member VO Central Node EDG VOMS Proxy Server Representative register query Applicant synchronize notify approve notify approve VOMRS notify approve Grid Site Grid Site notify approve Site Admin Site Admin LRPS LRPS Registration Flow

28. VOMS • User and server authenticate each other using certificates via the standard globus API • User sends a signed request to VOMS server • VOMS server verifies user identity and sends back the VOMS “pseudo-certificate” or “attribute certificate” • User creates proxy certificate containing pseudo-certificate as a non-critical extension • The RP extracts the authorization information and makes a decision using the Local Credential Authorization Service (LCAS) Client VOMS Auth DB Proxy Certificate Request Authentication To RP pseudocert pseudocert

29. 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

30. Delegation and single sign-on The Globus Toolkit: GSI

31. 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

32. Delegation • How the proxy certificate is created • 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 • Validation is almost identical to that of a regular certificate • 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

33. 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

34. “An open, decentralized, free framework for user-centric 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

35. Two Architectural Implementations 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 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

36. OpenID: Protocol Flow End user enters OpenID 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> User can select information to reveal to the relying party End User

37. Community Authorization Service The Globus Toolkit: GSI

38. 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 ……………………….. 

39. Community Authorization Service (CAS) • How it works… • 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

40. Community Authorization Service (CAS) • How it works… • Resource providersgrant privileges to the community • Each resource provider verifies… • Credential holder represents the community • Community policies are compatible with its own • Trust relationship established • Rights granted to the community identity

41. Community Authorization Service (CAS) • How it works… • 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

42. Community Authorization Service (CAS) • How it works… • When a user wants access to CAS served resources… • The user makes a request to the CAS server • CAS server verifies that the user has the appropriate privileges by checking its DB • CAS server issues the user a GSI restricted proxy credential • Credential contains policy giving user rights to perform the requested actions

43. Community Authorization Service (CAS) • How it works… • 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

44. 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 GSI: Credential Management

45. MyProxy • An Online Credential Repository • Basic idea • Issues short term credentials upon request, on behalf of a user request. Thus avoiding multiple user interactions

46. Public Key Infrastructure • Public Key Cryptography • Digital Signatures

47. 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.

48. 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

49. 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

50. 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 myproxy-get-delegation program to contact the server and request a delegation of the user’s credentials