Authentication Authorization Identity Issues in Grids SURA

Authentication, Authorization, & Identity Issues in Grids SURA Grid Workshop Austin, TX December 8, 2005 Jim Jokl University of Virginia SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

Agenda • • Quick Refresher on PKI Globus & GSI My. Proxy & Grid portal integration Overviews – Shibboleth and Grid. Shib – Virtual Organizations (VO), VOMS, VOX, VOMRS • Example: SURAgrid approach – Cross-certification and PKI Bridges – National PKI context – Directory integration (VO approach) • Campus infrastructure integration SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

Two Types of Cryptography • Symmetric key cryptography – A pre-shared secret is used to encrypt the data – Some examples: DES, 3 -DES, RC 4, 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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

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 1. Bob obtains a copy of Alice’s public key 2. Bob encrypts the data using the public key and sends it to Alice 1. Alice receives the data 2. Alice decrypts the data using the private key that only she possesses SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

Public Key Cryptography one key Plain Text the other key Encrypted Text – 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. SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

Certification Authorities and Trust Root Certificate Intermediate Certificate User A Cert User C Cert Intermediate Certificate User B Cert User D Cert • 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 User E Cert • The “I” in PKI SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

PKI Mutual Authentication • Client Authentication 1. Client connects to server and sends user’s certificate 2. Server uses its root key store to validate the user’s certificate 3. 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 1. Server replies sending its digital certificate to the client 2. Client validates the server’s certificate using its trusted root store 3. 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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

Globus Proxy Certificates Grid. CA Root Certificate Grid. CA Intermediate Certificate User Certificate Proxy 1 Proxy 2 • 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 Proxy 3 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

Globus Toolkit Authentication and Authorization Configuration • Basic PKI authentication configuration – /etc/grid-security/certificates – Populate with trusted CA certificates and policy files – Example: • 860 e 3429. 0 -> UVa-root-skp. crt • 860 e 3429. signing_policy • UVa-root-skp. crt – Open. SSL can generate the certificate hashes • openssl x 509 -hash -in UVa-root-skp. crt –noout SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

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/email. Address=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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

Testing Globus Authentication Configuration using Open. SSL User’s Computer SSL with PKI Authentication Globus Gatekeeper Computer Cluster Job Queues • Testing the gatekeeper PKI configuration • Remember: Globus uses SSL with PKI authentication • openssl s_client -ssl 3 -no_tls 1 -connect gate. target. edu: 2119 -cert. globus/usercert. pem -key. globus/userkey. pem -CApath /etc/grid-security/certificates SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

My. Proxy 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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

Some Basic My. Proxy Protocol Functions • PUT – place a credential on the My. Proxy 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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

My. Proxy in a Grid Portal Environment • User initializes credentials in My. Proxy Server • User logs into portal • Portal retrieves proxy credentials • User interacts with portal • Jobs are submitted via gatekeeper e v rie y ox Pr et R My. Proxy Server Grid Portal Server Globus Gatekeeper User Web Login SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Cluster Job Queue December 8 & 9, 2005, Austin, TX

My. Proxy Basic Authorization • Internal and configurations options for: – Who can store credentials on server – Ensures that only the owner can delete, overwrite, 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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

My. Proxy 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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

Shibboleth • Project of Internet 2 and NSF Middeware Initiative User – Focus: intercampus authentication and authorization – Federated identity 1 3 • Fundamental design goals User’s Shibboleth ORIGIN Site – Privacy protection – Strong technology • PKI cryptography • Signed SAML assertions WAYF 5 6 8 9 2 Shibboleth Protected Web Site (TARGET) 4 – Use local campus authentication 7 for intercampus applications Local Auth. N – Support directory based Directory authorization via AA (6 -8) Schematic of Shibboleth Process Flow • edu. Person schema SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

Shibboleth and Grid. Shib • 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 edu. Person SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

Shibboleth and Grid. Shib • Grid. Shib Globus plugin (GT 4) – Makes authorization decisions based on data from a Shibboleth AA • Grid. 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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

