[TYPO3-ect] Enhanced Rights Management
David Toshack
david at vaultin.com
Mon Jul 17 04:32:05 CEST 2006
Hello all,
I have been holding out on posting this email until I can get to
creating a proof of concept extension, but due to the current brewing of
the partner framework and talk of enhanced rights management, thought I
would post this now.
-+_-_-_-_-_+-
For an enterprise level content management system, TYPO3 has survived
without real RBAC (Role Based Access Control)[1] for quite some time,
but I think 5.0 would be a great time to change this. Authentication is
such an integral part of so many open source php web applications and it
would be a shame to reinvent the wheel. I think the new LiveUser[2] pear
package looks very promising.
LiveUser is a fairly new pear library and it comes with an
administration package, LiveUser_Admin[3]. The LiveUser data structure
can be used in three levels of complexity as displayed with the
following diagram:
http://www.backendmedia.com/LiveUser/liveuser_db_schema.png
LiveUser data structure relation to TYPO3
-----------------------------------------
Compare the LiveUser tables in the data structure above with the
following points:
- the liveuser_applications table: could represent extensions. To have
LiveUser apply to your extension all you would have to do is:
* Add an sql insert to your ext_tables.sql file, like so:
INSERT INTO liveuser_applications VALUES (DEFAULT, <extkey>, <extname>)
* Add define statements to represent default right_level of access
required for default or specific fields, functions and views.
Similar to the "exclude" TCA value, but allowing multiple levels via
an integer rather than boolean value. This is currently done with
define statements in LiveUser, and could be done as follows without
modification:
define('EXTKEY_[DEFAULT||PLUGIN|TCA|MODULENAME]_[DEFAULT||VIEW|CREATE|DELETE]',
[0-5]);
This is the standard use, but the value carried is only an integer
from 0-5, so it would be quite easy to store it and access it as
Typoscript. Maybe Page TSconfig for admin levels and Typoscript
Templates for right_levels below. Since FE and BE users and groups
would in effect be merged, admin level restrictions can also be
placed on FE plugins. Another nice side effect is that page tree
access control can also be managed by TSconfig. We would need either
a decent access module to configure all these TSconfig options.
Maybe enhancing the current LiveUser_Admin interface would be
sufficient.
* Add right_level access to your code by wrapping it with something
like:
if ($LU->checkRight(EXTKEY_PLUGINNAME_ACTIONNAME)) { }
There is a full API for code integration but most of the access
control is handled by the specific define statements you use with
checkRight(). I would assume defaults like the following would
belong somewhere like ext_localconf.php, or maybe even as a part of
the TCA to replace the "exclude" variable in ext_tables.php:
define('EXTKEY_DEFAULT', 0); // Anonymous users
define('EXTKEY_PLUGINNAME_DEFAULT', 1); // Website Users
define('EXTKEY_TCA_DEFAULT', 2); // Admin Users
define('EXTKEY_TCA_TABLENAME_DEFAULT',2); // Admin Users
define('EXTKEY_TCA_TABLENAME_FIELD',3); // Area Admin Users
define('EXTKEY_MODULENAME_DEFAULT',3); // Area Admin Users
define('EXTKEY_MODULENAME2_DEFAULT',4); // Super Admin Users
define('EXTKEY_PLUGINNAME2_DEFAULT',5); // Master Admin Users
These permissions are based on the following LiveUser Perm Types:
* anonymous : LIVEUSER_ANONYMOUS_TYPE_ID = 0 // Anon User Perm
* user : LIVEUSER_USER_TYPE_ID = 1 // FE User Perm
* admin : LIVEUSER_ADMIN_TYPE_ID = 2 // Ltd Area Perm
* area admin : LIVEUSER_AREAADMIN_TYPE_ID = 3 // One Area Perm
* super admin : LIVEUSER_SUPERADMIN_TYPE_ID = 4 // Multi Area Perm
* master admin : LIVEUSER_MASTERADMIN_TYPE_ID = 5 // All Areas Perm
// Only One
This is the default LiveUser way of doing it. Another option is to
store these integer values in the appropriate TS config files. These
permission files really should be stored outside the DocumentRoot. I
suppose the ter could include a hook to move any LiveUser conf files
to another specified path. maybe the liveuser_applications db table.
It would also be great to be able to:
1. Extend alt_doc.php to include the option for dynamic rights
selection for all fields ... (if the user has a high enough
right_level to edit permissions to that field of course). BE
content access control can then be allocated like in
tm_contentaccess. Maybe some of its features can be included in
a partner_rights extension too.
2. It would be nice to browse search and edit right definitions
with a powerful interface; extending LiveUser_Admin if we have
to. The partner framework should play a big part here too,
including links from partner searches based on relationship type,
rights, occupations, or whatever else.
With the new extension dependency install option, it would be easy
to create an extension with nothing more than a dependency of any
number of groupware extensions, an imported pagetree, partner and
permission data, ... and before you know it, voila! You have a TYPO3
point and click groupware suite!
Ok, I know. It isn't really as simple as that. But it actually can
be quite simple, with the option of medium to complex if its
required.
Extensions would have to be modified in order to take advantage of
the new partner_rights authentication, but these would make great
QuickStart packages which is already on the ECT list of projects[4].
As you can see, this type of access control can be very
specific. Defaults could also be included in plugin, tca and module
init classes.
- the liveuser_area table: could be a group of applications (extensions)
that make up similar roles. Like a department of an organization, or
maybe a QuickStart package mentioned previously for a groupware suite.
LiveUser is extended by LiveUser_Admin, which is the framework for
managing these users, groups, rights, areas and applications. I don't
know too much about this yet. I'm looking into it, but it should be
possible to include it as a module.
- the liveuser_rights table: contains access to an area, and authorizes
the right_level available to a user, which can be as easy as that if
simple mode is used.
The right_level associated with the user is authenticated against the
right definitions above.
Groups can also be used to administer right_levels if medium mode is
selected. In complex mode; subgroups, "implied rights" and directly
assigned area admins are other ways of gaining your highest access
level.
- the liveuser_perm_users table: is the center of all users and rights.
It has a one to many relationship with liveuser_users, which could be
replaced with the tx_partner_main table. The liveuser_perm_users table
also has a perm_type of integer values. This is what they generally
mean:
LIVEUSER_ANONYMOUS_TYPE_ID = 0 //Anonymous website user of the
public website
LIVEUSER_USER_TYPE_ID = 1 //Front end logged in website user of
the public website
LIVEUSER_ADMIN_TYPE_ID = 2 //You need at least this level to
access the backend
LIVEUSER_AREAADMIN_TYPE_ID = 3 //This level has all access enabled
for its area by default in complex
mode
LIVEUSER_SUPERADMIN_TYPE_ID = 4 //This perm_type has all access
enabled for the whole site by
default
LIVEUSER_MASTERADMIN_TYPE_ID = 5 //This user is equivalent to the root
user of a unix system. There can
only be one.
For finer grained access control, user and group rights connections
with medium and complex modes should be used to accumulate your
highest found appropriate rights_level.
As it is still quite a new project I am sure there will be issues that
will need to be ironed out. It has also been nominated for inclusion
into the Zend Framework. It was rejected due to its complicated API, but
now with the simple, medium and complex modes; I think it will be a good
contender for Zend_Auth. Maybe we can include some of its functionality
in tx_lib.
Is this a waste of time or does anybody see merit in this?
Cheers,
David
[1] http://en.wikipedia.org/wiki/Role_based_access_control
[2] http://pear.php.net/package/LiveUser
[3] http://pear.php.net/package/LiveUser_Admin
[4] http://wiki.typo3.org/index.php/Extension_coordination_team
More information about the TYPO3-team-extension-coordination
mailing list