Here is the item I mentioned about the confirmation page in the
webauth FAQ ("Why does weblogin display another page after login?"):
http://webauth.stanford.edu/faq.html#PF02
This could be replaced by an HTTP redirect.
Bob say's we might at least want it to be conditional on whether
it's the initial login. And, part of the intent is also to provide a
final opportunity for the user to cancel, which would be lost
in always refreshing. (I'm not sure how critical that feature
is, though).
Ideally, perhaps this should be user-configurable. I don't
think we need to solve this for the pilot, though...
Concerns from Jeff Schiller (8/1/2006)1. Can be supported from a CGI(or fcgi) script (no integration with
base webserver required).
2. Item 1 can be done from Java, PHP, Perl and Python under Solaris,
Linux and IIS/Windows.
a) Libraries already available for these languages/operating
system, or token format trivial enough that parsing it doesn't
require a major development effort.
b) Simple design, doesn't require multiple message exchanges
between the various system components.
3. May have an Apache module available. Both for version 2.X and
1.3.X.
4. Is secure (of course).
I wrote a system a number of years ago (which we actually used in production for two years for the undergraduate housing lottery) which met these requirements (well, we never did 3, but we didn't need to). Code to create and parse the tokens was written in Java, C and Python (Perl would not be hard to add, nor PHP).
I can share the code, formats, I just have to find the code... We stopped using it when we converted to using Certificates even for the incoming students accessing the lottery the summer before they arrived on campus.
---------------------
Could you please indicate what versions of the following you think we need to support in such a system, in order to support NIST web servers?
- Operating systems (Linux, Solaris): Yes. Linux and Solaris
- Apache: 1.3.20+ (maybe only 1.3.26+)
- OpenSSL: 0.9.7 and 0.9.6k+ (0.9.6 can probably be dealt away with if it is a
big problem).
(The intent here is to get an idea of the range of Unix-based software versions we need to support, not to imply that Windows/IIS will not be supported; please feel free to pass along any version requirements for Windows/IIS as well).
----------------------
Following up on my testing of Stanford's Webauth package, and
arising from ongoing concern about its lack of support for web
servers other than Apache 2.0, I have spent some time evaluating
a similar (Apache 2-based) test set-up of Michigan's Cosign package,
which also offers official support for Apache 1.3, IIS, and Java.
Summary: If our priority is to deploy a service supporting
all of our required web server platforms as quickly as possible,
then Cosign is probably the logical choice. But if, as I believe,
it is more important to choose the best base for building a quality
service in the longer term, and if we acknowledge and accept the risks
and commitment inherent in going with a package currently lacking our
required platform support, then we should choose Webauth.
Cosign basically works, is similar to Webauth in approach,
capabilities, and security, and appears to be supported well by
upstream maintainers. Compared to Webauth, it does not seem to be as
well architected or documented, and configuring it properly is a bit
more difficult. Its support for authentication via other Apache
modules (e.g. mod_ssl for X.509 certificates, and mod_auth_kerb for
HTTP/SPNEGO) is currently not as good as in Webauth (though the latter
is still far from complete in this area), and would require
development effort for our use.
Webauth offers the following advantages:
- Less complex design: Under Cosign, a daemon running on the login
server manages session state. Under Webauth, session data is stored
in session cookies, rather than on the central server.
- Superior quality in code base, documentation, etc.
- Better integration with other Apache authentication modules
- Additional Apache module providing LDAP integration (untested)
- Apparently better about minimizing exposure of ticket files,
SSL keys/certificates; does not require separate user account
on login server.
- Extensible protocol
Webauth requires the following development work for pilot release:
- Port to Apache 1.3?
- Add the ability to authenticate via X.509 certificates as well
as username/password and HTTP/SPNEGO. Add user options for
doing their preferred method by default.
- Ensure proper setting of REMOTE_USER variable (i.e. canonicalize
instead of stripping realm).
- Develop customized login, logout, confirmation, error and
documentation pages.
- Miscellaneous build system work.
Webauth will likely require the following longer-term development
work (minimally):
- IIS support
- Java servlet support
- Improve delegation
Cosign has the following advantages:
- Apache 1.3 support
- IIS support (untested)
- Java support (untested)
- Site-wide logout
- Site-wide idle timeout
- Some additional delegation functionality (e.g. application server
module can apparently request proxy cookies as well as Kerberos
tickets)
- Has some built-in support for X.509 certificates, but this seems
to require Michigan's KX.509 package.
- Fewer external software dependencies (Webauth requires the
cURL library on application servers, and mod_fastcgi and
several Perl modules on the login server).
Cosign would require the following development work for pilot release:
- Improve its support for other Apache authentication modules,
including making redirection work after falling back to
login via username/password; add user options for doing their
preferred method by default.
- Rationalize/canonicalize REMOTE_USER setup.
- Improve setup/handling/cleanup of daemon, ticket cache, SSL
directories.
- Develop customized login, logout, and other HTML pages.
- Improve build system.
Cosign will likely require the following longer-term development
work (minimally):
- Improve delegation
- Improve LDAP integration
Cosign's site-wide logout and timeout features are possible
because its central server maintains session state; Webauth's
architecture makes such features unfeasible to implement.
However, while these features might be useful, I do not feel
that they are critical; instructing users to exit the browser
(thus destroying all session cookies) to terminate the
authenticated session seesm sufficient. Also, the additional
delegation and certificate functionality does not seem terribly
useful for our purposes.
Clearly Cosign's principal advantage is its official support for a
wider range of web server platforms, including Apache 1.3, IIS, and
Java (though the only documentation I have seen for the latter is in
its CVS source repository). If we choose Webauth, we will be faced
with doing significant development work to support those additional
platforms; there is no Apache 1.3 version at all, so we would have to
do that port ourselves. (See my recent analysis of the work involved;
I have sent mail to Stanford asking what interest, if any, they might
have in such a port, but have not yet received an answer). Webauth
customers have contributed an IIS filter and a Java servlet
implementation, but these are not currently supported by the Webauth
maintainers. So, there is definitely some risk that we would end up
supporting one or more of these with little or no help from upstream
maintainers. Yet if we acknowledge that our initial deployment will
only constitute the first phase of a long-term effort to provide an
authentication/authorization infrastructure for the web, and that
either package would merely be a base which will likely require
significant development work in any case to enhance, interface to, and
support, then it makes sense to choose Webauth for its superior design
and quality, and accept the risks and development commitment inherent
in that choice.