Authentication, Authorization, & Identity Issues in Grids

1. Authentication, Authorization, & Identity Issues in Grids SURA Grid WorkshopAustin, TX December 8, 2005 Jim Jokl University of Virginia

2. Agenda • Quick Refresher on PKI • Globus & GSI • MyProxy & Grid portal integration • Overviews • Shibboleth and GridShib • Virtual Organizations (VO), VOMS, VOX, VOMRS • Example: SURAgrid approach • Cross-certification and PKI Bridges • National PKI context • Directory integration (VO approach) • Campus infrastructure integration

3. Two Types of Cryptography • Symmetric key cryptography • A pre-shared secret is used to encrypt the data • Some examples: DES, 3-DES, RC4, etc • Public key cryptography • A pair of mathematically related keys are generated • One of the keys, the Public Key, is freely distributed • The other key, the Private Key, is kept confidential • Given one of the keys, it is computationally very hard to compute the other

4. Public Key Cryptography • Data encrypted using the public key can only be decrypted by the person with the private key Example: Bob sends secret data to Alice • Bob obtains a copy of Alice’s public key • Bob encrypts the data using the public key and sends it to Alice • Alice receives the data • Alice decrypts the data using the private key that only she possesses

5. EncryptedText PlainText Public Key Cryptography one key • Likewise, data encrypted with the private key can be decrypted by anyone having a copy of the public key • Assuming that the private key is protected and held by an individual, this is the basis for a digital signature • If I encrypt data using my Private Key, anyone with my published Public Key can decrypt it. Since they used my Public Key to decrypt the data everyone knows that only I (with my Private Key) could have encrypted the data. the other key

6. Certification Authorities (CA) and Registration Authorities (RA) • Accept certificate requests from users (RA) • Validate the user’s identity (RA) • Generate and sign the user’s certificate attesting to the mapping of the identity to the public key (CA) • Revoke certificates if needed (RA/CA) • Operate under a set of policies and practices at a specific Level of Assurance (RA/CA) • Operate directories and other databases • The combination of the CA, RA, and associated directories forms the Public Key Infrastructure

7. A Digital Certificate is: • An object that binds a user’s identity to their public key • An object signed by a Certification Authority (CA) • An object containing some attributes about the person who owns the certificate • An object containing some information about the CA • Useful for relying party to understand campus identity policy • Often published in a campus directory if support for encryption is anticipated

8. Root Certificate Intermediate Certificate Intermediate Certificate User A Cert User B Cert User D Cert User E Cert User C Cert Certification Authorities and Trust • You determine if you trust a certificate by validating all of the certificates starting from the user’s cert up to a root that you trust • 100+ root certificates in my Microsoft store • The “I” in PKI

9. Digital Certificates and Security • Login id and password never flow over the network • Strong cryptography – what does flow over the network is very safe • Enables mutual authentication • Defeats a variety of man in the middle attacks • No (practical) brute-force attacks • Is often easier to use than login/password

10. Certificate Profiles • A description of the fields in a certificate • Recommended fields to use • Field values • Critical flags • Recommendations for PKI architects on the various trade-offs available as they select their certificate profile • Example Profile

11. Trust, Private Key Protection and Non-Repudiation • Digital signatures - based on the idea that only the user has access their private key • A user’s private key is generally protected by the workstation’s operating system • Typical protection is no better than for any password that the user lets the operating system store • Hardware tokens can be used for strong private key protection, mobility, and as a component in a non-repudiation strategy

12. Grid Security Infrastructure (GSI) • Basic Grid security needs • Strong authentication • Ability to encrypt data • Cross-organizational security infrastructure • Single sign-on • Solution • GSI is based on PKI and certificates are used for authentication • Uses mutual authentication and encryption when needed

13. Client Authentication Client connects to server and sends user’s certificate Server uses its root key store to validate the user’s certificate Server sends client some random data; client uses private key to encrypt data; server decrypts data validating that client has access to the private key Server Authentication Server replies sending its digital certificate to the client Client validates the server’s certificate using its trusted root store Client sends some random data to the server; server encrypts the data using its private key; client decrypts data validating that server has access to the private key Globus uses SSL/TLS to accomplish mutual authentication PKI Mutual Authentication

