Status | |
|---|---|
Impact |
|
Driver | |
Approver | |
Stakeholders | Antonio Verni Niccolò Pasquetto Riccardo Costa Paurav Munshi Alessandro Falezza Andrei Dodu |
Informed | |
Due date | When does this decision need to be made by? |
Outcome | Option 1: RBAC |
Add your comments directly to the page. Include links to any relevant research, data, or feedback. |
Summarize this decision in the table below. Type /date to quickly add the due date and @mention the driver, approver, contributors, and informed to keep everyone on the same page.
|
At the moment the user’s permission schema is realized with four tables in the DB:
USERS: contains users and passwords
GROUPS: contains users’ groups
MENUITEM: contains all functionalities among menuitems, submenus and buttons
GROUPMENU: contains the associations between GROUPS and MENUITEM
This is ok for the Swing GUI, but in a REST application the workflow is slighty different
It would be nice to use the same DB tables, by adding new ones
Option 1: | Option 2: | |
|---|---|---|
Description | ||
Pros and cons |
|
|
Estimated cost |
|
Add action items to close the loop on open questions or concerns
Different analysis led to the same conclusion: in order to improve (in the short-term) the actual permissions system in the web application (core+api+ui) with minimum changes it will be enough to develop the proposed solution (Paurav Munshi) which introduces:
a DB table for “Entitlements” (CRUD for each entity)
a DB table for “Group-Entitlements” definition (linked to the actual USERGROUP)
a DB table for “User-Usergroup” association that allows multiple roles to the same user (it will affect also how the application works in non-web environment (core+gui)
There’s a 
Doesn’t provide fine graned policies as ABAC