Translations
Info
All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh

Enhanced Rights Management

From TYPO3Wiki
Jump to: navigation, search
This page belongs to the Extension coordination team (category ECT)

Title:
Main editor:
Project status:

Enhanced Rights Management
David Toshack
collection of interest

notice - Open Content License

This document is published under the Open Content License

The content is related to TYPO3 - a GNU/GPL CMS/Framework available from typo3.org



Enhanced Rights Management is an ECT (Extension Coordination Team) project for the management of user rights-related data.

Using an external rights framework

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 and rights management is such an integral part of so many open source PHP web applications and it would be a shame to reinvent the wheel. There are a few RBAC implementations that I think are worth investigating for the purpose of TYPO3 access control.

I would prefer a standards based approach and like the look of the XACML/SAML specification [2]. There is an implementation of Sun's OpenSSO for interpreted languages called Lightbulb[3] but this only really covers authorization rather than rights management.

Based on the fact that there is a research proposal for including XACML in J2SE[4] and that OASIS have come up with an XACML RBAC profile[5], I think its safe to say that XACML has become the access control specification standard. However implementing this would be quite a task!

SunXACML[6] and PERMIS[7] are true XACML standards based RBAC implementations in Java but it would be a big job to port either of these to PHP.

There have been many RBAC implementations referenced for the Zend Framework[8] which look quite good. I am have been very interested in implementing the Pear::LiveUser[9] and Pear::LiveUser_Admin[10] packages into TYPO3. However, now I'm not so sure as the Zend_ACL[11] component is now out of incubation for the Zend Framework.

In fact, since this is more of a 5.0 proposal than 4.x, I am changing my recommendation to some form of Zend_Auth/Zend_ACL implementation. RBAC has been discussed at great length[12] in regard to Zend_ACL and there are quite a few examples of how it can be applied to both the Controller[13][14] and persistence[15] layer.

Maybe the LiveUser interface could even be revamped with Zend libraries. But this is just food for thought for now. Hopefully this can be revisited when Flow is ready for Authentication and Access Control features.

PEAR LiveUser

PEAR LiveUser is a fairly new pear library and it comes with an administration package, LiveUser_Admin[16]. The LiveUser data structure can be used in three levels of complexity as displayed with the following ER diagram: http://www.backendmedia.com/LiveUser/liveuser_db_schema.png

Örjan Persson was kind enough to draw a little image to illustrate a sample user/group/right structure: http://oss.backendmedia.com/images/LiveUser/LiveUser.png

LiveUser data structure relation to TYPO3

Compare the LiveUser tables in the data structure above with the following points

the liveuser_applications table

This 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 Allowed

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.
  1. 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

This 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

This 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

This 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.

conclusion

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 it has become quite flexible.

The Zend Framework has a Zend_ACL library and there is a Zend_ACL proposal for changes be based on a quite mature 3rd party PHP ACL framework called PHPGACL[17]. I have posted to the PHPGACL developers mailing list to ask if the Zend Framework or the XACML OASIS RBAC Profile will be considered for future releases.

PHP RBAC implementation

There's a discussion about rewriting eGroupWare from scratch. There is a private proposal site, also discussing permission management.

The idea for the Rights-Management of the rewrite is, to work on one common RBAC library for eGroupWare, TYPO3 and eZ Components.

See

Relations

relating projects (edit this, in alphabetical order)