14. Globus Proxy Certificates GridCA Root Certificate • Proxy certificates are signed by the user’s end entity certificate • A new key pair is used • Short lived proxy credential • Usable as if it were a normal certificate within the globus infrastructure • Not a security risk for other campus uses of PKI • Basic Constraints field • grid-proxy-init GridCA Intermediate Certificate User Certificate Proxy1 Proxy 2 Proxy 3

15. Globus Toolkit Authentication and Authorization Configuration • Basic PKI authentication configuration • /etc/grid-security/certificates • Populate with trusted CA certificates and policy files • Example: • 860e3429.0 -> UVa-root-skp.crt • 860e3429.signing_policy • UVa-root-skp.crt • OpenSSL can generate the certificate hashes • openssl x509 -hash -in UVa-root-skp.crt –noout

16. Globus Toolkit Authentication and Authorization Configuration • Basic Globus authorization configuration • Simple file-based authorization is a basic GSI service • A mapping file is used to map Unix user names to certificate DNs • /etc/grid-security/grid-mapfile • "/C=US/O=University of Virginia/OU=UVA Standard PKI User/emailAddress=jaj@Virginia.EDU/CN=James A. Jokl 52" jaj • An LDAP call-out can be used instead of the simple Grid Mapfile • Newer versions of Globus add more authorization capability

17. Testing Globus Authentication Configuration using OpenSSL • Testing the gatekeeper PKI configuration • Remember: Globus uses SSL with PKI authentication • openssl s_client -ssl3 -no_tls1 -connect gate.target.edu:2119 \ -cert .globus/usercert.pem -key .globus/userkey.pem \ -CApath /etc/grid-security/certificates Globus Gatekeeper Computer User’s Computer SSL with PKI Authentication Cluster Job Queues

18. MyProxy Service • A service for retrieving proxy credentials • Commonly used in Grid Portal environments • A server service for storing and protecting user’s private keys • Keys are stored on a secure server • Keys are encrypted using the user’s password • User password is not stored on the server • Provides some protection against server compromise

19. Some Basic MyProxy Protocol Functions • PUT – place a credential on the MyProxy Server • Server generates a key pair and certificate request • Client, which has access to the user’s private key, signs the request creating a proxy certificate • GET – obtain a proxy certificate from the server • Client generates a key pair and certificate request • Server signs the request using the stored credential and sends the proxy credentials to the client • INFO – list the available credentials on the server • DESTROY – remove credentials on the server

20. MyProxy in a Grid Portal Environment • User initializes credentials in MyProxy Server • User logs into portal • Portal retrieves proxy credentials • User interacts with portal • Jobs are submitted via gatekeeper MyProxy Server Retrieve Proxy Grid Portal Server Globus Gatekeeper User Web Login Cluster Job Queue

21. MyProxy Basic Authorization • Internal and configurations options for: • Who can store credentials on server • Ensures that only the owner can delete, over-write, or change credential password • Which clients are able to obtain delegated credentials from the server • Protection for access to stored credentials • Lifetime for stored credentials

22. MyProxy Commands • myproxy-init: store proxy • myproxy-logon: retrieve proxy • myproxy-info: query stored credentials • myproxy-destroy: remove credential • myproxy-change-pass-phrase: change password encrypting private key • myproxy-store: store credential • myproxy-retrieve: retrieve credential

23. Shibboleth • Project of Internet2 and NSF Middeware Initiative • Focus: intercampus authentication and authorization • Federated identity • Fundamental design goals • Privacy protection • Strong technology • PKI cryptography • Signed SAML assertions • Use local campus authentication for intercampus applications • Support directory based authorization via AA (6-8) • eduPerson schema User 1 9 WAYF 3 2 User’s Shibboleth ORIGIN Site Shibboleth Protected Web Site (TARGET) 5 6 8 4 7 Local AuthN Schematic of Shibboleth Process Flow Directory

24. Shibboleth and GridShib • Focus: leverage the attribute work done in the Shibboleth community for Grid authorization in Globus • Shibboleth architecture includes the Attribute Authority (AA) and signed SAML assertions • Campus directories are being upgraded to support standardized schema such as eduPerson

25. Shibboleth and GridShib • GridShib Globus plugin (GT4) • Makes authorization decisions based on data from a Shibboleth AA • GridShib Shibboleth plugin • A name mapping plugin that maps certificate Subject DNs to local Principal Name • Uses an equivalent to a grid-mapfile • With the local principal name, attributes can be obtained from the Shibboleth AA • WAYF-type functionality is preconfigured • Beta Gridshib software is available now

