Transcript The Raven Web Authentication Service

The Raven Web Authentication
Service
Jon Warbrick
University of Cambridge Computing Service
[email protected]
What is it?
●
Some software
–
●
A centrally-managed authentication server
–
●
the real 'Raven'
What does it give you?
–
●
grandly entitled 'The University of Cambridge
Web Authentication System' (ucam-webauth)
an authenticated identity for a web browser user
Why authentication, why ANOTHER system?
Why do we need authentication?
●
Much of the time we don't and shouldn't
–
●
●
the web succeeded because it was free
But sometimes we do
–
to control access
–
so we know who we are talking to
–
to provide customisation, user privacy, etc.
AAA - Access control, Authentication,
Authorization
IP address-based and
DNS name-based
●
Only does access control
●
Too lax
●
–
just who has access to a .cam.ac.uk host?
–
open proxies
Too restrictive
–
●
working at home, in another department, etc.
But in practice it's all we've got...
–
... at the moment
Public/private keys and PKI
●
Client keys/certificates supported in https:
●
But https: can be overkill
●
Transporting keys is tricky:
–
Please memorise your new 1024-bit private key:
–
MIICXQIBAAKBgQDf+LNk7CvEBGM5EgJBhhN7sh0yDZdOqVBlmfL5xHJvn3feRGSy
MLvIWiBxZNkYUUOKDPdr/kj3i+FQ+W4udpUscIj6g6OZHhaH1JgdFrfUHu1Jgb8c
uTWzTM2yaWj0zcPS8ca4sHGYVzXrUQR7HHMgJjcaLd9QL0rhsnXHcZF9FwIDAQAB
AoGAcI7kWUv3ksNBumS6jYN8NyYEVitOZ1Hf/a+o1K1NdZuG+kUU9hhXxxDETTiJ
ghcVAkQR9EwPD5lU2wT/wooF3SZ8fvCQz8aynUepdtfvDxh5576sAFNIifFenT6J
O8n7k7E+k/nCczioniPWnxuI4XA0oJs7j8QJnaarHUGvvEECQQD9s+CSyWGkvTod
Hu/q6+vbDQflvxL0sVWGr+6xkI3XdBj/oKIOapgHjZx/Xl9eJB6lpnYlH5LKW2EW
EPWIwOolAkEA4f/m6bQY0o9ut5uDGDnJ/Ivf6xDFzySw5TPZgPN+wKdrf3gQmUWk
ImwAX7ImDHhxK9O6W7p+SJH3/yGyKOJ/iwJBAJfNf7yU/vYBu7oc/tWEYNXrUCRq
Vj9PtKsorhxVMGoQr7yVMyKJKXqrg066+zlrR2M63UqNP9oRH2CCuUgglnkCQEc7
ENy4FtrGum7EZR1NmYwvyfOc5bvUJK0ZGoS6Okkee5NBlHm6qXDv+W4wCC4GCCV4
JlSjAwp8d13CkRSxzuECQQDsuG/4/a2w3rBfxcE43wbSTC6PPWJa7WUcx8jQy6s8
lHl+ticOSiYv4YqO0djPgBN8EzV7Axy15VFUO7RLutKs
So that leaves us with passwords
●
●
●
Passwords are well known but little
understood
Users accumulate user-name/password pairs
–
which they can't remember
–
so they use the same ones in lots of different
places
Administrators have to create, issue, re-issue
and revoke accounts
Passwords (cont)
●
HTTP 'Basic authentication'
●
Form-based authentication
●
–
send unencrypted passwords in clear
–
this can be resolved with https:
–
but we've already said https: can be overkill
HTTP 'Digest authentication' resolves many
problems, but has others of it's own
A central password server?
●
●
●
●
Web server asks user for username/password
Web server sends user-name/password for
validation to central server
If validation succeeds, the web server gives
the user the resource they want
... and can now impersonate the user on
every other web server in the system
... and so to Raven
●
●
It's a ...
–
... centrally managed ...
–
... password based ...
–
... authentication service for web applications ...
–
... that doesn't give away users' passwords
Relies on features of HTTP and common
browsers, hence limited to web contexts
How does it work?
Start with a web browser
Browser
[br]
User requests a URL
br  ws : URL
Web Server
[ws]
1
Browser
[br]
Web server redirects to auth
service
ws  br : redirect(authURL+request(URL))
Web Server
[ws]
2 1
Browser
[br]
Browser contacts auth service
br  as : authURL+request(URL)
Auth Server
[as]
Web Server
[ws]
3
2 1
Browser
[br]
Auth service and user interact
Auth Server
[as]
Web Server
[ws]
5 4 3
2 1
Browser
[br]
Auth service redirects to
URL+response
as  br : set_cookie(id), redirect(URL+response(id))
Auth Server
[as]
Web Server
[ws]
6 5 4 3
*
2 1
Browser
[br]
Browser requests URL+response
br  ws : URL+response(id)
Auth Server
[as]
Web Server
[ws]
6 5 4 3
*
2 1 7
Browser
[br]
Web server redirects to original
URL
ws  br : set_cookie(id), redirect(URL)
Auth Server
[as]
Web Server
[ws]
6 5 4 3
*
2 1 7 8
Browser
[br]
*
Browser requests URL (again)
br  ws : URL, cookie(id)
Auth Server
[as]
Web Server
[ws]
6 5 4 3
*
2 1 7 8 9
Browser
[br]
*
and then...
●
●
●
Subsequent requests to WS authenticated by
the local cookie, until it expires
Subsequent visits to AS can be partially or
completely satisfied by the AS cookie until it
expires
The best way to logout is to quit the browser
So what does all this look like?
Request http://mnementh.csi.cam.ac.uk/raven-test/new-open/document1
Enter user-id and password and click 'Submit' to get:
Request http://mnementh.csi.cam.ac.uk/raven-test/new-open/documen
Request http://raven.cam.ac.uk/project/testfiles/document1.html
Enter user-id and password and click 'Submit' to get:
Timeout: return to our first document later:
Click 'Continue' to get:
Request http://mnementh.csi.cam.ac.uk/raven-test/private/document1.ht
Click 'Continue' and get:
Click 'Cancel' anywhere and get:
Choose 'override login options':
... and get
Account management:
Account management:
Account management:
What doesn't it do?
●
Authorization
●
People without CRSids
●
POST requests (properly, yet)
●
Central logout
●
Anything that isn't web-based
●
Security
How do you use it?
●
Protocol specification
http://raven.cam.ac.uk/project/waa2wls-protocol.txt
●
Pseudo-code Application Agent
http://raven.cam.ac.uk/project/algorithm.txt
●
... but that's the hard way
Apache
●
●
mod_ucam_webauth (for Apache 1.3 and 2)
LoadModule ucam_webauth_module \
modules/mod_ucam_webauth.so
AACookieKey afef845ce49666ab04b36976a
<Directory "/cam-only">
Order allow,deny
Allow from .cam.ac.uk
AuthType WebAuth
Require valid-user
Satisfy any
AADescription 'Cam-only area'
</DirectoryMatch>
Apache (cont)
●
●
●
Also supports
–
Require user jw35, rjd4
–
Require group cs-staff
–
Satisfy any
Sets REMOTE_USER environment variable
(just like basic auth) and others
Should be able to use group files, DBM files,
databases, ...
Perl CGI script
●
#!/usr/bin/perl -w
use Ucam::WebAuth::CGIAA;
my $aa = Ucam::WebAuth::CGIAA->new
(cookie_key=>'eb78ba43b0222f28498');
my ($complete, $headers)
= $aa->authenticate;
print $headers if $headers;
exit unless $complete;
my $userid = $aa->principal
if $aa->success;
... and more
●
A beta release of a PHP module
–
●
●
●
needs work – any volunteers?
A JAAS implementation for Java servlet
containers (e.g. Tomcat) by CARET
A Ruby implementation by Thomas Counsell
of Clare College
Anyone for IIS ?
The project plan
●
Now
–
●
●
Available on request for testing and pilot
deployments
Late June (perhaps July...)
–
Passwords available to everyone
–
Available to all cam.ac.uk web servers
1 September 2004
–
Supported service
Where do you go from here?
●
Pilots
●
Deployment from June
●
Consider expanding 'ucam-only’ access
●
http://www.cam.ac.uk/cs/raven/
●
[email protected]
If you have been, thanks for
listening
I expect you have some questions