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 – , social networking sites, blogging sites, online collaboration tools, etc. But each site has a unique way for us to login 1 Wouldn’t it be great to have just one set of credentials?

Solution: OpenID 2 For example:

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? 4 Website (relying party or RP) End User 3. Perform URL discovery Identity Provider (IdP) 4. Return IdP endpoint 5. Request login 7. User logs in 8. Return auth. result RP IdP User 1. RP asks the user to login Relying party provides an interface to request user’s OpenID URI 2. User submits OpenID URL 6. Redirect user to IdP 9. Grant user access?

OpenID IdP Discovery Which identity provider is responsible for authenticating this user? 5 HTTP HEAD: 200 OK Date: Tue, 11 Aug :55:47 GMT Server: Apache/ (Fedora) DAV/2 mod_ssl/ Content-Type: text/plain … Client-Date: Tue, 11 Aug :55:47 GMT Client-Peer: :443 Client-Response-Num: 1 X-XRDS-Location: opEndpoint= Retrieve HTTP response headers Identity provider endpoint URL is discovered

OpenID User Authentication Redirect user to the discovered IdP endpoint IdP authenticates the user 6 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

OpenID User Authentication (2) User approves the authentication request Authentication result is shared with the relying party 7 The user explicitly authorizes the release of the authentication result

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, , 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 10 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 to verify the account creation (for password-based accounts)

Demo: OpenID Identity Provider 11

OpenID-Enabled Certificate Authority Goal: Enable users to request short-term certificates using their OpenID automatically 12 A relying party User enters their OpenIDOr logs-in directly with their IdP IdP whitelisting

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 Obtains user information from the attribute exchange 14 OpenID authentication

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 16 But, OpenID is not a perfect solution…

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 17 An attempt to steal usernames/passwords by impersonating a legitimate (high value) website Example:

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

One-time Use Identifiers Mitigates Tracking 20 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 Login again and get a new random ID

Demo: One-time Use Identifiers 21

OpenID/Shibboleth Comparison 22 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.)

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