Authentication vs Authorisation - Access Management in Software Systems

Security forms a critical part of any software application. One crucial aspect of security is managing access to an application; for citizen-facing systems that the government commissions, this becomes mission-critical: any slip up can prove to be disastrous, as exemplified by multiple instances of the leakage of sensitive information such as a data leak that hit the State Bank of India in 2019 and a large breach of the labour department of the Government of Jharkhand in 2018.

Managing access involves two distinct processes-- authentication and authorisation; terms that are often used interchangeably. This blog is the first of a series on access management in government systems. This part is aimed at explaining what these terms mean and how they are distinct. It is also a simple introduction to the concept of a Single Sign On - SSO.

To better explain the difference between authentication and authorisation, we will draw an analogy to passports and visas (this might be the closest you will get to talking about visas during this period!). We end with an explanation of the current authentication scenario in legacy software systems and how SSO can improve this landscape. Future editions in this series will speak about the implementation of access management in Indian government systems, how Aadhaar fits – and does not fit – into this picture, and what various government entities can do to implement open source auth by themselves.

#What: Auth as passports and visas

Consider a travel analogy: when visiting a foreign country, you will typically be required to present two documents: your Passport and a Visa. The Passport is for confirming your identity – the presence of a government-issued physical Passport is the factor that “authenticates” this – and the Visa stamped on its pages indicates to the destination country what set of permissions a visitor has access to. Are they permitted to engage in employment? Are they permitted to travel throughout the region? What is the expiry date of their access? The Visa, thus, represents what a visitor is “authorized” to do.

While the travel analogy makes the distinction between the two clear, it brings up another question: when using government portals to book rail tickets, pay electricity and water bills, do you end up using a different username / password for each system? There is one government but for distinct parts of the same system, we need different credentials - is that not redundant?

You may manage this by having a neat notebook with a 100 credentials or you may autosave them in your browser. But is this a secure and efficient way of managing access to disparate government systems?

#Single Sign On

If a single Passport can work regardless of which country is being visited, why do separate government applications require separate login credentials? A single set of credentials should be sufficient to authenticate one’s digital identity regardless of which application one is trying to sign in to: registering for a new driver’s license or paying one’s advance tax. This is what is often referred to as a “Single Sign On” (SSO) capability.

Implementing this within a set of existing, deployed applications is possible if user identities are managed independently: think of it as needing only a single set of credentials to sign in to multiple bank account applications. Instead of the user identities – your name, bank account number – living inside each separate application, they are removed and managed centrally by a separate component, which manages your registrations to each application, and the required metadata linked with each.

#Authorisation: Access Control Lists

While this external component manages identity – or the Passport, from the earlier analogy – there is also a definite need to manage what the user is authorised to do within each application - your Visa. In most software systems, an “Access Control List” (ACL) is a very standard form of accomplishing this. In the simplest terms, it is, as its name suggests, a list outlining the types of access that users have to different resources within an application.

This ACL layer is made to sit between any requests that the user may make from their client, to determine whether the resource requested is accessible to their assigned role and respond accordingly.

In future posts, we will explain the state of SSO within government applications in India, the value inherent and the limitations present in the adoption of Aadhaar for digital authentication, and finally, describe a way to implement these capabilities for government systems: open-source, not vendor-locked, and inherently deployable on any infrastructure. Essentially, one passport and a system to grant and track visas for all travel.

This is the first part in a series on open-source authentication and authorisation in government systems. The next part will focus on the current landscape in India, and the final part will focus on building open-source auth systems for specific use-cases