Five months ago, we launched a new schema language with the goal of reducing the complexity of designing applications' permissions systems and with the open sourcing of SpiceDB, the number of users working with the schema language is larger than ever. It's an exciting time to participate in the community building around SpiceDB and to see the applications that people have been capable of modelling. With that growth, we've observed patterns emerging in schemas and compiled some useful techniques for other users to use as they begin configuring their own permission systems.
Group membership
Scenario: Apply specific users or members of a group to a permission on an object type.
In this example, a group can have users as admins and as members.
Both admins and members are considered to have membership in the group.
A role can be applied to individual users and groups.
All individually applied users as well as members for applied groups will have the allowed permission.
Super-admin / site-wide permissions
Scenario: Given an organizational hierarchy of objects where (regular) admin users may exist for a single level of the hierarchy, apply permissions for a set of super-admin users that span across all levels of the hierarchy.
In lieu of adding a super_admin relation on every object that can be administered, add a root object to the hierarchy, in this example platform.
Super admin users can be applied to platform and a relation to platform on top level objects.
Admin permission on resources is then defined as the direct owner of the resource as well as through a traversal of the object hierarchy to the platform super admin.
Synthetic relations
The -> operator allows for walking a relation hierarchy in order to compute permissions. But what if a permission is intuitively thought of as multiple relation traversals? Synthetic relations can simulate multiple walks across permissions and relations.
Given the example hierarchy, portfolio can have folders, folders can have documents, we’d like a reader of a portfolio to also be able to read documents contained in its folders. The read on documents could be thought of as:
reader + parent_folder->reader + parent_folder->parent_portfolio->reader
The relation traversals can be modeled using intermediate, synthetic relations:
Recursive permissions
Scenario: Given a nested set of objects, apply a permission on the ancestors to its descendant objects.
In this example, a folder can have users with read permission. Additionally, users that can read the parent folder can also read the current folder. Checking read permission on a folder will recursively consider these relations as the answer is computed.
Get involved
We’re always looking to the community for ways to improve both the developer experience for writing schema configs as well as making the config language more powerful. In fact, several of these patterns can be credited to insightful questions initially asked by users in our Discord channel.
If you’re just getting started, here are some interesting existing issues to help get acquainted with schemas and of course you can create a new issue for an improvement you’d like to see.
- Add 'public' keyword/type: https://github.com/authzed/spicedb/issues/1
- Implement the Language Server Protocol: https://github.com/authzed/spicedb/issues/179
- Add support for mixins/templates/inheritance in schema: https://github.com/authzed/spicedb/issues/224
- CLI command for validating schemas: https://github.com/authzed/spicedb/issues/290
Join us on Discord to get feedback on your schema config and to discuss the ongoing development of SpiceDB.
Additional Reading
If you’re interested in learning more about Authorization and Google Zanzibar, we recommend reading the following posts:
