Authentication, Authorization, & Identity Issues in Grids

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

http://860e3429.signing_policy.txt/


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


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


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


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


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


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


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


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


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


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


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


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


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


Some VOMRS Data Elements• Roles

– Visitor, Candidate, Applicant, Member• Status

– New, Approved, Denied, Suspended• Authorization Status

– New, Approved, Denied• Rights

– Full, none


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


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

http://www.educause.edu/HEBCA/623


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


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


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


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

https://www.pki.virginia.edu/nmi-bridge

http://www1.sura.org/3000/SURAgrid_sharing.html


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


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


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


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


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


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


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


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


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


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?


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

http://middleware.internet2.edu/hepki-tag/opensrc.html



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

http://www.educause.edu/imsp


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


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


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


• Thank You

• Questions, Discussion?


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

http://middleware.internet2.edu/hepki-tag/#PKI_Lite

http://middleware.internet2.edu/certpolicies/


http://www.educause.edu/hebca

http://www.educause.edu/hebca

http://www.usherca.org/

http://computing.fnal.gov/docs/products/vomrs/vomrs1_2/wwhelp/wwhimpl/js/html/wwhelp.htm

http://gridshib.globus.org/

http://myproxy.ncsa.uiuc.edu/

Authentication, Authorization, & Identity Issues in Grids

Documents

Transcript of Authentication, Authorization, & Identity Issues in Grids