Roles & Permissions

Game Framework uses Role-Based Access Control (RBAC) with 4 default roles and 40+ granular permissions.

Default Roles

Workspace Owner

Full control of workspace and all resources.

Permissions:

• All package operations
• All version operations
• All workspace settings
• Member management
• Billing management
• Delete workspace

Use case: Workspace administrators and founders

Workspace Developer

Publish and manage packages and versions.

Permissions:

• Create, edit, delete packages
• Create, delete versions
• Upload artifacts
• Manage webhooks
• Create API keys

Use case: Core development team members

Workspace Tester

Download and test packages.

Permissions:

• View packages and versions
• Download artifacts
• View webhooks
• View downloads

Use case: QA team members

Workspace Viewer

Read-only access to workspace.

Permissions:

• View packages
• View versions
• View workspace info

Use case: Stakeholders, managers, auditors

Permission Categories

1. Packages (5 permissions)

2. Versions (4 permissions)

3. Artifacts (4 permissions)

4. Webhooks (5 permissions)

5. API Keys (3 permissions)

6. Downloads (2 permissions)

7. Workspace (4 permissions)

8. Members (4 permissions)

Role Inheritance

Roles inherit permissions:

graph TD
    Owner[Workspace Owner<br/>Full Control]
    Developer[Workspace Developer<br/>+ Package Management]
    Tester[Workspace Tester<br/>+ Testing]
    Viewer[Workspace Viewer<br/>Read Only]
    
    Owner --> Developer
    Developer --> Tester
    Tester --> Viewer

• Owner has all permissions
• Developer inherits from Tester
• Tester inherits from Viewer
• Viewer has base read permissions

Checking Permissions

Via API

# Check user permissions
curl https://registry.yourcompany.com/v1/me/permissions \
  -H "Authorization: Bearer YOUR_TOKEN"

Response:

{
  "workspace_id": "ws_ID",
  "role": "workspace_developer",
  "permissions": [
    "packages.view",
    "packages.create",
    "packages.edit",
    "versions.create",
    "artifacts.upload"
  ]
}

In Flutter/Dart Code

When using the API, check permissions before actions:

// Check if user can publish
final hasPermission = await client.checkPermission('packages.create');
if (!hasPermission) {
  throw Exception('Insufficient permissions');
}

Custom Roles (Enterprise)

Enterprise plans can create custom roles:

curl -X POST https://registry.yourcompany.com/v1/workspaces/ws_ID/roles \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "release_manager",
    "display_name": "Release Manager",
    "permissions": [
      "packages.view",
      "versions.create",
      "versions.deprecate",
      "artifacts.upload"
    ]
  }'

Best Practices

1. Principle of Least Privilege

Grant minimum necessary permissions:

# ✓ Good - specific role
QA Engineer: tester role

# ✗ Bad - excessive permissions
QA Engineer: developer role

2. Regular Role Reviews

Audit member roles quarterly:

curl https://registry.yourcompany.com/v1/workspaces/ws_ID/members \
  -H "Authorization: Bearer YOUR_TOKEN"

3. Separate Production Access

Use different roles for different environments:

• Development: Developer role
• Staging: Tester role
• Production: Viewer role (read-only)

4. Document Role Assignments

Maintain role assignment docs:

Security Considerations

Owner Protection

• Cannot remove last owner
• Owner transfers require confirmation
• All owner actions are audited

Permission Caching

Permissions are cached for performance:

• Cache duration: 5 minutes
• Revoked access effective within 5 minutes

Audit Logging

All permission checks are logged:

curl https://registry.yourcompany.com/v1/workspaces/ws_ID/audit-logs \
  -H "Authorization: Bearer YOUR_TOKEN"

Next Steps

• Managing Members - Add team members
• API Keys - Create scoped API keys
• Audit Logging - Monitor access