 |
 |
I realize that the EZProxy list is the vendor's list but to some extent, I think some of this conversation needs to happen there too. Perhaps there's others there who can support an initiative to develop some sort of an alternative. However, many libraries on that list though will be in the same boat as me/my library, I suspect: I may or may not have the technical expertise to monkey with other options, but I definitely don't have the time. It would be hard to justify to my boss that I'm spending time on a proxy alternative when we already have EZProxy. When I'd asked EZProxy list about alternatives I heard about this: HANServer: http://www.hh-han.com/en/default.cfm I haven't done a thorough analysis of functionality because I got nervous about getting English language support from a German company, though I see now that they're partnering with LM Information Delivery (I don't know who THEY are either...) I really do think that the library community needs to do something and this whole thread has served to reinforce that - $500 per year or no. -----Original Message----- From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Scott Prater Sent: Monday, February 03, 2014 9:06 AM To: [log in to unmask] Subject: Re: [CODE4LIB] EZProxy changes / alternatives ? 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 [log in to unmask] 5-5415