Our overall aim is to implement Shibboleth SSO as widely as possible so we can return authentication where it belongs; with central computing where credentials are managed.
Whether for personalized features of the ILS, or for access to ILLiad, or authentication to EZproxy, staff and patrons should be able to authenticate with their primary campus credentials. It should be seamless, self-explanatory, and easy to use.
Our primary campus Shibboleth IdP accepts three different modes of authentication: x.509 certificate, Kerberos userid and password, Kerberos tickets. Our Collaboration Account IdP accepts registered userids and passwords or OpenID, and connections from the InCommon Federation.
We need EZproxy to redirect patrons to those IdPs as needed, regardless of who they are and where they are coming from.
MIT standardized on x.509 certificates for authentication to web resources many years ago. EZproxy has never supported the use of certificates for authentication, so we externalized all authentication for EZproxy resources in a cgi script, which is invoked with this directive in user.txt:
::cgi=https://libproxy.mit.edu/cgi-bin/scriptname?
The script looks for a valid certificate and if one is found, sends the authenticated patron back to EZproxy via a ticket url. EZproxy then sets up the proxied session. If no certificate is presented, or the certificate is invalid, the patron is redirected to an error page.
The existence of this single point of control made it the natural place to impose more complex controls as the need arose over the years. Some of our resources require more stringent access control than the presentation of a certificate. All of this special handling falls within the category of authorization, as distinct from simple authentication via cert.
This means that we are now dependent on being able to do authentication AND authorization on the proxy server. Two changes are now causing us to re-think this landscape. The first is the advent of Shibboleth and the second is the deprecation of the ::cgi= mechanism by OCLC.
EZproxy supports Shibboleth, acting as its own SP, but it does not have any standardized API or exit facility to allow authorization processing. In order to use EZproxy's native Shibboleth support, authentication must be combined with authorization in the Shibboleth IdP, a retrograde step that we are not willing to take. We need Shibboleth authentication on the proxy server AND an externally-scripted authorization facility.
The only way I know to do that is to continue with the ::cgi= mechanism and put the external script in a directory controlled by Shibboleth. When EZproxy invokes the external script, the session will automatically be redirected to Shibboleth for authentication, and on return the script will proceed with any requisite authorization processing.
This makes us vulnerable to the retraction of ::cgi= support in some future release of EZproxy. In a more perfect world EZproxy would have a standardized API that acted in concert with all its supported authentication mechanisms, but such is not now the case.