Skip to main content

Add Permit.io permission checks to n8n workflows

Add Permit.io permission checks to n8n workflows with the Permit community node, so a workflow can branch on whether a user is allowed to act, or find the users who are allowed to approve a request. This guide is for developers who build n8n workflows and already have a Permit policy.

n8n is a workflow automation platform. The Permit node sends requests to a Permit policy decision point (PDP) and returns the PDP's response as the node's output, which later nodes in the workflow can read.

Prerequisites

  • An n8n instance, on n8n Cloud or self-hosted, where you can install community nodes. See n8n workflows.
  • A Permit.io policy with the resources, actions, and roles your workflow checks.
  • Your environment API key. See Get your API key.
  • For attribute-based access control (ABAC) policies, an Edge PDP that your n8n instance can reach over the network. See Run the PDP.

1. Install the Permit node

  1. In the n8n workflow editor, click + to add a node.
  2. Search for Permit and select the Permit node.
  3. Click Install node and wait for the installation to finish.

The package name is @permitio/n8n-nodes-permitio. For other installation methods, see Install community nodes in the n8n documentation.

2. Add Permit API credentials

  1. In n8n, open Credentials and create a credential.
  2. Search for and select Permit API.
  3. Fill in the fields:
FieldValue
API KeyYour Permit environment API key. The node sends the key as a bearer token to the PDP.
PDP URLThe PDP that the node sends requests to. The default is the Cloud PDP, https://cloudpdp.api.permit.io.

When you save the credential, n8n tests the credential with a permission check request to the PDP URL.

Choose a PDP URL

The Cloud PDP supports role-based access control (RBAC) and relationship-based access control (ReBAC). For ABAC policies, use an Edge PDP. See Cloud PDP capabilities.

For an Edge PDP, set PDP URL to an address that your n8n instance can reach:

Where the PDP runsExample PDP URL
Same machine as a self-hosted n8nhttp://localhost:7766
Another serverhttp://your-pdp-server:7766
Same Docker network as n8nhttp://pdp-container:7766
Kuberneteshttp://pdp-service.namespace:7766

n8n Cloud can't reach localhost or a private network. To use an Edge PDP with n8n Cloud, expose the PDP at a public HTTPS address, and restrict who can reach that address.

3. Add a permission check to a workflow

Add the Permit node to a workflow, select the Permit API credential, and choose an operation:

OperationWhat the node returnsPDP endpoint
CheckWhether a user can perform an action on a resource./allowed
Get User PermissionsThe permissions of a user, per tenant and resource instance./user-permissions
Get Authorized UsersThe users who can perform an action on a resource type, with the role that grants the action./authorized_users

Node fields accept n8n expressions, so you can take the user, action, or resource from earlier nodes. For each operation's fields, see Permit node reference.

Verify the check

  1. Set Operation to Check, and set User, Action, and Resource to a user, action, and resource key from your policy.
  2. Run the node.
  3. The output has an allow field. For a user whose role allows the action, allow is true. For a user without such a role, allow is false.

If allow is false for a user who should be allowed, check that the user is synced to the environment of your API key, and look up the decision in the audit log.

Check RBAC, ABAC, and ReBAC policies

The Permit node sends the same operations for every policy model. The values you set in the node decide which policy the PDP evaluates. The JSON objects below show the values for each model.

Role-based access control (RBAC)

Set User, Action, and Resource. The PDP allows the action when one of the user's roles has the permission:

{
"user": "alice@company.com",
"action": "read",
"resource": "document"
}

Attribute-based access control (ABAC)

Set User, Action, and Resource, and turn on Enable ABAC. In the Check operation, Enable ABAC sends the body field of the incoming item, such as a webhook payload, as the resource attributes. Every field in the body becomes a resource attribute. The ABAC policy then evaluates conditions on attributes such as expense_amount:

{
"user": "john.employee",
"action": "submit",
"resource": "expense",
"attributes": {
"expense_amount": 1500,
"category": "Travel",
"department": "Engineering"
}
}

ABAC checks need an Edge PDP. See Choose a PDP URL.

