Business Requirements

• Provide a single sign-on service for use by MIT web applications requiring authentication
• Provide a solution for authenticating to web applications from "kiosk machines" and other clients where X.509 certificates cannot be used.
• Must work with all popular web browsers, and require no additional software to be installed on the user's client machine
• Must initially support the existing authentication infrastructure (X.509 certificates), as well as username and password over TLS.
• Central servers will be operated and maintained by NIST
• Must provide a clear and intuitive interface to the end user, which does not detract from the experience of using the protected web application
• Must be easily integrated into existing application web servers. Procedure must be at least as easy as the current certificate mechanism and even easier if possible.
• Must be well documented
• Must be extensible to support new authentication mechanisms as standards evolve and MIT's needs evolve.
• Must support integration with authorization systems
• Must provide detailed logging/audit trail for diagnosis of problems.
• Must support integration with emerging inter-institutional authentication systems
• Should optionally support credential delegation
• Ensure 24/7 availability of the service; scalability
• Must support web server pools
• Central servers must require minimal effort to maintain
• Must offer flexible configuration options

Operations Requirements

• Must be stable
• Must be secure
• Maximum FTE required to operate must be less than (TBD) unless new staff is funded
• Must be scalable
• Must include suffcient diagnostic information for operations to determine cause of problem quickly and easily under adverse circumstances
• Should be easy to reinstantiate
• Source code should be readily accessible and buildable so that "emergency" patches can be applied.

Evolving issues

WebSSO and OpenID

Technology Requirements

In choosing a base package for web authentication, ISDA was most interested in evaluating packages based on the following criteria:

o        Must be well architected, documented, and supported by upstream developers

o        Secure (SSL, Kerberos, encryption, secure cookies scoped to single web server)

o        Must support server pools for redundancy and scalability

o       Support integration with LDAPv3 for authorization

o        Support integration with a Shibboleth deployment

o       Must be extensible for future development

o       Linux-based

o       Capable of clustering, load-balancing, and failover for high availability

Having selected WebAuth as our base package, in turn it has requirements of the central authentication server(s) used in the deployment, for the participating web servers that use the service, and for the browsers used by the clients of the web applications. These are as follows:

-         WebAuth has the following requirements for the Authentication Server(s)  used in the deployment:

• • Linux platform (preferred)
  • Apache 2.0.46+
  • OpenSSL 0.9.7+
  • cURL 7.10.2+
  • Kerberos v5
  • Perl 5.6.1+
  • Perl modules:

• *- *-- HTML::Template
  • *-- FCGI
    • Crypt:SSLeay

• • mod_fastcgi (optional)

• WebAuth has the following requirements for participating Application web servers (for initial version):
  • Linux or Solaris operating system
  • Apache 2.0.43+ or Apache 1.3+ (with SSL and DSO support)
  • OpenSSL v0.9.7+
  • Kerberos v5 (for authenticated communication with central server)
  • cURL 7.10.2+
  • OpenLDAP (for eventual optional LDAP support)
  • Cyrus SASL (for eventual optional LDAP support)

• Browser requirements:

o       Cookies enabled

o       SSL/TLS enabled

o       HTTP/SPNEGO support (optional authentication method)

-------------------------------------

The login server should support multiple authentication methods:

• X.509 certificates (must)
• Username and password over SSL (must)
• http-spnego (highly desireable)

The application servers (typical web servers run by DLCs) will use Shibboleth.

The system should support application server that are running:

• Linux
• Solaris
• Windows Server 2003 or later
• Apache 1.3.26+ (must)
• Apache 1.3.20+ (should?)
• Apache 2.x+ (must, get specific numbers)
• OpenSSL 0.9.7 (must)
• OpenSSL 0.9.6 (should?)
• IIS 6.0 or later (must)
• IIS 5.0 or earlier (not needed)

What are the requirements imposed by the Shibboleth components?

Are there browser requirements?

What about other application servers such as the Oracle WebAS server?

Are there UI requirements?

What are the documentation requirements?

What are the support requirements?

Are there other integration requirements such as support Roles, Moira, or other components?