- [ Resources ](/resources) Share- [ ](https://www.facebook.com/sharer.php?u=https://about.ebsco.com/markdownify/node/163176) - [ ]() - [ ](< http://www.linkedin.com/shareArticle?mini=true&url=https://about.ebsco.com/markdownify/node/163176&title=Breaking Barriers to Accessing Knowledge with OpenAthens&summary=&source=>) - [ ]() ## Breaking Barriers to Accessing Knowledge with OpenAthens [Webinar](/taxonomy/term/5178) | Original broadcast date: 11 February 2026 Discover how a modern approach to authentication can eliminate barriers to knowledge access and transform your users' experience. We explore: - The most common myths about authentication. - How to differentiate between proxy/IP and SAML. - Best practices to offer secure and frictionless remote access. - Real-world stories from institutions that have adopted OpenAthens. - Live Q&A with OpenAthens customers and experts. #### Transcript | [ Download ](javascript:void(0)) ### Breaking Barriers to Accessing Knowledge with OpenAthens Ref Link: https://about.ebsco.com/markdownify/node/163176**Emma Freeman** Welcome again, everyone. I'm going to kick it over to James Edwards, international sales manager at OpenAthens, to introduce our guests and get us started. So take it away, James. **James Edwards** Yes. Thank you, Emma, and hello, everybody, and thank you for being here. So my name is James Edwards, and I'm a senior business development manager at OpenAthens. I've been with OpenAthens for, nine years, I think coming up to ten years now. And, yeah, my role is really to help in institutions, organizations understand authentication specific to that sort of library and research space and help them overcome any issues or hurdles they may have and that give that understanding of what OpenAthens can can bring to an institution. And with me today, I also have, Matt and Mike speaking. And so, yeah, Matt, if you'd like to introduce yourself a bit more. **Matt Van Ast** Sure. Thanks, James. My name is Matt, and I'm a system architect at the University of Guelph. And we implemented OpenAthens in summer spring and summer of 2024 switching from EZproxy. **James Edwards** Thank you, Matt. Yeah. And Mike? **Michael Purcell** I'm Michael Pursell. I work at the Totten Rivers University in Kamloops. And, like Matt, we just recently implemented, OpenAthens last year, as part of a migration of everything, iOS, authentication system, you name it. So it all happened at once. **Matt Van Ast** Thank you. Sure that was fun. **Michael Purcell** Yeah. It was dicey. But it worked that great, but it was a lot of work. Yeah. **James Edwards** So this session is really going to be about exploring some myths about IP and proxy and federated access and things. So we've got, like, five myths lined up where we're going to, you know, have a discussion about, but just to really give a nice base understanding of OpenAthens and what it is and how we break barriers to knowledge, is just explaining the product, you know, in just very overview, give it a nice overview of the service. So you'll hear a few things today, single sign on being one of those. With OpenAthens and what we're talking about there is true single sign on. So we're talking about users using one username and, password to access all of the library's resources. So there's no logging in multiple times, but with the same username and password, it's one login once, and then they get access to everything once they stay in that browser. That's obviously a really good user experience. It might be something that you don't currently offer. That's a really nice thing as, a nice difference with it. But, also, there's some uniqueness to open admins around federated access that we'll dive into that gives a real nice, better user experience. Because at the end, really, what this is really focused on is your users, whether they're students, researchers, faculty, whoever they are who's trying to access that content, can we make that as easy and straightforward for them? So we are removing barriers by removing payrolls, removing clunky software, all of those sort of things. And this will certainly come up, the complete solution. Today, we are talking IP, proxy, and SAML. OpenAthens does do all of those, which is one of the mess later. So I kind of already, got we've given that one away already, but it is a complete solution that does all three, and we will explain that in a bit more detail coming up. And, really, I think this is one of the core ones that we don't cover today, but at this core of what OpenAthens does and the way it works, it is privacy preserving. There is no need for, you know, a person identifiable information to be sent out there to vendors for this to work at its core functionality. None of that's needed. Your users' privacy is protected. So that's really just a really brief things of covering what OpenAthens provides as a service. So let's bust some authentication myths, and this is really out there. So do you know your proxy from your SAML? So for myth number one, that's what we'll start with is proxy IP recognition is just as secure as federated SSO. So I'll just, yeah, give a little bit on this. I mean, what we're talking about here is actually sort of two methods of recognition and authentication. They ask actual different things. With IP recognition, obviously, you have an IP address. It's location based, and you send that IP or you give that to a vendor. And if someone tries to access that ticks from that location, but it's not actually user. You don't know that user specifically. Federated SSO is using SAML based, offend which is a a standard that is built for authentication needs, and it uses various different things in order to make that authentication process. So I guess, you know, before jumping into that security side of things, maybe if I throw it over to you first, Mike, if you're happy to answer this. You know, was security a thing that came to your mind when looking at OpenAthens, and were you moving from an IP solution before that? **Michael Purcell** We were moving from an IP solution. We used to use EZproxy and, you know, it served us well, but it was coming to the end of the slide. And there was definitely more security problems with it than we have with OpenAthens, which is none. I was regularly getting messages from vendors of people compromised login credentials, which meant I spent a ton of time looking for EZproxy logs, you know, blocking an IP address, notifying our IT department about the compromised stuff. And so it disappeared. And then, yeah, in this one area, we're very, very happy with OpenAthens. **James Edwards** Yeah. Matt, do you have anything to add to that? **Matt Van Ast** Yeah. So we switched we had EZproxy. We did have federated SSO in front of it, but it was still proxy-based recognition between the vendors. But before we put federated SSO in front of it, it was a location based. So if you're on campus, you could get access to it. So that was always an issue because you can never like, a library's a public building, so it's public access. You can't really control who's coming into your building and who's accessing your resource in some of those scenarios. So we definitely had a lot of IP blocking for a period of time. And then once we put federated sign on in front of that, that greatly reduced it. But, again, we still had it open when it was on campus, so that was always a problem. And now with OpenAthens, it does require authentication every time. At least that's how we configured it. You don't have to configure it that way, but we took that opportunity switching systems to just say you're going to authenticate every time for that at least once per day because the cookie session can last up to eight hours. But you authenticate once if you're on campus or off campus, and it's made things a lot smoother for us. **James Edwards** And I so, I mean and I think, you know, if you're if you ever cross come across IT and, you know, you use authentication methods in the wider IT environment, IP really will be used. I mean, as I say, it's not actual authentication. It is a sort of recognition side of thing. SSO, you identify that individual user as match touch you know, touch on that. You know, you with an IP, their former location, but you don't know actually who that user is and should they actually even be on that location. I think, you know, it's a little bit of an easy one maybe on this one, but, yeah, I think it is clear to say that, you know, federated SSO is built with kind of security in mind, and it's what many other systems use, you know, single sign on Microsoft. You know, a lot of them are using that SAML based, a substandard in order for that offend authentication stuff. And so moving off of that IP, you know, you are going to we should see that drop in perhaps, you know, issues that go on. And it also comes down and look, I think we'll come onto this as well, that user role based. That user-based authentication is key because they can a vendor can block a user. They don't have to block an IP range. And so, yeah, you kind of have that more ability and more uptime for the rest of your users. And I think, you know, we might have seen this come across some vendors already. The vendors are choosing to not accept IP anymore as a method of access. You know, I think, you know, as an industry, we are we've we all accept IP largely in most cases, so it still is the normal. I mean, most traffic goes via an IP, whether that is a proxy system or not, but some vendors are now saying, no. You know what? We need a SAML or something based authentication system, not IP because it protects their content as well at the end of the day. So it's about protecting yourselves and protecting the vendors who and their content that they're offering. **Michael Purcell** So If I could just jump in. One of the things is the security related that that drew me to it is there's a lot of expertise out there, which I don't have. I'm a librarian, not a not a programmer. So I'm very happy with the security part because it's actually a lot of it handled by our IT department. We're much more knowledgeable in it. So it that's that was a big selling point for us. There was a question here. Are you supporting our affiliated walk-in users? Our institution, unlike said, are mass where you have to log in, we have IP recognition pass through. So if you if you log in and you're in the IP range, you don't see an EZproxy login sorry, an OpenAthens login in campus. That doesn't work for our guest users. But what all we do is we create a guest account for them, and the library technician will log them in and then log them in to get access to the online resources. And it's a very easy workaround with the smaller number of people we get from the outside. **James Edwards** Yeah. I think there there'll be an element of that later we can cover about, yeah, the multiple methods of access using. But, yeah, it we understand there is that need sometimes for that on-site IP access still because it's the norm. It's what we're used to. It's what the industry has sort of grown from and on. It's just whether that is the right method is perhaps the question that needs to be asked at times. But, yeah, we can set that up and stuff. Thanks, Mike, for answering that. **Matt Van Ast** I'll briefly address that walk in question as well. We do support walk ins since we switched to OpenAthens. And similar to Michael's, it's a it's, like, an auto registered account. So if they're accessing our login page from on campus, it recognizes that they're on campus by IP, and then it prompts them to register their email. And we actually handle authentication with OpenAthens via API. So all our authentication is external. So they register their email, and it automatically creates an OpenAthens account with that registered email, and they're sent off to the resource. So we have a kind of a our federated SSO is handled by us with our institution, and then OpenAthens has their federated SSO with the vendor. And it all plays nice. **James Edwards** Yeah. Yeah. It is. Yeah. I'm trying to replace just using that IP to maybe add these other options, and thanks, Matt Mike, for explaining that there are ways to, you know, keep that same kind of user experience and where a user can you can still offer your content to people who aren't perhaps already registered. There are ways to make sure they can still get that content. So, yeah, I think for the first myth, I think we're comfortable with Sarah, and we covered there that, you know, it's busted that that actually, you know, SSO, federal SSO is a more secure method of access if we're going down that that option for authentication. Another key one, and this is quite an interesting one to show, you know, because it there is difference in user experiences around this. And so myth two is users prefer proxy IP recognition for its simplicity. So, you know, we're first of we're talking users here. We're end users, really. And for them, do they know what they're using? That's first thing. They probably don't have a clue how any of this works anyway. But as we've touched on there, IP recognition is fantastic for a user to turn up somewhere, click on a link, just get access. There's no login. It's just, you know, how that's done and how that's managed can be a bit is a bit different. So do users prefer that? One, they probably don't know what they're using, but that is probably a user experience they would like. Yes. It's just whether it's relevant in today's world. How does it work in today's world? And then with proxies, obviously, there's the login process going on. You might have VPNs for remote access because once we get to remote access, IP really does start to become a bit more complicated and not as user friendly. So I guess, yeah, Matt, perhaps you first. Do you know, have you noticed any changes in user experience? Was there, you know, any feedback you got from a change to OpenAthens? Anything you'd to add to this myth? **Matt Van Ast** Yeah. So similar to, like, it's this kind of goes off of your remote access thing. So users might sometimes prefer the IP recognition because, yeah, they get to campus and they click and they're good to go. However, it can really lead to staff and patron access confusion. You have a lot of example scenarios where a patron can't get access, and then you're trying to explain to them, well, were you on campus trying to access it? Were you remote? What link did you click? What system did you click it from? Do you have a bookmark or a Zotero library? There's all these things that you're trying to figure out what do they did. So we had all these scenarios for a while, and it's gotten a lot better once we started to force that, authentication and just say, your workflow is going to be the same no matter where you are. You're going to authenticate, and then you're sent off to the resource. So it's really streamlined our troubleshooting. And with the federated SSOs, we use Microsoft 365, and it's a seamless login experience between all our enterprise applications across the institution. So they log in once into one system, and then they maybe only have to click a link, and they won't have to multifactor authenticate again. It remembers their cookie session and everything. **Michael Purcell** I would jump in and say that the users definitely like the IP on campus, the push through. But an interesting story, as we were implementing changeover, we had OpenAthens turned on actually late 2024. We weren't promoting it. This was tied into our FOLIO migration. But looking at the logs, people were using OpenAthens to get into resources out on the Internet without a single piece of publicity that was even there. It's very intuitive for them. So they would obviously apparently go via a Google search, end up end up at a publisher's page, log in to the institution. It's all very intuitive. It uses the same login, as Matt said, as the rest of campus. So I the simplicity, obviously, is there, and people are taking advantage of it before we even told them this new service was available. **James Edwards** Nice. Yeah. And that's definitely one of the things I would sort of pick up on something that I often, you know, talk about when we're introducing sort of a federated SSO OpenAthens to institutions who want to know more about it is what is the impact going to be on the end users? And, largely, you know, as you've touched on there, Michael, you don't have to promote that you're using OpenAthens, really. It should fit nicely and seamlessly into their kind of journey right now. The only difference might be is if they were used to IP On-site, they might now have to log in, or they would then have to log in. But, I mean, how many services do we log into these days? And provided you've got that SSO set up, it should be, you know, still a very pleasant user experience. But, yeah, one of the key things there, though, that they do benefit from is now they can log in at the vendor platform. And Michael said that they can search their institution, log in from there, take them to the login screen, however it might be. Use it to your standard institutional login screen. It's something that will be familiar to them. And, yeah, as I say, straightforward, something they'll follow without having to have any instructions or guidance to do. And that's a lot of the seamless access movement you kind of you may have heard of out there, where vendors are trying to make this more standardized across their platforms because we appreciate every platform vendor can be different to log into, but we're hoping to have that standard institutional login button, and so it's a very same experience. And the second one there, which I often touch on as well, is because, it can identify an individual, users can make use of personalization offered by these vendors and these platforms. So, you know, EBSCO accounts, Elsevier, often all of them, you can have, you know, clinical key. You can have your own personal account. And not only will OpenAthens log users, authenticate users into the platform, it will also log them into their own personal accounts that they have that they've been set up. So they don't have to remember, oh, what was my password for this site for that personalization box? And so that's a nice just sits in into their user experience and make sure that they also are then getting the most out of some of the functionality that these vendors offer. Yeah. **Michael Purcell** If I can jump in again, one thing about personal accounts, especially in EBSCO Discovery. It's a problem we used to have. It doesn't exist anymore. People were confused about that personal account login, and it's all gone away with OpenAthens. Plus, it provides another area of us for instruction. There's a lot more you can do with that personal account. But now that it's easy to use, we've got a lot more options in how people can use EDS. **James Edwards** I was going to jump on that unless you had anything to add to that. That's fine. **Matt Van Ast** Yeah. With regards to the personal account, this is, like, the automatic account creation when, you know, you sign into a resource that's supports federated SSO. Yeah. I was going to talk about it on the next question, but I can, spin it up here is we actually went the opposite route for Guelph. We don't release any attributes to, any of the platforms. And one of the reasons was some of them, sorry. Just looking it up here. Yes. So some prompted if you were doing a federated, access to them, they prompted a local account creation. Like, it didn't automatically create it, and we didn't want to, like, force that on the patron. And because it wouldn't take you directly to the resource. It would, like, say, hey. You should you should have created an account. And we didn't want to force that on the patron, so we swapped that to be a proxy access resource. We didn't want it to be federated partly because a lot of our patrons might already have accounts not associated with their actual institutional accounts, so they would lose all their previous, bookmarks or whatever that resource is tracking. So it'd be forcing them to have another account that they don't regularly use. **James Edwards** That's no. Yeah. Certainly. And that is down to policy for processes you want to take. And, yeah, there are different ways of approaching that. But yeah. So thanks for giving those two sort of examples on that. But, yeah, it's at the end of day. It's the users, how you want to, you know, give them to them or protect them because some yeah. Sometimes they pop up screens. It's not high for user. It's going to be one thing. But thank you. I just see there's a couple of questions in there. So, the one about ProQuest that eBook Central does not support OpenAthens. Can you I'd have to find out ProQuest does, and the platform does support OpenAthens. So eBook Central specifically, I'm not sure in which way maybe that's not being supported, but I would have thought that, but I will have to find out definitely because I don't know any information **Matt Van Ast** I might know what they're talking about. **James Edwards** Yeah. No, please, Matt. Yeah. If you've got that. Yeah. **Matt Van Ast** So there's this thing I'm going to be talking about it, like, at question five, but it's called special linking. So there are certain vendors that don't support the OpenAthens redirector. So, like, there's a standard redirector tool that formats the link. So it's like go dot OpenAthens, similar to how you prefix a proxy on, like, EZproxy. So the majority of the resources worked fine using the redirector option. However, there we found when we implemented, we had five or six vendors that had special linking. So you have to put in, like, customer parameters into the URL params, and then that tells it, oh, you're authenticating by Shibboleth or SAML, and then it fires it off to OpenAthens that way. But the redirector itself didn't work. So we have, like, a whole other like, a workflow around how to handle these special linking customers. **James Edwards** Yes. There might be those user unique cases now. So I think we will touch on linking a bit later if you said. But yeah. Sorry. Anonymous there can't give you much more on that, but, yeah, hopefully, that's something. **Matt Van Ast** We have ProQuest, and we use it with Open Athens. **Michael Purcell** With Open Athens. Yeah. So do we. **James Edwards** What I'll do is I'll I'll hopefully towards the end, I'll put in the chat just some links to some additional information just so you can go to places to find out some of this stuff as well, directly. And then also, Chris, there, you've mentioned a question on, about login fatigue and the eight hours. So that is set, but we do have perhaps the way to maybe change that in, or development to maybe change that in the future. But at the moment, that is the rule that is set within OpenAthens for all customers. What I'll do is make sure that is, again, fed in, that this is a question for the development to maybe proceed that ticket. So I'm just going to jump into the next question, and we're going to see if this question we got time because I'm worried about time on there. We want to cover everything we have in the in the webinar itself. So that myth too, believe yeah. Busted that in terms of, you know, do they well, users don't really know. But when it comes to remote access, which is most access these days, you know, you want to move away from your call IP doesn't work remotely unless you're using a sort of a proxy or perhaps a VPN, which is not usually a very good user experience. So this, you know, quite a big one then. So proxy IP recognition provides better access control. So this can be full of in many different terms of, you know, access to who, access to what, for providing that control. And I guess, you know, it comes down to IP is really location based, whereas federated can also, you know, do control down to that sort of individual as its user-based access. I guess, Matt, if you happen to go first, do you have any, you know, controls that you use around this that you've, you know, been better handled since OpenAthens implementation? **Matt Van Ast** Well, that statement certainly is not true that IP recognition provides better access control. So, yeah, we used to have vendor blocks, like I said before, when we were more open. And since implementing, we've had none. No blocks at all. Because that means resource like, platforms can't really block the OpenAthens IP because they would block every entire customer that they have. So they're going to resolve it really fast. So, yeah, a big thing to understand with the federated configuration, I touched on it briefly before, is the vendor doesn't actually have to know who the patron is with the federated SSO. It can be configured either globally or at the individual resource level if any specific user attributes are released to the vendors. Otherwise, it is they it's like a shared hash token that they get. It's kind of similar to Apple or Google's hide my email when you use their systems to authenticate into something else. Just yeah. That's the big one. **Michael Purcell** We don't we as a policy, you know, we share very little information with the vendors. So mean and we didn't do that with EZproxy either. But there are more options in open access to do that. And I just don't agree with that. That they provide IP recognition provides better access control. That's just not true. **James Edwards** Okay. Yeah. And as you touched on that, there are controls within these of the OpenAthens, which can go down to permission setting as we call them where you would release attributes to us, yeah, to control that access to various platforms specifically. So a law school within a university would have law content just for its law students, and OpenAthens can give you that access control to make sure when it's only the law students that will access that, you know, in the in the, in that content. So, yeah, I think that's a clear one that, yeah, it's definitely yeah. It's not, it's busted on that one. Federated access will help you get that more access control. **Matt Van Ast** Yeah. There is, I'll just jump in. There's ways to configure OpenAthens for, like, per permission set access based off of attributes that you can provide when you authenticate your users. So if you do have access to user groups like staff or students or department level things, you can really play around with how strict you want to get for access levels. **Michael Purcell** Definitely. We haven't gone there yet, but I could foresee a day when we do we typically, up till now, get a database expected everyone should use it. That might not always be the case, and OpenAthens could work with us around that. **James Edwards** Yeah. And on that part, I mean, all I would say is it particularly I mean, I've got to go too depth into how you might set up OpenAthens, but on both situations here, we have that local directory connections that Microsoft has mentioned. And, yeah, we would need those attributes from that system in order to create those permission sets in a nice auto autonomous way, so your users fall into those groups correctly. And, yeah, attribute release is a key part of that. It's just it has to come from your directories. But most cases, I'd say a lot most institutions do have that blanket. Everyone can access everything. But, yeah, then with OpenAthens, it gives them that functionality to think about, actually, do we need to offer that, or can we, yeah, offer content for specific groups here and make it up on varied cases. Great. So, yeah, so moving on to Myth four. Said there are some questions. We will come on to them, hopefully, at the end. Yeah. Yeah. Got time there. But we've got Myth four here. So proxy IP recognition is easier to manage. Now if there's something I've never had to manage, an EZproxy system or, just using IP access. Yeah. Has the management of the system changed since the move to OpenAthens? Michael, would like to go first on that one? **Michael Purcell** There's definitely work in managing a system like EZproxy. It is easy to use. That's why it's popular, and I don't want to slam it. But it was work. You've got to constantly update your the stanzas, which is a configuration for each vendor, configuration changes for a lot of if a vendor changes a server, then we got to go change the stanza. It was work. I I'm not going to say it was wearing my fingers to the bone on it, but know, it was work. And I was like, god, you have you have to maintain, and that workload is much lower now. **Matt Van Ast** Yeah. The admin interface is certainly a boon to work with compared to other proxy systems. And from a like, it's the easier recognition. Like, IP recognition is maybe easier at first for the initial setup. But if you have the IP of your proxy server, if it has to change due to, like, server maintenance or, like, hardware or software upgrades, that's a very large project. We went through that where we had to update our local IP with every vendor that we manage. So we had to reach out to three, four hundred platforms to be like, hey. Our stuff's changing, and you got to coordinate that. So that was a lot, and that wouldn't happen in this but if in this particular instance if it's with OpenAthens. **James Edwards** Yeah. I'm happy to sort of share a bit more about that, why that would be different with OpenAthens. And so, I mean, we already touched on kind of there is IP proxy IP used within OpenAthens. There is a man OpenAthens managed proxy service as part of OpenAthens. But predominantly, when we're talking OpenAthens, we're talking federated SSO. So it's SSO using SAML. You would come across all the time. There's a lot of what we call one to one SSO. So that's one connection to so it's one vendor, one connection, then you just make it like that. There's work involved in doing that, but they would also need updating. And this is where the federation piece comes in where with the federation, you've all joined as a shared trust network, and you're all sharing that metadata altogether. And so when you need to make a change, you just update it in the federation, and then it goes out to the other federation members that you are connected with. And so there isn't that need to, to acknowledge everyone individually. That does come up during onboarding. You know, there is that big switch. In most cases, you know, the outreach will be done by who by EBSCO or a partner or OpenAthens in order to make those changes, but that's on onboarding. But when it comes to changes and then that management of it, yeah, it's all done sort of more centrally. And when it comes to a proxy change, that's the OpenAthens again manages that also. There is no more stanzas or anything like that to do within the service. And I think, you know, as we're seeing more and more now, IPs are not set as they used to be. It used to be you have an IP; it would stay like that. But more and more, yeah, IT are introducing sort of dynamic IPs that constantly change, and so they have to come up with perhaps unique circumstances for the library in order to maintain that IP access. So, yeah, I think, yeah, as said, it's not, easier to manage, Voice IP federated, so it has certainly helped with the management piece of that. So then moving on to the last one here, and then we can jump into the questions. So as we have covered this a little bit, and I think, Matt, you mentioned you've got something you like to add to this is you can't have both proxy IP recognition and federated SSO. So, yeah, OpenAthens can still allow you to adopt IP access directly on-site, although none of that traffic will go for OpenAthens, so you will miss out on reporting and usage of that, and the management side of it. We do have a managed proxy IP service, and we have the federated service. And the reason why we have that managed proxy part is because a lot of vendors out there just don't have the technology to work with, with SAML federated access. So we wouldn't want you to have two solutions and two ways of managing all of this. So we manage that all centrally. But for a user, they don't know how they've got there, really. It's all still very seamless. It's the same way, and we'd like to try and make sure that's as simple as possible. So, yeah, Matt, I think you said you had some things you wanted to talk around this. Anything you'd like to add around this sort of myth? **Matt Van Ast** Sure. Yeah. So you definitely can have both resources configured. It could be federated or proxy access or even both. The way that OpenAthens deals with that is the redirector links. So when you use a redirector link, it tries to use the federated option first. But if that's not configured, it uses the proxy option. For a scenario where you have both configured for the same resource, even though there's no real reason you would do it, it can be done, then you have to link directly to the proxy URL. And you can get that from the admin interface, and then it gets the users proxied. So then this is that scenario where I was we'll say that while talking about the redirector, there are a few resources that require special linking, as I mentioned before, and they don't really work with the redirector. Like, they won't prompt for authentication or it doesn't get to, like, the end target. And then I think EBSCO generally provides you I think they provide you with a list of customers that or vendors that are known special linking people, but you find it during implementation as you're testing. So you have to link with these special URL parameters that they provide you as a customer. So this led our institution to create our very own link generator application that resides on our main website, and this handles all the special rules. So we obfuscate the complexity from our staff, for all the rules. So they put in the resource link that they need, and it spits out the format. It's either a redirector link or it's a special linking. And then that's the link that they put into, like, a course reserve system or, like, a guide or wherever they're storing external links that they want to send patrons to. So, yeah, that's one of the big things I wanted to talk about. **Michael Purcell** We had an overlap from EZproxy open at once. We're both running at the same time, and we had an orderly, you know, shutdown one and the other. But you they could definitely work together, although I see no reason to do so apart from the implementation phase when everyone's going to change all over the website and web presence. But as soon as you can, I would recommend just going straight to OpenAthens because it can do everything? **James Edwards** Yeah. And that's I mean, we I think it'll be around for a long time that IP is still going to be used. Really, it'd be more proxy, just proxy IP then. It's just because of these vendors, these platforms. You know, some of them, they're not large. They don't have big development teams to adapt to these new, you know, authentication systems. And so although we try to promote that, yeah, it's still we want to make sure that there you can still give access, and it's still straightforward for those end users, on that. And, what's looking at as to this part? I've had it's now just escaped me. But yeah. So I think, yeah, that's you know, on that last one, you know, you kind of both bust that. Yes. You certainly can have, both systems, running side by side. You can do it with OpenAthens. Sometimes you might just, you know, keep eye on-site IP going, as I mentioned. But the only, you know, issues you start coming around then with that is you're going to have different user experiences, which we touched on at the start, and that could be confusing for end users. So maybe bringing them all just to one same experience across the board really works well. And Matt talked about, yeah, the linking. The linking is difficult. It's a whole separate topic. I'm ready to talk about some of the linking. We try to make it as straightforward as possible with our redirector, and but there are always unique cases, some vendors where it was not quite a hundred percent working with that. But we do want to try and make it as straightforward for the librarians themselves in order to put a link up that is going to be that one. You have to worry about whether it's a proxy resource or a federated resource. The OpenAthens redirector is going to pick the right choice, the right option for it. You don't have to have a separate link just because it's the type of resource. Yeah. **Matt Van Ast** And the linking issues are not anything OpenAthens related in a sense. Like, we had weird linking rules and problems in previous proxy-based systems as well. **James Edwards** Good. So, yeah, we had a couple of questions come in. I think we've got time for them. So, yeah, if you do have any, please put them in the q and a, and we will try our best to answer them. And so we've got an anonymous one. Can you use open Athens for direct access, I e, for vendor login page along with proxy IP recognition, i.e., from a to z list discovery layers, etcetera? It sounds like yes based on what Matt is saying but just verifying. Yeah. I think it was yes. You can definitely you with OpenAthens, if it's a proxy resource, it's unlikely to have an institutional login option at directly at the vendor login page. So vendor login sites are often those with institutional login options are often federated sites in particular. And so, yeah, it happens a lot that way. A lot of these EZproxy IP recognition, so I'm not sure how you're interpreting that in from the x zed, but, yes, both will work at the same time. So it doesn't matter how a user gets to a vendor, whether it's from the library, a zed list, discovery service, or directly, OpenAthens will work with whichever way the user's trying to get there. That's how I interpret that. Matt, did you have anything? **Matt Van Ast** It's kind of how I interpreted it as well. Your statement's correct. Like yeah, you'll figure it'll some sort of some form of authentication will work fine with OpenAthens. It's just yeah. There's different options available, I guess. As you implement, you find them. **James Edwards** Good to know. I have question here from Chris. With the rise of AI bots, Cloudflare has gotten much more strict about trying to block suspected AI activity. This unfortunately ends up blocking EZproxy, which requires the vendor whitelisting our EZproxy IP. Is this what you mean about having less vendor blocking when using OpenAthens? Yeah. Matt, Michael, I mean, that's… **Matt Van Ast** I mean, it's certainly part of it. For sure. That is a big part of it. Yeah. So that won't happen with OpenAthens because you are required to authenticate. Again, if you configure it that way, you can configure it to be open if it's on campus, in which case you're going to run into the same problems Because there are systems out there that can spoof IP addresses, so then it maybe it does look like it's coming from on campus, which is one reason why we forced authentication. So it completely stops that scenario. But you can do that with any proxy system, forcing authentication. **Michael Purcell** Yeah. We haven't had that reflected in that question ourselves. **James Edwards** Yeah. Just to explain a little bit on that. I mean, so this would be for, again, federated vendors and, you know, so we you would know which ones were federated and which ones were still using the manage open access managed proxy for it. But those that are using that that the federated group, the reason why it changes is because what we're sending to a vendor to authenticate that user is like an entity ID scope, and there's a unique identifier, which is unique to every individual. Now, again, I'm a stress. It's not ident person identifiable anyway. It's just unique as a as a thing. It's a so it's bunch of codes, but it's just for that individual. So a vendor, you know, when they want to switch off any suspicious activity, they have that identifier to be able to switch off that individual rather than just the IP address, which would that's what they would then have to block. So that's where, you know, you they can just block that individual from misuse, and then everyone else can still get access to that platform. And so we're not saying that, you know, there's no still no stoppages. It's just the vendor can actually be more specific about who they block that access to and help you to identify that user. You can go back through and find out who that individual is if required. The vendor can't because they, I say, they actually know who that is as an individual. So, Chris, I hope I hope that's helped there. Can you talk about log file access and any supported analytics views? Oh, let's just move from there. And I took views of those logs such as the analytics dashboard. So I haven't planned to show that today. Again, we can follow-up with demos and demonstrations of it and links to where you can see it. There's obviously different sorts of reporting usage OpenAthens give. So we do give a lot of information on the usage of your users and what they're accessing. In terms of logs of activity, that's you know, there is administration logs of sorts, and then it has how far you want to go with that. You might have to ask the team specifically to give you some specific other logs on that depending on the information you're after. I guess, yeah, Michael or Matt, do either of you use the reporting or the logs in particular that you're going for, you know, that you look for in OpenAthens? **Matt Van Ast** Yeah. We use some of the analytics stuff. It a lot of it depends on what attributes you use when you create your user accounts. Like, so we track, like, a user group. So if it's staff or student or faculty and then department level, like, department they're in. So you can get some interesting information when you look at that. Like, people in engineering use these, you know, for resources and, like, nothing else or something like that. There's not really log files. You can track down, like, access points by user, like, maybe, like, last time they were logged in or, you know, the resources that they're going to. But there's you're not troubleshooting like you do with EZproxy, typically. **Michael Purcell** I can I can speak to that? The only time I look at log files was for troubleshooting and which I had to do free EZproxy. Not at all in OpenAthens. There are there is a good analytics dashboard, though. And if you choose as Matt's institution does to break down the logins by group, there is information about it. We have chosen not to do that. So it's basically use counts for every database. But if you want more elaborate statistics, you can get them. **Matt Van Ast** Yeah. I mean, with EZproxy in particular, there was no statistics. Right? You have to generate everything from, like, a log file, basically. So we've used it just for, like, trends. Like, one thing that we find interesting is at our institution, no one accesses anything until one PM. It's like one PM to midnight is when people do stuff, not before. **James Edwards** No. Thank you. Yeah. I have to say that the reporting, there's a lot on that. There's a lot on our website, so you can see more on that. Again, you have questions, then you can please reach out to EBSCO, and they will be happy to demonstrate the reporting module to you on that. And a question here from Charlie and Emma. Please jump in if we are running out of time. But, yeah, Charlie, in your experience, what's the turnaround time for OpenUp and support to resolve access issues compared to being able to do most fixes within the library for EZproxy? So, yeah, so definitely over to yourselves, Matt and Michael. **Matt Van Ast** Michael, you go first. **Michael Purcell** I'll jump in and say that what happens, turnaround is very good. But I would say even though you can fix stuff in EZproxy yourself, you're not always aware of a problem until the patrons report it, at which point then you've got to go around and see where the problem with the stanza was. So I think what happens with open happens is a lot of problems actually just don't appear because of the federation. Whereas in fixing it yourself, you can fix it yourself very quickly, but you've got to find the problem. Some are going to report it to you, and then you got to search the web. You know, OCLC has good documentation on that, but you then you've got to find it and update the standard and restart everything. So I think in that case, OpenAthens. **Matt Van Ast** Yeah. Similar to what Michael says, I think in EZproxy, there's a lot of problems that are just not found or they so they're there for a long time. And then maybe you find out about it months later, and then you can fix it. The way OpenAthens is architected, the issue is found faster that one exists, and then they do tend to correct it within you know, it's probably a couple days, typically. There are sometimes longer ones, but that is typically at the resource level instead of at the OpenAthens level. That can still happen, and that would have still been an issue no matter what your setup is. **James Edwards** Yeah. And I'm just doing some of the support. Obviously, we have ourselves open up and high-level support. But yourselves as EBSCO customers, you know, your first level of support is going to be EBSCO. So there is that joint portal to understand where to go to for that support, and they provide an excellent first, you know, first and second line as we would call it support. And then if anything does then get raised, it will then, you know, make its way up the channels to open Athens if it's something that they can't do. But, yeah, hopefully, you know, the experience from that is good, and, you know, some of we often hear is praised as the support. And I know EBSCO, certainly, they pride themselves on the support they offer there. So another, yeah, question here for, from Chris, and it's probably, you know, a nice important one is, do you, you know, do you have any advice for a library about to migrate to OpenAthens as part of a university system? Matt, do you want to go first on that one? **Matt Van Ast** I mean, that's a big topic. That could that could be a whole other webinar. Yes. I mean, half tech people involved. I think that's a recommended thing when they implement. You definitely want some sort of tech person on the team, especially initially. Try and have an overlap. So, like, have your proxy-based system around for a few months after the fact just in case. We had one we had one resource out of five or six hundred that wouldn't work with OpenAthens, but it was very, very rare that you can't get one to work. So you kind of have to evaluate. Like, we have ended up just not continuing on with it because it was a very low usage resource. So it was just a perfect time to have ties with it. But so all the major ones, we've never had any issues, but you might find something. **Michael Purcell** I could talk about this all day. We just did it recently. Like, as Matt said, it's a it's a huge topic. I would secondly, said make a friend of your IT department. They will have to configure the VP and that's their job. They're great at it. So make them your friend. The second one I would say is communicate this change to your commune your TAMs community early. You'd be surprised how many different people on campus have, like, EZproxy links all over the place that you would never imagine. So develop a process to publicize that. We did have university library on migration team, and her talking to the deans was very, very helpful to get the message coming from the top down, not just off our web page. **Matt Van Ast** We updated our EZproxy login page. So we to, like, provide notification that changes were being made and that they needed to migrate bookmarks and things like that. And then, like, our link generator tool, we offered that as, like, a bookmark option, like, you know, change your bookmarks using this tool. And then we after a few months when we were getting closer to turning off EZproxy completely, we put a big, ugly pop up on our login page saying this service is discontinuing. Update your bookmarks. But, yeah, we really got in the face of patrons, but progressively. **Michael Purcell** Yeah. You have to do that. We set up a page for faculty to report broken links. We would fix it for them, create a new link, send it to them, but they've got to know about it. So, yeah, then it's more of a communication challenge, I think, than a technical challenge. **Matt Van Ast** And, look out for bookmark managers like Zotero, where they have saved proxy information, like, four or five years ago, and it prefixes it. So our system turned off, but then people had Zotero things with the old proxy saved in the configuration. So they're creating new links with nonworking proxy links. **Michael Purcell** Yeah. We still get errors like that, although we've been on OpenAthens for quite some time. We even we publicized the fix to that on the main library page. It was totally unexpected thing. So once again, it's all communication. **James Edwards** Yeah. That discovery before an implementation, some of the things I pick up on and tell them is you definitely get IT involved in some of some of the discovery calls. That's not their IT involvement isn't heavy with OpenAthens. The setup process, really, that it's quite a simple process for them to be involved there. But to give them that understanding of why you're doing this and why you're moving to the system, most will be quite be quite happy on board with that choice as, again, because you're moving further away from IP. But you might want some functionality that's just not actually possible without the ITs involved. We talk about attribute release again. We could talk about this all the time, but it's just to have those things to be prepared in that discovery so you can make sure that everyone's aligned and everyone knows what's being asked. And then the linking and finding the links, that's the that's the big part, yeah, that communication piece that those will stop working, yeah, with the new system. **Emma Freeman** I'm going to pop in and give us our five-minute warning. So I think we could maybe get through one or two more questions just to keep that in mind. **James Edwards** Yeah. Thanks. Yeah. So I have a question here. Does OpenAthens talk to the existing in common default SP profile, I. E, that sends the default SAML attributes, or does that custom profile need to be set up for the org or with each vendor? So, I can't I'm not specifically exactly on the in common and the default SP profile and what it is, but certainly, OpenAthens can be your IDP into InCommon. So you can replace whatever Shibboleth usually is being used with OpenAthens to work in the InCommon, federation. You can keep both in there as well. There's complications around that. That's a whole another topic to talk about. But, yes, certainly, in terms of the SAML attributes, we will then match the profile that's needed for that, but you can also set up custom rules with OpenAthens for each specific vendor, within the in common within the Open Access Federation. As I touched on the start, at the bare minimum, it's completely anonymous. Nothing additional needs to be sent to for that core functionality or authentication to work. However, there are vendors that might ask for something. They might ask for email address, which obviously isn't perhaps, which could be identifiable in some way. They might ask for some other details. And so should you need to or want to or actually, yeah. We would say question the vendor on why they're asking for them. But if there is a specific need for maybe some functionality that you do wish to, you know, feel users to have, then you might need to send that additional attribute. But you can control that within the OpenAthens attribute release policy, yeah, to make sure the right information is going to the right the right places. And, yeah, Matt, Michael, has that been something you've delved into that specific, you know, unique attribute release? **Michael Purcell** No. We no. No. Yeah. **Matt Van Ast** Just where we were implementing, we looked into it. Right? But I think you covered it. You can have your default institutional one that you set up in OpenAthens that maybe you only have one or two attributes, or you create a custom one that you configure with OpenAthens and your institution where you maybe have five or ten attributes. So those reside in OpenAthens. And then as James said, you pick and choose what you release to the resources and their platforms. And when we were looking at it and the way that we and the experience we wanted our patrons to have, we don't release any of them. So they go to the platform, and it's like they're you know, they have access for the institution, but they don't have automatic accounts. And then they manage that. If they want to have all these accounts at these platforms, they're free to do it. **James Edwards** Just seeing time I'm sorry, Brad. Because we have your name, we can answer yours out after the webinar. There's a two there from anonymous. So just thought we could answer those hopefully quickly. And then, yeah, further questions again, we could provide the answers for, anyway. So just to say and to confirm, access can be set up so a user's IP address is not exposed to the vendor. Yes. For any federated platform, that is correct. That's the answer. They will not see the IP. If the vendor, though, only accepts IP, that's what we have to send them. So it won't be but the user's IP, if it's going by the managed proxy service, it will be the OpenAthens IP that's unique to your account, which is obviously their IP, but I just want to make sure we're clarifying that. So, yes, it is a federated, no need for an IP to be sent to the vendor. And then have you and I guess, yeah, have you seen a reduction in access errors that require users to clear their cache? I guess that's going to be up to Michael and Matt. **Michael Purcell** Yeah. Yes. I would say that. I wasn't really sure how much they need to click clear their cache anyway, but it's not not as much an issue now. **Matt Van Ast** It does still crop up for us, but a lot of it has to do with, like, the federated cookie size and how many systems that they are accessing. So they we find that the patron logs into their email, into their course link, into this module, and that thing. If, you know, if they've logged in to ten different systems during that day, sometimes they'll have a problem if they're going into their tenth customer platform. **Emma Freeman** Alright. **James Edwards** That's fine. Sorry to Brad, but we'll get back to you, Brad, on that question for him. **Emma Freeman** Yes. Thank you so much, everyone, for all of your questions, and thank you, James, Matt, and Mike, for a wonderful conversation. We will be following up with everyone who attended and registered for this webinar with, you know, follow-up on your questions and some key insights that we learned from this webinar. And thank you all so much for your time. It's a very informative session. Thank you so much. **Michael Purcell** Thank you, everybody. Thank you. Alright. **Matt Van Ast** Thank you. **James Edwards** Have a good day. **Emma Freeman** Have a good day. *Transcripts are generated using a combination of speech recognition software and human transcribers, and may contain errors.* #### You might also be interested in ![](https://assets.ebsco.com/asset/c35d1362-3c7f-4c5e-9521-1db840c407df/meet-mosaic-video-image-780.png) ## Meet Mosaic, by GOBI Library Solutions [ Watch video ](/resources/meet-mosaic-gobi-library-solutions) ![Mosaic logo with illustrated balloons celebrating the product's second anniversary](https://assets.ebsco.com/asset/e0133b2c-0947-4159-a761-26fd94b248d9/Mosaic-Turns-Two-Infographic-web-780.png) ## Mosaic Turns Two: Two Years of Progress [ View infographic ](/resources/mosaic-turns-two) ![](https://assets.ebsco.com/asset/8b5ad26d-b064-41b7-8d76-7307e00aece1/ebsco-timeline-video-image-780.png) ## Celebrating EBSCO Milestones in Partnership with Libraries [ Watch video ](/resources/celebrating-ebsco-milestones-partnership-libraries)