A2 Roles
When designing an application we might need to avoid that malicious users access other users' content. In order to manage authentication-related issues, roles can be defined and assigned to users. The implementation of the authorization mechanism is done using Access Control Lists. The main idea is to create roles and assign them to users. Sometimes it may even be useful to create one role per user, to get the finest granularity possible, while in other situations you will give the asterisk permission for admin functionality.
A role is composed of resources and permissions over resources. Resources are specific route paths (used by the HTTP requests) and the permissions are actions (HTTP requests type) that can be performed over the resource.
The A2 module, provides a REST API with the routes to manage users, their roles and also check the authentication and authorization.
The module uses Access Control Lists (ACL) for the roles administration. The roles have permissions over their resources (RESTful HTTP routes, e.g. /users) and the permissions are actions that can be performed by the given role over the resources (the HTTP request type, e.g. GET, POST, PUT, DELETE or *).
The users with admin role can change the roles, resources and permissions. They can also add or remove a role from a specific user. (Note: an admin user can remove the admin role from another user but it cannot remove the admin role from itself as there must always be at least one admin in the database.)
The administration view from A2 allows to see the defined roles. For instance, the admin role has the following information about permissions:
Figure 1.: A2 allows to see the permissions of the different roles. For instance, we can see that the admin has all permissions.