[Mapbender-dev] Motion to enhance the user/group model

Mon Jun 9 10:57:03 EDT 2008

Christoph

Ideally WMS and WFS should be "ownable" by a group, for ease of management
and for consistency throughout Mapbender.   The changes needed to make this
happen are more substantial then the user/group/application changes in the
proposal.  

Taking WMS for example, the field wms.wms_owner identifies the owner.  That
user has write access to the WMS and read access is controlled by access to
an application - any user with access to an application with a WMS can read
that WMS.  One solution would be to separate WMS access from the application
and control read/write access through a couple of tables (wms_mb_group &
wms_mb_user) like what is done with an application.  There are benefits to
this approach (user level control to a WMS), but it separates service access
from the application, does this violate the Mapbender design?  Another
option would be to put a WMS in a group whose members have management rights
- this seems backwards and somewhat confusing to me.

Any ideas from devs?

Thanks

Len

> -----Original Message-----
> From: mapbender_dev-bounces at lists.osgeo.org 
> [mailto:mapbender_dev-bounces at lists.osgeo.org] On Behalf Of 
> Christoph Baudson
> Sent: Monday, June 09, 2008 6:54 AM
> To: Mapbender Developer List
> Subject: Re: [Mapbender-dev] Motion to enhance the user/group model
> 
> Hi Len
> 
> before casting my vote I want to discuss one more thing. At 
> the moment, only users can own WMS and WFS. Is that some kind 
> of a problem? Do we want/need groups to own services?
> 
> Beside this point I'm positive on your motion, as it only 
> adds functionality. If you don't need the enhanced group 
> model, you can stick with the old model.
> 
> Thanks
> 
> Christoph
> 
> Len Kne schrieb:
> > Greetings
> >  
> > After discussion at the last several IRC meetings, I motion to:
> >  
> > 1. Add a table mb_group_mb_group
> >  
> > 2. Allow groups to own applications/guis
> >  
> > 3. Allow an owner of a group to administer members of that group
> >  
> > Background
> >  
> > The overall goal of this motion is to simplify the 
> administration of 
> > users, groups, and applications.  Allowing groups to be members of 
> > groups may reduce the number of groups needed in a Mapbender 
> > installation.  Allowing a group to "own" an application and 
> owners of 
> > a group to edit members will help Mapbender installations with 
> > multiple administrators.  Some more details for the three parts.
> >  
> > 1. Adding the table mb_group_mb_group will allow groups to 
> be members 
> > of other groups.  This will simplify "read" access to 
> applications by 
> > allowing a hierarchical structure of groups.  The table 
> will consist 
> > of two columns, fkey_mb_group_id and 
> fkey_mb_parent_group_id.  Minor 
> > changes will be needed in class_user to query the new table and 
> > determine user application permissions.  This change does 
> not remove 
> > or change any current functionality of the user/group model.
> >  
> > 2. Most of the pieces needed for groups to own applications are 
> > already in place, they just need to be enabled.  Currently 
> > gui_mb_group.mb_group_type is unused, but could perform the same 
> > function as gui_mb_user.mb_user_type.  The function 
> getOwnerByGui in 
> > class_administration already queries to 
> gui_mb_group.mb_group_type to 
> > assign application ownership, but most modules are 
> currently not using 
> > this class.  As part of the administration module work this 
> summer, I 
> > propose to change the modules to use this administration 
> class.  The 
> > only step left for groups to own applications is to create a simple 
> > module for people to add the owner attribute to the table 
> (similar to 
> > mod_gui_owner).  This change does not remove or change any current 
> > functionality of the user/group model.
> >  
> > 2a. Optionally, it may make sense to combine the functionality of 1 
> > and 2 together.  Currently class_user creates an array with what 
> > applications a user has "read" access to and class_administration 
> > creates an array of owners with "write" access.  Combining 
> these into 
> > one function would produce an array with user access level to an 
> > application (by including owner, they have write access).  
> This could 
> > allow for other levels of access ton an application in the future.
> >  
> > 3. Currently users can only be edited by a single owner.  
> This makes 
> > it hard for Mapbender installations with multiple administrators to 
> > manage users - for example an administrator may not be able 
> to manage 
> > a user that is using an application they manage because the 
> user was 
> > created by another admin.  This change will create a class 
> that will 
> > allow an owner of a group to fully manage members (users and other
> > groups) of the group, including editing, creating, and 
> deleting.  This 
> > way administrative functions could be distributed.  No new 
> tables or 
> > fields (with the exception of the new table in 1) are 
> needed for this 
> > motion.
> >  
> > 3a. This motion could have security implications for 
> current Mapbender 
> > installations depending on how groups are setup.  It is therefore 
> > recommended that a new variable be added to Mapbender.conf to allow 
> > administrators to enable/disable this functionality.
> >  
> > Link to previous discussion
> > http://lists.osgeo.org/pipermail/mapbender_dev/2008-June/001216.html
> >  
> > Thanks
> >  
> > Len
> > 
> ----------------------------------------------------------------------
> > --
> >
> > _______________________________________________
> > Mapbender_dev mailing list
> > Mapbender_dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/mapbender_dev
> >   
> 
> 
> --
> _______________________________________
> 
> W h e r e G r o u p GmbH & Co. KG
> 
> Siemensstraße 8
> 53121 Bonn
> Germany
> 
> Christoph Baudson
> Anwendungsentwickler
> 
> Fon: +49 (0)228 / 90 90 38 - 15
> Fax: +49 (0)228 / 90 90 38 - 11
> christoph.baudson at wheregroup.com
> www.wheregroup.com
> Amtsgericht Bonn, HRA 6788
> _______________________________________
> 
> Komplementärin:
> WhereGroup Verwaltungs GmbH
> vertreten durch:
> Arnulf Christl, Olaf Knopp, Peter Stamm
> _______________________________________
>  
> 
> _______________________________________________
> Mapbender_dev mailing list
> Mapbender_dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapbender_dev
> 