Authorization Model for sAPPat

[jultra]

I'm thinking we can use a role-based approach which will initially have the following roles:

Basic Role-based Authorization Model

• Administrator. Admin can do anything.
• Manager. A manager has CRUD permissions to all the data of the application, except those that are related to User management.
• Contributor. A contributor has CRUD permissions to the data he/she uploaded in the application.
• Viewer. A viewer can only view data from the sAPPat database and has no create/update/delete permissions.

Address-based Authorization In addition to this basic role-based authorization model, the data elements that can be updated/created by contributors will be limited to the geographic location that the contributor is assigned to. For example, a contributor assigned to a Palo, Leyte municipality will be able to add only those data belonging to the jurisdiction of Palo, Leyte Municipality.

[jultra]

Anu @vmromero, what do you think?

[vmromero]

Yeah. It can start like that and then later on the records can be relegated to the entities should they wish to be involved in updating their own data. We have to ensure lang that the roles are configured in consonance to the current roles assumed by different actors (e.g., local government units and government line agencies.)

[jultra]

Aah, in that case, an attribute-based access control that combines the role, political unit, and other attributes like product or industry segment should do. A bit more complicated lang siya implement.

For example, we can have the ff policies:

• a user with role=editor, political unit=region, political unit value=8, industry segment = fisheries, will be able to CRUD all records under Region 8 and fisheries.
• a user with role=editor, political unit=municipality, political unit value=palo, industry segment=*, will be able to CRUD all records under the municipality of Palo.

What do you think?

On Fri, Jan 14, 2022 at 7:05 PM vmromero @.***> wrote:

Yeah. It can start like that and then later on the records can be relegated to the entities should they wish to be involved in updating their own data. We have to ensure lang that the roles are configured in consonance to the current roles assumed by different actors (e.g., local government units and government line agencies.)

— Reply to this email directly, view it on GitHub https://github.com/jultra/sappat/issues/6#issuecomment-1013022822, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABX7EOK36NN2B6EPIPLBV4TUV77QJANCNFSM5L6AGY5A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

[jultra]

I'm thinking we can add an organization model that carries the geographic information. Then we can assign a user to an organization with an appropriate role.

For example, we can have the tuple org x (Org_Name, Political Level, Jurisdiction) e.g, (LGU Palo, Municipal, Palo Leyte). Political level can either be municipal, provincial, regional, national. Then we can assign permissions to users using (User, Org_Name, Role) where role can either be admin, manager, contributor, viewer.

[jultra]

This function was implemented in this commit: 31a4a0c @vmromero