InCommon Library Services

[Tobias J Kreidl <>]

The EZproxy front end can take on a two-fold role.  First of all, you
can immediately redirect any requests from specified IP address ranges
to bypass the EZproxy mechanism altogether, and thereby save a lot of
resources by just pushing the user off to the destination (and getting
rid of the EZproxy connection).  The problem here is that this precludes
any initial authorization, so in the Shibboleth "guest" (or even user)
login model, there would be no authentication step at all.

If the IP address in the above scenario is not in the exceptions list,
then the user is hit with a custom login page.  Depending then on what
wherever the local system wants and be either granted some sort of
ticket (cookie) or not.  As mentioned before in a private message, we
use a CAS-based model at present and have an LDAP entry that
specifically looks to see if the user has a library proxy flag set.  If
not, they go no further (unless they're already in the exceptions IP
address group).

So, one of the advantages I think in Shibboleth would be to find a means
to handle authentication, even for guests.  The other main point above
is whether or not you want all or just part of the network traffic to
flow through the EXproxy mechanism or not.  Here, on-campus, we have
lots of users right now who -- by virtue of the local IP addresses -- do
not get proxied, hence we can get away (for now) with a less hefty
EZproxy server.

Thus, the processing sequence starts in this case within EZproxy and
deals initially with the originating IP address.

--Tobias

Tobias J. Kreidl
Northern Arizona University
Information Technology Services/
Academic Computing