Enabling Easy and Flexible Deployments of the Auth Layer

We talked about Avanti’s authentication layer in a separate post sometime back!

Authentication at Avanti Fellows: The what, why and how?

It now supports more than 3500 students across 100 schools in Haryana. A month ago, it was time to extend the authentication layer across different groups. Groups, in the context of Avanti, stand for the different programs we support. Each group consists of either students or teachers in a school supported by Avanti Fellows. For example, since Avanti supports students studying in government schools in Haryana, these students fall under one group, HaryanaStudents. The teachers in government schools in Haryana form another group, HaryanaTeachers. A few other examples of groups would be students studying in government schools in Delhi or in Himachal Pradesh. Supporting various such groups required refactoring the way auth layer was built. The codebase was built with some assumptions about the user in mind. For example, irrespective of the user, the auth layer asks for a 10 digit ID. These assumptions don’t always hold up in reality. Hence, instead of embedding data directly into the source code of the auth layer, we decided to obtain the data from external sources or generate it at runtime. This is the best option when you want to scale because scaling would mean supporting different kinds of data for different programs.

The most important step in accommodating various groups is identifying what differentiates how the auth layer is used by these groups.

Configurable Parts of the Auth Layer

• The User Interface (UI)

  Each group uses different terminology for the unique identifier. For example, Haryana calls it Student Registration Number (SRN) meanwhile, Delhi calls it Student ID. Currently, the user prompt is “Please enter your SRN”. When an invalid entry is used, they are prompted with an error, “Please enter correct SRN”. But now that various groups are to be supported, the auth layer needs to accommodate different terminology being used in each group.

For Haryana, the ID is called “SRN”

For Delhi, the ID is called “Student ID”

• The database of valid users

  To decide whether a user entry is valid, we need to have a list of valid user IDs that can be referenced. This list is specific to each group. The auth layer should dynamically decide which list to use depending on the group that the user belongs to.

• The validation rules

  Our auth layer follows group-specific pre-defined rules to validate the user entries. For example, Haryana requires 10 characters for its user ID while Delhi requires 11. Until the user enters the given number of characters they are shown an error message indicating that their current input is invalid.

For Haryana, the identifier is a 10 numeric characters string

For Delhi, the identifier is an 11 numeric characters string

All these factors affect how the auth layer should look and work for each group. We had to come up with a solution that is robust, scalable and requires minimum development each time a new group is onboarded.

Structure of group configuration

We decided to store all the group-specific details in a JSON object. Whenever the auth layer is used by a group, the app reads data from that specific object to accommodate changes.

This object contains the following keys:

• text: This sub-object contains all the text strings for each component of the UI. It contains these text strings as further sub-objects for each language translation. So far, we support English and Hindi.

• input: This sub-object contains details about the unique identifier. The number of characters (length of the identifier) and the type of characters (numeric or alphanumeric).

• dataSource: This sub-object contains details about where the database of valid users resides. It also contains the metadata of the database such as the name of the database and the column of the identifier in the database.

• maxNumberOfIds: Avanti’s auth layer has the unique feature of allowing multiple users to log in simultaneously. This feature was added as there was a use-case where multiple users (i.e. students) were using the same device to log on. You can read more about it in our previous post. This value tells us how many such users can log in at the same time.

• userType: The auth layer currently supports students and teachers as users and this key tells us which kind of a user is logging through the auth layer.

The text strings involved in the user interface

New workflow

The full workflow of the auth layer

To identify which group a user belongs to, the URL is appended with an additional parameter called group.

A sample URL looks as follows:

http://auth.avantifellows.org/?purpose=attendance&redirectTo=plio&redirectID=fatbjcbubu&subPurpose=plio&group=DelhiStudents&authType=ID

Before the auth layer loads for a user, the group name is extracted from the URL and a call is made to the backend to retrieve all details specific to that group.

Based on this object, the auth layer modifies its UI to conform to the rules in the object.

We also extended our analytics by adding two extra fields to our data warehouse: group and userType. This helps us analyse attendance metrics across groups.

As you can see, we have added two extra fields; the name of the group and the type of user (the last two columns)

Conclusion

The introduction of a group-specific object decreases the development time and helps us onboard a new group faster. Each object contains rules of a group for the auth layer app to follow and conform. Whenever a new group needs to be supported, all the required rules are stored in an object which is then added to our database for the auth layer to read. Previously, adapting to changes to a new group would take us a day or two. Now, it takes us less than a day. Currently, we support Haryana, Delhi, Himachal Pradesh, Vigyan Jyothi and Remote Learning Programs.

Future work

We currently still need development time to onboard new groups. Adding the list of users and the group object requires developer resources. We are working on building a UI that will allow organizations to add their own groups. This can reduce development time to zero!