How did you deal with suppliers which were slow to adopt federated access management?
Typically if the vendor could support a SAML connection, we would do a “one to one” connection between OpenAthens and their system. Failing a vendor’s ability to accept SAML we would fall back to a proxy-based solution. In a number of cases we were willing to “go first” or “go early” with tech support as they were familiar with at least the term “Shibboleth” but were not making the connection to SAML. So the terminology if Scott was talking to a vendor was frequently SSO > SAML > OpenAthens, which is similar to Shibboleth.
Do you think those vendors really saw the benefit or simply do what customers ask of them?
Hard telling. Some had IT champions that were really excited about moving customers to SAML vs. IP/Proxy, others were happy to do whatever we wanted.
Are Millersville aware of RA21/Seamless access? Were the vendors you 2. spoke to?
Yes, Millersville is aware of RA21/Seamless access. That particular term was not invoked much (if at all) to avoid confusing the conversation further.
Why does IT not need to know? Will that ever change?
I think IT not needing to know was in reference to “IT not needing to know with whom we have connected to OpenAthens; only that IT needs to connect with OpenAthens.” One of the huge benefits of OpenAthens and the catalog of resources (along with reporting and a logic layer) is that Millersville does NOT need to ask IT for anything specific to any vendor.
Part of the strategy to let IT know how exhausting this could be (setup, administration, overhead, maintenance, reports we’d be asking for, etc.) was to let them try and make a few SAML connections with vendors. Days and hours later after the first two … “how many more to go?” Only 90. I then brought up “there is this service that costs X and can do A, B, and C for us so you don’t have to” ….
Here, have some money, now get out of my office. The further IT stays away from our content providers / publishers the better off we probably both are.
At Millersville, and several others of which I am aware, Library SAML connections are handled with OpenAthens, and “university” services are handled via InCommon (the North American identity federation). And while that isn’t “optimal” per se, it does provide a very clean line for not trampling on each other from an administrative perspective, and there are not at Millersville THAT many points of obvious overlap between “Oh, I want to check something with the Bursar’s office via our Student Information System and then seamlessly move to the Library.” That situation is two logins, but they LOOK pretty similar so it’s an extra step, but pretty straight forward for users to understand. We know each other exists, we converse when we need to, but we don’t ask too many questions.
May be too complicated – but with the 4 school options in the WAYF – does OA have the ability to setup a URL that will use a specific 1 of the 4, so that when you as a patron are on the portal page for a specific university, could we just offer up that direct link without the need to go through a WAYF? I think I’ve asked this before and was told not yet possible?
Not at this time. The way this works is if a URL is pointing to Millersville University’s OpenAthens entityID, it is pointing to the settings configured therein – to reference four unique Identity providers. That said, OpenAthens’ development and enhancement work is heavily influenced by library feedback, so enhancements like these are under consideration for future product changes.
Is it possible to set user attributes within the OpenAthens admin interface for eg students from partner institutions, rather than rely on IT to set appropriate attributes in AD?
Answer from Scott: It could be, but that’s insufficiently granular for the purposes of providing access by program; status as a “student” would be too broad. And it would be a whole lot of manual work on our part – which is to be avoided at all costs.
Essentially, history and experience with the institution has shown that manual approach to be unsustainable and if the university does ask something like that, the library’s answer is no (even if technically possible) because the library is not the arbiter of who is or is not affiliated with the university, that is the university’s job, not the library’s.
While that is a hardline answer, it does nearly always result in a better systematic solution. In addition, Millersville does not actually know/track who the partner institution students actually are. We rely upon the partner institution to keep track of those students (yes, we take their word on that) and they signal to our OA who those students are (or are not) by including specific attributes. No attribute, no access; If attribute, please proceed to the Millersville library.