User Role Management and How to implement it

Traditionally, the responsibility of role management has been solely vested in the administrator, irrespective of the application's nature. This paradigm persists today, but what are the implications?

The basic structure of a role management section within an application basically involves the creation of a role, the creation of permissions, and attaching permissions to specific roles (this way we can ensure that a user is given a role rather than a permission, as permissions belong to roles). Ideally, the administrator or super administrator has the rights to create, give, and change roles. One of the most common ways of facilitating roles to different kinds of users is by:

1. Incorporating role selection on the registration page - robust applications like digital libraries can provide customized features and access levels based on user roles (scholar, student, normal user). During the sign-up process, users can choose their appropriate role to ensure a personalized experience.
2. Giving predefined roles on registration - with this option a user registered and is automatically given a role like "user".
3. Changing user roles in the admin panel - the administrator or super administrator has the capabilities to change user role from the admin panel.

It all sounds good and practical as there is normally a security feature in-place, especially on "changing user roles in the admin panel" whereby packages like spatie permissions are normally used to ensure that roles management is effective. But is utilizing spatie enough? Of cause not. Although spatie works, it does not account to the fact that anyone who can manage to get their hands onto the administrator login details can login and change anyone's role. How do you then defend against that?

There are multiple ways to adding security layers on your application. We are not going to focus on firewalls and etc. Now, besides ensuring that the created user account has a verified email, the implementation includes:

1. 2-factor authentication - this has become a common security feature on a lot of applications, in fact it is a minimum-security requirement.
2. FIDO2 -this is a latest standard that incorporates the web authentication (WebAuthn) standard. FIDO allows organizations to apply the WebAuthn standard by using an external security key, or a platform key built into a device; to sign in without a username or password (this is basically the usage of passkeys to login to your account).

With the abovementioned you can guarantee that your application meets the minimum-security threshold, there are other ways of securing your application besides the abovementioned. But cross-site scripting and other vulnerabilities should be mitigated before attempting to integrate the abovementioned.

Now that we have cleared the air, let us continue on how the user can request a role change. Enabling users to request role changes can simply take place with a simple role change request from the user panel which sends an email from the user to the application's support team. Given that different roles possess distinct permissions and functions, the administrator receives these requests and generates a unique random string specific to the requested role. This string is then communicated to the user, who must subsequently submit it through a designated form within their user panel. Upon submission, the code executes the next step of the role change process which will effectively lead to the updated user role upon approval.

We must remember that although we have implemented our security layers, our administrator does not have the right to change anyone's user role, as the role change is initiated from the user panel by that user (not from the admin panel).  Administrators are limited to two key actions: approving role change requests and suspending user accounts. Suspended accounts are automatically deleted after a period of inactivity lasting between 30-90 days. The abovementioned logic works in these steps:

1. Setup a role change request logic - in the admin panel, there should be a "role change request" section under the user's section. This will allow the super administrator/s to generate random strings which will be associated with specific role change requests. The string should be hashed before being stored in the database with an expiration time and should only be usable once.
2. Setup a role request logic - the user should have a form that can only be usable at least 30 days after the account has been activated. The form should allow the user to request a role change to any user roles you allow them to switch to. This sends the administrator/s a unique token with the user details (name, email, and the role). 
3. Role change Approval - after the user has submitted the request code they received from the administrators; the administrator or super-admin should be able to approve the request which then completes the user role change. This means that inside the "role change request" section (you can name it whatever you want), there should be an option to see the requests made, whereby the authorized personnel can approve those requests based on the submitted string, unique token, and user details.

With this attempt you can ensure that user accounts are protected and role change requests do not put your own access in danger. This way of role management is currently being tested, and we welcome any feedback. Send us an email on info@wabnev.co.za and let us hear what you think.