#446 Controlling View Access by User Type

New_Feature
open
nobody
5
2012-12-08
2003-09-03
No

I think it is essential that Tikiwiki have some method of
restricting access to various pages by various user
classes or it will never gain wide acceptance. For
example, I have created a website
(http://www.newwarriors.org) that is open to all
registered users, but the organization’s financial pages
are to be limited to initiated men only. The Human
Resources Department of a company wants to publish
job openings company wide but wishes to restrict salary
information to upper level management.

The current Group system can protect some pages in a
very cumbersome way (each operation must be set), but
other objects are not protected at all. Further,
permissions are not carried through to child or linked
pages/objects.

I see two ways to create the necessary security. The
first way is to have every page, forum, gallery, and
other object have a permissions section similar to that
found in the admin module section where Group viewing
privileges are assigned (although this is not working
properly in 1.7.1.1). Only those groups assigned to the
page/object can even view it, and of course, the other
group permissions apply as well. Multiple groups can be
assigned to a page/object. This implies that any object
derived from or linked to from the Group protected page
must inherit its Group properties from its parent.

The upside to this approach is that groups already exist
within the Tiki framework so maybe the required mods
would not be gigantically hairy.

The downside to these mods is that it makes Groups do
more than one function, which is currently to define
what a user can DO. Second, it means that a lot of
groups and subgroups need to be setup in order to
accommodate this method.

Consider a small company, the Wiki Widget Company
(wwc on Nasdaq). The company has three levels of
employees: Managers, Grunts, and Peons. Managers
can look at all stuff, Grunts can look at their stuff and
Peon stuff, and Peons are well… peed on… they can only
look at their stuff. So, three Groups could take care of
the page view problem.

However, within each group, there are still admins,
editors, and viewers. So, now we need to have 9
Groups set up in order to restrict view access yet
provide for group permission functionality.

There is yet another problem. The Wiki company has
three departments: Manufacturing, Sales, and
Accounting. Each wishes to have its own protected
areas; only Sales Managers can look at Sales deep dark
secrets, etc. To do this only with Groups means that
there must now be 27 defined Groups in order to provide
complete flexibility with respect to page/object viewing.
It is clear that this is an exponential problem. Four
departments with four levels of employees and four
levels of permissions yield 64 groups.

The second way to approach this is to create a new
security variable, the “Section”. Each page/object has
an additional field on it; the Section(s) assigned to it,
and all child pages/objects inherit the section. Each
user is now assigned one or more Sections in addition to
being assigned to Groups. Now, page access is
controlled by the section and edit/update permissions
are controlled by the Group.

This approach gets us back down a reasonable number
of entries for the Wiki Company. First, there are only
three Groups: admins, editors, and viewers. However,
there must still be nine Sections created: For each
department, there must be Manager, Grunt and Peon
Sections. So, 12 entries need to be managed. For the
example of four departments, four levels of employees,
and four group permissions, the number becomes 20
instead of 64.

This approach creates a 2D matrix of viewing and editing
permissions. A truly ideal security system would
implement a 3D matrix security permissions approach. In
addition to the Groups and Sections described above,
a “Level” is also added. Each user is assigned to one or
more Levels in addition to one or more Sections and one
or more Groups. Each page/object and its children now
have both Section access control and Level access
control.

Now, three Groups are set up: admin, editors, viewers.
Three Sections are set up: Manufacturing, Sales,
Accounting. Three Levels are set up: Managers,
Grunts, and Peons.

Upsides: Groups retain their original function; in fact
the ‘view’ permissions are no longer necessary. Users
are assigned with maximum flexibility and admins have a
minimum number of entries to maintain. This also
eliminates the exponential growth problem. Downsides:
Lots of coding.

I close by commenting on a suggestion made by Marc
LaPorte that Categories could be used as Sections as I
have described them. While this sort of works, it limits
the ability to index pages/objects as Categories are
intended, and it makes view management difficult.

Consider our company once again. They want their
website information organized into “Employee
Information”, “Product Information”, and “Internal
Operations”. Categories are great for creating this
organization. For example, all the open jobs from Sales,
Manufacturing, and Accounting are published
independently by each department with the Employee
Information category.

However, if Categories control views, then either these
particular categories could not be used unless I went
through the clunky process of having subcategories for
each department and management level. To provide the
same view access as previously described, I’d potentially
need 9 subcategories in each category.

I’m hoping you folks can have this ready for V 1.8.
Seriously, if one looks at commercial packages, or some
of the sites set up with shareware MySource from
squiz.net, you’ll see that there are restricted sections,
and it is based on a department/section concept.

Thanks for permitting me to share my views.

Discussion

  • Wayne Herbert

    Wayne Herbert - 2003-09-04

    Logged In: YES
    user_id=824974

    Upon further thought, new created pages or objects do not
    need to inherit Section and/or Level from the parent page,
    they inherit their security permissions (Section, Level, Group)
    from the user. After all, a user cannot be adding to page
    that is not within her security already.

     
  • Wayne Herbert

    Wayne Herbert - 2003-09-05

    Logged In: YES
    user_id=824974

    Allow me to pre qualify the following statements. I am not a
    Tiki expert. I have modified three templates to suit the needs
    of my particular app and the mods were minor.

    Having said that, I believe the mods to add Section and Level
    type security, while tedious since the changes involve many
    modules, are not particularly difficult.

    Currently, each page/object examines a set of variables
    governing permissions, which apparently are set at login time.

    a) add a new table (or two for both Section and Level) in
    the "users" area of the DB... users_sections and users_levels.

    b) create the appropriate admin screens to
    add/change/delete Sections and Levels. There is a default
    of "All" in both Sections and Levels to get things started.

    c) under the admin/general, permit the admin to set what the
    default Section and Level will be for registering users.

    d) when a user logs in, her section(s)/level(s) are also stored
    as with group permissions.

    e) each object in the db gets two fields added to it; Section
    and Level.

    f) at each point in the code where group permissions are
    checked, additional lines of code are added to check section
    and level.

    g) for menus, modules, and other things that might use lists
    or arrays, the build of the object needs to check for Section
    and Level. For example, if a custom menu is a list of user
    pages, then the Section and Level of each page added must
    be equal to or less than the Section/Level of the menu being
    built.

    OK, this is oversimplified, aka, "high level design", but it looks
    to me that the modular nature of tiki makes these additions a
    straightforward process.

     
  • Wayne Herbert

    Wayne Herbert - 2003-09-08

    Logged In: YES
    user_id=824974

    Allow me to pre qualify the following statements. I am not a
    Tiki expert. I have modified three templates to suit the needs
    of my particular app and the mods were minor.

    Having said that, I believe the mods to add Section and Level
    type security, while tedious since the changes involve many
    modules, are not particularly difficult.

    Currently, each page/object examines a set of variables
    governing permissions, which apparently are set at login time.

    a) add a new table (or two for both Section and Level) in
    the "users" area of the DB... users_sections and users_levels.

    b) create the appropriate admin screens to
    add/change/delete Sections and Levels. There is a default
    of "All" in both Sections and Levels to get things started.

    c) under the admin/general, permit the admin to set what the
    default Section and Level will be for registering users.

    d) when a user logs in, her section(s)/level(s) are also stored
    as with group permissions.

    e) each object in the db gets two fields added to it; Section
    and Level.

    f) at each point in the code where group permissions are
    checked, additional lines of code are added to check section
    and level.

    g) for menus, modules, and other things that might use lists
    or arrays, the build of the object needs to check for Section
    and Level. For example, if a custom menu is a list of user
    pages, then the Section and Level of each page added must
    be equal to or less than the Section/Level of the menu being
    built.

    OK, this is oversimplified, aka, "high level design", but it looks
    to me that the modular nature of tiki makes these additions a
    straightforward process.

     
  • Philippe Cloutier

    Logged In: YES
    user_id=738765

    Uf!
    At least of of your replies is a duplicate ;)
    That seems to me like a lot of work.
    I'll have to re-think about what you propose, but it looks
    quite complete as a solution to the simplistic Tiki
    permissions system.
    However we should think about that for 1.9 in my opinion.
    Anyway, grats for the thinking/writing :)

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks