InCommon Library Services

[Rich Wenger <>]

I volunteered to describe our situation at MIT.

Our current authentication model on the proxy server makes use of an 
external
Perl script.  MIT has used x.509 certificates for identification for 
many years now,
but EZproxy does not support certificates for authentication of patrons.

Our authentication script runs in an SSL environment and communicates with
EZproxy via encrypted ticket urls.  Patrons that fail to authenticate 
are redirected
to various error pages.

Because the script is such an obvious control point, a number of other 
things have
been added to it over the years.  The most important of these is an 
authorization
function that we implemented last year.

Because of some latency in the cancellation of certificates and other 
credentials after
students, faculty, or staff memberis leaves the Institute, we identified 
some cases where people
who had graduated and were in private business were still able to get to 
our resources,
including a couple of databases whose license terms explicitly forbid 
access to anyone who is not
currently at MIT.

The central computing group developed a set of web services into a Roles 
database
that contains up-to-date information on the status of each faculty 
member, staff member,
student, and affiliate.  A change in status is registered in Roles 
within 24 hours.

The authentication script watches for the urls of databases that are 
restricted, and when
it sees one, queries the Roles database for authorization after 
successful authentication.
If Roles reports a non-active status, the patron is refused access with 
a message indicating
why, and providing an email address to contest the issue if they wish.

It is not obvious how we will handle this authorization step when we 
convert EZproxy to
Shibboleth authentication.  I would like to see EZproxy include some 
exits where control
could be passed to outside programs for a go/no-go signal if needed, and 
stubbed out otherwise.  

We want to implement Shibboleth as widely as possible so we (the 
Library) can get out of
the authentication business, but we have to remain in the authorization 
business.  Perhaps
this project will suggest some ways to do this.

--
Rich Wenger
Systems Programmer, MIT Libraries

617-253-0035