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.