The Design and Implementation of an OpenID-Enabled PKI

Kevin BauerUniversity of Colorado

Supervisor: Dhiva Muruganantham

2

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?

3

Solution: OpenID

For example: http://ksbauer.myopenid.com

4

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

5

How Does OpenID Work?

Website(relying party or RP)

End User

3. PerformURL discovery

Identity Provider (IdP)

4. ReturnIdP endpoint 5. Requestlogin

7. User logs in8. Returnauth. result

RP IdP User

1. RP asks the user to login Relying party provides an interface to request user’s OpenID URI2. User submits OpenID URL

http://natron.es.net/openid/kevinbauer3

6. Redirectuser to IdP

9. Grant user access?

6

OpenID IdP Discovery

• Which identity provider is responsible for authenticating this user?

http://natron.es.net/openid/kevinbauer3HTTP HEAD:

200 OKDate: Tue, 11 Aug 2009 17:55:47 GMTServer: Apache/2.2.11 (Fedora) DAV/2 mod_ssl/2.2.11Content-Type: text/plain

…Client-Date: Tue, 11 Aug 2009 17:55:47 GMTClient-Peer: 198.128.5.22:443Client-Response-Num: 1X-XRDS-Location: https://natron.es.net/claimed_xrds.jsp? opEndpoint=https://natron.es.net/provider

Retrieve HTTP response headers

Identity provider endpoint URL is discovered

7

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

8

OpenID User Authentication (2)• User approves the authentication request

• Authentication result is shared with the relying party

The user explicitly authorizes the release of the authentication result

9

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

10

Our Project: Develop OpenID Infrastructure for ESnet

Three main deliverables for our project:

1. OpenID identity provider2. OpenID-enabled certificate authority3. OpenID-enabled collaboration tool (TWiki)

11

ESnet OpenID Provider

Two authentication methods: username/passwords, client certificates

Persistent Account Storage:- LDAP to store authentication credentials- MySQL database to store user attributes

Automatic Registration:Automatic enrollment for token holders; All“international grid trust federation” certs. trusted

Registration Validation:Send confirmation e-mail to verifythe account creation (for password-based accounts)

12

Demo: OpenID Identity Provider

13

OpenID-Enabled Certificate Authority• Goal: Enable users to request short-term certificates using

their OpenID automatically

A relying party

User enters their OpenID

Or logs-in directlywith their IdP

IdP whitelisting

14

Demo: Certificate Request with OpenID

15

OpenID Collaboration Site• Goal: Use OpenID to login to an ESnet TWiki• TWiki is an example of another OpenID relying party

• Obtains user information from the attribute exchange

OpenID authentication

http://natron.es.net/openid/kevinbauer3

16

Demo: OpenID for Collaboration: Twiki

17

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…

18

Open Problems with OpenID: Phishing

• What is phishing?

• 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

An attempt to steal usernames/passwords by impersonating a legitimate (high value) website

Example:

19

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)

20

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, e-

mail, 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

21

One-time Use Identifiers Mitigates Tracking

https://natron.es.net/provider

Login to RP with the IdP endpoint, not OpenID

This allows the user to login directly with their IdP

Authenticate with the IdP as normal and ask for one-time use identifier

IdP returns a randomly generated and authenticated OpenID to the RP

https://natron.es.net/openid/1exrt9ezhp9ug

https://natron.es.net/openid/36lse1cyoz4u Login again and geta new random ID

22

Demo: One-time Use Identifiers

23

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.)

24

Future Work

• Currently finishing a blog site to provide up-to-date 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

25

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