What Permission Systems Are
To ensure a resource’s security, integrity, and performance, as well as prevent its data from unauthorized use, you can consider limiting access to resources your Cloudentity client application deals with. In Cloudentity, it can be done by configuring a permission system. This is a tenant-wide configuration -— once set, it covers all applications and workspaces within a tenant, so there’s no need to create an individual permission system for every workspace.
However, your tenant isn’t limited by a single permission system. You can create as many permission systems, as you need: for example, per an identity pool or application-dedicated and enable individual policies for each one.
Cloudentity’s Permission Systems facilitate permission checking and handling access to resources using the Google Zanzibar-inspired database with fine-grained permissions.
For a permission system to run, you must set up a schema—the outline of how the access is to be granted. The schema connects objects: a resource—the target to be accessed, and a subject—what or who will access the resource. In the example below, the schema defines the application’s permissions toward the email address.
How Permissions Work
Let’s say a permission system schema holds the following:
- Email address as
- Reader as
- Read as
- Application as
The schema delineates the access to the resource and the level of this access. The resource-subject connection is determined by relations, which are characterized by permissions.
In our example, we see that the application is the
reader for the email address,
and the reader has the
With a schema like this, you don’t have to look for attributes assigned to the subject. Instead, you make an exact check: whether the application can read the email address.
The permission system looks for the path
email address > read > reader > application. If this path exists, the application can read
the email address, and you get
true in the response. Otherwise, the response is