Authentication, Authorization and Auditing

Managing user identities and roles for authentication and authorization, as well as keeping track of who does what, are basic building blocks across most of the apps and platforms we build.

As different projects may have quite different Authentication, Authorization and Auditing requirements, we list here some relevant implementations from past and current projects, so that new projects with similar requirements can benefit from existing knowledge (or code, where applicable).

Wildlife Insights

Original documentation: https://github.com/ConservationInternational/WildlifeInsights---API-Service/blob/develop/docs/README_RBAC.md (may not be accessible to everyone -- I'll see if we can create a Vizzuality clone for reference)

Authentication

SSO microservice (https://github.com/ConservationInternational/Wildlife-Insights---SSO, as above). Originally meant to allow authentication via different Passport strategies. Only local strategy implemented.

Authorization

RBAC system with roles that apply to three different entity types: projects, initiatives (groups of projects), organizations (groups of projects and initiatives). Besides roles on these entities, users can also have a single generic role, which is used for some compartmentalized "super-admin" tasks to reduce the attack surface.

Roles on projects/initiatives/permissions can be Viewer (read-only access), Editor (can edit most resources of an entity but not manage the entity itself nor grant roles to other users), Owner.

Users with any role on an ancestor entity (organization or initiative) are granted an implicit viewer role on the descendant initiatives or projects. This is handled via PostgreSQL triggers: when roles are changed on any entity, implicit role sets are computed and grant/revoke operations are performed by creating/updating/deleting rows in the pivot tables that record user/role/entity associations.

Permission checking is implemented via a NestJS middleware. Each REST endpoint and GraphQL query/mutation can be decorated with permissions decorator that dictate which permission a user must have in order to be allowed access to the endpoint/query/mutation.

A handful of REST endpoints are public (no authentication requited). Likewise a few GraphQL queries are public; this is implemented through an ad-hoc hack as a clear separation of concerns was not possible through the NestJS GraphQL module at the time this was implemented.

Climate Change Laws of the World/Transition Pathways Initiative

We use Devise to handle the authentication, a very standard gem used extensively in the Rails world: https://github.com/heartcombo/devise

And we handle the authorization via the CanCanCan gem: https://github.com/CanCanCommunity/cancancan

Authorization abilities are defined in this model: https://github.com/Vizzuality/laws_and_pathways/blob/develop/app/models/ability.rb

We have three levels of access: Super User > Publisher > Editor. And inside Publisher and Editor there is compartmentalisation related with the two sides of the application: CCLOW and TPI. So Publishers and Editors can be constrained to just a set of tables.

We also handle some specific attributes management rules in the model via validation: https://github.com/Vizzuality/laws_and_pathways/pull/246/files#diff-e2f31da7a09f3ac90bee9d7de263ff04

Note by Agnieszka: [this] would be my choice probably 99% of the time for Rails apps

Mars MGIS platform

Details: https://github.com/Vizzuality/mgis/blob/develop/docs/README_permissions-management.md

Authentication

Integration with Mars' SSO workflow, which is based on Azure AD and OAuth2.

Details and references: https://github.com/Vizzuality/mgis/blob/develop/docs/README_OAuth2.md

Authorization

RBAC for endpoint-level authorization (all users can read all data; some users may create and update data with given constraints - see ABAC below; some users may manage all the platform's data).

ABAC for row-level authorization (users who can create and update data may do so only for data that belongs to business units or product groupings they have oversight of). This is done at the API level (i.e. not via PostgreSQL row-level security); the business requirement was mainly to validate requests to submit data in bulk: if a user would not be allowed to write one or more of the rows they are trying to write, the whole submission is rejected as this would normally mean that there are spurious rows in the data.

The implementation was a quick rehash of the Wildlife Insights permission management system, without the multi-tenancy components, and plus the row-level ABAC component.