How does Magento 2 ACL works

I'm not quite sure why this was the case, but I found that using:

MagentoCompanyApiAuthorizationInterface

..rather than..

MagentoFrameworkAuthorizationInterface

yielded the correct ACL check result from within in an Adapter class that I was working on. The latter may require the context, I'm not entirely sure why it was always returning false for me.

Magento 2 authorization system

1. The acl.xml is declaring resources used for backend actions protection and web API. It means, authorization system is now unified

2. Resulting merged acl.xml is used to build 2 identical ACL trees for managing permissions in the admin panel. One is on the admin user role edit page, another is on web API integration edit page

3. Permissions are checked in MagentoBackendAppAbstractAction::_isAllowed when accessing admin panel pages (this method is almost always overridden in child controllers to perform check against custom resource). During web API calls processing this check is done by framework based on resources node declared in webapi.xml

4. See any core acl.xml to understand the syntax, e.g. customer module acl.xml. Also Magento 2 has XSDs available for all configs, so if configured properly, IDE should verify and suggest correct syntax on the fly

5. To check if current user (admin or web API) has permission to access particular resource declared in acl.xml, just use MagentoFrameworkAuthorizationInterface::isAllowed($resource). User context is identified automatically in this case

Update

Programmatically Checking ACL Rules

Magento provides an abstract type, MagentoFrameworkAuthorizationInterface, which a client programmer (you!) can use to validate the currently logged in user against a specific access control rule. i.e., if you were playing fast and loose with Magento’s Don’t use the Object Manager guidelines, the following

$auth = $object_manger->get('MagentoFrameworkAuthorizationInterface');
if($auth->isAllowed('Pulsestorm_AclExample::config')) {
    //user is logged in here
} else {
    //user is not logged in here
}

would check if the currently logged in user was assigned our Pulsestorm_AclExample::config rule. If you’re not playing fast and loose with Magento’s Don’t use the Object Manager guidelines, you can inject the auth checking object with something like this

public function __construct(MagentoFrameworkAuthorizationInterface $auth)
{
    $this->authorization = $auth;
}

If you’re in a controller that extends the MagentoBackendAppAction controller, you automatically have access to the authorization checking object via the _authorization property.

namespace VendoreNameModuleNameControllerAdminhtmlIndex;

class Index extends MagentoBackendAppAction
{
    protected function someControllerMethod()
    {
        return $this->_authorization->isAllowed('VendoreName_ModuleName::vendoreName_moduleNameadmin_index_index');
    }

}

Regarding the controller method above — if you’re injecting additional arguments via the __construct method, don’t forget to include the admin context object (MagentoBackendAppActionContext). This context object is where the auth checking object is, itself, instantiated and injected.

class Index extends MagentoBackendAppAction
{
    protected $resultPageFactory;
    public function __construct(
        MagentoBackendAppActionContext $context,
        MagentoFrameworkViewResultPageFactory $resultPageFactory)
    {
        $this->resultPageFactory = $resultPageFactory;        
        return parent::__construct($context);
    }
    //...
}

Finally, for the curious, in a stock Magento install (circa spring 2016), the MagentoFrameworkAuthorizationInterface object type resolves to a MagentoFrameworkAuthorization object. The class for this object is found here

#File: vendor/magento/framework/Authorization.php

For More Click here