With dozens of databases available, it’s easy to get lost in all the authentication methods. Although we try to make it as simple and user-friendly as possible, we often have to make compromises with the providers who have their own policies and technical constraints. So let’s go on a tour of all the authentication processes you might encounter when accessing the databases subscribed by the library. The most common and probably the most transparent solution is IP based authentication. For those of you who don’t know, an IP address is a number that uniquely identifies your computer (or your tablet or your phone) on the network. When you connect to the HEC network, you are automatically given an IP address from the pool of addresses owned by HEC. And because our providers know what IP addresses are owned by HEC, they can tell that you are accessing their servers from campus and they give you access to everything we subscribe to. No login, no password, hard to beat that! However, there’s a problem with this method: what happens when you aren’t on campus? This is where our reverse proxy comes in. The reverse proxy is an intermediary. Instead of going straight to the provider’s website, you send requests to the proxy, the proxy sends them to the provider, and sends you back the responses. Because the proxy is on the HEC network, it’s as if you were accessing the database from campus. For that method to work you have to click on the links that we put on the library website: you might think that you’re going directly to the provider’s website but actually you’re interrogating our reverse proxy (If you look carefully you will see “ezproxy.hec.fr” in the URL). In that case, of course, you have to type in your HEC username and password, but it is still IP based authentication.
Now let’s look at another authentication method that we use frequently, called Single Sign-On (SSO). More specifically we are going to talk about SAML (short for Security Assertion Markup Language), which is one way to do SSO. Single Sign-On basically means that you can log into many different services with only one user ID and password. It comes in many flavours and one of them is SAML, a useful implementation when the services are distributed across many domains on the web (like our databases). With SAML, when you want to access a service, you are redirected to an Identity Provider (IdP). If you log in successfully with the IdP, you are issued an “assertion” that you pass on to the service provider and in turn the service provider will grant you access to the allowed resources. In our case, HEC play the role of the Identity Provider and the Services Providers are the many database publishers with whom we have a subscription
That way, you log in once, the publishers don’t need to keep a database of all HEC users’credentials and you don’t have to remember yet another username and password.
Do you remember the software “Shibboleth” we talked about in the introduction? It’s a SAML implementation.
It’s great news when a provider allows one of these two methods of authentication. But this isn’t always possible. For some of them you need to create your own account (Bloomberg, Forrester) and for others we need to type in the password ourselves! This is by far the worst method and we try to avoid it as much as we can!
In conclusion, we know that the chosen method isn’t always ideal, but we try to improve it. Whenever we negotiate with a provider, we ask them to make the best effort to implement a user-friendly and “school-friendly” method of authentication. This might be a good time to remind you that the databases subscribed by the library are meant to help you with your academic education and are NOT meant to provide free data to the company you are working for during your internships. It’s harder for us to negotiate good resources when the providers are afraid that students in internships will share their privileges with their employers. Therefore, in a nutshell, whatever the authentication method is, don’t share your password with anyone!