Open Athens
Search OpenAthens Open Athens

Where next for Local Authentication?

AvatarBy Beth Rutter
Category - Blog

Tuesday 5th April 2016

OpenAthens users of Local or Devolved Authentication (OALA or DA) are at a crossroads


Recent changes in both OpenAthens products and the IT context in which they operate have created some exciting new capabilities for users of Authentication systems. It’s now possible to directly and securely connect your Network Directory system (eg Active Directory or LDAP) with your Library and e-Resource authentication systems, bringing many benefits to both users and administrators of these systems. But what does this mean for users of Local Authentication systems; for example, OALA or OA DA?

Marrying Library services with IT

Before now, it’s been necessary to run locally-installed “bridging” services between an organisations core Directory service and the world of online resources (eg Publisher websites, online databases such as EBSCO and ProQuest). This is because of several factors, primarily:

1.  Traditionally IT Departments were nervous about exposing their core Directory services to the Internet, given that these services are primarily about Security Management and controlling access

 2. Until recently, the two worlds couldn’t speak the same language – common protocols between Directory services and Web-based Publisher resources were incompatible or incomprehensible

One of the most popular “bridging” systems deployed was OpenAthens Local Authentication, or OALA. A previous generation of technology used to achieve part of the same function was OpenAthens Devolved Authentication (or DA). These systems acted as “translators” – bridging the gap between core Directory services and Library systems, and providing a key “authentication” function by enabling validation of a User Access Request. These access requests would be received from a Publisher site using the SAML protocol, the Local Authentication system would validate (grant or deny) the request by performing a lookup in the core Directory service and then return the result to the Publisher site, authorising or blocking the users request to access the web-content.

These systems offered benefits of allowing users to use one Username and Password for all services, and to access both remote (web-based) and local services through these credentials. However, this approach required that Local Authentication systems be installed and maintained within the organisations IT estate – a specialist job for the often-overworked IT Department.

The world has changed!

Now, it is possible to directly and securely connect core Directory services with cloud-based services without the need for locally-installed “Middleware”. This has been enabled through several recent developments:

1. The adding of suitable protocol support by the core Directory vendors – eg Microsoft Active Directory for Federated Services (ADFS), supporting SAML connectivity

2. The increasing popularity of cloud-based services such as Office365, which require the adoption of ADFS by IT Departments

3. The enrichment of the cloud-based Authentication services (for example, OpenAthens MD) with both functionality to rival Local Authentication systems AND connectivity options to communicate directly with core Directory services and local Applications

These advances mean that it is possible to dispense with the locally-installed “bridging” layer, and directly connect your core Directory service to your Library authentication service in a fashion which will be supported by your IT Department.

So what?

The benefits of this direct connection are many-fold:

1. No need to install and maintain Local Authentication services; no local servers or Virtual Machines, requiring regular patching and update, no more need for IT Departments to worry about these specialist servers and the complex networking required

2. Cloud-based authentication is extremely scalable and reliable – instead of running on your local servers, this service now runs in Eduserv’s Cloud infrastructure of massive servers with dual-site redundancy, ensuring incredible uptime

3. Secure – our “Authentication Cloud” is monitored and updated 24/7/365 as part of our service. We run regular Penetration Testing and can provide documentary evidence about our compliance to industry best-practice

4. Future-proof – instead of running local services which you are responsible for upgrading, the Cloud-based authentication service is upgraded and enhanced directly by the OpenAthens team

What does this mean for my OALA/DA implementation?

Users of Local Authentication services now have a comprehensive, credible alternative approach to consider when the time comes to review their current implementation:

– To continue to enhance and invest in Local Authentication

– To switch to Cloud-Based Authentication

For users of OALA, this decision is not a pressing one and can be taken at the next logical break point; for example, if it becomes necessary to add new servers or Virtual Machines to the current OALA installation in order to achieve higher system availability or performance, or to upgrade to a new version of OALA.

For users of DA, this decision should be taken soon as OpenAthens have announced their intention to retire DA services in Autumn 2016.

I use Local Authentication as a Single Sign-On to local applications – surely Cloud can’t do this?

The OpenAthens Cloud Authentication service offers several capabilities to support local Single Sign-On, including:

– Various Application Connectors to “read” user information from local applications – for example, Library Management Systems (LMS), local SAML applications

– An API to enable Local Applications to be developed and implemented which make “function calls” on the Cloud-based Authentication service; for example, “Authenticate”, “Open Athens Session”

Additionally, many previously Locally-installed applications (eg VLEs) are now adopting the Cloud-based model and integrating with core Directory services and Authentication services using this approach.

But changing is surely complicated and risky?

Any change should be approached and planned carefully in order to reduce risks to user’s service, but there are many migration tools and features to make the process simple and straightforward. For example;

1. It’s possible to test the new features/functions using an “offline” version of your live system, without affecting your actual live service

2. Cutover to the new service is simplified by the provision of “toggle” switches (ie “visible” or “invisible”)in the Administration area – and you can “toggle” back to the old system in the event of problems arising

And your users keep the benefits of single Username and Password, and any personalisation they may have setup in their online resource sites (eg saved searches, bookmarks, Continuing Professional Development training credits) is preserved.

What is the way forward? Increased engagement with a digital world

The array of resources and applications available to researchers, scholars and analysts continues to grow. An established username and password that creates a seamless user-journey across platforms removes barriers to entry and increases end-user engagement.

At first glance, local authentication and associated technologies can appear complex, but OpenAthens integrates systems in the background to prove a secure, simple technology that opens up a wealth of valuable information to those who most need it.

Share this article