Content access control via group selection

Created by: Lester Caine, Last modification: 01 Nov 2006 (08:20 UTC)

Basic Outline

The basic design of the protector service is to provide a package agnostic way of identifying material that is to made visible to different groups of users. In it's simplest implementation it provides a means of creating an anonomous set of pages that cover all of the packages available, and gets round the current restrictions that the package based permissions system imposes.
Guest visitors are presented with a fully functional set of content that they can view and navigate as if they were registered users, and which they can search without being able to see 'secure' content.
This facility gets round the problems of 'view' permission being set on a package by package basis. Each content item is allocated to a group, and is only visible to members of that group. Since users can be assigned to a number of groups, there is no need to assign content to more than one group ( however that facility can be made available, but complicates the basic plan of protector ).
In a default system, content would be identified as anon, registered, and admin, and only admin users would be able to see pages that are 'restricted' to the admin group. Registered users are also members of the anon group, and so also so the base anon content.

Simple Developments

One of the reasons for wanting to introduce this structure was to provide for different 'types' of registered users. As an example, genealogy information can be of a personal nature, but the core information should be generally available. The anon level would provide an overview of historic and other public material, registered users would have access to a larger range of material, while family members would be allowed access to more private information. Where larger bases of information exist, there may be more than one 'family' group, and users can be members of a number of those groups, but still be blocked to accessing data on other family groups.
A more 'commercial' application of protector is the restriction of material based on the organisational structure of a company. The general workers get access to the first level of documentation, while supervisors can see material related to their level of 'security', and managers, a higher level of security. Different departments may have their own supervisor and manager groups, so that supervisors for one department can't see content in anothers, while managers may be members of multiple supervisor groups, and see all the information for their area of the company.


Hopefully it is now obvious that this approach can be applied to other areas of restricted access, such as content moderation. The generation of new material can be automatically classified to, for example, a moderator group, and normal registered users will not be able to see the content. A simple function in the protector filter ensures that the creator of an item can always see their own items independent of group, but the ability to change the group setting will be restricted to moderators. Since this is a package agnostic service, the process can be applied to any new content items, such as a comment, or blog entry, and while the author can see that entry, the general users will not until the item is moved to a more generally visible group.
Moving items from a moderator group ( and there could be a number of such groups ) into the generally visable group could be carried out manually via the normal item edit, or an alternative means can be added via additional service functions. One option is to use the stars package ( should that be 'service' ) and once an item has received a certain level of stars, the group flag is automatically changed.

Other developments

One of the main problems with this approach is the fact that the current integral permissions system requires separate view, edit, admin permissions for every package. What would be nice would be to replace that complexity with a much simpler create/edit/admin function for each group, in much the same way as the unix security system works. This would remove the cumbersome management functions required to control the currently vast array of permissions. A simple start to this may be possible by introducing a generic set of basic permissions, but this does need to be addressed.

Operating Modes

There are currently two modes of operation of the service, single group and multiple group.
Personally I only see the need for content being assinged to a single group and this makes management of the content a lot easier. A user will be assigned to multiple groups and can therefore see a spread of data.
The service has been extended to allow content to be assigned to multiple groups, but this is a mode that I can see will only cause problems in the future and complicates the validation logic in the SQL. While I can see the advantage of being able to assign content to more than one group, we are already seeing requests for 'modified' versions of content based on a user id, and that I see in a similar light. Just like translations, different content should have different copies, so while you may have content for 'X', a second copy for 'Y' should be a second copy so that modifications made to 'Y' that are not appropriate for 'X' are not visible by 'X'!


This still needs a review!
The current protector package SHOULD already be operational in HEAD via the servicesSql interface, and provides filtering on lists and serach results and restricts access to content where the group setting do not match. Not sure if comments are being correctly filtered at this time, but 'moderation' of comments would require that function.
It would be nice if links from unsecure content to secure content were simply disabled, rather than going to a 'you do not have permision to view this page!'
Some additional management of the protector selection when editing would be useful, a permission on a group to be able to the grouping of a content item.
A display of the 'group' of a content item when the basic view is selected. This may need to be 'inteligent' so that, say, a moderated group item is flagged as 'unapproved', but a simple text field against each group may be all that is needed ( anon->Public, registered->Private, moderated->Unaproved for example ).

Related Items

Packages » Optional Packages

Packages that can be added to bitweaver to expand the core functionality.

  •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •  Array  •  Array