Minimum Requirements
PostgreSQL: Version 13.8 or higher Please ensure your system meets these requirements before proceeding with the following steps:- Set Up & Run Permify Service
- Model your Authorization with Permify Schema
- Store Authorization Data & Schema
- Perform Access Check
Want to walk through this guide 1x1 rather than docs ? schedule a call with an Permify engineer.
Set Up Permify Service
You can run Permify Service with various options but in that tutorial we’ll run it via docker container.Run From Docker Container
Production usage of Permify needs some configurations such as defining running options, selecting datastore to store authorization data and more. However, for the sake of this tutorial we’ll not do any configurations and quickly start Permify on your local with running the docker command below:- Port 3476 is used to serve the REST API.
- Port 3478 is used to serve the GRPC Service.
- Authorization data stored in memory.
You can examine Deploy using Docker section to get more about the configuration options and learn the full integration to run Permify Service from docker container.
Test your connection
You can test your connection with creating an HTTP GET request,Model your Authorization with Permify Schema
After installation completed and Permify server is running, next step is modeling authorization with Permify authorization language - Permify Schema- and configure it to Permify API. You can define your entities, relations between them and access control decisions of each actions with using Permify Schema.Creating your authorization model
Permify Schema can be created on our playground as well as in any IDE or text editor. We also have a VS Code extension to ease modeling Permify Schema with code snippets and syntax highlights. Note that on VS code the file with extension is “.perm”. Let’s create our authorization model. We’ll be using following a simple user-organization authorization case for this guide.-
The
userentity represents users. This entity is empty because it’s only responsible for referencing users. -
The
organizationentity has its own relations (adminandmember) which related with user entity. This entity also has 2 actions, respectively:- Organization member and admin can view files.
- Only admins can edit files.
For implementation sake we’ll not dive more deep about modeling but you can find more information about modeling on Modeling Authorization with Permify section. Also you can check out Real World Examples section to better understand some familiar use cases modeled with Permify Schema.
Configuring Schema via API
After modeling completed, you need to send Permify Schema - authorization model - to Write Schema API for configuration of your authorization model on Permify authorization service. Example HTTP Request on Postman:| Required | Argument | Type | Default | Description |
|---|---|---|---|---|
| [x] | tenant_id | string | - | identifier of the tenant, if you are not using multi-tenancy (have only one tenant) use pre-inserted tenant t1 for this field. |
| [x] | schema | string | - | Permify Schema as string |
/v1/tenants/{tenant_id}/schemas/write
Store Authorization Data
After you completed configuration of your authorization model via Permify Schema. Its time to add authorizations data to see Permify in action. You can write relationships and attributes as ACLs by using Write Data API For our guide let’s grant one of the team members (Ashley) an admin role. Example HTTP Request on Postman:| Required | Argument | Type | Default | Description |
|---|---|---|---|---|
| [x] | tenant_id | string | - | identifier of the tenant, if you are not using multi-tenancy (have only one tenant in your system) use pre-inserted tenant t1 for this field. |
| [x] | tuples | array | - | Can contain multiple relation tuple object |
| [x] | entity | object | - | Type and id of the entity. Example: “organization:1” |
| [x] | relation | string | - | Custom relation name. Eg. admin, manager, viewer etc. |
| [x] | subject | string | - | User or user set who wants to take the action. |
| [ ] | schema_version | string | 8 | Version of the schema |
/v1/tenants/{tenant_id}/data/write
Created relationship: organization:1#admin@user:1
Semantics: User 1 (Ashley) has admin role on organization 1.
Perform Access Check
Finally we’re ready to control authorization. Access decision results computed according to relational tuples and the stored model, Permify Schema action conditions. Lets get back to our example and perform an example access check via Check API. We want to check whether an specific user has an access to view files in a organization. Can the user 1 view files on organization 1 ? POST/v1/tenants/{tenant_id}/permissions/check
| Required | Argument | Type | Default | Description |
|---|---|---|---|---|
| [x] | tenant_id | string | - | identifier of the tenant, if you are not using multi-tenancy (have only one tenant in your system) use pre-inserted tenant t1 for this field. |
| [x] | entity | object | - | name and id of the entity. Example: organization:1. |
| [x] | action | string | - | the action the user wants to perform on the resource |
| [x] | subject | object | - | the user or user set who wants to take the action |
| [ ] | schema_version | string | - | get results according to given schema version |
| [ ] | depth | integer | 8 | - |
