Feature enhancement ft. access control

[kushagra189]

This issue is being created to cumulate all the subsequent pending issues with access control feature enhancement with the intent to track them all together. New issues, if required must be tagged under this.

Here are the intended flows of access control from the user and application perspective.

Client Application setup and superuser flow

User resource interaction flow

Based on the above flows, the following tasks are pending in order to complete the feature requirements for access control implementation.

• Implement default client for default permissions - Currently default permissions are handled at a hardcoded base path. However, this should be made configurable.
• Enable super user configuration - A super user configuration needs to be supplied as a part of the existing access control configuration (listed under security definitions). Using this, a superuser/admin access can be created for all endpoints of the client application (including the permission endpoints)
• Permission endpoints need to be protected - Currently permission endpoints are open and not decorated. Once the superuser/admin config is in place, we can enable the cabin authorization for these too.
• Document client-specific user stories and supply pet-store examples for the same - For handling resource permission management, clients need to write their endpoint logic. For example, in case a user has access to create (POST) a resource, the latter should automatically have permission to update (PUT/PATCH) and delete (DELETE) resources in addition to fetching (GET) resources. This sort of user story needs to be documented so that onboarding applications can handle the logic for permission creation on their end.
• Configurable identifiers for permissions - Low priority issue, but we need to provide a way to configure the identifiers used for storing permissions.