Role Based Access Control

[YashKumarVerma]

Google Summer of Code 2021 Wrap-up

Objectives

• Role-Based Access Control System
  • To remove the old attribute-based control system.
  • To implement a role-based access control system.
  • To come up with a new structure for the routes file and migrate old routes to new formats.
  • To cover all routes defined in the application under a control system without explicit declarations.
  • To provision dynamic roles in the system which can be configured/defined as per needs.
  • To load the definitions about the roles in the system via a database in place of static files.
  • To create a responsive and dynamic admin panel in React to configure the rules in real time.
  • To declare APIs that allow the admin to configure the portal in real time.
• Caching database calls
  • To research a method that works consistently with all functions with minimum changes.
  • To write a robust library (discussed later) to dynamically cache any given function.
  • To future proof the library by extending support for typescript if migration/upgrade happens.
  • Robust testing of the caching library to ensure consistent results.
  • Decide which functions are to be cached
• Objectives completed which were originally not part of the proposal
  • Break the codebase into modules/services that deal with specific functionality.
  • Streamlined use of environment variables in the application.
  • Single point configuration for databases and roles services.
  • Refactor a major part of the main application.
  • Wrote documentation for parts of the project that were not under the scope of the proposal.
  • Established a new code style based on Airbnb's guide.
  • Fixed almost all critical linting issues.
  • Published a standalone library on NPM for caching that can be used in other projects as well.
• pull request

---

Role Bases system

Services Logging their details at runtime

Role definitons

Default role definitions: changes done here are hardcoded into the application, and are automatically seeded into the database at runtime. This allows deploying the same codebase to multiple clusters with similar configurations, even if all are running on different databases. use case: different branches of a pathology lab

note the hierarchy in the roles that are implemented. Each higher role automatically gets all rights of a lower one.

Documentation: all services written have extensive documentation that should aid developers working on the project.

Middleware: since the routes are bound to the application during runtime based on the configurations defined in routes.json, middleware is used to enforce the rights access.

APIS

• to read roles data

  GET /api/roles
  

• to write roles data

  POST /api/roles
  

Architecture

There has been a fundamental change in the way the application is structured. Even when I was limited on time, I have tried to club together similar functionality in form of modules or services (located in /services). This allows easy testing and a single point of contact for all operations. Earlier there was a lot of redundancy in the codebase, which is now removed as all calls are made to a single service and code is not duplicated.

Dependency

In order for the cache system to work, a new dependency of redis had to be added. The changes in the deployment will be needed to include a redis container for the cache service.

Note

• full GSoC documentation is here which includes the cache module as well as the admin interface.

[YashKumarVerma]

@birm if you could review this, I would fix the conflicts at once and make it ready to merge

[birm]

I've added a topic branch, as this configuration is enough different from the original that it's good to have the option. Maybe we'll switch which one is default at some point? Honestly, it's a little difficult for us to feel out what is useful to our users no matter how many meetings with them we have 😄

Of course, this is great work, and I thought I'd already pulled this into a topic branch. Apologies that it's taken this long.

[birm]

Suggested change

**Note**: this pull request is not initiated to be merged, but to have a single point status check of the project progress.

(or the entire file?)