26. Virtual Organizations (VO) • Grids are frequently built to support inter-institutional research projects • Not all users at each institution should be able to access Grid resources • Grid security is important and inter-institutional Grids still need strong user authentication • Like the researchers, resources are likely to be placed on the Grid by multiple organizations • A description of a Grid Virtual Organization • The collection of researchers and the resources that they are enabled to access can be thought of as a VO

27. Virtual Organization Tasks • Policies • Who can join the organization • How are resources allocated e.g., what agreements are needed between resource owners, resource consumers, and the VO • Implementation • Inter-institutional authentication • Authorization: all users in a Grid may not all have the same roles. Group-based authorization may be needed

28. Some Virtual Organization Tools • VOMS – VO Membership Service • Holds VO authorization information such as a user’s groups and certificate information • When a user submits a job, VOMS generates an extended proxy with a short lifetime • VOX – VOMS eXtended • Holds additional information on each VO member to support authorization decisions by resources • VOMRS – VOMS Registration Service • A central registry of users for the VO • Holds status, roles, certificate, rights, etc • Approval process for database entries

29. Some VOMRS Data Elements • Roles • Visitor, Candidate, Applicant, Member • Status • New, Approved, Denied, Suspended • Authorization Status • New, Approved, Denied • Rights • Full, none

30. Example: SURAgrid Approachfor Authentication and Authorization • Goal • Develop a scalable inter-campus solution • Preferred mechanisms • Leverage campus middleware activities • Researchers should not need to operate their own authentication systems • Use local campus credentials inter-institutionally • Rely on existing higher education inter-institutional authentication efforts

31. Inter-campus Globus Authentication • Leverage native campus PKI credentials on SURAgrid • Users do all of their work using local campus PKI credentials • How do we create the inter-campus trust fabric? • Standard inter-campus PKI trust mechanisms include • Operating a single Grid CA or trusting other campus CAs • Cross-certification and Bridge PKIs • How well does Globus operate in a bridged PKI? • OpenSSL PKI in Globus is not bridge-aware • Known to work from NMI Testbed project • Decision: work with intercampus trust based on a PKI Bridge • Leverage EDUCAUSE Higher Education Bridge CA (HEBCA) when ready

32. Background: Cross-certification I: UABS: UAB I: UVAS: UVA • Top section • Traditional hierarchical validation example • Bottom section • Validation using cross certification example • UVA signed a certificate request from the UAB CA • UAB signed a certificate request from the UVA CA • This pair of cross certificates enables each school to trust certs from the other using only their own root as a trust anchor • An n2 problem I: UABS: User-2 I: UVAS: User-1 I: UABS: UAB I: UVAS: UVA I: UABS: UVA Cross Certs I: UVAS: UAB I: UVAS: User-1 I: UABS: User-2

33. Bridge CA Cross-certificate pairs Campus A Campus B Campus n Mid-A Mid-B User A1 User B1 User B1 User A2 Background: Bridged PKI • Used to enable trust between multiple hierarchical CAs • Generally more infrastructure than just the cross-certificate pairs • Typically involves strong policy & practices • Solves the n2 problem • For SURAgrid we preload cross-certs

34. SURAgrid Authentication Schematic Campus F Grid F’s PKI SURAgrid Bridge CA Campus E Grid E’s PKI Cross-cert pairs D’s PKI Campus D Grid A’s PKI B’s PKI C’s PKI Campus A Grid Campus B Grid Campus C Grid

35. SURAgrid Authentication Status • SURAgrid Bridge CA • Off-line system • Used Linux and OpenSSL to build bridge • Cross-certifications with the bridge complete or in progress for 8 SURAgrid sites • Several more planned in near future • SURAgrid Bridge Web Site • Interesting PKI issues discussed in paper

36. Higher Education Bridge Certification Authority (HEBCA) • A project of EDUCAUSE • Implement a bridge for higher education based on the Federal PKI bridge model • Support both campus PKIs and sector hierarchical PKIs • Cross-certify with the Federal bridge (and others as appropriate) • Should form an excellent permanent trust fabric for a bridge-based Grid

37. Model SURAgrid Authentication Campus F Grid F’s PKI HEBCA Campus E Grid E’s PKI Cross-cert pairs D’s PKI Campus D Grid A’s PKI B’s PKI C’s PKI Campus A Grid Campus B Grid Campus C Grid

