There are two parts to this request:
- Update the login filter for all Fermi Web applications
- Update the version of CAS
Login Filter update
The login filter is what allows Fermi web applications to communicate with the Single-Sign-On CAS server.
In its original design it made use of a domain specific Cookies to handle the propagation of login/logout actions across Fermi web applications. Since then the login filter is being used by other experiments and the domain specific Cookie provides a barrier across which the SSO information cannot propagate.
The logic of the filter has been updated to span across a sub-domain: for example it will be possible to carry the login/logout information across glast-ground.slac.stanford.edu and srs.slac.stanford.edu and exo-data.slac.stanford.edu.
The overall logic is more sound and will be easier to explain in future security reviews.
This change is NOT backward compatible. What this means is that going from one application with the new login filter to one with the old one (and vice-versa), the login/logout information will not be carried and a user might have to login/logout again.
For the change to be effective, the login filter for all Fermi applications (and other experiments as well) will have to be updated.
CAS Server update
We are currently using a very old version of the CAS server that provides authentication against the SLAC Kerberos server.
We have a new version of CAS that is not interfacing with the SLAC Crowd server. This means that SLAC users will still be able to login with their Unix/Windows credentials, but additionally the Single-Sign-On will be extended to Confluence and Jira. In other words logging in to Jira or Confluence will authenticate users against the new Login Filter. The reverse is also true, logging in one of the Fermi web applications will automatically migrate to Confluence and Jira.
It will also be possible to authenticate non-SLAC users against their Confluence account. This might be of no interest to Fermi, but other experiments might like this feature.
The API for the new CAS server is backward compatible with the old one, so it should be easy to put the old CAS server back in production if needed.