Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (12)
Ähnlich wie Session s083 01 - moving away from ip authentication
Ähnlich wie Session s083 01 - moving away from ip authentication (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Session s083 01 - moving away from ip authentication
- 1. Moving away from IP Authentication May Yan may.yan@ryerson.ca @mayyan
- 2. ● IP Authentication preferred for all Electronic Resources ● Ezproxy server for off-campus access Our systems ● III Sierra ● Summon ● SFX ● Single Sign-on with Central Authentication Service (CAS) integration ○ Student emails ○ Electronic Resources ○ ILS renewals / patron accounts ○ Learning Management (D2L Brightspace)
- 3. Ransomware University IT systems and logins under attack Denial of Service Attacks Compromised Accounts Virus Sci-Hub notices Blocked IPs Excessive download notices
- 4. Ransomware
- 7. IT wants: 2 factor authentication/No IP authentication Two Factor Authentication Concerns ● Vendors cannot support this natively ● Increasing barriers to e-resources use ● Students and staff who do not have smart phones ● IT support for working with patrons who have problems using 2 factor process CANNOT DO THIS QUICKLY ● Want to wait until all university systems are using 2 factor (library doesn’t want to be singled out) ● Get plan in place to get fobs for all students who need it. (Who will pay?) What about using ezproxy and get all on campus users to login & no more IP authentication Concerns: ● Excessive download blocks from vendors impacting all patrons ● 1 point of failure for all resources ● Redirection of on campus vs off campus traffic must use same URL Benefit: ● CAS already setup for 2 factor, easy add for 2 factor when mandated.
- 8. Other Authentication Methods 1. Personal User Login/Password (Service Provider manages user authentication) 2. IP Authentication a. Proxy server redirects traffic after locally managed user authentication to vendor resources so that it appears to be from IP range of library b. Trusted Proxy Server c. VPN 3. Federated authentication through SAML a. OpenAthens (was Athens) b. Shibboleth (shibboleth.net) 4. Referring URL Authentication – an authenticated link to service provider from a secure or password protected web page. SP checks that this URL is registered to grant access. 5. Patterned IDs (library cards & barcodes) 6. Patron ID files (library cards & barcodes) 7. Cookie
- 9. Our Proposed Solutions Problem: One Point of failure 2 proxy servers: 1 for off-campus traffic, 1 for on-campus traffic Problem: Must maintain same URL for proxy links for both servers Local on-campus DNS mapping of proxy URL to on campus server Problem: Reduce risk when there are excessive download blocks from vendor “Algorithmic switching” between 3 IPs per server - to help mitigate whole server being blocked when there are excessive downloads
- 10. Timeline December 2016 Configuration, setup and testing January 2017 Requiring on-campus login started January 2017 February Update IP range on a few key resources for testing March Update IP range using vendor admin portal Start to contact vendors to update IP range
- 11. Lessons - During Setup ➢ Keep staff & librarians informed ➢ Keeping two configuration files in sync a challenge ➢ Setting up second server was more difficult than anticipated - not much experience in doing it.
- 12. Lesson - After Roll Out ➢ Single Sign-On doesn’t work for some on campus products - ARES opens up IE browser and students have to sign on again. ➢ Walk in guest accounts no longer works - must change them to ezproxy accounts and limit off campus use ➢ We can’t tell if the algorithmic swapping of IPs is working at all. (Need to do more testing) ➢ Inform staff and patrons of the change and why but not confuse them: we went for a “increase security as requested by CCS” message. ➢ Students have been good about the changes. ➢ Some faculty are NOT happy.
- 13. Benefits ➢ More ezproxy logs so we can do more with our assessment projects ○ Currently already a project to analyze resource use with grades ➢ Never could test our off campus access while on campus to mimic student experience, and now we can. ➢ A cheap solution to carry us over until there is better technology for our needs that is supported by all of our vendors.
- 14. Will this reduce our e-resources usage?
Hinweis der Redaktion
- Good afternoon, my name is May Yan, and I’m an ER Discovery & Access Librarian from Ryerson University in Toronto, Canada. I’m speaking today about a change we recently made to move away from using campus wide IP authentication for our resources. My presentation is to give you some background to what prompted the changes, what compromise we made with our campus IT Group and some lessons from this process.
- Ryerson University serve approx 42,000 FTE. Our current 2016-2017 electronic resources budget is approximately 3.75 Million USD. Up until December 2016, we use proxied URLS for all electronic resources with our proxy server was configured to bypass for all on campus IP. The changes I’m speaking about today has been in place since January of this year.
- In March 2016, We were contacted by our university computing department (CCS) saying that they are going to requiring 2 factor authentication on university’s most high risk systems. Electronic resources were classified as high risk due to what we spend on the resources each year, how often they are targeted, the reputational risk if we got into legal dispute with a vendor. The library was able to push back on this request a bit by expressing our concerns about making a change. Mainly that we didn’t want any additional barriers to the use of our resources. This was okay with them at that point. However, Click In 2016 Universities in Canada targeted with ransomware. Click One of the biggest one was when University of Calgary was hosting Congress of the Humanities and Social Sciences (Congress is the biggest conference in Canada each year) Click Ryerson is hosting Congress of the Humanities and Social Sciences in May 2017. So, right after the University of Calgary news, we have had further push to increase security again.
- In March 2016, We were contacted by our university computing department (CCS) saying that they are going to requiring 2 factor authentication on university’s most high risk systems. Electronic resources were classified as high risk due to what we spend on the resources each year, how often they are targeted, the reputational risk if we got into legal dispute with a vendor. The library was able to push back on this request a bit by expressing our concerns about making a change. Mainly that we didn’t want any additional barriers to the use of our resources. This was okay with them at that point. However, Click In 2016 Universities in Canada targeted with ransomware. Click One of the biggest one was when University of Calgary was hosting Congress of the Humanities and Social Sciences (Congress is the biggest conference in Canada each year) Click Ryerson is hosting Congress of the Humanities and Social Sciences in May 2017. So, right after the University of Calgary news, we have had further push to increase security again.
- In March 2016, We were contacted by our university computing department (CCS) saying that they are going to requiring 2 factor authentication on university’s most high risk systems. Electronic resources were classified as high risk due to what we spend on the resources each year, how often they are targeted, the reputational risk if we got into legal dispute with a vendor. The library was able to push back on this request a bit by expressing our concerns about making a change. Mainly that we didn’t want any additional barriers to the use of our resources. This was okay with them at that point. However, Click In 2016 Universities in Canada targeted with ransomware. Click One of the biggest one was when University of Calgary was hosting Congress of the Humanities and Social Sciences (Congress is the biggest conference in Canada each year) Click Ryerson is hosting Congress of the Humanities and Social Sciences in May 2017. So, right after the University of Calgary news, we have had further push to increase security again.
- In March 2016, We were contacted by our university computing department (CCS) saying that they are going to requiring 2 factor authentication on university’s most high risk systems. Electronic resources were classified as high risk due to what we spend on the resources each year, how often they are targeted, the reputational risk if we got into legal dispute with a vendor. The library was able to push back on this request a bit by expressing our concerns about making a change. Mainly that we didn’t want any additional barriers to the use of our resources. This was okay with them at that point. However, Click In 2016 Universities in Canada targeted with ransomware. Click One of the biggest one was when University of Calgary was hosting Congress of the Humanities and Social Sciences (Congress is the biggest conference in Canada each year) Click Ryerson is hosting Congress of the Humanities and Social Sciences in May 2017. So, right after the University of Calgary news, we have had further push to increase security again.
- While conceptually the library agree that 2-factor is the right approach for campus IT security, we had some serious concerns about impact on our patrons. Most importantly we didn’t want there to be too much of a barrier to accessing our resources and we didn’t want the library to be singled out. CLICK So, even our second discussion with them, we were able to push back on 2-factor authentication until it’s implemented across campus, but CCS wanted us to require all users on and off campus to login using our proxy server and to remove IP authentication on campus. CLICK We explained we would be concerned about losing access for all patrons when when we are blocked by vendors. (right now, at least on campus we can still access things when the proxy server was blocked) We didn’t want to have 1 point of failure for all resources for if something went wrong with the server. So they suggested that we run two servers. But with two servers we also didn’t want to have to deal with managing different URLs. They must share one URL but direct traffic behind the scenes to right server. So we did agreed that it’s a good compromise if we can find solutions for these concerns and that and while we will reduce the IPs we register with our vendors to only the ezproxy servers and a couple of back-up internal testing machines. We also told them it would likely take over a year for us to fully reduce the IPs since we would have to contact each provider. After they picked their jaws off the table, they agreed that we should proceed with that plan.
- I wondered if there were any other authentication methods available to us to consider using instead and if any other method might be supported by all of our ER providers. I pulled a list of our resources and without contacting each vendor directly, I checked what methods they supported by looking at their admin websites and other readily available documentation. I found that while many vendors supported many other authentication methods, other than IP authentication, none were prevalent enough for us to abandon the IP+ proxy setup for something else. The closest contenders were shibboleth/OpenAthens, which approximately 30% of our vendors supported. So, even if we want to use it, we’d still have to support IP authentication and still maintain our proxy server. Luckily we were able to work with CCS to come up with solutions to address our major concerns so we could proceed with a compromise.
- So, this is what we came up with as a solution. 2 proxy servers, essentially broken up by on campus or off campus traffic. Local DNS map for the proxy URL to handle route the load to proper server without having separate URLs. Ideally, if one server fails, we can flip to another server. And the Algorithmic switching between 3 IPs for each server.
- We really pushed for work to be completed and tested during our low period in December. Must have switch made by January 2017 to help us identify a clear point in time for statistics analysis. We also prefer to make changes in general to coincide with new terms so that it wouldn’t confuse patrons mid term and will give librarians a chance to fix their teaching materials. So this is where we are now. After requiring everyone to login to resources for about a month, we started to test reducing our IP range during a low period, where our campus has reading week in February. We started with EBSCOnet and ProQuest, and when no problems encountered, we started to reduce the IP on other resources as well, mostly the ones we could update through admin portals. So of all of our databases, about 25% we could update via the admin websites. Bulk of work for ERM will likely take place in the summer as a special project to contact each vendor, with the remainder updated at each product renewal. And now we are in April, what are some of the lessons so far?
- Because we had to test with live servers, we setup the second server and tested it with a few IPs until all problems. Even though we had problems setting up the second server to work properly, there was little impact to our patrons because of the on campus IP bypass. We know we could continue with it until we resolved all issues. Testing with Live servers was a risk.
- We fully expected that single signon would work for patrons and that this was going to be of limited hassle but, we found out later that it didn’t help with certain products like ARES which opened up IE and forced students who were using firefox or chrome to sign on again. We completely forgot about the impact to walk in patrons on campus with this change. In February we got word from our borrower services group letting us know that patrons are confused and don’t know what to do when they were trying to access e resources. Our walk in alumni uses a one day login and password to use our computers. Alumni didn’t have single sign on accounts or theirs didn’t allow for access. Luckily it wasn’t hard to come up with a solution. While we make changes to reduce our IP range various resources will be in different stages of if they will have IP authentication on campus or not. And this was going to happen for a long period of time. This makes it difficult for our reference staff, and liaisons to work with patrons when they have access issues. We decided to use a fairly generic message to inform our staff and patrons of what to do if they couldn’t access resources the way they used to. And followed up with a little more detail for library staff as to the reasons why changes were being made without going into too much detail. Generic Message was “accessing it via the library links first to make sure you are using a proxy link” if you have issues accessing resources. Students have adjusted to the change well, but Faulty was a different story. Faculty that used to just google for things and get access are now expected to look for articles from library systems and they are NOT happy about it. This means we need additional liaisons interactions with them. For faculty savvy enough, we’re instructing them on how to setup Proxy Auto-Configuration (PAC) files for sites they use the most.
- Our proxy servers run practically for free because when we got the licenses for them they were $500 one time fees, and we haven’t paid for anything since. However we are going to be upgrading and moving on to the new pricing scheme of $500/server/year. In contrast I got a quote for OpenAthens for $5000 a year.
- Only time and an analysis on our usage stats will tell. (The big story in January 2017)