38. FBCA HEBCA SAFE Commercial Others Bridge to Bridge Context • A federal view on how the inter-bridge environment is likely to develop • FBCA – Federal Bridge • SAFE – Pharmaceutical • HEBCA – Higher Ed • Commercial - aerospace and defense • Grid extensible across PKI bridges?

39. SURAgrid AuthN/AuthZ Status • Bridge CA and cross-certification process • Forms the basic AuthN infrastructure • Builds a trust fabric that enables each site to trust the certificates issued by the other sites • The grid-mapfile • Controls the basic (binary) AuthZ process • Sites add certificate Subject DNs from remote sites to their grid-mapfile based on email from SURAgrid sites

40. SURAgrid AuthZ Development • Grid-mapfile automation • Sites that use a recent version of Globus will use a LDAP callout that replaces the grid-mapfile • For other sites there will be some software that provides and updates a grid-mapfile for their gatekeeper

41. SURAgrid AuthZ Development • LDAP AuthZ Directory • Web interface for site administrators to add and remove their SURAgrid users • Fully distributed model where each site maintains its central VO membership data • Directory holds and coordinates • Certificate Subject DN • Unix login name (prefixed by school initials) • Allocated Unix UID (high numbers) • Some Unix GIDs? (high numbers) • Perhaps SSH public key, perhaps gsissh only • Other (tbd) • Reliability • Replication to sites that want local copies

42. SURAgrid AuthZ Development • Sites contributing non-dedicated resources to SURAgrid greatly complicate the equation • We will provide a code template for editing grid-mapfiles to manage SURAgrid users • Publish our LDAP schema • Sites may query LDAP to implement their own SURAgrid AuthZ/AuthN interface

43. Likely SURAgrid AuthZ Directions • User directory or directory access • Group management • Person attributes • VO names • Store per-person, per-group allocations • Integrate with accounting • Local and remote stop-lists • Resource directory • Hold resource usage policies • Time of day, classifications, etc • Mapping users to resources within resource policy constraints • We’ll learn a lot more about what is actually required as we work with the early user groups

44. Campus Grid AuthN DecisionsGeneral Higher Education Context • How a campus chooses to implement their Grid authentication may be influenced by other higher education middleware efforts • Highlights from some other projects follow

45. PKI and USHER/HEBCA • (How) do all of these PKI pieces fit together? • USHER – US Higher Education Root CA • HEBCA – Higher Education Bridge CA • Campus Certification Authorities • EDUCAUSE contract for outsourced certificates • What should a campus be doing?

46. Fundamental Campus PKI Decision: Build or Buy • Building your own PKI • Certification Authority (CA) • Developing or installing CA software (e.g., simpleCA, etc) • Operating it in a secure environment • Implementing the Registration Authority (RA) function • Identity proofing of individuals • Handling requests for revocation, etc. • Some considerations • Early investment in staff time, likely lower per-certificate costs for large deployments in the long run • Users can have as many certificates as they need • Software examples at: http://middleware.internet2.edu/hepki-tag/opensrc.html

47. Fundamental Campus PKI Decision: Build or Buy • Buying PKI services • Certification Authority (CA) • Provided by the outsource company • Operated remotely in a secure environment • Implementing the Registration Authority (RA) function • Identity proofing of individuals • Handling requests for revocation, etc. • Some considerations • Quick start-up • Annual costs bounded by the number of certificates issued • Root certificate likely already trusted by your browsers and installed in your operating systems • May limit the number of certificates that each user can have • Example: http://www.educause.edu/imsp

48. Your Campus May Have non-Globus needs for a Central PKI • The build vs. buy decision may be influenced by your PKI applications • Electronic mail (S/MIME) • VPN (IPSec), Wireless (EAP-TLS), & SSH authentication • Web authentication • LionShare • Digital signatures on documents • Applications with large numbers of users may tip the balance towards the “build” option • Note that certificate management (getting the same certificate/key on multiple computers) can be hard for users

49. HEBCABridge Cross-certificate pairs Campus A Campus B Campus n Mid-A Mid-B User User User User Inter-organizational Trust USHER CA Campus CA Campus CA User Campus CA Campus CA Campus CA User User User

50. FBCA HEBCA SAFE Commercial Others A Higher-level View of Inter-organizational Trust Educause Verisign CA Campus CA Campus Users Campus CA Campus CA Campus Users Campus Users USHER CA Campus CA Campus CA Campus CA