Identifier of the tenant, if you are not using multi-tenancy (have only one tenant) use pre-inserted tenant <code>t1</code> for this field. Required, and must match the pattern \“[a-zA-Z0-9-,]+\“, max 64 bytes.
object
*
Required
object
PermissionCheckRequest is the request message for the Check method in the Permission service.
metadata
object
metadata
object
PermissionCheckRequestMetadata metadata for the PermissionCheckRequest.
schema_version
string
schema_version
string
Version of the schema.
snap_token
string
snap_token
string
The snap token to avoid stale cache, see more details on Snap Tokens
depth
integer
depth
integer
Query limit when if recursive database queries got in loop
entity
object
entity
object
Entity represents an entity with a type and an identifier.
type
string
type
string
id
string
id
string
permission
string
permission
string
The action the user wants to perform on the resource
subject
object
subject
object
Subject represents an entity subject with a type, an identifier, and a relation.
type
string
type
string
id
string
id
string
relation
string
relation
string
context
object
context
object
Context encapsulates the information related to a single operation,
including the tuples involved and the associated attributes.
tuples
array
tuples
array
A repeated field of tuples involved in the operation.
attributes
array
attributes
array
A repeated field of attributes associated with the operation.
data
object
data
object
Additional data associated with the context.
arguments
array
arguments
array
Additional arguments associated with this request.
In Permify, you can perform two different types access checks,
resource based authorization checks, structured in the following form: Can user U perform action Y in resource Z ?
subject based authorization checks, structured in the following form: Which resources can user U edit ?
In this section we’ll look at the resource based check request of Permify.
In high level, access of an subject related with the relationships or attributes created between the subject and the resource. You can define this data in Permify Schema then create and store them as relational tuples and attributes, which is basically forms your authorization data.
Permify Engine to compute access decision in 2 steps,
Looking up authorization model for finding the given action’s ( edit, push, delete etc.) relations.
Walk over a graph of each relation to find whether given subject ( user or user set ) is related with the action.
Let’s turn back to above authorization question ( “Can the user 3 edit document 12 ?” ) to better understand how decision evaluation works.
When Permify Engine receives this question it directly looks up to authorization model to find document edit action. Let’s say we have a model as follows
entity user {}entity organization { // organizational roles relation admin @user relation member @user}entity document { // represents documents parent organization relation parent @organization // represents owner of this document relation owner @user // permissions action edit = parent.admin or owner action delete = owner}
Which has a directed graph as follows:
As we can see above: only users with an admin role in an organization, which document:12 belongs, and owners of the document:12 can edit. Permify runs two concurrent queries for parent.admin and owner:
Q1: Get the owners of the document:12.
Q2: Get admins of the organization where document:12 belongs to.
Since edit action consist or between owner and parent.admin, if Permify Engine found user:3 in results of one of these queries then it terminates the other ongoing queries and returns authorized true to the client.
Rather than or, if we had an and relation then Permify Engine waits the results of these queries to returning a decision.
Identifier of the tenant, if you are not using multi-tenancy (have only one tenant) use pre-inserted tenant <code>t1</code> for this field. Required, and must match the pattern \“[a-zA-Z0-9-,]+\“, max 64 bytes.
Body
application/json
PermissionCheckRequest is the request message for the Check method in the Permission service.
The pack methods provided by protobuf library will by default use
'type.googleapis.com/full.type.name' as the type URL and the unpack
methods only use the fully qualified type name after the last '/'
in the type URL, for example "foo.bar.com/x/y.z" will yield type
name "y.z".
JSON
The JSON representation of an Any value uses the regular
representation of the deserialized, embedded message, with an
additional field @type which contains the type URL. Example:
If the embedded message type is well-known and has a custom JSON
representation, that representation will be embedded adding a field
value which holds the custom JSON in addition to the @type
field. Example (for message [google.protobuf.Duration][]):
A URL/resource name that uniquely identifies the type of the serialized
protocol buffer message. This string must contain at least
one "/" character. The last segment of the URL's path must represent
the fully qualified name of the type (as in
path/google.protobuf.Duration). The name should be in a canonical form
(e.g., leading "." is not accepted).
In practice, teams usually precompile into the binary all types that they
expect it to use in the context of Any. However, for URLs which use the
scheme http, https, or no scheme, one can optionally set up a type
server that maps type URLs to message definitions as follows:
If no scheme is provided, https is assumed.
An HTTP GET on the URL must yield a [google.protobuf.Type][]
value in binary format, or produce an error.
Applications are allowed to cache lookup results based on the
URL, or have them precompiled into a binary to avoid any
lookup. Therefore, binary compatibility needs to be preserved
on changes to types. (Use versioned type names to manage
breaking changes.)
Note: this functionality is not currently available in the official
protobuf release, and it is not used for type URLs beginning with
type.googleapis.com. As of May 2023, there are no widely used type server
implementations and no plans to implement one.
Schemes other than http, https (or the empty scheme) might be
used with implementation specific semantics.