The Design and Implementation of an OpenID-Enabled PKI

subduedjourneyΛογισμικό & κατασκευή λογ/κού

28 Οκτ 2013 (πριν από 3 χρόνια και 7 μήνες)

102 εμφανίσεις

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

1



Wouldn’t it be great to have just
one

set of credentials?

Solution: OpenID

2

For example:

http://
ksbauer.myopenid.com

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


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

a
uth. result

RP

IdP

User

1.

RP asks the user to login

Relying party provides an interface

t
o request user’s OpenID URI

2
.

User submits OpenID URL

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

6
.

Redirect

user to
IdP


9
.

Grant user access?

OpenID
IdP

Discovery


Which identity provider is responsible for
authenticating this user?

5

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

HTTP HEAD:

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

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

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 e
-
mail 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 OpenID

Or 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

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

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

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