Authorizing the creation of child resources

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.