[TYPO3-ect] Enhanced Rights Management
Jan-Hendrik Heuing [DD]
jh at digitaldistrict.de
Tue Jul 18 20:01:49 CEST 2006
I just saw that on the tycon-agenda... Just that you know. Maybe it would be
interesting to invite those to that discussion:
"Intranet framework with ACL and BE-user-based FE editing (Jens Kristian
Mygent / Sune Vestergaard) "
"David Toshack" <david at vaultin.com> schrieb im Newsbeitrag
news:mailman.1.1153103531.24617.typo3-team-extension-coordination at lists.netfielders.de...
> 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