Implement RBAC security endpoints

Question

Introduction

Once we have made a functional first implementation of our database management system RBAC #3375, we will proceed to make the endpoints for the administration of this.

Endpoints definition

We must make the following endpoints in order to cover the functionalities as indicated in #3287 :

Roles and policies management

Customizing RBAC must be as simple as possible, so a catalog of new API endpoints will be provided to operate the CRUD cycle of roles and policies: - PUT /security/role: creates a new role given a name, a rule and optionally the ids of policies related to it. - GET /security/roles: lists all existing roles and their details. - GET /security/role/:role_id: gets the full definition of a role given its id (including policies related to it) - POST /security/role/:role_id: updates an existing role. It allows changing the rule, name or relating policies. - DELETE /security/role/:role_id: deletes an existing role. It should also remove all the relationships to any policies. - PUT /security/policy: creates a new policy given a name and a definition. - GET /security/policies: lists all existing policies and their details. - GET /security/policy/:policy_id: gets the full definition of a policy given its id (including name and definition) - POST /security/policy/:policy_id: updates an existing policy given its id. - DELETE /security/policy/:policy_id: deletes an existing policy. It should also remove all the relationships to any roles. - POST /security/role/:role_id/policy/:policy_id: attaches a role and a policy. - DELETE /security/role/:role_id/policy/:policy_id: detaches a role and a policy.

Pending

• [x] PUT /security/role
• [x] GET /security/roles
• [x] GET /security/role/:role_id
• [x] POST /security/role/:role_id
• [x] DELETE /security/role/:role_id
• [x] PUT /security/policy
• [x] GET /security/policies
• [x] GET /security/policy/:policy_id
• [x] POST /security/policy/:policy_id
• [x] DELETE /security/policy/:policy_id
• [x] POST /security/role/:role_id/policy/:policy_id
• [x] DELETE /security/role/:role_id/policy/:policy_id

该提问来源于开源项目：wazuh/wazuh

Answer 1

Status update

We've been debating the functions and uses of these endpoints and the RBAC database, now I'm going to comment on the changes with respect to the first definition and the current state of development.

We will start by commenting that currently we are not following some good practices for the spec of our RESTful API, as we can see in the following link PUT-POST in RESTful API . As we can see the PUT method is idempotent, which means that if the request is executed multiple times the result must be the same as if we execute it only once, this means that the PUT method must be used to modify existing entities in the system or to create a specific entity which we create with a identifier in the URL, the POST however does not have the feature of being idempotent which causes that if we execute the request N times, in the end we should have N different entities. Therefore it is necessary to modify all our spec to adjust it to the use of good practices. From here I will comment the endpoints in the same order that in the first definition but placing the correct method as we have indicated:

• POST /security/role: The method has been modified to POST, for this endpoint initially the definition said that a new role would be created giving its name, rule and optionally a list of associated policies. We decided to remove the option to add a list of associated policies due to problems with concurrency. The problem is that SQLAlchemy in combination with SQLite3 uses sessions for possible users who are in the system so that one user can be adding a role while another is deleting it, causing a race condition. We have decided to leave the functionality of adding policies to a role to the endpoint created for this: PUT /security/role/:role_id/policy/:policy_id, this method has also seen its method altered.

• GET /security/roles: At first this endpoint indicated that all roles should be listed with their details, which was interpreted as all their information, this has been redefined and it has been decided to show only the name and rule of each role.

• GET /security/role/:role_id: This endpoint is working correctly, we must change the database definition of the policy element of the Policies object (varchar to text).

• PUT /security/role/:role_id: This endpoint has seen modified its method, initially in that method could modify the policies as well as the name and rule, we have chosen to remove this feature and leave the union of role-policy to the endpoint created for this: PUT /security/role/:role_id/policy/:policy_id

• DELETE /security/role/:role_id: This endpoint has not been modified.

• The policy endpoints have not been modified.

• PUT /security/role/:role_id/policy/:policy_id: The method of this endpoint has been changed, this endpoint is exclusively responsible for creating relationships between roles and policies, if a role or policy does not exist should cancel the operation.

• DELETE /security/role/:role_id/policy/:policy_id: This endpoint has not seen its original definition modified.