UMBC’s WebAuth

1. UMBC’s WebAuth Robert Banz – UMBCbanz@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. IntegrationWebCT • 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. IntegrationBlackboard • 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. IntegrationMyUMBC • 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