The Design and Implementation
of an OpenID-Enabled PKI
Kevin Bauer
University of Colorado
Supervisor: Dhiva Muruganantham
The Login Explosion Problem
• Everyone uses a variety of web services
– E-mail, social networking sites, blogging sites, online collaboration tools, etc.
• But each site has a unique way for us to login
• Wouldn’t it be great to have just one set of credentials?
1
Solution: OpenID
For example: http://ksbauer.myopenid.com
2
What is OpenID?
• OpenID is an authentication protocol
– It provides a way for a user to prove their identity
• OpenID’s primary design considerations:
– Simplify your online experience
• Eliminates the need for multiple user names and passwords
• Single Sign-On: Authenticate once, log-in many times
– Decentralized
• No central authorities, users are free to choose their identity
providers
– Third-party websites never see authentication credentials
• Your user names and passwords are safer
– Built on existing web technologies
• Leverages the ubiquity of HTTP(S), URI, XML, SSL, Diffie-Hellman
• No specialized technologies are necessary
3
How Does OpenID Work?
1. RP asks the user to login
Relying party provides an interface
to request user’s OpenID URI
2. User submits OpenID URL
3. Perform
URL discovery
RP
4. Return
IdP endpoint
5. Request
login
8. Return
auth. result
http://natron.es.net/openid/kevinbauer3
User
IdP
6. Redirect
user to IdP
7. User logs in
9. Grant user access?
Website
(relying party or RP)
Identity Provider
(IdP)
End User
4
OpenID IdP Discovery
• Which identity provider is responsible for
authenticating this user?
HTTP HEAD: http://natron.es.net/openid/kevinbauer3
Retrieve HTTP response headers
200 OK
Date: Tue, 11 Aug 2009 17:55:47 GMT
Server: Apache/2.2.11 (Fedora) DAV/2 mod_ssl/2.2.11
Content-Type: text/plain
…
Client-Date: Tue, 11 Aug 2009 17:55:47 GMT
Client-Peer: 198.128.5.22:443
Client-Response-Num: 1
X-XRDS-Location: https://natron.es.net/claimed_xrds.jsp?
opEndpoint=https://natron.es.net/provider
Identity provider endpoint URL is discovered
5
OpenID User Authentication
• Redirect user to the discovered IdP endpoint
• IdP authenticates the user
User should manually verify IdP URL
when authenticating with a password
(to mitigate phishing attacks)
The referring site is displayed
The user provides their
authentication credentials
to the IdP
6
OpenID User Authentication (2)
• User approves the authentication request
The user explicitly authorizes the
release of the authentication result
• Authentication result is shared with the relying party
7
OpenID and User Information
• Beyond authentication, OpenID provides a
structured way of sharing information about
you
• Simple Registration Protocol
– Lightweight profile exchange
• Full name, nickname, e-mail, date of birth, gender,
postcode, country, language, and time zone
• Attribute Exchange Protocol
– More flexible information exchange
– Allows RP to request any information about users 8
Our Project:
Develop OpenID Infrastructure for ESnet
Three main deliverables for our project:
1. OpenID identity provider
2. OpenID-enabled certificate authority
3. OpenID-enabled collaboration tool (TWiki)
9
ESnet OpenID Provider
Two authentication methods:
username/passwords, client certificates
Persistent Account Storage:
- LDAP to store authentication credentials
- MySQL database to store user attributes
Registration Validation:
Send confirmation e-mail to verify
the account creation
(for password-based accounts)
Automatic Registration:
Automatic enrollment
for token holders; All
“international grid trust
federation” certs. trusted
10
Demo: OpenID Identity Provider
11
OpenID-Enabled Certificate Authority
• Goal: Enable users to request short-term certificates using
their OpenID automatically
A relying party
User enters their OpenID
IdP whitelisting
Or logs-in directly
with their IdP
12
Demo: Certificate Request with OpenID
13
OpenID Collaboration Site
• Goal: Use OpenID to login to an ESnet TWiki
• TWiki is an example of another OpenID relying party
OpenID
authentication
http://natron.es.net/openid/kevinbauer3
• Obtains user information from the attribute exchange
14
Demo: OpenID for Collaboration: Twiki
15
OpenID Summary
OpenID offers the following benefits:
• Single sign-on simplifies the online experience
• Third-parties don’t know our passwords
• Trust is decentralized
• Easy to deploy, built on proven web technologies
But, OpenID is not a perfect solution…
16
Open Problems with OpenID: Phishing
• What is phishing?
Example:
An attempt to steal
usernames/passwords by
impersonating a legitimate
(high value) website
• Particularly dangerous because OpenID credentials may grant
access to a large number of accounts
• Design effective UIs and educate users about risks
– Users should verify URLs and SSL certificates before releasing their
passwords
• Certificate-based authentication largely solves this
17
Open Problems with OpenID:
Hard to Leave the Web Browser
• Can we use OpenID with non-web applications?
– GridFTP, SSH, other legacy applications outside the browser
• Simple answer: Not really
– OpenID relies on browser interactions between the user
and their IdP
– Single sign-on functionality needs browser session state
• More complicated answer: Maybe
– Mimic the browser functionality within the legacy app
– Requires the legacy app to be modified (it’s now an RP)
18
Open Problems with OpenID:
User’s Privacy May Be at Risk
• OpenID exposes user information in two ways
– Problem: Attribute exchange releases user’s name, email, etc. to relying parties
• Solution: Give user’s ability to control what information is
released about them
– Problem: OpenID identifiers are persistent and global
identifiers  Behavior can be linked over time
• Solution: Give users dynamic identifiers, a different identity
each time they login to an RP
19
One-time Use Identifiers Mitigates Tracking
Login to RP with the IdP
endpoint, not OpenID
https://natron.es.net/provider
This allows the user to
login directly with their IdP
Authenticate with the IdP
as normal and ask for onetime use identifier
IdP returns a randomly
https://natron.es.net/openid/1exrt9ezhp9ug generated and authenticated
OpenID to the RP
https://natron.es.net/openid/36lse1cyoz4u
Login again and get
a new random ID
20
Demo: One-time Use Identifiers
21
OpenID/Shibboleth Comparison
• Both protocols offer
– Cross-domain authN
– Attribute exchange
– Single sign-on
• Key Differences
– Trust model
• OpenID assumes a completely open trust model
• Shibboleth is federated; trust only a limited set of IdPs
– Freedom to choose your IdP
• OpenID allows users to chose any IdP
• Shibboleth requires that authentication be handled by your
“home institution” (LBNL, ESnet, UC-Berkeley, etc.)
22
Future Work
• Currently finishing a blog site to provide up-todate information about our OpenID service
• Explore OpenID + OAuth as a way to enable
non-web OpenID authentication
• Explore how Shibboleth and OpenID can
interoperate
• Continue to improve the OpenID provider’s UI
23
Summary and Conclusion
• We developed OpenID infrastructure that
includes:
– An ESnet-operated OpenID identity provider
– An automated short-term certificate issuing
service that consumes OpenID
– A TWiki-based collaboration site that consumes
OpenID
• Thank you to Dhiva, Mike, and ESnet staff
24