<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[
<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[
Zend_RBAC is a component used to determine if a user (subject), member of one or more roles, has access to a resource.![]()
This component will be ZF >=2.0 only and will not be shipped with a (tentative) ZF1.11 Zend Framework: Zend_RBAC Component Proposal
Proposed Component Name
Zend_RBAC
Developer Notes
http://framework.zend.com/wiki/display/ZFDEV/Zend_RBAC
Proposers
Dolf Schimmel (Freeaqingme)
Zend Liaison
TBD
Revision
0.5 - 17 December 1909: Initial Draft. (wiki revision: 13)
Table of Contents
1. Overview
2. References
3. Component Requirements, Constraints, and Acceptance Criteria
requested object was assigned, the user MUST be allowed access. Otherwise, MUST NOT.
4. Dependencies on Other Framework Components
Soft;
- Zend_Exception
Optional:
- Zend_Db
5. Theory of Operation
Zend_Rbac is a component that can be used to determine whether a subject (user) that has one or more roles, has access to one or more resources, after you have defined the available resources, roles and users. One does only allow (not disallow) roles access to resources, assign users to roles, and determine if any roles inherit from other roles.
Following example based on [1]:
Interns can do everything a healer can do
Doctors can do everything an intern can
Healers have access to object 1 & 2 only
Interns have access to object 1, 2, 3 & 4 only
Doctors have access to object 1, 2, 3, 4, 5 & 6 only
This component is different than Zend_Acl because:
- Zend_Rbac does not feature the disallowing of access, only allowing access, meaning that there's no problems by design (as is with Zend_Acl: ZF-5369)
- It makes a distinction between roles and users (subjects) whereas Zend_Acl only has resources and roles
- It's faster and uses less lines of code (that's what I'm aiming at)
- It's adapter based by default
- It does not use privileges *
* If you want to replicate this behavior, you're advised to use several resources to achieve this. Meaning that where with zend_acl you have one resource named 'resource' with the privileges 'add', 'edit' and 'delete', you're expected to add the resources 'resource_add', 'resource_edit', and 'resource_delete'.
Some users (on IRC) have suggested to replace this component with Zend_Acl in ZF2.0 because it essentially does the same: determine if a certain user/role has access to a certain resource (but then done better
). If there's a majority in the community that wishes to replace this component with Zend_Acl, it should definitely be considered.
6. Milestones / Tasks
- Milestone 1: [DONE] Design notes will be published here
- Milestone 2: [DONE] Write unittests
- Milestone 3: [DONE] Write working (basic) prototype, commit in userbranch
- Milestone 4: [DONE] Write Resource Plugin, assertions, adapters & FC-lugin => userbranch
- Milestone 5: Drop class interface here (or emphasize link to userbranch, hey, developers are lazy by definition)
- Milestone 6: Get proposal reviewed, updated, accepted
- Milestone 7: Write documentation (or find s/o to do so, volunteers?
) - Milestone 8: Get code reviewed by Matthew/liaison and move to trunk
- Milestone 9: Release immediately, and don't forget to promote Zym meanwhile
7. Class Index
- Zend_Rbac
- Zend_Rbac_Exception
- Zend_Rbac_Object
- Zend_Rbac_ObjectInterface
- Zend_Rbac_Resource (interface)
- Zend_Rbac_Role (interface)
- Zend_Rbac_Subject (interface)
- Zend_Rbac_Object_Resource
- Zend_Rbac_Object_Role
- Zend_Rbac_Object_Subject
Todo (read: not in userbranch):
- Zend_Rbac_Adapter_DbTable
- Zend_Rbac_Adapter_Abstract
- Zend_Rbac_Assert_?
- Zend_App_Resource_Rbac
- Zend_Controller_Front_Plugin_Rbac
- More_To_Come?
8. Use Cases
| UC-01 |
|---|
The following code implements the given scenario under 'operation'
Alternatively you can use your models, by having them implement the correct interface, and adding a __toString() method that returns a unique identifier.
9. Class Skeletons
For the rest of the code, please see GitHub
]]></ac:plain-text-body></ac:macro>]]></ac:plain-text-body></ac:macro>
6 Comments
comments.show.hideJan 21, 2010
Sudheer Satyanarayana
<p>I have slightly different requirement for ACL.</p>
<p>Here's my initial draft of the pseudo code. Copied from <a class="external-link" href="http://projects.binaryvibes.co.in/wiki/bizsense/New_ACL_spec">http://projects.binaryvibes.co.in/wiki/bizsense/New_ACL_spec</a> (registration required to access the page)</p>
<ul>
<li>Ability to add roles</li>
<li>Ability to add privileges</li>
<li>Ability to query acl for a user, privilege and assertion</li>
</ul>
<p>A user can belong to many roles.</p>
<p>A user</p>
<p>Sample API</p>
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
class BV_Acl
public function setAssertion($assert); //set the assertion object
public function getUser();
}
Interface Acl_User {
public function getRoles();
}
]]></ac:plain-text-body></ac:macro>
<p>Things not required</p>
<ul>
<li>Role inheritance</li>
<li>Deny rules</li>
<li>Resources</li>
</ul>
Feb 01, 2010
Sudheer Satyanarayana
<p>I implemented a simple and effective Acl component - Bare_Acl. Code can be downloaded from svn - svn://svn.binaryvibes.co.in/bare/standard/trunk </p>
<p>Released under liberal BSD license. </p>
<p>Code is browsable online at <a class="external-link" href="http://projects.binaryvibes.co.in/repositories/browse/bare">http://projects.binaryvibes.co.in/repositories/browse/bare</a> (Registration required)</p>
<p>Let me know what you think about it.</p>
Feb 26, 2010
David Caunt
<p>I have a small suggestion, that the __toString method is not used to provide an identifier for the subject, and rather that an interface is used as per Zend_Acl_Role_Interface.</p>
<p>I think it is important that the magic __toString method remains available for programmers to use at their discretion. </p>
Mar 13, 2010
David Weinraub
<p>Quite agree.</p>
Nov 25, 2010
Simon
<p>"Some users (on IRC) have suggested to replace this component with Zend_Acl in ZF2.0 because it essentially does the same: determine if a certain user/role has access to a certain resource (but then done better ). If there's a majority in the community that wishes to replace this component with Zend_Acl, it should definitely be considered."</p>
<p>I strongly disagree. While RBAC may be useful in certain instances, ACL is very important in that you can deny access. RBAC would not work for a number of systems I've made. That's not to say it should not be added.</p>
<p>In regards to "'resource_add', 'resource_edit', and 'resource_delete'", I was happily unaware that was needed. In fact, no where do I see it mentioned. <a class="external-link" href="http://framework.zend.com/manual/en/zend.acl.refining.html">http://framework.zend.com/manual/en/zend.acl.refining.html</a></p>
Jan 06, 2012
Sebastian
<p>Is there still a discussion going on about Zend_Rbac? The integration of this component would be terrible useful. In my opinion it should be an extension to the Framework and not replace Zend_Acl.</p>
<p><strong>vote for it</strong></p>