Virtual Organizations (VO) • Grids are frequently built to support interinstitutional 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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

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 e. Xtended – 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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

Some VOMRS Data Elements • Roles – Visitor, Candidate, Applicant, Member • Status – New, Approved, Denied, Suspended • Authorization Status – New, Approved, Denied • Rights – Full, none SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

Example: SURAgrid Approach for 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 interinstitutional authentication efforts SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

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? – Open. SSL 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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

Background: Cross-certification • 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 n 2 problem I: UAB S: UAB I: UVA S: UVA I: UAB S: User-2 I: UVA S: User-1 I: UAB S: UAB I: UAB S: UVA I: UVA S: User-1 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide I: UVA S: UVA Cross Certs I: UVA S: UAB I: UAB S: User-2 December 8 & 9, 2005, Austin, TX

Background: Bridged PKI Bridge CA Cross-certificate pairs Campus A Mid-A User A 1 Campus B Mid-B User B 1 User A 2 User B 1 Campus n • Used to enable trust between multiple hierarchical CAs • Generally more infrastructure than just the cross-certificate pairs • Typically involves strong policy & practices • Solves the n 2 problem • For SURAgrid we preload cross-certs SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

SURAgrid Authentication Schematic Campus F Grid E’s PKI SURAgrid Bridge CA F’s PKI Campus E Grid Cross-cert pairs D’s PKI A’s PKI Campus A Grid B’s PKI Campus B Grid C’s PKI Campus D Grid Campus C Grid SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

SURAgrid Authentication Status • SURAgrid Bridge CA – Off-line system – Used Linux and Open. SSL 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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

Model SURAgrid Authentication Campus F Grid E’s PKI HEBCA F’s PKI Campus E Grid Cross-cert pairs D’s PKI A’s PKI Campus A Grid B’s PKI Campus B Grid C’s PKI Campus D Grid Campus C Grid SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

Bridge to Bridge Context • A federal view on how the FBCA inter-bridge environment is likely to develop • FBCA – Federal Bridge SAFE HEBCA • SAFE – Pharmaceutical • HEBCA – Higher Ed • Commercial - aerospace and Commercial defense Others • Grid extensible across PKI bridges? SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

SURAgrid Auth. N/Auth. Z Status • Bridge CA and cross-certification process – Forms the basic Auth. N 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) Auth. Z process – Sites add certificate Subject DNs from remote sites to their grid-mapfile based on email from SURAgrid sites SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

SURAgrid Auth. Z 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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

SURAgrid Auth. Z Development • LDAP Auth. Z 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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

SURAgrid Auth. Z 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 Auth. Z/Auth. N interface SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

Likely SURAgrid Auth. Z 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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

Campus Grid Auth. N Decisions General 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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

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? SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

Fundamental Campus PKI Decision: Build or Buy • Building your own PKI – Certification Authority (CA) • Developing or installing CA software (e. g. , simple. CA, 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. internet 2. edu/hepki-tag/opensrc. html SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

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 Lion. Share 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 SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

Inter-organizational Trust Cross-certificate pairs Campus A Mid-A User Campus B Mid-B User USHER CA HEBCA Bridge User Campus n Campus CA User SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide Campus CA User December 8 & 9, 2005, Austin, TX

A Higher-level View of Inter-organizational Trust FBCA Campus CA Educause Verisign CA Campus Users Campus CA SAFE Commercial Others Campus CA Campus Users USHER CA HEBCA Campus Users Campus CA SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

• Thank You • Questions, Discussion? SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX

Some References • • PKI-Lite middleware. internet 2. edu/hepki-tag HEPKI Model Certification Policy Software CA packages HEBCA – www. educause. edu/hebca USHER – www. usherca. org (soon) VOMS Grid. Shib - gridshib. globus. org My. Proxy - myproxy. ncsa. uiuc. edu SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide December 8 & 9, 2005, Austin, TX