Skip to main content

Permission Configuration

Advanced guide to configuring and managing permissions in your space.

Permission Model​

Layers of Access Control​

Qarion uses a layered permission model where checks flow from highest to lowest level: Platform Access -> Space Membership + Role -> Permission Rules -> Product Governance Roles -> Specific Access Grants.

Permission Inheritance​

Permissions generally flow from general to specific. First, the system checks if you have Platform access. Then it verifies your Space membership and role. Next, it evaluates any custom Rules that might modify your rights. Finally, it considers specific Product governance roles you hold.

Base Role Permissions​

Out-of-the-Box Roles​

Qarion provides three standard space roles with predefined capabilities.

Viewers can read all content, including the catalog, lineage, and quality results, but cannot make changes.

Editors have all Viewer permissions plus the ability to create and modify products, manage quality checks, and approve access requests (if they are also a Steward or Owner).

Admins have full control. In addition to Editor permissions, they can delete products, manage space members, and configure detailed permission rules.

Custom Permission Rules​

Creating Rules​

  1. Navigate to Settings → Permissions
  2. Click Add Rule
  3. Configure the rule:
IF [Role] tries to [Action]
AND [Conditions are met]
THEN [Allow/Deny]

Rule Components​

Actions​

ActionDescription
view_productSee product details
edit_productModify product metadata
delete_productRemove product
manage_qualityConfigure quality checks
approve_accessHandle access requests
view_credentialsSee source system credentials

Conditions​

ConditionUse Case
is_stewardUser is product steward
is_ownerUser is product owner
tag_matchesProduct has specific tag
created_byUser created the product

Rule Examples​

Allow Editors to delete products they created:

Role: Editor
Action: delete_product
Condition: created_by = current_user
Effect: Allow

Restrict credential viewing to Admins:

Role: Editor
Action: view_credentials
Effect: Deny

Allow stewards to manage quality on their products:

Role: Editor
Action: manage_quality
Condition: is_steward = true
Effect: Allow

Permission Rule Priorities​

Evaluation Order​

  1. Explicit Deny rules are checked first
  2. Specific rules override general rules
  3. If no rule matches, base role permissions apply

Conflict Resolution​

When rules conflict:

  • Deny always wins over Allow
  • More specific conditions win
  • Later rules override earlier ones (same specificity)

Source System Permissions​

Credential Access​

Control who can view/edit source system credentials:

LevelCan ViewCan Edit
No access——
View only✓—
Full access✓✓

Default Configuration​

  • Admins: Full access to all credentials
  • Editors: No credential access by default
  • Viewers: No credential access

Custom Credential Rules​

Create rules for specific source systems:

  1. Go to source system settings
  2. Configure credential access
  3. Assign users or roles

Pipeline Authoring Permissions​

Pipeline Authoring composes several permission layers; no single workspace grant authorizes the whole flow:

BoundaryPermission
Workspace discovery and contentWorkspace view or manage, subject to space access and visibility.
Repository readsRepository view.
Repository-backed changes and publicationRepository contribute, plus the applicable review and validation gates.
Brokered connector discovery or callsConnector execute.
Issue or revoke exact API write grantsConnector edit from a non-impersonating session.
Global egress profiles and runtime controlsSuperadmin; mutating controls also require a non-impersonating session.

The effective runtime permission profile can narrow tools, roots, risk, network, and side effects for one run. It never expands RBAC. Revoking space, repository, connector, workspace, issuer, or session authority causes later checks to fail closed, including live execution fences around approved effects.

See Pipeline Authoring Security for the complete approval, tool, sandbox, egress, audit, and troubleshooting model.

Testing Permissions​

Permission Checker​

Verify what a user can do:

  1. Go to Settings → Permissions
  2. Click Test Permissions
  3. Select a user
  4. View their effective permissions

Common Test Cases​

  • Can this Editor delete products?
  • Can this Viewer request access?
  • What can Stewards do on their products?

Troubleshooting​

"Permission Denied" Errors​

Check in order:

  1. Is the user a space member?
  2. What is their space role?
  3. Are there deny rules affecting them?
  4. Do they have the required governance role?

Unexpected Access​

If a user can do something they shouldn't:

  1. Check for permissive rules
  2. Review governance role assignments
  3. Verify space role is correct

Changes Not Taking Effect​

  • Users may need to refresh their browser
  • Some permission changes require re-login
  • Check for caching issues

Best Practices​

Start Simple​

  • Begin with base roles
  • Add custom rules only when needed
  • Document every custom rule

Use Governance Roles​

Instead of complex rules:

  • Assign Steward to let Editors approve access
  • Use Owner for important decision rights

Regular Review​

  • Audit rules quarterly
  • Remove unused rules
  • Test after changes

Documentation​

For each custom rule, document:

  • Why it was created
  • Who requested it
  • What problem it solves