Archival info about WIND

ColumbiaColumbia used to use an authentication system called WIND, which was based on the early CAS protocols.

This is old information about the WIND system.

.

Wind was originally implemented in Perl but is now a Java Servlets application like CAS2.

Some links about WIND:

WIND contrasted with CAS2

This is an informal document contrasting WIND and CAS2 that is the result of skimming the above WIND documentation.

WIND has a number of features not present in CAS2. In general it is probably easiest to think, while not entirely historically accurate, of WIND as a superset of CAS2 functionality.

WIND feature	How it relates to CAS2
Service registry including configuration of which services are authorized to use WIND for authentication, whether they are allowed to see UNIs (Columbia NetID-equivalents), which Affiliations they are allowed to know about, custom login UI components including a logo gif, custom help links, whether Columbia-wide standard WIND links appear. Expected future enhancement to allow more customized text on the login screen.	CAS2 does not register services using it and is stateless with regard to those services.
Logout UI customization by the service redirecting to logout, including a URI for CAS to link back to, some custom text, and an ability to do a "gateway logout" such that CAS does not present logout UI but just redirects back to the application.	CAS2 baseline does not offer any logout UI customization. Yale local CAS2 offers a request parameter which is a URI for which CAS will paint a logout link.
Password strength data in validation response including whether the password was typed to obtain the service ticket being validated (the equivalent of CAS2 renew=true except in the validation response), timestamp of last presentation of password, timestamp of last password change, and password change metadata (a URI suitable for linking to in case where the application rejects authentication due to unacceptably stale password).	No password strength metadata. CAS2 implements renew=true as a request parameter of ticket validation, which is less flexible than including the boolean of whether the password was typed in the validation response.
Handles: Only select services may see UNIs (Columbia equivalent of NetIDs) in the ticket validation response. Most services only get a Shibboleth-style persistent unique identifier which is oneWayHash(NetID, serviceIdentifier). This allows a service to provide authenticated personal customization without knowing whom it is dealing with and without being able to expose a key that can be used to look up the user in other systems.	CAS2 does not support handles.
Affiliations. Users have zero or more group affiliations which can be expressed in the ticket validation response. This is an especially powerful feature when used with Handles. When a service only cares that the authenticated user is a student, it doesn't need to know who that user is, and so can provide anonymous authenticated authorized access to, say, online library collections.	CAS2 does not provide any attributes or groups with the NetID in the validation response. Services that care about group affiliations of students will take the authenticated NetID and perform their own group and attribute lookups.
PGTs returned directly in ticket validation responses. WIND services needing Proxy Granting Tickets do not need to expose a secure callback listener to receive the PGTs and instead receive them directly in the ticket validation response. This lowers the barrier to entry for applications to obtain PGTs.	CAS2 Proxy Granting Tickets are vended via secure callback to an SSL'ed URL. Only the possessor of a valid SSL certificate for a callback URL will be able to receive Proxy Granting Tickets in the name of that URL. This requires that applications requiring PGT properly configure SSL and map a listener for PGTs.
Ticket strings are passed as a parameter named "ticketid"	CAS2 calls this request parameter "ticket"
Service URIs are passed as a request parameter named "destrination"	CAS2 calls this request parameter "service"

Additionally, CAS2 appears to have some features not present in WIND.

CAS2 feature	How it relates to WIND
Destinationless single sign on login. Users can authenticate to CAS for the purpose of establishing a Single Sign On session without having a service to which they would like to be redirected immediately. It is not clear that any real end user has ever actually used this feature.	WIND login requires a destination.
PGT vending via SSL callback. Only the possessor of a valid SSL certificate for a given URL will be able to obtain Proxy Granting Tickets in the anme of that URL.	End users are able to obtain Proxy Granting Tickets in the name of services authorized to obtain Proxy Granting Tickets. In practice this isn't a problem if proxying services are not authorized to proxy authenticate to any services to which nd users couldn't have authenticated directly themselves. In the case where a destination URL is not SSL'ed, a ticketid is exposed on the redirect from WIND such that the Adversary could sniff the ticket and validate it itself before the intended service, thereby obtaining a Proxy Granting Ticket in the name of the proxying service. This exploit is effectively suppressed by using only SSL'ed Destination URLs.
Gateway. Transparent checking for existing SSO session without CAS redenering login UI.	Gateway doesn't appear to be a supported login parameter in WIND.