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.

NameDescription
actionsActions is either route or activity that we as a user can do (or not do).
rolesRoles are user group that a user can belong to.
aclIs 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());