In This Article
ACLs are based around the idea of resources and roles:
- a resource is an object to which access is controlled;
- a role is an object that may request access to a resource.
Put simply, roles request access to resources. For example, if a parking attendant requests access to a car, then the parking attendant is the requesting role, and the car is the resource, since access to the car may not be granted to everyone.
Through the specification and use of an ACL, an application may control how roles are granted access to resources. For instance, in a web application a resource can be a page, a portion of a view, a route, etc. A role can vary based on the context in which the request is made: it could be the client identity sent with an API request; whether the users is an anonymous guest or a registered user of the site; etc.
Configure an ACL system
You can provide your ACL definitions using a configuration file, as follows:
// config/autoload/authorization.local.php return [ // ... 'zend-expressive-authorization-acl' => [ 'roles' => [ 'editor' => , 'contributor' => ['editor'], 'administrator' => ['contributor'], ], 'resources' => [ 'admin.dashboard', 'admin.posts', 'admin.publish', 'admin.settings' ], 'allow' => [ 'administrator' => ['admin.settings'], 'contributor' => [ 'admin.dashboard', 'admin.posts', ], 'editor' => [ 'admin.publish' ] ] ] ];
We use this same example in the documentation of zend-expressive-authorization-rbac, so that you can compare and contrast the two systems.
The above configuration defines three roles for a blog web site: an editor, a contributor, and an administrator. The contributor role has the editor role as a child role, meaning it inherits its capabilities. The administrator role has the contributor role as a child, inheriting both its direct capabilities, as well as any that role has inherited.
In ACL systems, parent roles inherit the permissions of their children.
Within zend-expressive-authorization-acl, resources are mapped to the route
name currently being requested. By default, all resources are denied access,
unless otherwise stated. In our example, we allow the route
the administrator, the routes
admin.posts for the
contributor, and the route
admin.publish for the editor. Because the
contributor inherits permissions from editor, they will also have access to
admin.publish route. Because the administrator inherits permissions from
contributor, they will have access to all routes.
You can also deny a resource using the
deny key in the configuration file.
For instance, you can deny access to the route
admin.dashboard by the
administrator by adding the following configuration in the previous example:
return [ // ... 'zend-expressive-authorization-acl' => [ // previous configuration array 'deny' => [ 'administrator' => ['admin.dashboard'] ] ] ]
The usage of
deny can help to configure complex permission
scenarios, including or excluding specific authorizations.
As noted earlier, zend-expressive-authorization-acl uses the current route name
to determine the resource. If you want to change the permissions type and the
logic for authorization, you will need to provide a custom implementation of
Found a mistake or want to contribute to the documentation? Edit this page on GitHub!