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
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
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, 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
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
User E
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
• 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
GridCA Root
Certificate
GridCA
Intermediate
Certificate
User Certificate
Proxy1
Proxy 2
Proxy 3
• 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
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:
• 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
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/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
SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
December 8 & 9, 2005, Austin, TX
Testing Globus Authentication
Configuration using OpenSSL
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 -ssl3 -no_tls1 -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
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
SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
December 8 & 9, 2005, Austin, TX
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
SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
December 8 & 9, 2005, Austin, TX
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
Globus
Gatekeeper
User
Web
Login
SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
Cluster
Job
Queue
December 8 & 9, 2005, Austin, TX
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
SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
December 8 & 9, 2005, Austin, TX
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
SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
December 8 & 9, 2005, Austin, TX
Shibboleth
• Project of Internet2 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
5
6
8
2
Shibboleth
Protected
Web Site
(TARGET)
4
7
Local AuthN
– Use local campus
authentication for
intercampus applications
Directory
– Support directory based
authorization via AA (6-8)
• eduPerson schema
WAYF
9
SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
Schematic of
Shibboleth
Process Flow
December 8 & 9, 2005, Austin, TX
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
SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
December 8 & 9, 2005, Austin, TX
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
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 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
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?
– 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
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 n2 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
A1
Campus B
Mid-B
User
B1
User
A2
User
B1
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 n2 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
SURAgrid
Bridge CA
F’s PKI
Campus F
Grid
E’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 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
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
HEBCA
F’s PKI
Campus F
Grid
E’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
• SAFE – Pharmaceutical
HEBCA
• HEBCA – Higher Ed
• Commercial - aerospace Commercial
and defense
Others
• Grid extensible across PKI
bridges?
SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
December 8 & 9, 2005, Austin, TX
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
SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
December 8 & 9, 2005, Austin, TX
SURAgrid AuthZ Development
• Grid-mapfile automation
– Sites that use a recent version of Globus will
use a LDAP callout that replaces the gridmapfile
– 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 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
SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
December 8 & 9, 2005, Austin, TX
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
SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
December 8 & 9, 2005, Austin, TX
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
SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
December 8 & 9, 2005, Austin, TX
Campus Grid AuthN 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., 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/hepkitag/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
– 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
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
User
USHER CA
HEBCA
Bridge
User
Campus
n
Campus
CA
Campus
CA
User
Campus
CA
User
User
SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
Campus
CA
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
HEBCA
Commercial
Others
Campus CA
Campus
Users
USHER CA
Campus
Users
Campus CA
Campus CA
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.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
SURA Cyberinfrastructure Workshop Series: Grid Technology: The Rough Guide
December 8 & 9, 2005, Austin, TX