The Future of Security, Yesterday: All About Authentication, Authorization and More…

Access to library resources from the user’s perspective is getting simpler and easier at a rapid speed. Most librarians working with tech and computing services in some form or another are working to set up, maintain and improve the end-user experience by means of managing access at one or more levels at their institutions. No matter what your role is in any given organization, even if you are not primarily responsible, it is always helpful to have an understanding of the terminology so we can speak intelligently and help translate for others we work for and with.  At my own law library this is very much at the forefront of our minds with the University of Georgia pushing fast towards all departments rolling out Single Sign On, and for a couple of years now institutions across the state have been working to migrate resource authentication to more singular authentication models via OpenAthens. Finding myself in the midst of new and overlapping zones of information has been at times both exciting and overwhelming. Amidst it all I keep coming back to acronyms, definitions and other jargon which I am working to commit to memory. I hope this post can serve as a resource not just for myself but other CS members who find themselves in the middle of or responsible for resource access and management.

Let’s start by deciphering the differences between Authorization and Authentication, and how they work together:

• Authentication – this is the process of something or someone (a user) proving their identity to someone else (usually a system or resource).
• Authorization – this is the process by which a system (usually a server) determines permission and grants access to something.
• Why are the two coupled together? The two terms are used in the same sentence and sometimes even interchangeably depending on who you are speaking with because systems/servers need to have some concept of who is requesting access.
• Authentication types required for authorization can vary widely depending on the security level(s) of systems and resources. The most common type of authentication is a username and password.  Other examples of authentication include ID cards, retina scans, voice recognition, and fingerprints.

As librarians we provide access to large collections of resources for our patrons. Patrons are of course users that have authorization to access items in the library. They may use their library card to check out physical items. In this scenario the card is the authentication that allows the library to authorize the individual to borrow the item. In the world of electronic resources our vast digital collections require the same authentication for authorization – but how do we manage that online?

Here is a small but hopefully handy set of acronyms to help you navigate this increasingly complicated terrain:

• IAM – Identity and Access Management
• AD – Active Directory
• SSO – Single Sign On
• FIM – Federated Identity Management
• FID – Federated Identity
• OAUTH – Open Authorization
• >IDP – Identity Provider
• CAS – Central Authentication Service
• <LDP – Lightweight Directory Service
• LDAP – Lightweight Directory Access Protocol
• SAML – Security Assertion Markup Language

There are many, many more of course, but for the sake of this blog post these are the few that I have encountered most recently and am grasping at for our own resource transitions. A great resource for reading more about terminology is The Secret Security Wiki.

Essentially Single Sign On is exactly what it sounds like it would be: a simplification of the login authorization process by authenticating once. It also adds a safety layer by reducing the potential for error since different individual or duplicated logins are reduced to one. SSO is a type of organization access control that seems to be the standard solution. Sounds peachy, right? Of course – but as with anything easier on the surface, the background configuration is complex. For an overview of SSO pros and cons, I found this Data Protection Blog Resource quite helpful. Arguments aside, we’ve been dealt a hand we must deal with. Implementing SSO for our sites and other resources requires certain protocols in place to handle the back-and-forth between our users, the interface they authenticate through, and our resources which they are authorized to access.

A part of this SSO equation, federated entities (independently managed domains that have established a trusting relationship) allow stored identity provider credentials to connect to identity management systems. SAML is just one protocol which is the standard for AD federation services for logging users into a variety of applications based on sessions in a different context.

Across our university multi-factor authentication is also gaining momentum for double-checking user identity, usually by way of a personal device. Although the necessity for multi-factor authentication is not there (yet) for users and library resources, it is yet another layer available if the resource calls for further security measures.

As I am wrapping my own head around the various pieces of the authentication-authorization puzzle our department is currently deconstructing, building, and before all is said and done rebuilding again, I will no doubt return to this post myself. Are there other terms to add to this post? Are you a CS-SIS member dealing with these issues as well? Share your advice, expertise and other experiences in the comments below!