Transcript UMBC`s WebAuth

UMBC’s WebAuth
Robert Banz – UMBC
[email protected]
http://www.umbc.edu/people/banz/webauth.html
A Few Terms
Authentication
Knowing that you are who you say you are.
Authorization
Knowing what you can/can’t do, usually gleaned from
other information than your name…
Often confused, as they are (usually)
intertwined!
What is WebAuth?
• Created as a Web Single Sign On
system during the Summer of 2000, to
provide a common authentication
interface to:
– WebAdmin, UMBC’s directory-enabled
directory and account management tools
– WebCT (3.x)
– Blackboard
What Is WebAuth?
• An Authentication Server, written in Perl,
running under Apache.
• Client API code for
– Perl, for use in CGI scripts and Apache
mod_Perl modules
– Java, for use in applications using the
servlet api
Motivation
• Provide reasonably strong authentication and
authorization data to web-based applications.
• Support a wide variety of web clients
– Needs to work with a minimum of services a web
browser can provide
• Not create a performance burden on servers
and/or clients
• Wide variety customer applications and
requirements
• Potentially extend the framework to provide
inter-domain (cross-campus) services.
“Reasonably Strong”
• You can trust it.
– Some kind of cryptographically signed
“thingy”
• Shouldn’t do “bad things”…
– Such as send your password, or other
authenticator in the clear.
The Lowest Common
Denominator
• Is passing CGI parameters…
– But, this can be cumbersome, as an application
programmer must re-send the data with every
transaction
– User would have to “re-authenticate” if they left
your site and came back.
• The “next to lowest” common denominator,
“Cookies”
– Most, if not all, web browsers support them.
– They are stateful, and stick with you.
– …but, they’re not very secure (but we can fix that)
Don’t Burden Your
Servers or Clients
• SSL is a CPU killer for your web servers
– …so, it shouldn’t be required when the
application content doesn’t dictate it
– …need to minimize the cost if a cookie is
sniffed.
The Kerberos Model
• User ‘authenticates’ themselves to a
‘trusted host’ (the KDC) and receives a
ticket granting ticket
• The ticket granting ticket is later
presented to the KDC for the issuing of
service tickets for specific applications
• Service tickets can only be decrypted by
the application they were created for.
The Kerberos Model
• Tickets also expire
• …So, service tickets have limited worth
– a function of their expiration time, and
cost of the information they are
protecting…
Translating Kerberos to
the Web
• When authentication is needed, the
user is redirected to the WebAuth
server
• If the user does not have a valid TGT:
– They are asked to authenticate
themselves
– A TGT, and a service ticket (in the form of
cookies) are issued for the requesting
application
– They are redirected back to the URL that
needed authentication
Translating Kerberos to
the Web
• If the user HAS a valid TGT:
– The TGT is verified, and service ticket is issued
with the same credentials contained in the TGT.
– The user is redirected back to the URL that
needed authentication
– There was no user interaction in this
exchange!
• So…
– We can tune the expiration times of Service
Tickets to lessen our exposure.
– We can tune ‘up’ the expiration time of the Ticket
Granting Ticket so a user does not have to
‘interact’ with the system during a typical session!
It’s not perfect…
• There are a few potential ways to ‘hack’
the system, as it exists now…
• …but there are ways we plan to fix
them.
Integration
WebCT
– Relies on standard HTTP Basic Authentication (via
mod_authdbm)
– Runs under Apache
– Created an Apache module, using mod_Perl
• Emulates part of mod_authdbm, with the exception of
where it gets it’s authentication
• Has also come in quite handy for adding common
authentication quickly to other web services!
– The WebCT user database is updated nightly from
our LDAP directory.
Integration
Blackboard
•
•
•
•
Running under Windows NT/ IIS
Uses JSP (Java)
Wrote a Java-based WebAuth client class
Blackboard integrated it into their login
process
• The Blackboard user database is updated
nightly from our LDAP directory.
Integration
MyUMBC
• MyUMBC is our web portal, rolled out in
august ‘99
• Uses it’s own authentication scheme,
authenticating users against the Kerberos
server directly
• Augmented the MyUMBC login process to
retrieve a ticket granting ticket for the user,
allowing for a seamless transition between
the web portal and linked applications.
• Future portal development to make use of
WebAuth directly.
The Client API
• Easy to use!
– In Perl, only a couple lines will check
someone’s authentication, or force them to
get some.
– Java is just as simple 
– Or, use the Apache module  
Future Directions
• Additional “authorization” encoded in
the service ticket by request
• Anonymous authorization-only for
library-like services
• Additional authentication levels / roles
• Cross-domain
authentication/authorization
More Information
• http://webauth.umbc.edu
– We plan to release the source, and will make it
available here!
• http://middleware.internet2.edu/shibboleth
– Internet2’s Web Access Control project