As a developer, we have to secure the exposed endpoints (APIs) according the desired permission rules.
openIMIS backend is configured with 2 authorizations layers:
- the django default (basic) permissions mechanism
- the RBAC ‘django-rules’ extensions
If any of the 2 layer grants the access, the access is given to the user.
openIMIS endpoints can be:
- django straight ‘views’ endpoints
- django-rest-framework endpoints (recommended)
- graphene GrapQL queries and mutations (via scheme definition)
At its very basis, backend modules can rely on:
- The django straight ‘views’ endpoints must be explicitly defined by the developers (please refer to https://docs.djangoproject.com/en/2.1/topics/security/ )
- The django-rest-framework, however, has been configured to enforce the default (type-based) django permissions mapping: GET on <module>.view_<model>, POST on <module>.add_<module>,...
- The graphene 'resolve_xxx' hook to access (query) object graph, and 'async_mutate' resolution for mutation
However, we recommend (and this is what is in place in reference modules such as claims,...) to enforce security in django model itslef (overriding the 'get_query' method). This ensures that security applies whatever endpoint technology (GraphQL, FHIR, ...) is exposing it.
For finer grained security (object-level) the django-rules module has been configured and is readily available for use (declaring predicates,...).