Relationship-based access control (ReBAC)

Set User, Action, and Resource, and set Resource Key to the key of the resource instance. The PDP evaluates the roles the user has on that instance, including roles derived from relationships:

{
"user": "manager@company.com",
"action": "approve",
"resource": "expense",
"resource_key": "exp-123"
}

Example: expense approval workflow

This workflow receives expense submissions, checks with an ABAC policy whether the employee can submit the expense, and emails the users who can approve it.

The ABAC Expense Approval System workflow in the n8n editor: a Webhook node, a Check Expense Permission node, an If node, then Get Authorized Approvers and Send email on the true branch, and Respond to Webhook on the false branch

Workflow structure

Node settings

  1. Webhook node: receives the expense submission as JSON, with the employee and expense details.
  2. Permit node, Check operation:
    • User: {{$node['Webhook'].json.body.employee_email}}
    • Action: submit
    • Resource: expense
    • Enable ABAC: on. The node sends the webhook body, including expense_amount and category, as resource attributes.
  3. IF node: routes on the allow field of the Permit node output. When allow is true, the item goes to the Get Authorized Users node. When allow is false, the item goes to a Respond to Webhook node that returns an error response.
  4. Permit node, Get Authorized Users operation:
    • Action: approve
    • Resource Type: expense
    • Resource Attributes (JSON): {"expense_amount": 1500, "category": "Travel"}
  5. Send Email node: emails the users in the Get Authorized Users output about the pending expense.

The workflow depends on an ABAC policy in Permit that allows submit on expense only below an amount limit, and a role that allows approve on expense. See Build ABAC policies.

Test the workflow with example payloads

Send this payload to the webhook. When your policy allows the amount, the Check returns allow: true, and the workflow emails the authorized approvers:

{
"employee_email": "john.employee",
"expense_amount": 1500,
"category": "Travel",
"description": "Client meeting"
}

Send this payload with an amount above your policy's limit. The Check returns allow: false, and the workflow returns the error response you configured on the denied branch:

{
"employee_email": "john.employee",
"expense_amount": 2500,
"category": "Travel"
}

Permit node reference

Each operation sends a POST request to the PDP URL of the credential and returns the PDP response as the node output.

Check

Checks whether a user can perform an action on a resource.

FieldDescription
UserThe user key. Supports expressions.
ActionThe action key, such as read or submit.
TenantThe tenant key. The default is default.
ResourceThe resource type key, such as document or expense.
Enable ABACSends the body field of the incoming item as resource attributes. Off by default.
Resource KeyThe resource instance key, for ReBAC checks. Optional.

The output has an allow field with the decision, true or false. The PDP can also return query and debug fields with details of the evaluation.

{
"allow": true
}

Get User Permissions

Returns the permissions of a user. See Get user permissions.

FieldDescription
UserThe user key.
Resource TypesA comma-separated list of resource types to include, such as expense,document. Optional.
Enable ABACIncludes permissions granted by ABAC policies. Off by default.

The PDP returns an object with one entry per tenant or resource instance. Each entry lists the permissions of the user there, as resource:action strings, and can include the roles that grant them:

{
"__tenant:default": {
"tenant": { "key": "default", "attributes": {} },
"permissions": ["expense:submit"],
"roles": ["employee"]
}
}

Get Authorized Users

Returns the users who can perform an action on a resource type, and the role assignment that grants each user the action. See Get authorized users.

FieldDescription
ActionThe action key, such as approve.
Resource TypeThe resource type key, such as expense.
TenantThe tenant key. The default is default.
Resource Attributes (JSON)A JSON object of resource attributes. The default is {}.
Enable ABACIncludes users authorized by ABAC policies. Off by default.

Example output:

{
"resource": "expense:*",
"tenant": "default",
"users": {
"finance.admin@company.com": [
{
"user": "finance.admin@company.com",
"tenant": "default",
"resource": "__tenant:default",
"role": "finance_approver"
}
]
}
}

In the output, users maps each user key to the role assignments that allow the action.

Get help

Next steps