Hallo,
I started a requirements document for a RBAC component one year ago, but
proposed a component to store hierarchic data instead. Now the Tree component
is stable and I've cleaned up the old req document.
Have a nice easter time, if you celebrate it!
--
Thomas Koch, Software Developer
Young Media Concepts GmbH
Sonnenstr. 4
CH-8280 Kreuzlingen
Switzerland
Tel +41 (0)71 / 560 53 81
Fax +41 (0)71 / 560 53 89
Mobile +49 (0)170 / 753 89 16
Web www.ymc.ch
eZ Component: AccessControl, Requirements
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:Author: Thomas Koch
Introduction
============
Description
-----------
The component provides functionality to implement access control to certain
areas or actions in an application. The design is based on the Role-based
access control (RBAC) system.
Requirements
============
While there are different levels of complexity of such a RBAC system, this
component has at least the following RBAC characteristics:
(A) Roles can be organized in a hierarchy. Permissions are inherited from
parent roles.
(B) Multiple Roles can be assigned to users.
(C) The representation of a user in this component is can be an integer
number or a string.
(D) Permissions are attached to roles. The representation of a permission in
PHP code is free to choose. Thus a permission can be for example just a
string like 'view' or 'edit', or a structure consisting of an action and
a section (object to do the action on).
Design Goals
============
The component can be tied to the Tree component to make use of different
storages for the role hierarchy. A simple mechanism to provide roles as hard
coded PHP structures is supported, to make this component usable without the
TieIn.
Special considerations
======================
The following characteristics of a RBAC system seems to be over complex for
webapplications and are therefore not supported by this component.
Nevertheless it could be possible to implement this functionality on top of
this component:
* An additional dimension to the user <-> permission mapping based on session
types. This means, that a used could start for example an administration
session and has more rights then in a normal user session. Or session can
be based on working hours.
* Additional conditions for the role <-> permission mapping, e.g. a user
could gain a permission only if he has two necessary roles for this
permission.
* Permissions may not be assigned directly to users. This would make the code
more complex and lead to bad administration practice.
* Static constraints are not supported. A static constrint is for example:
One user may not have role A and role B together.
* phpGACL supports negative permission assignments to roles. Thus a
permission given to a parent role could be revoked at a lower hierarchic
level. This functionality should not be supported since it leads to a wide
range of different kinds of nightmares.
* Original RBAC supports roles organized in a partial order, thus a role
could be child of different parents. I consider this as unnecessary
overhead.
Format
======
The XACML_ OASIS standard should be considered as a fileformat for
persistency.
.. _XACML:
http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-rbac-profile1-spec-os.pdf
RBAC methods
============
The following methods are taken from the NIST RBAC specification and could
help for a first orientation about a possible design.
Creation and Maintenance of Relations: assignUser, deassignUser (to Role),
grantPermission, revokePermission (User / Role)
Review methods: Mandatory (M) and Optional (O)
* AssignedUsers (M): returns the set of users assigned to a given role;
* AssignedRoles (M): returns the set of roles assigned to a given user;
* RolePermissions (O): returns the set of permissions granted to a given
role;
* UserPermissions (O): returns the set of permissions a given user gets
through
his or her assigned roles;
* RoleOperationsOnObject (O): returns the set of operations a given role may
perform on a given object; and
* UserOperationsOnObject (O): returns the set of operations a given user may
perform on a given object (obtained either
directly or through his or her assigned roles).
Functional Specification for Hierarchical RBAC:
methods:
* AddInheritance : establish a new immediate inheritance relationship
between two existing roles;
* DeleteInheritance : delete an existing immediate inheritance
relationship between two roles;
* AddAscendant : create a new role and add it as an immediate
ascendant of an existing role; and
* AddDescendant : create a new role and add it as an immediate
descendant of an existing role.
* AuthorizedUsers : returns the set of users directly assigned to a
given role as well as those who were members of
those "roles that inherited the given role."
* AuthorizedRoles : returns the set of roles directly assigned to a
given user as well as those "roles that were
inherited by the directly assigned roles."
* RolePermissions : returns the set of all permissions either directly
granted to or inherited by a given role;
* UserPermissions : returns the set of permissions of a given user
through his or her authorized roles (union of
directly assigned roles and roles inherited by
those roles);
* RoleOperationsOnObject : returns the set of operations a given role may
perform on a given object (obtained either directly
or by inheritance); and
* UserOperationsOnObject : returns the set of operations a given user may
perform on a given object (obtained directly or
through his or her assigned roles or through roles
inherited by those roles
Other projects
==============
phpGACL__ is an older PHP4 framework for Generic Access Control Lists. Some
concepts have been adapted by the Zend_Acl component. See also `phpGACL for
CakePHP`__.
There's also a linklist in the `Zend-Wiki`__.
PEAR `LiveUser`__ mixes authentification and permission handling. There are
only two backends supported, DB and XML, while XML handles only the simple
level of permission management.
.. __: http://phpgacl.sourceforge.net/
.. __:
http://groups.google.com/group/cake-php/browse_thread/thread/12591c4d7a25577
.. __:
http://framework.zend.com/wiki/display/ZFUSER/RBAC+%28Role+Based+Access+Control%29+References
.. __: http://pear.php.net/package/LiveUser
Frameworks
----------
* Seagull: Permissions can be given to access or not access actions.
* Sinfony: like Seagull:
<http://www.symfony-project.com/book/trunk/06-Inside-the-Controller-Layer>
* Prado: nothing like ACL
* Solar: like Seagull: <http://solarphp.com/class/Solar_Access_Adapter>
* Mambo and Joomla use phpGACL
References
==========
* Microsoft, `Role-Based Access Control for Multi-tier Applications Using
Authorization Manager`__
.. __:
http://technet2.microsoft.com/WindowsServer/en/library/72b55950-86cc-4c7f-8fbf-3063276cd0b61033.mspx?mfr=true
* NIST, `Role Based Access Control - Frequently Asked Questions`__
.. __: http://csrc.nist.gov/groups/SNS/rbac/faq.html
* Wikipedia, `Role-based access control`__
.. __: http://en.wikipedia.org/wiki/Role-based_access_control
* A `tutorial <http://csrc.nist.gov/rbac/rbacSTD-ACM.pdf>`_ about the
ANSI/INCITS 359-2004 standard.
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
