-
Notifications
You must be signed in to change notification settings - Fork 1
/
index.html
290 lines (268 loc) · 11.9 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="chrome=1">
<title>webSSO.github.com by webSSO</title>
<link rel="stylesheet" href="stylesheets/styles.css">
<link rel="stylesheet" href="stylesheets/pygment_trac.css">
<script
src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>
<script src="javascripts/main.js"></script>
<!--[if lt IE 9]>
<script src="//html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
<meta name="viewport"
content="width=device-width, initial-scale=1, user-scalable=no">
</head>
<body>
<header>
<img src="images/webSSO.svg" />
</header>
<div id="banner">
<span id="logo"></span>
<div>
<a href="https://raw.github.com/webSSO/internetDraft/master/README"
class="button"><strong>Internet Draft</strong></a>
<a href="https://groups.google.com/forum/?fromgroups#!forum/websso"
class="button"><strong>Google Group</strong></a>
<a href="/files/webSSO_CIS.pdf"
class="button"><strong>Presentation</strong></a>
</div>
</div>
<!-- end banner -->
<div class="wrapper">
<nav>
<ul>
<li><a href="#why">WebSSO's Motivation</a></li>
<li><a href="#ux">User Experience</a></li>
<li><a href="#how">Under the Covers</a></li>
<li><a href="#identities">Globally Unique Identities</a></li>
<li><a href="#protocols">Crossing Enterprise Boundaries</a></li>
<li><a href="#delegation">Secure Credential Delegation</a></li>
<li><a href="#compare">Protocols Compared</a></li>
</ul>
</nav>
<section>
<p>WebSSO is a new cloud-centric, federated authentication system
developed to solve the problems of deploying authentication across
heterogeneous infrastructures. It is a thin policy layer on top of
widely deployed and trusted protocols such as HTTPS and TLS client
certificate authentication. It provides:</p>
<ul>
<li>Single sign-on across local, Internet and cloud
infrastructures</li>
<li>Globally unique identities via existing certificate
authorities</li>
<li>Decentralized authentication</li>
<li>Credential delegation</li>
<li>Depoyment on existing HTTPS stacks</li>
<li>Multi-protocol support (i.e. not restricted to HTTP)</li>
<li>Cryptographic trust validation of all parties</li>
</ul>
<h3 id="why">WebSSO's Motivation</h3>
<p>It is true, there are lots of authentication protocols available.
Kerberos, for instance, is a widely deployed, mature protocol for
local infrastructure. However, it has almost no Internet presence,
mostly because identity providers are not willing to expose their
Kerberos servers to the Internet. Kerberos also competes in the
encryption space with SSL/TLS, the hands down winner in the
web-enabled world. Lastly, Kerberos has difficulty scaling in large,
flat topologies.</p>
<p>Outside of the enterprise context, OpenID has a large presence on the
Internet. As one of the first attempts at creating a federated
identity system in the Internet, it has accomplished remarkable things.
However, OpenID doesn't do single sign-on. Nor does it validate all
parties in the authentication transaction, leading to <a
href="http://en.wikipedia.org/wiki/OpenID#Security">problems with
security/phishing</a>. When combined with OAuth, OpenID can perform
credential delegation. But implementing these protocols is quite
complex, leading to bugs that compromise security. OpenID is also
tightly tied with the web-based world and has gained no traction
outside this environment.</p>
<p>The true problem arises when the local infrastructure and Internet
worlds meet. If you want to use your enterprise identity on the
Internet or in a cloud service, you're pretty much out of luck. The
same is mostly true with using your Internet identity in the
enterprise. Thus, webSSO came about as we began to envision a world
where there was no division between local, Internet and cloud
infrastructures.</p>
<h3 id="ux">User Experience</h3>
<p>When a user first encounters a webSSO Protected Resource, he or she
will be prompted to log in. In this case, the user has not acquired
any identities and the Protected Resource has suggested that the user
can use Facebook or Yahoo! to log in.</p>
<img src="images/workflow1.png" />
<p>Since the user wants to use his own webSSO identity, he types in his
user ID and domain and clicks add. The client will look up this user's
webSSO server and attempt to login:</p>
<img src="images/workflow2.png" />
<p>Once the user has established his/her webSSO identity, it can be used
for subsequent logins without entering credentials again:</p>
<img src="images/workflow3.png" />
<p>WebSSO can also be used in conjunction with traditional X.509
certificates:</p>
<img src="images/workflow4.png" />
<p>When a Protected Resource desires to acquire data from another
Protected Resource, it can prompt the user to grant it access. This
is called delegation:</p>
<img src="images/workflow5.png" />
<h3 id="how">Under the Covers</h3>
<p>A typical authentication system looks something like this:</p>
<img src="images/typical.png" />
<p>SSL/TLS client certificate authentication provides a unique feature in
that the Authentication Service (which issues the certificate) and the
Protected Resource do not need to communicate. This permits the
Authentication Service to live behind a firewall. The downside is that
the process for obtaining a certificate has typically been manual and
error prone:</p>
<img src="images/tls.png" />
<p>WebSSO is a simple policy layer on top of SSL/TLS client certificate
authentication. When connecting to a SSL/TLS-encrypted resource, the
resource can ask you to authenticate by providing a certificate. In
a traditional TLS transaction, if you don't have a certificate the
operation simply fails. However, in the webSSO case, if you do not
have an appropriate certificate, you can simply use webSSO to obtain
one:</p>
<img src="images/overview.png" />
<p>The end result is that we get the benefit of TLS authentication
without the drawback of the manual process:</p>
<img src="images/webSSO.png" />
<h3 id="identities">Globally Unique Identities</h3>
<p>WebSSO can provide private trust relationships via manual certificate
exchange. But one of the more interesting features of WebSSO is its
ability to provide globally unique identities. This works by utilizing
the pre-existing system of public X.509 certificate authorities to
validate domain ownership. For instance, if you want to bring up a
secure website on example.com, you will need to obtain a certificate
from a trusted certificate authority. This authority will verify that
you are the proper owner of your domain and issue you a certificate
vouching for this.</p>
<img src="images/certificates.png"/>
<p>WebSSO is really no different. If you want to bring up an
Authentication Service, you obtain a certificate from an authority
proving your domain (example.com). This permits you to issue user
certificates for [email protected].</p>
<h3 id="protocols">Crossing Enterprise Boundaries</h3>
<p>In webSSO, authentication is provided at the SSL/TLS encryption
channel layer. This means that webSSO can be used wherever SSL/TLS
encryption is used to protect a connection. This feature is what
permits webSSO to work transparently across local, Internet and cloud
infrastructures. For instance, you can use the same identity to log in
to your local print and file shares, web sites such as Facebook and
Google, and privately contracted cloud services such as HR or
virtualization.</p>
<p>However, many organizations are unwilling (for good reason) to expose
their Authentication Service to the Internet. WebSSO was designed
precisely for this scenario. Since webSSO does not require any contact
between the Authentication Service and the Protected Resources to whom
authentication will be provided, you can safely host your webSSO server
behind the corporate firewall and still permit the use of corporate
identities in the public Internet.</p>
<h3 id="delegation">Secure Credential Delegation</h3>
<p>Sharing data between services has become a critical feature of today's
modern web services. Yet most attempts at authentication when sharing
data have been handled by proprietary mechanisms or, more recently,
the OAuth protocol. In both cases this has been restricted to HTTP-
only services. Existing forms of delegation have also created an
atmosphere where sharing is unbounded and requires the sharing of
passwords.</p>
<p>WebSSO aims to provide an authentication delegation system which:</p>
<ul>
<li>Works across any protocol</li>
<li>Permits cryptographic trust validation of every party involved</li>
<li>Enforces time limits on all delegation grants</li>
<li>Does not require the exchange of passwords</li>
</ul>
<img src="images/delegation.png"/>
<h3 id="compare">Protocols Compared</h3>
<table>
<tr>
<td></td>
<td>Traditional X.509</td>
<td>webSSO</td>
<td>Browserauth</td>
<td>BrowserID</td>
</tr>
<tr>
<td>Deployment</td>
<td>Configuration</td>
<td>Configuration</td>
<td>Custom code</td>
<td>Custom code</td>
</tr>
<tr>
<td>Federation</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Single Sign On</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>HTTP-only</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Globally Unique Users</td>
<td>No</td>
<td>Yes</td>
<td>No</td>
<td>Yes (via email)</td>
</tr>
<tr>
<td>Dynamic Trust Management</td>
<td>No</td>
<td>Yes</td>
<td>No</td>
<td>No</td>
</tr>
<tr>
<td>Private AS</td>
<td>Yes</td>
<td>Yes</td>
<td>No</td>
<td>No</td>
</tr>
<tr>
<td>Delegation</td>
<td>No</td>
<td>Yes</td>
<td>No</td>
<td>No</td>
</tr>
<tr>
<td>Browser Changes</td>
<td>No</td>
<td>Minor</td>
<td>Minor</td>
<td>Crypto</td>
</tr>
<tr>
<td>Server Changes</td>
<td>None</td>
<td>Optional extended validations</td>
<td>Application changes</td>
<td>Application changes</td>
</tr>
</table>
</section>
<footer>
<p>
<small>Hosted on GitHub Pages - Theme by
<a href="http://twitter.com/#!/michigangraham">mattgraham</a></small>
</p>
</footer>
</div>
<!--[if !IE]><script>fixScale(document);</script><!--<![endif]-->
</body>
</html>