Upload
olive
View
31
Download
1
Embed Size (px)
DESCRIPTION
Authentication, Authorization, & Identity Issues in Grids. SURA Grid Workshop Austin, TX December 8, 2005 Jim Jokl University of Virginia. Agenda. Quick Refresher on PKI Globus & GSI MyProxy & Grid portal integration Overviews Shibboleth and GridShib - PowerPoint PPT Presentation
Citation preview
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
Authentication, Authorization, & Identity Issues in Grids
SURA Grid WorkshopAustin, TX
December 8, 2005
Jim JoklUniversity of Virginia
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
Public Key Cryptography– Data encrypted using the public key
can only be decrypted by the person with the private key
1. Bob obtains a copy of Alice’s public key
2. Bob encrypts the data using the public key and sends it to Alice
Example: Bob sends secret data to Alice
1. Alice receives the data
2. Alice decrypts the data using the private key that only she possesses
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
Public Key Cryptography
– 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.
PlainText
EncryptedText
one key
the other key
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
Root Certificate
Intermediate Certificate
Intermediate Certificate
User A Cert
User C Cert
User B Cert
User D Cert
User E Cert
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
PKI Mutual Authentication• Client Authentication
1. Client connects to server and sends user’s certificate2. Server uses its root key store to validate the user’s
certificate3. 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 Authentication1. Server replies sending its digital certificate to the client2. Client validates the server’s certificate using its trusted root
store3. 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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
Globus Proxy Certificates• 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 Root Certificate
GridCA Intermediate
Certificate
User Certificate
Proxy1
Proxy 2
Proxy 3
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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 protected]/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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
Cluster Job
Queues
User’s Computer
SSL withPKI Authentication
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
Grid Portal Server
User Web Login
Globus Gatekeeper
Cluster Job
Queue
Retriev
e Prox
y
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
User’s Shibboleth
ORIGIN Site
Shibboleth Protected Web Site (TARGET)
WAYF
Local AuthN
Directory
1
23
4
56
7
8
9
Schematic of Shibboleth
Process Flow
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
Some VOMRS Data Elements• Roles
– Visitor, Candidate, Applicant, Member• Status
– New, Approved, Denied, Suspended• Authorization Status
– New, Approved, Denied• Rights
– Full, none
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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 n2 problemI: UVAS: User-1
I: UABS: UVA
I: UABS: UAB
I: UABS: User-2
I: UVAS: UAB
I: UVAS: UVA
Cross Certs
I: UVAS: User-1
I: UABS: UAB
I: UVAS: UVA
I: UABS: User-2
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
Campus A
Mid-A
User A1
User A2
Campus B Campus n
Mid-B
User B1
User B1
Bridge CA
Cross-certificate pairs
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
SURAgrid Authentication Schematic
Campus E Grid
A’s PKI
SURAgrid Bridge CA
Campus B Grid
Campus C Grid
Campus D Grid
Campus A Grid
Campus F Grid
B’s PKI C’s PKI
Cross-cert pairsD’s PKI
E’s PKI
F’s PKI
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
Model SURAgrid Authentication
Campus E Grid
A’s PKI
HEBCA
Campus B Grid
Campus C Grid
Campus D Grid
Campus A Grid
Campus F Grid
B’s PKI C’s PKI
Cross-cert pairsD’s PKI
E’s PKI
F’s PKI
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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?
FBCA
HEBCASAFE
Commercial
Others
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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?
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
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
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
Inter-organizational TrustUSHER CA
Campus CA
Campus CA
Campus CA
Campus CA
Campus CA
Campus A
Mid-A
User
User
Campus B Campus n
Mid-B
User
User
HEBCABridge
Cross-certificate pairs
User
User
User
User
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
A Higher-level View of Inter-organizational Trust
FBCA
HEBCASAFE
Commercial
Others
Campus CA
Campus CA
Campus CA
Educause Verisign CA
USHER CA
Campus CA
Campus CA
Campus CA
Campus Users
Campus Users
Campus Users
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
• Thank You
• Questions, Discussion?
December 8 & 9, 2005, Austin, TXSURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
Some References• PKI-Lite middleware.internet2.edu/hepki-
tag• HEPKI Model Certification Policy• Software CA packages• HEBCA – www.educause.edu/hebca• USHER – www.usherca.org (soon)• VOMS• GridShib - gridshib.globus.org• MyProxy - myproxy.ncsa.uiuc.edu