Authorizing the creation of child resources
When implementing authorization, you face a classic "chicken-and-egg" dilemma: how do you authorize users to create new resources when authorization typically depends on permissions that are granted after those resources exist?
In the case of resources that have relationships with other resources (commonly modeled using relation-based access control (ReBAC)), you can use the parent resource to authorize creation of child resources.
Here's an example ReBAC policy:
actor User {}resource Organization { roles = ["member"]; permissions = ["read", "create_repositories"]; "create_repositories" if "member"; "read" if "member";}resource Repository { roles = ["reader"]; permissions = ["read"]; relations = { organization: Organization }; "read" if "reader"; "reader" if "member" on "organization";}test "members can create repositories" { setup { has_role(User{"alice"}, "member", Organization{"acme"}); } assert allow(User{"alice"}, "create_repositories", Organization{"acme"});}
Here, you can see that a user's ability to create repositories is based on the
Repository
's parent resource, the Organization
. However, unlike most
ReBAC-oriented rules, the rule is placed on the parent, instead of the child
inheriting the rule from its relationship to the parent.
See also
For help authorizing the creation of resources without relationships to other resources, see Bootstrapping root-level resources.