I'd add to the list that EZProxy integration with Shibboleth is fairly
minimal; for example, it doesn't support chaining attribute
authorities, which is an issue for us. We opened a ticket several years
requesting that feature, but realistically, I doubt it will ever get added.
If EZProxy were open source, and if I could make changes to it and push
them back up to codebase, I'd be a lot happier with it. Given the
market share it already has, I would think that releasing the source
code would be a good marketing decision: the pool of interested
developers who could implement new features, and help debug problems,
would increase dramatically, and also contribute to making the software
more secure. Perhaps with OCLC's new EZProxy hosted service, there
would be less of a financial incentive to keep the source closed, and
more of a product development incentive to open it up?
-- Scott
On 02/03/2014 10:09 AM, Andrew Anderson wrote:
For me it’s a little more concrete, and a little less abstract when it comes to
why a viable alternative to EZproxy is necessary. It has very little to do
with the cost of EZproxy itself, and much more to do with support, features,
and functionality.
There exists a trivial DoS attack against EZproxy that I reported to OCLC about
2 years ago, and has not been addressed yet.
Native IPv6 support by EZproxy has slipped by years now. I have patrons using
IPv6 for access today that I want to provide a better experience than forcing
them to use a 6to4 gateway at their ISP.
You cannot proxy https to http with EZproxy to secure the patron to proxy side
of the proxy communication, increasing your patron’s privacy.
I have requested that OCLC make a minor change to their existing AD
authentication support to enable generic LDAP/Kerberos authentication that was
denied because “no one wants it”. Since they support AD, 95% of the code
required already exists, and would make a lot more sense than some of the other
authentication schemes that EZproxy already supports. This closes the door on
integration with eDirectory, IPA, SUN Directory Server, OpenLDAP, etc. for no
good reason.
OCLC has been the steward of EZproxy for over 5 years now, and in that time,
they are yet to fully document the software. Every few months some new obscure
configuration option gets discussed on the EZproxy list that I’ve never seen
before, and I have been working with this software for over a decade now. This
is not only limited to existing configuration options, either — there was no
documentation on the new MimeFilter option when it was first introduced. I
would have expected that the IT staff at OCLC that is managing the EZproxy
service would have demanded full documentation by now, and that documentation
would have been released to customers as well.
EZproxy does not cluster well. The peering support is functional, but not
seamless when there is a failure. When a proxy in the server pool goes down,
the patron is prompted for authentication again when they land on a new proxy
server, since EZproxy does not share session state. External load balancers
cannot fix this problem, either, for the same reason.
EZproxy does not support gzip compression, causing library access use an
additional 80-90% bandwidth for textual content (HTML, CSS, JS, etc).
EZproxy does not support caching, causing library access to use an additional
30-50% additional bandwidth for cacheable web assets. (And yes, you can park a
cache in front of EZproxy to offset this, which is how I collected the 30-50%
numbers, but doing so breaks the “it’s easy and just works” model that EZproxy
promises.)
Combine the lack of gzip support with the lack of caching support, and you are
looking at around a 60-80% overall increase in bandwidth consumption. When you
have a user community measured in hundreds of users, things like gzip
compression and caching may not matter as much, but when your user community is
measured in the hundreds of thousands of patrons, these things really do
matter, and mean the difference between doubling your bandwidth costs this
year, or deferring that expense 5-7 years down the road.
So it’s not _just_ $500 per year when you take a step back and look at the
bigger picture. It’s $500 per year, plus the per Mb cost of your internet
connection — both inbound and outbound — which can be measured in hundreds of
dollars per month for larger sites. If you could could cut that by 2/3 just by
switching to a different proxy solution, that might get your attention, even if
you shifted the $500/yr support costs to a different entity.
Imagine never hearing “wow this library network is slow” again because a web
page that used to load 1MB of content was able to gzip that down to 600KB, and
300KB of that content was served off the local proxy server, leaving just 300KB
to pull off the remote server. How much is a better user experience worth to
you?
Bottom line: competition is good. Just look at how Internet Explorer is almost
a sane browser now, thanks largely to competition from Firefox and Chrome. If
coming up with a viable alternative to EZproxy using open source tools causes a
security, features, and functionality arms race, then everyone wins.
--
Scott Prater
Shared Development Group
General Library System
University of Wisconsin - Madison
[email protected]
5-5415
