@permitio/permit-strapi 1.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md ADDED
@@ -0,0 +1,139 @@
1
+ # permit-strapi
2
+
3
+ A Strapi 5 plugin that connects your Strapi application to [Permit.io](https://permit.io) for fine-grained access control. It supports RBAC, ABAC, and ReBAC out of the box, and enforces authorization on every API request without you having to touch your controllers.
4
+
5
+ ## What it does
6
+
7
+ By default, Strapi's built-in permissions work at the role level — a role either has access to a content type or it doesn't. This plugin adds a second enforcement layer that sits between the request and your controllers, giving you much more control over who can access what and under what conditions.
8
+
9
+ Once installed and connected, the plugin:
10
+
11
+ - Intercepts all `/api/` requests that carry a Bearer token
12
+ - Verifies the token and identifies the user
13
+ - Calls Permit.io to check if the user is allowed to perform the action on that resource
14
+ - Returns a 403 if the check fails, or passes the request through if it succeeds
15
+
16
+ Your existing Strapi setup does not need to change. The plugin registers a global middleware that handles enforcement automatically.
17
+
18
+ ## Requirements
19
+
20
+ - Strapi 5
21
+ - Node.js 22 (Node 23 is not supported by Strapi)
22
+ - A [Permit.io](https://permit.io) account
23
+ - For ABAC and ReBAC: a self-hosted Permit.io PDP. The cloud PDP only supports RBAC.
24
+
25
+ ## Running a self-hosted PDP
26
+
27
+ If you plan to use ABAC or ReBAC, you need a self-hosted PDP. The quickest way to run one locally is with Docker:
28
+
29
+ ```bash
30
+ docker run -p 7766:7000 \
31
+ --env PDP_API_KEY=<your-permit-api-key> \
32
+ permitio/pdp-v2:latest
33
+ ```
34
+
35
+ Use `http://localhost:7766` as the PDP URL when configuring the plugin.
36
+
37
+ ## Installation
38
+
39
+ ```bash
40
+ npm install @permitio/permit-strapi
41
+ ```
42
+
43
+ After installing, restart your Strapi server. The plugin will appear in the admin sidebar under the Permit.io section.
44
+
45
+ ## Getting started
46
+
47
+ 1. Open the plugin in the Strapi admin panel
48
+ 2. Enter your Permit.io API key and PDP URL
49
+ 3. Click Connect — the plugin will validate the key and sync your content types and roles to Permit.io automatically
50
+
51
+ From there, you can configure which content types are protected, set up attribute mappings for ABAC, or enable ReBAC per content type.
52
+
53
+ ## How authorization works
54
+
55
+ The plugin uses a two-layer model:
56
+
57
+ **Layer 1 — Strapi Users & Permissions**: controls which roles have access to which endpoints at all. You should grant full access per role here and let the plugin handle the fine-grained enforcement.
58
+
59
+ **Layer 2 — Permit.io middleware**: calls `permit.check()` on every request with the user identity, the action (find, findOne, create, update, delete), and the resource. Permit.io evaluates your policy and returns allow or deny.
60
+
61
+ Both layers must pass for a request to go through.
62
+
63
+ ## RBAC
64
+
65
+ Role-based access control is the default mode. When you connect the plugin, it syncs your Strapi roles to Permit.io. User role assignments are kept in sync automatically — when a user is created, updated, or deleted in Strapi, the plugin reflects those changes in Permit.io in real time.
66
+
67
+ To configure RBAC policies, use the Permit.io dashboard to set which roles can perform which actions on which resources.
68
+
69
+ ## ABAC
70
+
71
+ Attribute-based access control lets you write policies based on properties of the user or the resource. For example: only users in the `us` region can access products with `region: us`, or only users with `clearance: elevated` can access confidential records.
72
+
73
+ To enable ABAC:
74
+
75
+ 1. Make sure you are using a self-hosted PDP
76
+ 2. Open the plugin's ABAC Attribute Mapping section
77
+ 3. Select which user fields to include as user attributes (e.g. `region`, `department`)
78
+ 4. Select which fields on each content type to include as resource attributes (e.g. `region`, `confidential`)
79
+ 5. Save — the plugin will re-sync the resource schemas to Permit.io
80
+
81
+ The plugin fetches user and resource attributes at request time and passes them to `permit.check()`. For single-resource endpoints (`GET /api/posts/:id`), both user and resource attributes are included in the check. For list endpoints (`GET /api/posts`), the plugin performs a bulk check — it fetches all results, runs `permit.check()` against each one with its resource attributes, and filters out any the user is not allowed to see.
82
+
83
+ Relation fields are supported in attribute mappings. When a content type has a relation field (e.g. `company`), the plugin flattens it to `companyId` (the related record's ID) for both resource and user attributes. Use the flattened name (e.g. `resource.companyId`, `user.companyId`) when writing conditions in Permit.io.
84
+
85
+ You configure the actual access rules (user sets, resource sets, condition set rules) in the Permit.io dashboard.
86
+
87
+ ## ReBAC
88
+
89
+ Relationship-based access control ties permissions to the relationship between a user and a specific record. For example: a user can edit a document because they created it, or they can view it because someone shared it with them.
90
+
91
+ To enable ReBAC for a content type:
92
+
93
+ 1. Open the ReBAC Configuration section in the plugin
94
+ 2. Enable ReBAC for the content type
95
+ 3. Set the creator role — the role assigned to users when they create a record (defaults to `owner`)
96
+ 4. Define instance roles — the roles that can be assigned on individual records (e.g. owner, editor, viewer)
97
+ 5. Save the roles — they will be synced to Permit.io as resource roles
98
+ 6. Use the Sync Instances button to push all existing records to Permit.io as resource instances
99
+
100
+ New records are synced to Permit.io as resource instances automatically when created. Deleted records are removed from Permit.io automatically.
101
+
102
+ One thing to be aware of: automatic creator role assignment is not yet implemented. When a record is created, the instance exists in Permit.io but no relationship is assigned to the creator. You need to assign instance roles manually from the Permit.io dashboard or via the Permit.io API after creation.
103
+
104
+ ## Syncing users
105
+
106
+ New users are synced to Permit.io automatically when they register. If you have existing users, use the Sync All Users button in the User Sync section to push them to Permit.io in bulk.
107
+
108
+ ## Protected resources
109
+
110
+ By default, all content types are protected. You can toggle individual content types off in the Protected Resources section if you want Permit.io enforcement to skip them entirely.
111
+
112
+ ## Fail open behavior
113
+
114
+ If the Permit.io client is not initialized or if the PDP is unreachable, all requests pass through without enforcement. This means a misconfigured or disconnected plugin will not break your API — it just stops enforcing until you reconnect.
115
+
116
+ ## Contributing
117
+
118
+ The plugin uses [yalc](https://github.com/wclr/yalc) for local linking during development.
119
+
120
+ In the plugin directory:
121
+
122
+ ```bash
123
+ npm install --legacy-peer-deps
124
+ npm run watch:link
125
+ ```
126
+
127
+ In your Strapi project:
128
+
129
+ ```bash
130
+ npx yalc add @permitio/permit-strapi
131
+ npx yalc link @permitio/permit-strapi
132
+ npm install
133
+ nvm use 22
134
+ npm run develop
135
+ ```
136
+
137
+ ## License
138
+
139
+ MIT