americancouncils / kalinka Goto Github PK

These currently take maps with the resource type as the base key, but it makes more sense for them to take the role name as the base key.

In order to account for a lot of complexity that we're going to run into, we know we can't rely solely on role mappings to guard policies. This proposes a new Authorizer/Decider set of interfaces, and reimplements the current role authorization mechanism as just one of potentially many Decider implementations.

Authorizer and Decider API

<?php

interface AuthorizerInterface
{
    public function can($action, $domain, $context = null);
    public function registerDecider(DeciderInterface $decider);
}

interface DeciderInterface
{
    const ALLOWED = true;
    const DENY = false;
    const ABSTAIN = null;

    public function decide($action, $domain, $context = null);

    public function supportsAction($action);
    public function supportsDomain($domain);
    public function supportsContext($context);
}

In this scenario, current Kalinka authorizer usage would not change, though the meaning would be slightly different. Currently, when you call $kalinka->can('edit', 'document', $document); you are declaring that you will be checking the edit action on the document guard. This guard has been configured to check policy methods internally, based on how the user roles are configured, and who the subject is.

In the new implementation when you call $kalinka->can('edit', 'document', $document);, you are checking the edit action on any registered deciders in the document domain. One of those deciders may or may not be the RoleDecider, which then makes a decisions based upon its guards and configuration.

Essentially, the current implementation just becomes one possible implementation of a more general interface.

Authorizor::can Behavior

Now that more than one Decider can make decisions, the results of Authorizer::can need some more explanation. Generally, any call to Authorizer::can behaves like a blacklist, meaning as long as one Decider denies the action, the action is denied.

• when any decider denies: denied
• when all deciders abstain: denied
• one or more deciders allow, and the rest abstain: allowed

This still allows us to represent roles in the RoleDecider as a whitelist - for example, if any role grants access, but other roles deny access, the RoleDecider will still decide to allow, and the check will still pass as currently is the case. However, when more complex cases come along, new deciders still have the ability to deny access to the check for their own reasons.

Refactoring

The current RoleAuthorizor and Guard system would need to be somewhat refactored, but not too much. Ultimately, I think it would work this way:

• AuthorizerInterface changes to the above definition
• RoleAuthorizor becomes RoleDecider and implements DeciderInterface
• The concept of a Guard is now specific to the RoleDecider, rename these to DomainGuard

To represent our current usage, setup would now look something like this:

<?php
use AC\Kalinka\Authorizer;
use AC\Kalinka\Decider\RoleDecider;
use ACME\ExamGuard;
use ACME\AOGuard;

$authorizer = new Authorizer();

$roleDecider = new RoleDecider($roleConfig);
$roleDecider->registerGuard(new ExamGuard);
$roleDecider->registerGuard(new AOGuard);

$authorizer->registerDecider($roleDecider);

if (!$authorizer->can('edit', 'exam', $exam)) {
    throw new Exception('computer says no');
}

//check passed, do app stuff

Bundle configuration in KalinkaBundle would need to be refactored somewhat - but again, probably not too much. Some names change, but ultimately how the DomainGuard and RoleDecider work, and are configured, stays roughly the same.

The latter prevents certain kinds of passed functions from working correctly