rbac-expert

Map authorization decisions to the canonical OpenFGA RBAC model.

4|5|Updated Nov 5, 2025
One-click install
npx skills add https://github.com/cogni-dao/cogni --skill rbac-expert
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: rbac-expert
Source: https://github.com/cogni-dao/cogni/tree/main/.claude/skills/rbac-expert
Command: npx skills add https://github.com/cogni-dao/cogni --skill rbac-expert

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Navigating and enforcing the cogni-template OpenFGA RBAC model to prevent misconfigurations and to establish a durable, canonical authorization mindset across the team.

Core Features & Use Cases

  • Defines the principal→role→capability discipline and codifies invariants like deny-by-default and fail-closed.
  • Serves as a reference when designing protected actions, debugging authz_denied vs authz_unavailable, or updating the rbac-model.json/infrastructure.
  • Guides developers in validating and hardening access flows across routes such as /nodes/{id}/developers and /nodes/{id}/access-requests.

Quick Start

Explain how to validate an authorization check against the current OpenFGA RBAC model.

Frequently Asked Questions about rbac-expert

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I map authorization decisions to the OpenFGA RBAC model?

To map authorization decisions to OpenFGA RBAC, validate role-to-capability mappings against the canonical rbac-model.json. This enforces a principal-agnostic model with deny-by-default and fail-closed semantics to prevent authz misconfigurations.

What is the difference between authz_denied and authz_unavailable in access control?

The difference between authz_denied and authz_unavailable lies in fail-closed semantics: authz_denied means an explicit denial based on role-to-capability mappings, while authz_unavailable indicates an AuthorizationPort failure requiring debugging against the OpenFGA model.

How do I validate protected actions and node access flows for RBAC governance?

Validate protected actions and node access flows by checking role-to-capability mappings across routes like /nodes/{id}/developers. Use the OpenFGA RBAC model to ensure deny-by-default invariants hold for all principal-to-role assignments.

Does OpenFGA support principal-agnostic models with deny-by-default semantics?

Yes, OpenFGA supports principal-agnostic models with deny-by-default semantics. The canonical RBAC model codifies these invariants alongside fail-closed semantics, ensuring all authorization checks map securely to role-to-capability mappings.

Why does my RBAC configuration fail closed during authorization checks?

RBAC configuration fails closed during authorization checks to enforce fail-closed semantics, returning authz_unavailable through the AuthorizationPort when the OpenFGA model cannot definitively validate the role-to-capability mapping.