Authorization
Authorization Component gives you the ability to create custom ACL metrics which is unique to each of your extension/application.
In most other solutions, you are either restrict to file based configuration for ACL or only allow to define a single metric for your entire application. This simplicity would later become an issue depends on how many extensions do you have within your application.
Basic Concept of RBAC
Before we begin let look at the basic concept of RBAC with Orchestra Platform.
Name | Description |
---|---|
actions | Actions is either route or activity that we as a user can do (or not do). |
roles | Roles are user group that a user can belong to. |
acl | Is a boolean mapping between actions and roles, which determine whether a role is allow to do an action. |
Default Authorization Driver
For Orchestra Platform, an instance of Orchestra\Authorization\Authorization
is always created to authorise the user. You can retrieve the instance via:
<?php
use Orchestra\Support\Facades\ACL;
use Orchestra\Support\Facades\Foundation;
$acl = Foundation::acl();
# or using the container.
$acl = app('orchestra.platform.acl');
# or via the ACL facade.
$acl = ACL::make('orchestra')->makeOrFallback();
Make or Fallback
makeOrFallback()
would actually use the database storage when the application installed or fallback to use runtime handler when the application is yet to be installed.
Verifying an Authorization
As an example, when accessing the User Management page Orchestra Platform will make the following authorization check:
<?php
use Orchestra\Support\Facades\Foundation;
abort_unless(Foundation::acl()->can('manage user'), 401);
Adding Additional Actions
Aside from the default actions available you can always add new actions and set the permission:
<?php
use Orchestra\Model\Role;
use Orchestra\Support\Facades\Foundation;
$acl = Foundation::acl();
// Attach 'View Dashboard' action.
$acl->actions()->attach(['View Dashboard']);
// Allow admin to access 'View Dashboard'.
$acl->allow(Role::admin()->name, ['View Dashboard']);
// Deny member to access 'View Dashboard'.
$acl->deny(Role::member()->name, ['View Dashboard']);
Creating Custom Authorization Driver
It's sometime common for an extension to have custom authorization driver. This would allow each driver to have a clear separation of actions making it much easier to manage or control.
Imagine we have a acme
extension, the configuration below is all you need in your extension/application service provider.
<?php
use Orchestra\Support\Facades\ACL;
$acl = ACL::make('acme');
With just ACL::make()
you can start building authorization for your application. However on every request you need to define the authorization schema and it's not dynamic (can't configured via the GUI since everything is hard-coded).
To solve this, you can integrate with the Memory Component to allow a persistent storage of the ACL metric.
<?php
use Orchestra\Support\Facades\ACL;
use Orchestra\Support\Facades\Foundation;
$acl = ACL::make('acme')->attach(Foundation::memory());
Updated less than a minute ago