1. UMBC’s WebAuth Robert Banz – UMBC banz@umbc.edu http://www.umbc.edu/people/banz/webauth.html

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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