Skip navigation



WebAuth Features

WebAuth is only one of several available web authentication systems. This page summarizes its features and offers a brief comparison to several other major systems.


Some of the most significant WebAuth features are:

  • Supports any browser that supports SSL/TLS and cookies and requires no special browser configuration.

  • Implemented as an Apache authentication mechanism and therefore works with any other Apache directive, any software that supports taking the user identity from REMOTE_USER, and Apache authorization mechanisms such as groups.

  • Uses an existing Kerberos infrastructure to authenticate users and to authenticate web servers to the central authentication system. Alternately, any other authentication mechanism supported by Apache may be used to authenticate users, including client-side certificates or SPNEGO. WebAuth works the same either way from the perspective of all web servers using WebAuth. Only the central weblogin server needs to know how users are authenticated.

  • Built-in LDAPv3 integration (with GSSAPI authentication) for authorization and to retrieve directory data about authenticated users.

  • Extremely scalable. Supports pools of web servers serving the same content and pools of weblogin servers and WebKDCs, all of which can be used interchangeably without breaking authentication. Almost all state is stored encrypted on the client browser rather than on a central server, making it trivial to add additional systems to a web pool without invalidating existing logins.

  • Mature, well-tested, and configurable. Stanford deployed WebAuth 1.0 in July of 1997 and the current WebAuth is based on our experiences and user issues with all the previous versions. The current version started with a ground-up rewrite and significant improvement completed in February of 2003. WebAuth supports a wide variety of configuration directives and some features (like session timeouts and required login) that are rare among web authentication systems.

  • Thorough documentation, including full Apache-style manuals for the Apache modules and a fairly complete protocol specification.

  • Under active development, with regular releases and support on the mailing list.

  • Very extensible protocol, with hooks available to add additional authentication mechanisms, options, and data types as needed. The current implementation relies on Kerberos, but nothing in the protocol assumes Kerberos and some other authentication infrastructure could be used if needed.


The most serious weakness currently in WebAuth is the lack of an IIS implementation. There is an unsupported implementation for Apache for Windows, but most Windows web servers run on IIS and can't move to Apache. There is a proof of concept implementation as an IIS filter, but a proper implementation would need to be an IIS extension. In the meantime, WebAuth users can use Shibboleth on IIS for authentication and use WebAuth as the IdP for Shibboleth, but this requires setting up and managing an additional web authentication system. They could also use an Apache server as a proxy for the Windows system, let Apache do the authentication, and then pass the authentication information in the request to the Windows server, but this is a little complex to think about and requires that the application restrict access to the proxy servers and pull authentication information from HTTP headers.

WebAuth also doesn't support simple site-wide logout. This is a design constraint that will be difficult to change (although there are a few possibilities for getting something a little like site-wide logout). By design, WebAuth stores session information as user cookies rather than on any central service. The advantage is that the user has full control over their own session; the disadvantage is that the cookies this information is stored in are scoped to each individual WebAuth-using system the user has accessed. This means that to fully log out, there is no substitute for exiting the browser or taking some other action that destroys all browser session cookies.

Neither of these limitations are likely to be fixed soon, although we are interested in doing a WebAuth implementation for Windows if we can find funding and resources. If either is particularly important to you, WebAuth may not be for you. For sites particularly concerned with these two problems, we recommend Cosign, another excellent web authentication system that supports IIS and site-wide logout.

WebAuth vs. Cosign

Compared to WebAuth, Cosign has the following features:

  • IIS support
  • Site-wide logout from a single URL
  • Site-wide idle timeout
  • Somewhat more mature ticket delegation

WebAuth has the following features that don't appear to be in Cosign:

  • Tighter LDAP integration
  • No ongoing dependence on the central daemon after auth
  • Finer-grained option control at the content provider level
  • Slightly more thorough documentation
  • Better Debian and Ubuntu support

In general, the systems are very close in capability. Had Cosign been available (and were we aware of it) when we started implementing WebAuth v3, we probably would have enhanced it rather than developing our own system. Now, both systems have very similar features and either is an excellent choice.

One interesting difference is the security model. Both WebAuth and Cosign are, apart from the difference of how logout is handled, equally secure. Cosign doesn't put as much of the authentication data into the cookie, but WebAuth uses 128-bit AES encryption (upgradable to 256-bit if desired) and regular key rotation for the data that it puts into the cookie. The Cosign model allows for site-wide logout and central control of sessions; the WebAuth model has less complexity in the central daemon (WebKDC in the WebAuth parlance) and an authenticated session has no dependency on the WebKDC after the initial authentication. It's a design tradeoff; each solution has its own advantages and disadvantages.

WebAuth vs. Shibboleth

Shibboleth is primarily a system for doing inter-institutional authentication and as such is not a direct competitor to WebAuth. In fact, Stanford intends to deploy both, using WebAuth as the authentication mechanism for the Shibboleth IdP. Shibboleth requires a site provide a central mechanism for authenticating users and only provides glue around that authentication, so it is a natural ally of systems like WebAuth and Cosign.

You can run Shibboleth as a single sign-on system internal to a site, and in that mode it has the following advantages over WebAuth:

  • IIS support
  • Deep LDAP integration with attribute release policy
  • Can generalize to interinstitutional authentication
  • Uses certificates for authentication
  • Doesn't require Kerberos

WebAuth has the following advantages as a site authentication system:

  • Easier to set up and configure
  • Fewer dependencies and simpler technology
  • Leverages an existing Kerberos infrastructure

Many sites will want to run both Shibboleth and some other site-specific web authentication system such as WebAuth or Cosign.

WebAuth vs. CAS

CAS is a web authentication system developed at Yale and now adopted by JA-SIG. It has a particularly Java-centric outlook, which may be an advantage or a drawback depending on your needs.

CAS has the following advantages over WebAuth:

  • Tight Java integration
  • Leverages existing Java features heavily
  • Simple handling of proxied auth to other CAS applications
  • Client implementations for many languages and platforms
  • Login server support for many different authentication methods

WebAuth has the following advantages:

  • Integrated authorization support
  • LDAP integration for non-Java applications
  • Supports delegated Kerberos credentials
  • Handles clustering of the service internally

As opposed to WebAuth, which provides only standard Apache authentication and authorization module, CAS provides a toolkit that allow a wide variety of clients to use the central CAS login service (written in Java) or use other authentication methods through the same API. It looks like a good choice for an environment where most applications are custom-developed, due to the wealth of client implementations, particularly if Java is a primary implementation language. It is very deeply integrated with Java and may be off-putting for environments will little or no Java expertise.

Last modified Friday, 12-Dec-2014 02:31:11 PM

Stanford University Home Page