...
Unfortunately, this fails sometimes at Yale. It is not clear if anyone else experiences this problem with CAS, and it may be due to some local network problem or the way we configure the network. However, frequently enough the Flow seems to get broken when the user hits Enter on the page where he submits the userid and password. The JASIG CAS code stores one important piece of data in a Webflow variable (the service= string) that has to be available after this form is submitted, and it has no logic that can recover if the Flow is broken by some network problem. It is relatively trivial to program around this, because the service string could just as easily be stored in a hidden field of the form as in a Flow variable. However, this is a modification of the JASIG code that makes CAS more robust against failure of the Webflow mechanism for whatever reason.
Preferences
CAS has a large number of optional features, but they are all configured by the central administrator. There is no provision for the User to select optional CAS behavior. It seemed that this feature would be required in the future, so a "proof of concept" module has been created called CAS preferences. When the user goes to the /cas/preferences URL he is presented with a Form where he can select various check boxes and radio buttons. These choices are then written to a Cookie scoped to the CAS server and are available at the beginning of the login Webflow to influence the path through subsequent login sequences. This could be used to enable additional forms of authentication, special processing, or even additional logging to debug a problem someone else is having.
Statistics
There is a standard CAS page with basic server information, but Yale Production Services has a standard format expected for Opsview. So we used the requirement to add Yale specific monitoring data.