Federated Identity,PKI, and the Grid
Nate KlingensteinInternet2
ndk@internet2.edu
国立情報学研究所
２００７年６月１日

Federated Identity
Review• Takes identity from one

authentication domain and “extends”
it to access another• Providers trust each other and rely on
information from each other toauthenticate users and grant access• How does this trust work?
2

Server Authentication inFederated Identity• IdP’s and SP’s need to be able toauthenticate each other• “Metadata” is used to describe
providers• Your provider’s metadata is for yourpartners to use• Metadata associates providers withendpoints and keys or certificates• Your provider presents its matching
key to prove its identity4Server Authentication inFederated Identity• Assertions, attributes, nameidentifiers, and more can beencrypted in SAML 2.0• All messages protected by TLS/SSL• Public Key Cryptography is critical for
federated identity5

Bearer Assertions• Federated Identity uses “bearer”
tokens in web browsers• If I have an assertion, it’s true about me• Makes delegation hard
• Means there’s no way for an SP toauthenticate a user directly• Broken in a good way for most apps
6

Bearer Token Security• Lots of safeguards are possible toprevent assertions from being stolenor misused• Very short time limits• Replay detection• Sometimes, IP address and other checks• Assertions are addressed to specific SP’s
7

Making bearer tokens
more secure• Some applications require greatersecurity• Need to authenticate the user themselves
to be really sure it’s the right person• PKI is good for this, but it is tough touse for many people• Just ask 秋山さん
8Three ways to combine
PKI and SAML
• Use PKI to authenticate to an IdP• Use PKI as confirmation whenpresenting a SAML assertion• Put a SAML assertion or its

information in an x.509 certificate

9PKI/SAMLCombination #1• Use PKI to authenticate to the IdP• Means SP’s don’t have to understand PKI,
your CA, or handle revocation• Still get extremely high-quality
authentication• Easy to do this today with Shibboleth• But what about security as theinformation goes to the SP?
10

PKI/SAML Combination#2• SAML assertions can be “holder ofkey” assertions too• When an assertion is presented, theclient must also have the rightprivate key• Only a few deployments do this• In narrow applications
11

PKI/SAML Combination#3• Place SAML information within an x.
509 certificate• Backward compatibility is the only reason• But that’s a pretty good reason• Do you try to populate lots of x.509
fields dynamically from SAML?

• Or just attach the SAML in an extension?
12

Advantages to Combining
PKI and Federated ID• Fresh information• Privacy preserved still• Revocation is no problem• PKI can do things federated identity
can’t do alone, like signing &encryption

13

Advantages to Combining
PKI and Federated ID• Much more flexibility in issuance ofuser certificates• User certificates help solve IdP
discovery• Still have to give keys to users
though...

14

Federated Identity & theGrid• Since researchers accessing the Grid
usually come from a campus• And the campus already manages
these users’ identities...

• Why not use federated identity tobring campus identities to the grid?

15

GridShib• Project out of NCSA since ’04• Attaches Shibboleth identities to GT4• Places a special DN in a MyProxycertificate• Queries for attributes using this DN

16

SLCS and EGEE,
ShibGrid, DyVOSE, etc.
• Lots of other projects to attach

Shibboleth to other Grid middleware• Uses a similar strategy as GridShib• Some integrate with VOMS and more
• SLCS from EGEE is thinking hard about this• All still use x.509 certificates• Backward compatibility is needed
17

OGSA
• New “express security” profile indrafts• Profiles the use of WS-Security forOGSA• WS-Addressing• WS-Security SAML profile• WS-Security Username Token Profile• WS-Security x.509 Profile
18