1 / 45

The Raven Web Authentication Service

Jon Warbrick University of Cambridge Computing Service jon.warbrick@ucs.cam.ac.uk. The Raven Web Authentication Service. What is it?. Some software grandly entitled 'The University of Cambridge Web Authentication System' (ucam-webauth) A centrally-managed authentication server

virgili
Télécharger la présentation

The Raven Web Authentication Service

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Jon Warbrick University of Cambridge Computing Service jon.warbrick@ucs.cam.ac.uk The Raven Web Authentication Service

  2. What is it? • Some software • grandly entitled 'The University of Cambridge Web Authentication System' (ucam-webauth) • A centrally-managed authentication server • the real 'Raven' • What does it give you? • an authenticated identity for a web browser user • Why authentication, why ANOTHER system?

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

  4. IP address-based andDNS 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

  5. 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+LNk7CvEBGM5EgJBhhN7sh0yDZdOqVBlmfL5xHJvn3feRGSyMLvIWiBxZNkYUUOKDPdr/kj3i+FQ+W4udpUscIj6g6OZHhaH1JgdFrfUHu1Jgb8cuTWzTM2yaWj0zcPS8ca4sHGYVzXrUQR7HHMgJjcaLd9QL0rhsnXHcZF9FwIDAQABAoGAcI7kWUv3ksNBumS6jYN8NyYEVitOZ1Hf/a+o1K1NdZuG+kUU9hhXxxDETTiJghcVAkQR9EwPD5lU2wT/wooF3SZ8fvCQz8aynUepdtfvDxh5576sAFNIifFenT6JO8n7k7E+k/nCczioniPWnxuI4XA0oJs7j8QJnaarHUGvvEECQQD9s+CSyWGkvTodHu/q6+vbDQflvxL0sVWGr+6xkI3XdBj/oKIOapgHjZx/Xl9eJB6lpnYlH5LKW2EWEPWIwOolAkEA4f/m6bQY0o9ut5uDGDnJ/Ivf6xDFzySw5TPZgPN+wKdrf3gQmUWkImwAX7ImDHhxK9O6W7p+SJH3/yGyKOJ/iwJBAJfNf7yU/vYBu7oc/tWEYNXrUCRqVj9PtKsorhxVMGoQr7yVMyKJKXqrg066+zlrR2M63UqNP9oRH2CCuUgglnkCQEc7ENy4FtrGum7EZR1NmYwvyfOc5bvUJK0ZGoS6Okkee5NBlHm6qXDv+W4wCC4GCCV4JlSjAwp8d13CkRSxzuECQQDsuG/4/a2w3rBfxcE43wbSTC6PPWJa7WUcx8jQy6s8lHl+ticOSiYv4YqO0djPgBN8EzV7Axy15VFUO7RLutKs

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

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

  8. A central password server? • Web server asks user for user-name/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

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

  10. How does it work?

  11. Start with a web browser Browser [br]

  12. User requests a URL br  ws : URL Web Server [ws] 1 Browser [br]

  13. Web server redirects to auth service ws  br : redirect(authURL+request(URL)) Web Server [ws] 2 1 Browser [br]

  14. Browser contacts auth service br  as : authURL+request(URL) Auth Server [as] Web Server [ws] 3 2 1 Browser [br]

  15. Auth service and user interact Auth Server [as] Web Server [ws] 5 4 3 2 1 Browser [br]

  16. 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] *

  17. Browser requests URL+response br  ws : URL+response(id) Auth Server [as] Web Server [ws] 6 5 4 3 2 1 7 Browser [br] *

  18. 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] * *

  19. 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] * *

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

  21. So what does all this look like?

  22. Request http://mnementh.csi.cam.ac.uk/raven-test/new-open/document1.html

  23. Enter user-id and password and click 'Submit' to get:

  24. Request http://mnementh.csi.cam.ac.uk/raven-test/new-open/document2.html

  25. Request http://raven.cam.ac.uk/project/testfiles/document1.html

  26. Enter user-id and password and click 'Submit' to get:

  27. Timeout: return to our first document later:

  28. Click 'Continue' to get:

  29. Request http://mnementh.csi.cam.ac.uk/raven-test/private/document1.html

  30. Click 'Continue' and get:

  31. Click 'Cancel' anywhere and get:

  32. Choose 'override login options':

  33. ... and get

  34. Account management:

  35. Account management:

  36. Account management:

  37. What doesn't it do? • Authorization • People without CRSids • POST requests (properly, yet) • Central logout • Anything that isn't web-based • Security

  38. How do you use it? • Protocol specification http://raven.cam.ac.uk/project/waa2wls-protocol.txt • Pseudo-code Application Agenthttp://raven.cam.ac.uk/project/algorithm.txt • ... but that's the hard way

  39. Apache • mod_ucam_webauth (for Apache 1.3 and 2) • LoadModule ucam_webauth_module \ modules/mod_ucam_webauth.soAACookieKey afef845ce49666ab04b36976a<Directory "/cam-only"> Order allow,deny Allow from .cam.ac.uk AuthType WebAuth Require valid-user Satisfy anyAADescription 'Cam-only area'</DirectoryMatch>

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

  41. Perl CGI script • #!/usr/bin/perl -wuse 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;

  42. ... 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 ?

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

  44. Where do you go from here? • Pilots • Deployment from June • Consider expanding 'ucam-only’ access • http://www.cam.ac.uk/cs/raven/ • cs-raven-devel-request@lists.cam.ac.uk

  45. I expect you have some questions If you have been, thanks for listening

More Related