Overview

WIND provides a protected reentry service, which offers single sign on style functionality while reserving the ability to challenge users for credentials at any point, usually when passing into a service that does not elect to participate in single sign on.

WIND provides a simple developer API while allowing for a range of information to be released according to the requesting service, including encrypted identifiers and affiliation information.

Outstanding Issues

New Features

• Ticket proxying is required for portal use.
• XML formatted replies are required by AIS for PeopleSoft.
• Destination based restrictions on login requests to replace host based restrictions ticket validation.
• Password aging (perhaps by returning time until expiry) for services that require it.
• Possible use of a Verisign certificate to facilitate Java developers.
• Service requested logout to force password reentry before the WIND session expires.
• Improved documentation, including "best practices for web auth" (eg: do you need ssl?) and management friendly documentation (eg: why should you use wind?).

"Big Picture" Issues

• The new style affiliations returned by WIND may not be the best format for returning this data. Alternatives, if desirable, include reverting to old style affiliations and switching to a more complicated schema, such as SAML.
• Is a more strongly centralized authz infrastructure required?
• Login page revisions, currently proposed to simplify the login page and invert the service and Columbia logos.
• Perl implementation performance vs other models, including Java servlet.
• WIND may not make best use of available developer time, given the concurrent development of Shibboleth hosted by AcIS, or given several other campus sign on platforms under development, including WebISO, Cosign, and CAS 2. (Relatedly, AIS has made preliminary offers of developer time to facilitate the implementation of their desired feature set.)

Wdamb Retirement

Proposed Options

1. Continue WIND Development

   Under this option, WIND continues on its current development track, which may or may not include a rewrite to another language. Selecting this option does not exclude using Shibboleth for interrealm applications.

   Advantages

   • Existing clients will not necessarily need to modify their code.

   Disadvantages

   • Another application requiring in house maintenance.

2. Switch To Another Campus Sign On Solution

   Under this option, WIND development ceases. An alternative project is adopted (candidates include CAS 2, Cosign, and WebISO). Selecting this option does not exclude using Shibboleth for interrealm applications.

   Advantages

   • As facilities are introduced into these solutions by other developers, they can be introduced locally with minimal developer time.

   Disadvantages

   • AcIS will certainly require local customizations, including for aname and affiliation support, and these changes may not be accepted back into the selected project.
   • Retiring WIND will require existing clients to adjust their code, even for CAS (since WIND and CAS 1 are not 100% compatible).

3. Consolidate Development With Shibboleth

   Under this option, WIND development merges with Shibboleth development.

   Advantages

   • One less codebase to maintain.
   • Possibility of freeing up developer time.

   Disadvantages

   • Shibboleth installation is heavy weight (requires web server modifications), imposing additional requirements on client developers.

Regarding wdamb retirement, it is possible to use a module like mod_shibboleth or mod_cas to incorporate the sign on system with Apache. This is a fairly heavy weight imposition, and an alternative approach using a module designed to perform authentication locally on the server, may allow for faster service. The disadvantage of the alternative approach is that it will require locally developed code and that effort will be required to ensure compatibility with the campus sign on system for participation with single sign on enabled services.

Suggested Action