<<<  Chapters | FAQ | Glossary  >>>

CUWebAuth for Apache and IIS 

CUWebAuth Administrator's Guide

Web Authentication is the process by which a web site can obtain the identity of a user who is attempting to use the web site.    Such functionality has been part of the “web browsing experience” for years – many web users are accustomed to web sites which ask for an ID and password in a secure web page, or may be familiar with a dialog box which the browser will “pop up” when an ID and password are needed.

In the context of authentication here at Cornell, there are two potential problems with this functionality.    The first is that it may be possible to intercept the ID and password as it is transmitted from the web browser to the web site.    The simplest forms of web authentication may not protect well (or protect at all) against this threat.   The second potential problem is that you are giving your password to that web site.    This may not appear to be a problem at all—don’t they already know it?   In the case of most commercial and/or banking web sites, this is probably true.    You’ve set up one account with one institution or company—and they issue you a password, which you must provide back to them when attempting to perform restricted tasks on their site.   However in Cornell’s environment we utilize Kerberos to achieve a single sign-on authentication system.    This means that the same ID and password (your NetID and password) are valid at many different sites.    If every site asked you for your password, every administrator would know it.    A malicious administrator could then impersonate you on other systems!    So, you should never give your password to any web site unless it is done using an officially sanctioned method.

This is where CUWebAuth comes in.    CUWebAuth is the software needed to safely obtain credentials from your end users without needing to see their password.     It also provides you with the ability to use every supported (central) authentication mechanism available.     With the latest version of CUWebAuth, your users will be able to authenticate:  

• Directly with CUWebLogin
• Directly with SideCar (deprecated)
• Indirectly via uPortal proxy
• Directly with inline method
• With future authentication mechanisms easily  

CUWebAuth is the only way to do web authentication using CIT’s central authentication and authorization mechanisms .

CUWebLogin is a web only login mechanism.   No additional software is required on the browser side.   The user logs in via a single login page.   Once logged in, the user can access any sites that use central authentication.   This provides a single sign on experience when using campus web based applications.

When a user tries to access a protected resource, CUWebAuth redirects the browser to the login server.   At the login server, the user enters their NetID and password.   Once the NetID and password are verified, the browser is redirected back to your web site, this time with a cookie based token that allows the user to establish a session with your site.

SideCar has been a valuable tool over the years because it enables web based systems and non-web based “fat” clients to share in a common single sign on environment.   It has the advantage of providing an ideal user experience, where the user logs in once and has access to many Cornell services all day long.

Unfortunately, SideCar doesn’t work with Network Address Translators (NATs) such as those provided by personal wired and wireless routers.   Also, SideCar has some security vulnerabilities that we expect will become easier to leverage in the not too distant future.   For that reason, Sidecar will soon be retired.

Cornell’s implementation of the JA-SIG uPortal product allows multiple “channels” to be displayed on a single web page.   Each of these channels can live on a different web server.   If each web site needs to authenticate the user, you could have many authentications happening during a single page loading on uPortal.  To improve performance, uPortal uses a proxy mechanism to request pages from each web site.

uPortal sends Kerberos credentials via HTTP headers.  The CUWebAuth enabled web server can be configured to accept these credentials.  The proxy mechanism is entirely under the control of each web site's webmaster.   In order to work, proxy support must be enabled, and uPortal must be listed as a trusted host.

Like the proxy method, the inline method sends Kerberos credentials via HTTP headers.   The inline method is useful for applications that have direct access to the user's credentials.  This could either be a fat client running on the users desktop or the KProxy service.

Until recently this has been mostly experimental.   The kProxy service was added to allow fat clients such as WebDAV to work with CUWebAuth protected web sites.  The WebDAV client uses SSL and basic authentication to securely transmit NetID and password to the kProxy server. The kProxy server then logs into Kerberos and gets credential to send to the WedDAV server via reverse proxy.  The credentials are sent to the WebDAV server via the inline method.

Like the proxy mechanism, the inline method is completely under the control of each webmaster.

A big advantage of using CUWebAuth is that your application can leverage new security upgrades and new authentication technologies without requiring significant changes to your application..   Changes such as an upgrade to Kerberos version 5, only require a reinstall of CUWebAuth and minor configuration changes.

Copyright 2006 Cornell University.

<<<  Chapters | FAQ | Glossary  >>>