Add contextual tuples for global read and admin access

[nsklikas]

IAM-910

• Prefix the global object
• Use contextual tuples so that logic for global read and admin access is not persisted to openfga

One issue that we need to look into is that users will be able to create a role or a group called __system__global and it will collide with our tuples. One way around this is to add a check either on the roles/groups API or on the openfga module to prevent writes and deleted of objects that start with the system prefix. I can work on this on this PR or I can create an issue (I prefer the latter).

Once this PR is merged, we will no longer need to add the tuples with <resource>:global to openfga. I will remove them from the wiki.

I have tested it manually, but please take some time to test it yourselves as I might have missed some functionality.

Closes #290

[shipperizer]

need to update wiki docs and seed.sql as well

[shipperizer]

ok went a bit deeper to recall what happens under the hood

so from an authorization perspective what we need to check when we do a GET /api/v0/<resources> is to simply check if we have the can_view permission on <resource>:<global_tag>

from this perspective all is the same across different backends,be it OpenFGA or Hydra/Kratos etc

where it differs between resources is when we ask for the resources to the underlying backend, so for Hydra/Kratos/Oathkeeper we get all due to issues with pagination and filtering

for OpenFGA resources (role and group) instead we are able to show only what we are matched with via the can_view, which is different from the assignee

in the latter case having the contextual tuple might be beneficial if we wanted to say "see all roles, no matter what`, not sure we want that at this point though

[shipperizer]

ok went a bit deeper to recall what happens under the hood

so from an authorization perspective what we need to check when we do a GET /api/v0/<resources> is to simply check if we have the can_view permission on <resource>:<global_tag>

from this perspective all is the same across different backends,be it OpenFGA or Hydra/Kratos etc

where it differs between resources is when we ask for the resources to the underlying backend, so for Hydra/Kratos/Oathkeeper we get all due to issues with pagination and filtering

for OpenFGA resources (role and group) instead we are able to show only what we are matched with via the can_view, which is different from the assignee

in the latter case having the contextual tuple might be beneficial if we wanted to say "see all roles, no matter what`, not sure we want that at this point though

after chat, all is clear, my bad