Download to read offline
Uploaded byOpenAthens
Access Lab 2020: OpenAthens and Alma implementation
The document outlines the transition from WAM to OpenAthens for access management at the University of Leeds, detailing the conversion process, including syntax changes and proxy configurations. It addresses publisher provider issues, including the need for IP whitelisting and the resolution of federated access challenges. Additionally, it mentions various tips and resources for troubleshooting during the implementation process.
![5G Explained! A High Level Overview [Introduction]](https://cdn.slidesharecdn.com/ss_thumbnails/5gexplainedahighleveloverview-260119165306-cc137a3e-thumbnail.jpg?width=640&height=640&fit=bounds)
Access Lab 2020: OpenAthens and Alma implementation
- 1. When WAM went OpenAthensand Alma implementation at the University of Leeds 1
- 2. Conversion from WAMto OpenAthens http://0- provider.com .wam.leeds.ac.uk /journal-ISBN https://0- provider-com .wam.leeds.ac.uk /journal-ISBN https://go.openathens.net/redirector /leeds.ac.uk?url=http%3A%2F%2F provider.com/journal-ISBN WAM syntax OpenAthens syntax 2
- 3. Conversion from WAMto OpenAthens https://0- provider-com .wam.leeds.ac.uk /journal-ISBN WAM https dots and dashes complication 3 https:// provider.com /journal-ISBN
- 4. Conversion from WAMto OpenAthens 4
- 5. Conversion from WAMto OpenAthens Example plain URL from title in collection 5
- 6. Conversion from WAMto OpenAthens http://0- provider.com .wam.leeds.ac.uk /journal-ISBN http:// provider.com /journal-ISBN WAMME D DE- WAMMED 6
- 7. Conversion from WAMto OpenAthens proxy enabled for all resources no flexibility to opt out proxy not enabled for all resources flexibility to opt in Alma Proxy Configuration 7
- 8. Publisher Providers OpenAthensSetup • Organization ID • IdP (Identity Provider): https://passport01.leeds.ac.uk/idp/shibboleth • Federation: OpenAthens Federation or UK Access Management • Scope: leeds.ac.uk 8
- 9. Publisher Providers OpenAthensSetup • OpenAthens University of Leeds IP address 9
- 10. Publisher Providers IssueResolution 10
- 11. Publisher Providers IssueResolution Got our OpenAthens credentials? We’re not registered for federated access. OK – can you whitelist our OpenAthens IP? 11
- 12. Publisher Providers IssueResolution 12
- 13. Publisher Providers IssueResolution Resource Needs Allocating Not registered for Federated Access Domain needs registering Deep Linking not supported Identify issue source WAYFless Syntax needs updating Development Issue ‘not compatible with OpenAthens – only Shibboleth’! 13
- 14.
- 15. Publisher Providers IssueResolution Resource Needs Allocating Not registered for Federated Access Domain needs Registering Deep Linking not supported Identify issue source WAYFless Syntax needs updating Development Issue ‘not compatible with OpenAthens – only Shibboleth’! 15
- 16. Publisher Providers IssueResolution 16
- 17. Publisher Providers IssueResolution Resource Needs Allocating Not registered for Federated Access Domain needs Registering Deep Linking not supported Identify issue source WAYFless Syntax needs updating Development Issue ‘not compatible with OpenAthens – only Shibboleth’! 17
- 18. Publisher Providers andIssue Resolution 18
- 19. Publisher Providers andIssue Resolution 19 DOI URLs
- 20.
- 21.
- 22. Tips and tricks… Problem Solving Screencast VPNRefeds website https://met.refeds.org 22
- 23. Tips and tricks… Problem Solving Screencast VPNRefeds website HTTP Headers Extension 23
- 24. Questions?? 24 Karen Abel Subscriptionsand E-Resources Coordinator k.r.abel@leeds.ac.uk
Editor's Notes
- #2 Here at Leeds University Library, after much consideration and preparation, in the summer of 2019 we migrated Library Management System from Innovative’s Sierra to Ex Libris’s Alma. In hand with this came a migration of authentication systems. For most of our resources, we had been using Web Access Management, or WAM, the authentication system provided by Innovative, and managed within Sierra. In losing Sierra we would also lose WAM. The university had already begun a subscription to OpenAthens and so the logical move was for us to embrace OpenAthens as our new authentication system for library resources in tandem with our move to a new LMS.
- #3 When first considering our move from WAM to OpenAthens, we thought the task would involve a mass conversion of individual resource URLs from a WAM syntax to the OpenAthens syntax. This is because, in Sierra, every individual book or journal has this WAM syntax embedded within the record’s URL and we presumed this would also be the case in Alma. As our OpenAthens subscription was already up and running via the university prior to our move away from Sierra, we figured if we converted all our resource URLs within Sierra, we would create a seamless authentication transition between LMSs. The WAM syntax for URLs beginning http comprises a ‘0-‘ before the core of the URL and then ‘.wam.leeds.ac.uk’ between the core and the resource identifier. This is easily removed ready to be replaced with the OpenAthens header and encoded version of the URL. To make things a little more complex, however, the WAM format is slightly different for those URLs beginning with https.
- #4 For the core element only of these, when WAMMING then, any dots are converted to dashes and any dashes to double dashes. In reverting back to their plain version ready to apply the OpenAthens syntax, the dots and dashes within the core needed identifying and reverting whilst simultaneously pulling off the magic trick of ignoring those dots and dashes that are in the tail of the URL. In addition, the dashes became dots again but the double dashes must not become dots but rather a single dash! All a bit of a challenge but, by working with Sierra’s Global Edit tool, we found ways to carry out the conversion and to cater for these complexities.
- #5 However, after some time spent working on these Global Edits we realised we had navigated ourselves part way down a rabbit hole. As we gained access to Alma’s Sandbox and began to familiarize ourselves with the structure of the system, we learned that the authentication does not need to be embedded into the URLs of each individual resource in Alma but rather Alma will take care of this for you in the background, provided you have the authentication configured in your proxy settings.
- #6 The proxy can then be enabled at either a collection or individual title level. Here we see it enabled at the collection level for a Taylor and Francis e-book collection, ready to apply OpenAthens to all the plain URLs for each resource within that package.
- #7 So, the focus for the conversion switched to a need to simply rid the individual resource URLs in Sierra of WAM (instead of also converting them to OpenAthens). However, we needed to be cautious about this. We had a tricky cutover period to navigate between LMS systems. Whilst we needed de-wammed resources in Alma we also needed to retain wammed resources in Sierra so that our users would continue to gain authenticated access whilst we prepared Alma with the build up our data ready to Go Live. So we carried out a tightly timed de and re-Wam exercise. (This involved using Sierra’s global updates that we had previously experimented with –thankfully not a complete rabbit hole exercise after all). The resources were temporarily de-wammed just before the data extraction for Alma was carried out, and then promptly re-wammed again ready for our users to continue gaining authenticated access in the final two weeks of Sierra use before we went live with Alma.
- #8 The transfer to OpenAthens within Alma still wasn’t fully resolved as there are limits to the proxy configuration options. With the majority of our resources using OpenAthens, we wanted the config to enable the proxy for everything and give us the ability to manually opt out for those few resources where OpenAthens wasn’t compatible. However, the choices in Alma are either to enable the proxy for everything, with no opportunity to opt out or, to have the proxy enabled for nothing, with the ability to opt in. To retain flexibility, we would have to go with the latter option, the proxy enabled for nothing. But this would then mean manually switching it on for vast numbers of resources and collections, a manual task which would take significant time and delay return to full access for our users. The solution was to create a massive set of all our migrated electronic resources and then run a job on these (an Alma function) to enable the proxy for them all. So, our configuration is indeed set to option 2, to assume the proxy is not enabled for our resources but, by running this job on everything we migrated, we have now enabled it for everything retrospectively and are in a position where anything new coming in can be managed on a collection by collection basis.
- #9 Whilst we worked on the shift of our resources between the LMS systems and the setting up of OpenAthens configuration in Alma, we were also focussing attention on our publisher providers, whether or not they were compatible with OpenAthens and, if so, whether they were set up ready to operate. Both OpenAthens and ourselves reached out to our providers to make sure they had the details required to set us up as OpenAthens customers; namely our Organisation ID; Identity Provider; the name of the Federation we use and the Federation Scope. We also needed to make sure that we had allocated the providers in our OpenAthens Catalogue by going into the OpenAthens admin portal and assigning permission sets.
- #10 Whilst federated access is the preferred authentication route, OpenAthens provide authentication by means of proxy IP too for those institutions that aren’t able or don’t wish to register with a federation. Each institution has its own OpenAthens IP which can be whitelisted by a provider in the same way they would whitelist the university campus IP range. From the end user’s perspective, if the access is WAYFless, the authentication process is no different whether it is provided through a federated or proxy IP route. And from the institution’s perspective, there is also no difference. The same OpenAthens syntax can be applied to the URL. But, clearly, for the provider in setting this up, instead of the Scope and the IdP they will need OpenAthens IP address instead.
- #11 This difference between IP and Federated authentication methods is, we have discovered, a common reason for access issues that have surfaced since we went live with OpenAthens. An example scenario pans out like this: ANIMATION CLICK: One of our users reports a 404 OpenAthens error when trying to access a resource. ANIMATION CLICK: We disenable OpenAthens in Alma as a temporary measure to stop the 404 error getting in the way of the campus IP range working and advise our users that, for off campus access, they can log into our Desktop Anywhere service that will place them within our IP range. We check the OpenAthens catalogue to make sure the provider has an entry and that they are allocated. All appears well from this perspective.
- #12 We email the provider to ask if they’ve got us set up properly with our OpenAthens credentials. They reply explaining that they’re not registered for federated access. We then give them our OpenAthens IP and ask if they can whitelist that instead.
- #13 On re-checking the resource in the OpenAthens catalogue we can see it’s categorised as federated, not proxied, proxied being the proxy IP authentication version. So, we give OpenAthens a shout and ask them to set up a proxied entry instead. Once set up, OpenAthens is now good to go with this provider, with the redirector link operating just as it would have done had federated access been the mechanism working in the background.
- #14 So, providers not registered for federated access and needing the proxy version of OpenAthens setting up is a common issue and here’s a round up of some others that we have found crop up fairly often. ANIMATION CLICK: It might be as simple as the provider’s resource needing allocating in our OpenAthens catalogue. In an ideal world, we would have all of these set up but, with many hundreds to allocate, some have slipped through the net. Plus, sometimes there is more than one version for a provider in the catalogue and we haven’t always chosen the right one. ANIMATION CLICK: Sometimes there is a change by the provider in the syntax of the WAYFless URL. If this hasn’t been updated in the UK Fed records then it will cause errors as the OpenAthens redirector will still be pointing to the old WAYFless syntax. This is an issue that needs to be resolved by conversation between OpenAthens and the provider. ANIMATION CLICK: In a similar scenario, sometimes a provider’s domain is not registered in the UK Fed records. For example, with one provider, their commercial site was listed but not the site used by educational institutions. Again, this was unravelled by process of a triangular conversation between us, OpenAthens and the provider.
- #15 This triangular conversation is at the heart of the solution to many of the issues. The team at OpenAthens have been great at reaching out to providers on our behalf and filling us in on the results of the conversations. Likewise, often it will be us reaching out to the providers (who are also usually very helpful) and either copying in a Rep from the OpenAthens team or getting back to OpenAthens with the results of our findings.
- #16 This open conversation has proved invaluable on those occasions where it is not clear where the issue lies. ANIMATION CLICK: Often, an access issue involves de-tangling and all the more so whilst we are in the phase of getting to grips with a new LMS.
- #17 To give an example, ANIMATION CLICK on one occasion, we received a report of a user getting a ‘forbidden’ message when attempting to access one provider’s resource. On initial investigation, we realised ANIMATION CLICK that the resource had not been allocated to us in the OpenAthens admin portal area. This resolved the forbidden error but revealed a further problem. With the proxy enabled in the Alma settings for this resource, authentication was successful but, rather than arriving at the journal target page, ANIMATION CLICK the user would be taken to the resource’s home page. Disenable the proxy and the user would arrive successfully at the journal target page but, of course, without authenticated access. We got in touch with OpenAthens who found that, using a redirector link generated from a plain URL for the resource, they were able to authenticate and reach the target page successfully. So the question became: what is happening in Alma to make this fall over? It transpired Alma’s Community Zone facility was providing an outdated platform URL. So, what started out looking like an authentication issue was only partly so. The resource needed allocating yes but, beyond that, it was a tidying job to be taken care of within the LMS.
- #18 ANIMATION CLICK: Not all providers are able to offer deep-linking (or article level linking) to their resources. This causes an issue when the LMS is set up to take users to an article but, following authentication, they arrive back at the resource’s homepage. There are a couple of ways to rectify this. Either a target linking parameter can be set up by the provider for the redirector to work with (which would be a scenario involving a conversation between OpenAthens and the provider). Or, if the provider is not in a position to do this, the IP proxy version of OpenAthens can be used instead. So, it’s worth noting that the IP proxy system can be used where federated access is not available AND to enable deep linking. ANIMATION CLICK: A frequent misunderstanding we’ve come across with platform providers and publishers is the notion that they only support Shibboleth, not OpenAthens and so are not able to move forward with our request to set up OpenAthens authentication. In fact, if they support Shibboleth and are registered with the UK Federation, then they will be able to use OpenAthens too. The only problem, as far as federated access goes, is if they are not registered with a federation. ANIMATION CLICK: Finally, sometimes there is a bigger developmental issue to be addressed that may effect multiple providers. We happened to hit on one of these when we prepping our migrations….
- #19 In readiness for the move, we had established methodical testing against sample URLs for each of our suppliers and began to discover large numbers of supplier URLs that were not at this point operating as they should with OpenAthens. In particular, these related to our e-book packages and effected approximately 10,000 e-books from over 10 providers (including major suppliers such as Springer, Cambridge and Oxford). Facing the loss of off-campus authentication for all these resources post migration we were very keen to identify and resolve the issue.
- #20 What they all had in common was use of DOI URLs and, in conversation with OpenAthens, we discovered that there was in fact a recognised problem with DOIs not working. OpenAthens had received reports of this from other clients too. In a timely result for us, a fix for DOIs was established in readiness for our migration resolving in one fell swoop a large number of our OpenAthens incompatibility issues.
- #21 Having looked at some of the issues we’ve resolved with the help of OpenAthens and our providers I thought it might be useful to just flag up some tools that we’ve found useful along the way to help us identify issues. ANIMATION CLICK: The first is the use of screen casts. Whilst screenshots are great, sometimes it’s handy to be able to show the various screens and stages that an authentication issue moves through when trying to demonstrate an issue. There are various free tools of this on the web but we’ve found screen-cast-omatic works well for us.
- #22 The second is using a the VPN to take us out of our IP range and enable us to simulate off-campus access. The browser Opera has a built in VPN feature and has become a mainstay for us in replicating off-campus authentication.
- #23 Thirdly, OpenAthens recommended to us use of the Refeds website which allows you to see what federations any organisation is registered with. A handy tool if you are having the ‘we’re not compatible with OpenAthens, only Shibboleth’ conversation with a provider.
- #24 And finally, we also make good use of the HTTP Headers browser extension, which allows us to see exactly what journey a user is taken on from OPAC to provider platform via authentication.
- #25 So that’s a summary of our journey from Sierra to Alma, WAM to OpenAthens and some of the types of issues we’ve found along the way. I’m happy to take any questions…