From a thread on a vendor user group mailing list, where someone was (justifiably) complaining about a vendor saying they wouldn’t allow proxied access to their platform anymore, but would require some mysterious not really described proprietary auth process for users, but which sounded like it would be a terrible inconvenience for users.
Some of the response kind of, from my perspective, approached “EZProxy is great, we can’t let anyone challenge it”. I’m not sure that’s the right attitude.
EZProxy is a really terrible solution for just about everyone involved.
It’s just the best solution we have that actually pretty much works.
It slows down access for our patrons. We have overseas patrons — all their traffic needs to travel all the way to our US city to go through our EZProxy, then from our EZProxy all the way to the actual vendor, which could be on yet another continent again. That’s a pathological case, but even in ordinary usage we’re slowing down the connection, making it dependent on our hardware and our networks. I know for a fact at my institution access to licensed resources is slower because of EZProxy being in the way.
Plus it’s terrible that our patrons only get access if they access through our “proxied links”. If our patrons find something via Google, and it’s something we license, shouldn’t they have some easy way to figure that out and get access? Shibboleth in theory could solve that — but only if vendors implement consistent recognizable interfaces so our users can recognize they can institutional access, with click-flows that make it convenient and quick for a user to do it. Some working group (of In-Common?) is working on promulgating best practices for some of this, but I’m not sure I can find their work. This is part of it, but doesn’t actually touch upon the consistent recognizable interface for login, which I think is actually the most important part!
Vendors don’t like it because they lose all control of who has access to their app, they have to trust us to give the right people access. But that’s good for us, and even Shibboleth doesn’t do anything different there, really. In a world where most of our use is ‘off campus’, I’m not sure there is any way for the vendor (rather than us) to control who has access, without making things impossible to manage and hard on us and our patrons.
Vendors also don’t like it if they want to enforce a limit on number of simultaneous accesses as part of their service model. EZProxy makes that much harder, if not impossible. Shibboleth properly implemented might actually let them do that. But implementing it properly is a pain for both vendors and us.
Implementing Shibboleth at all is a pain for us.
But EZProxy is a really terrible solution. It can’t last forever (I hope). I don’t know of anything better than a shibboleth or shibboleth-like solution, despite it’s pain. IF the vendors actually do it right.
So I’d be careful sticking to an “We demand EZProxy forever!” attitude with the vendors. It’s not realistic, it’s not really even good for us or our patrons. But at the same time, yeah, we can’t accept alternatives that are even worse for our patrons, like some weird proprietary authentication scheme that requires us to distribute sensitive shared passwords to our users somehow, or go through weird click-flows they’ll never understand, or create personalized accounts at our vendors sites, or whatever. We really need vendors to do Shibboleth (or some other similar protocol) right, AND we need Shibboleth to be a LOT easier to set up and maintain on our side.
Bibliographic Wilderness 
I agree shibboleth is a steep learning curve, but once in place is fairly stable and fairly straightforward to maintain.
Some of the work being done to package a more intuitive “discovery service” into the Shib SPs might help some of the vendors implement a more intuitive interface for users to find their home institution. http://bit.ly/e9GriK
Or not, as there are so many ways to implement SAML, vendors might just continue to do their own thing anyway.
I do think proxy access is great for those small publishers who don’t really have the technical staff to implement shib, but provide awesome services. IP access is just so easy for them to manage.
We tried out Shibboleth authentication through InCommon for a couple of vendor databases and from a user perspective it made a lot of sense, the big problem was the way the vendor presented how to authenticate … usually it was a menu and you had to scroll through … of course not finding your instituion name and not knowing you were supposed to click on the In Common group.
Agreed Sean, getting everyone to have the same consistently branded simple as possible login process is the only way it’ll work for our users. For instance, all our vendors login buttons have to look the same and be easily findable, and take you to a similarly looking screens where you immediately choose your institution through easy to use controls, then login to your usual institutional login screen.
Yeah — it is the classic “Where Are You From” (WAYF) problem. Thanks, Chad, for posting a link to the Shib-Dev’s work on the Shibboleth Embedded Discovery service. Kudos to JISC and the U.K. in general for advancing Shib work.
Jonathon, this caused some discussion here about how to integrate EZproxy closer with Shibboleth to provide some paths to content that don’t require proxying. What are the pain points you are thinking of in Shibboleth implementation? The WAYF one stands out however I think with some decent UI/UX work we can make it less painful.
Are any of you in production with an institution IdP that communicates directly to a content provider Service Provider?
We do have EZProxy do redirection to WAYFless Shib login here too. I think that actually works reasonably well — but is sort of a side feature to EZProxy, not it’s core proxy feature (hence the “proxy” in the name EZProxy).
It’s the actual _proxy_ function of EZProxy that I consider a terrible solution (not EZProxy specifically, but any proxy solution).
I think that vendors more and more are providing their own WAYF, which then causes their SP to communicate directly with the local institution IdP. I think that’s the right way to do it, and I think that’s recommended by one of the EZProxy best practices recommendations I can never find. But that still requires some consistent branding for the vendor ‘login’ functionality, so users can recognize it as available applying to them. (That’s also a recommendation somewhere). And WAYFless login, where we redirect to the vendor with a URL param that tells them the IdP they should use for login, is another way, although with the same problem that the user has to be coming from a link on our website for it to work.
I can think of no better solution than this type of Shibboleth workflow, with improved UI. The main problem with it is just the difficulty of supporting Shibboleth for both libraries and vendors. (Especially for libraries, especially say a public library — which typically has no institutional identity service other than it’s ILS — wouldn’t it be nice if ILSs out-of-the-box no-extra-charge provided a Shibboelth IdP based on the ILS patron database, for libraries in this position? Don, if OCLC offers an ILS product with a patron database, that’s one thing you could do.)
If the Shibboleth solution caught on completely though, there’d be much less need for EZProxy. EZProxy is a proxy. You don’t need a proxy anymore if you’re doing Shibboleth. That’s really my point. EZProxy’s WAYFless login redirecting capabilities are kind of incidental, and if that’s all we needed, we could do it with simpler possibly free software. But it’ll probably be a long long time (if ever) until that state is reached.
I am trying to implement Shibboleth in a research library in India. Is it possible to implement Shibboleth without a Federation? I am through with the testshib and want to try access an SP. When contacted Science Direct I got a reply that I should join a Federation. Please help me.
It is possible to implement a Shibboleth Identity Provider without a federation, but it may not be possible to get Science Direct to auth against your Shibboleth directly without a federation, I am not sure. I don’t know the details, this is def not my area of expertise, either technical or the ‘business’ issues. I am not sure where else to go for help; are you familiar with the code4lib listserv? You might try asking for advice there.
Prepare for a lot more traffic on this post of yours. OCLC just announced they’re ditching the one-time fee in favor of a *yearly* one for EZProxy.
Yes the price now is $6,500 USD for initial purchase plus $650 USD/year. How much was it before ?
ezproxy was $495 one-time price in 2006 and was supposed to have permanent upgrades for free. OCLC has now said that version 6 with WSkey will cost $495 annual subscription.
Still IMO a reasonable price for the value we get from it (it’s _essential_ to the way we provide user workflows for licensed resources in the current environment), and reasonable compared to other library-sector enterprise software.
What I think is arguably unreasonable is to keep paying every year with virtually no maintenance or improvement. Not so much as an issue of price — all successful software is a living organism, and we can’t afford at any price to keep using software that receives no development attention. Our users deserve better UX than they are getting, and a better thing in the EZProxy role is part of this.
My musings about a potential direction for an open source replacement based on nginx: https://bibwild.wordpress.com/2017/03/03/idea-i-wont-be-doing-anytime-soon-of-the-week-replace-ezproxy-with-nginx/
Hi, I am a librarian from Management & Science University, Malaysia, my library is using RemoteXs much like a hosted EZproxy system but from different publisher. http://remotexs.in/remotexs
I find it since it’s cloud based and the publisher setup everything for us rather than through vendor.