Security Statement


  • Samarth / we / us/ our : Project Samarth implemented by the Institute of Informatics and Communication, University of Delhi South Campus and funded by the Ministry of Education.
  • Samarth eGov Suite / Samarth ERP : Samarth eGov system accessible online through a  URL obtained on and fully qualified domains.
  • Institution / they / them / their : Higher Education Institution using Samarth eGov Suite.
  • User / End-User /  you / your : Institution’s users (employees, students, self-registered or any user account created by the institution on Samarth eGov Suite).
  • “Personal Information” in this privacy statement refers to any information from which a user’s identity is apparent or can be reasonably ascertained.


Authentication is the process of verifying the identity of a user and is the basis of the login feature in Samarth. Samarth login uses an identifier (e.g. a username or an email address) and a secret token (e.g. a password or an access token) to ascertain if the user is the one as claimed to be.


Authorization is the process of verifying if  a user has the correct  permission to commit a specific task.  Samarth uses two authorization methods: Access Control Filter (ACF) and Role-Based Access Control (RBAC).


Access Control Filter (ACF) is a simple authorization method best used by applications that only need some simple access control. As the  name indicates, ACF is an action filter that can be used in a controller or a module. When a user  requests  to execute an action, ACF will check a list of access rules to determine if the user is allowed to access the same .


Role-Based Access Control (RBAC) provides a simple yet powerful centralized access control. Samarth uses a General Hierarchical RBAC. Using RBAC involves two parts: building up the RBAC authorization data, and using  the authorization data to perform access checks in places where it is needed.

Samarth stores authorization data in a database for dynamic role and permission management. The databases are encrypted using industry standard AES-256 encryption algorithm.

For building authorization data for RBAC, Samarth follows the process below:

  • Defining roles and permissions.
  • Establishing relations among roles and permissions.
  • Defining rules.
  • Associating rules with roles and permissions.
  • Assigning roles to users.


In order to provide increased security for user passwords, including the worst case scenario of  the application being breached; we need to use a hashing algorithm that is resilient against brute force attacks. Samarth uses this to securely generate and verify hashes. When a user provides a password for the first time (e.g., upon registration), the password is hashed. The hash is then associated with the corresponding model attribute and is safely stored in the database for later use. When a user attempts to log in, the submitted password is verified against the previously hashed and stored password.


Samarth allows administrators to reset passwords for the users from the interface following a  standard password generation process.

Samarth offers a “reset password” via email feature to users. When resetting a password via email, a user generates a secure token which is saved to the database and then sent to the registered email of the end user via email which in turn, allows them to prove ownership of that account. Pseudo-random data is used to generate the unique and hard to guess secure token, preventing an attacker from predicting the token's value and resetting the user's password.


Samarth uses secure connection via SSL.


Data is prefixed with a hash generated from the secret key and data, to allow for verification that the data hasn't been tampered with, by a third party or corrupted, in any way.


Samarth Databases are not shared between institutions. Each institution is provided a separate Database.

All Database (DB) clusters use the industry standard AES-256 encryption algorithm to encrypt your data on the server that hosts your DB clusters. All DB instances, logs, backups, and snapshots are also encrypted.


We reserve the right to update this Security and Privacy Statement at any time, and will seek to inform you of substantial updates. We may also notify you in other ways from time to time about the processing of your personal data.