Refactor Access Control

[kushagra189]

Few enhancements are required for the implemented access control functionality:

• Access control configuration should include a parameter for the path at which the admin/permission endpoints will be hosted, e.g. the default could be /admin/access-control as it is now.
• Further we need to move access control configuration as a part of the security configuration and the complete module must move to the security module.

[uniqueg]

Thinking about the first point some more, I don't think it is really required. It is very hard to provide a client for an arbitrary user-provided admin/permission API (after all, it's not just the base path, but the endpoint or endpoints, including semantics, that we would need to know), and I don't think it's worth going there. Instead we should probably focus on adding a client for the default API, and for that we know the routes. Users might still be able to reuse that client if they host a /permissions API at the expected base path (if all they are doing is modifying the behavior of the default endpoints). And if they wanna add a completely different API, then they would also need to implement the client along with it.

So rather than updating the model, I would rather create an issue to implement a client for the default permission endpoints, which then can be used in the controller logic of a FOCA app. A second issue would then be to use that client in the petstore example to automatically set the permissions of a newly created resource such that the creater becomes the owner of the resource, i.e., they should be allowed to read (GET/petsandGET /pets/{id}) and delete (DELETE /pets/{id}`) the resource. A third issue should focus on implementing what it takes to set owner permissions also for the permissions for that resource themselves in order to allow a user to, e.g., share the resource with another user.

[kushagra189]

Closing this issue and bifurcating it into separate small tasks will be easier to monitor.