bknd-assign-permissions_skill

Overview

This skill explains how to assign and manage role permissions in Bknd to enforce fine-grained access control. It covers simple permission strings, extended permission objects with allow/deny effects, conditional policies, entity-specific rules, and variable placeholders for runtime context. Use it to design predictable, testable role behaviors and protect sensitive operations.

How this skill works

Permissions can be declared as plain strings for broad grants or as objects to specify effect (allow/deny) and attach policies. Policies include conditions, effects (allow/deny/filter), and optional row-level filters; conditions support operators like $eq, $in, $gt, etc. Variables such as @user.id and @entity are resolved in condition and filter fields to enforce runtime constraints. Deny always overrides allow, and server config reload is required after changes.

When to use it

• When assigning CRUD rights to roles across entities
• When you need entity-specific or multi-entity permission sets
• When adding conditional policies (e.g., owners can edit their records)
• When restricting powerful actions like raw DB queries
• When validating role behavior in staging or QA

Best practices

• Start with minimal permissions and grant only what’s needed
• Prefer explicit permission objects for complex rules and audits
• Use policies with $in and specific entity names to avoid accidental matches
• Test each permission by logging in as the role and exercising endpoints
• Avoid implicit_allow unless you intentionally want a permissive default
• Keep descriptive policy descriptions and restart the server after edits

Example use cases

• Create a read-only viewer role with permissions: ["data.entity.read"]
• Define a blog_author role with full CRUD on posts and read-only categories using policies scoped to entity names
• Make a content_editor that can CRUD only posts and comments via condition { entity: { $in: ["posts","comments"] } }
• Lock down admin by setting implicit_allow: true but deny data.raw.query and data.raw.mutate
• Enforce row-level ownership: allow data.entity.update only when @id == @user.id using condition and filter