ahmido
d90fb0f963
PR Body Implements Spec 065 “Tenant RBAC v1” with capabilities-first RBAC, tenant membership scoping (Option 3), and consistent Filament action semantics. Key decisions / rules Tenancy Option 3: tenant switching is tenantless (ChooseTenant), tenant-scoped routes stay scoped, non-members get 404 (not 403). RBAC model: canonical capability registry + role→capability map + Gates for each capability (no role-string checks in UI logic). UX policy: for tenant members lacking permission → actions are visible but disabled + tooltip (avoid click→403). Security still enforced server-side. What’s included Capabilities foundation: Central capability registry (Capabilities::*) Role→capability mapping (RoleCapabilityMap) Gate registration + resolver/manager updates to support tenant-scoped authorization Filament enforcement hardening across the app: Tenant registration & tenant CRUD properly gated Backup/restore/policy flows aligned to “visible-but-disabled” where applicable Provider operations (health check / inventory sync / compliance snapshot) guarded and normalized Directory groups + inventory sync start surfaces normalized Policy version maintenance actions (archive/restore/prune/force delete) gated SpecKit artifacts for 065: spec.md, plan/tasks updates, checklists, enforcement hitlist Security guarantees Non-member → 404 via tenant scoping/membership guards. Member without capability → 403 on execution, even if UI is disabled. No destructive actions execute without proper authorization checks. Tests Adds/updates Pest coverage for: Tenant scoping & membership denial behavior Role matrix expectations (owner/manager/operator/readonly) Filament surface checks (visible/disabled actions, no side effects) Provider/Inventory/Groups run-start authorization Verified locally with targeted vendor/bin/sail artisan test --compact … Deployment / ops notes No new services required. Safe change: behavior is authorization + UI semantics; no breaking route changes intended. Co-authored-by: Ahmed Darrazi <ahmeddarrazi@MacBookPro.fritz.box> Reviewed-on: #79
75 lines
2.2 KiB
Markdown
75 lines
2.2 KiB
Markdown
# Quickstart: Tenant RBAC v1
|
|
|
|
This guide provides a quick overview for developers on how to use the Tenant RBAC v1 system.
|
|
|
|
## Checking Permissions
|
|
|
|
The core of the RBAC system is a set of defined capabilities. To check if the currently authenticated user has a specific capability, use Laravel's `Gate` facade.
|
|
|
|
**NEVER check for roles directly.** Always check for capabilities.
|
|
|
|
### In PHP (Controllers, Policies, Livewire Components)
|
|
|
|
```php
|
|
use Illuminate\Support\Facades\Gate;
|
|
|
|
// Check for a specific capability
|
|
if (Gate::allows('tenant.members.manage')) {
|
|
// User can manage members
|
|
}
|
|
|
|
// You can also deny access
|
|
if (Gate::denies('tenant.settings.manage')) {
|
|
abort(403);
|
|
}
|
|
```
|
|
|
|
### In Blade Views
|
|
|
|
You can use the `@can` and `@cannot` directives in your Blade templates to conditionally show UI elements.
|
|
|
|
```blade
|
|
@can('tenant.members.manage')
|
|
<button>Add Member</button>
|
|
@endcan
|
|
|
|
@cannot('tenant.danger_zone')
|
|
<p>You are not authorized to access the danger zone.</p>
|
|
@endcannot
|
|
```
|
|
|
|
### In Filament Resources
|
|
|
|
Filament actions and pages can be protected using the `can` method.
|
|
|
|
```php
|
|
use Filament\Actions\Action;
|
|
use Filament\Resources\Pages\ListRecords;
|
|
|
|
// Protecting an action
|
|
Action::make('delete')
|
|
->requiresConfirmation()
|
|
->action(fn ($record) => $record->delete())
|
|
->visible(fn ($record) => Gate::allows('tenant.policies.delete', $record));
|
|
|
|
// Protecting a page
|
|
class ListMembers extends ListRecords
|
|
{
|
|
// ...
|
|
public static function canView(): bool
|
|
{
|
|
return Gate::allows('tenant.members.view');
|
|
}
|
|
}
|
|
```
|
|
|
|
## Capability Reference
|
|
|
|
A full list of available capabilities is defined in `specs/065-tenant-rbac-v1/contracts/capabilities.md`.
|
|
|
|
## Key Principles
|
|
|
|
1. **Capabilities, Not Roles**: All authorization checks MUST be against capabilities, not roles (`owner`, `manager`, etc.). This decouples the application's logic from the role definitions.
|
|
2. **Server-Side Enforcement**: UI hiding is not security. Always enforce permissions on the server-side (in controllers, actions, or policies) in addition to hiding UI elements.
|
|
3. **Use Policies for Model-Specific Logic**: For authorization logic that depends on a specific model instance, use a Laravel Policy class.
|