Access Control and Topic Inheritance Question

Hi,

I have one web, not Main, and under it I have two groups that will be able to view and edit their content within this web. Each groups' content will branch off a separate top level topic. I want the web to be visible only to these two groups. I want the top level topic for each group to be visible only to that group (e.g. if they click to a top level topic they are not permissioned to see, an error page appears). And I want all topics attached to a top level topic to inheirit the view and topic change settings for their top level topic. If someone has time to help me sort out settings, I'd like to validate the best approach.

There is no inheritance of topic permissions. The "hierarchy" of topics is a soft hierarchy, The web is a flat topic space. You might be able to use TopicTemplates to set the topic security. But if you really need this level of topic security it is probably better to use separate webs.

Currently, I have the web WebPreferences topic with these settings which limits access to the web to my two groups:

* Set DENYWEBVIEW = WikiGuest
* Set ALLOWWEBVIEW = OneGroup, TwoGroup, AdminGroup, AdminUser
* Set DENYWEBCHANGE =
* Set ALLOWWEBCHANGE = OneGroup, TwoGroup, AdminGroup, AdminUser
* Set DENYWEBRENAME =
* Set ALLOWWEBRENAME = AdminGroup, AdminUser

One comment - using both DENY and ALLOW can be unpredictable. I don't recall if there is any precedence, but ALLOW... will deny everybody else. DENY... allows everybody else. Combining both says deny everbody and allow everybody. You don't need the DENY for WikiGuest This is incorrect. The order of precedence is defined and predictable. Explained further below.

For the top level topic for OneGroup, on the More Topic Actions page, the Edit Topic Settings page, I have these settings:

* Set ALLOWWEBVIEW = OneGroup, AdminGroup, AdminUser
* Set ALLOWWEBCHANGE = OneGroup, AdminGroup, AdminUser

For the top level topic for TwoGroup, on the More Topic Actions page, the Edit Topic Settings page, I have these settings:

* Set ALLOWWEBVIEW = TwoGroup, AdminGroup, AdminUser
* Set ALLOWWEBCHANGE = TwoGroup, AdminGroup, AdminUser

In theory, looking at the documentation, this should work: someone assigned to OneGroup should see their top level topic and its branch topics while being unable to see the TwoGroup top level topic. However, this does not work.

I'm not sure about what happens if you try to change the WEB level controls in a topic. These two variables are set as FINALPREFERENCES in the WebPreferences topic. So unless you changed this, they cannot be changed per topic.

Can you tell me what I have missed in the documentation? Also, if this is the best approach? There is a small amount of content that will use the INCLUDE macro and so, in theory, it is easiest to put all content into one web. But I am open to other approaches if it achieves the goals stated above in my first paragraph.

One thing to note is that a Wiki is typically most successful if it is open and permits collaboration. Also locking down VIEW access in a common name space can be confusing for users. A user might try to create a topic that exists, that they cannot view.

Thank you for any insight and help!

-- GeorgeClark - 04 Feb 2010

---

Thanks, George! I have some quick follow up questions.

Specifically, your third point about the list of values for FINALPREFERENCES, is it true that if I remove ALLOWWEBVIEW and/or DENYWEBVIEW from that list of values then setting those values at the topic level will work? Right now, all topics "inheirit" the web settings: perhaps this is because the ALLOW and DENY are in the list of FINALPREFERENCES?

On your second point, DENY for WikiGuest, that is the only way I could find to force login. The wiki has proprietary business information. People permissioned to see the data are free to use the wiki as a wiki. But login is first required. Is there another way to avoid this possible confusion between DENY and ALLOW? Is there another way to force login before viewing pages?

Finally, the real permissions issue appears to be about sharing a small subset of topics between the two groups while providing secure access to two distinct sets of topics. Because the INCLUDE variable does not have a setting to override permissions (or does it?), that suggests the most efficient solution is a single web with a dedicated subweb for each of the two groups. Common shared topics would be at the web level. Secured topics would be at the subweb level. I believe this approach would allow INCLUDE START/STOP to work within the common topics to be shared inside the secured topics with an INCLUDE that points to the common topics permissioned to be visible to both groups. In short, this has to be a fairly obvious problem to solve. If you have any ideas about how best to organize, I would appreciate your insights based on your knowledge of Foswiki.

I appreciate your help!

-- TimSlavin - 05 Feb 2010

ALLOWWEB settings only really make sense in the WebPreferences topic. They provide default settings for the entire web, which can then be overridden on a per-topic basis (i.e. TOPIC has precedence over WEB). If there are no explicit TOPIC settings, then it will fall back to the WEB settings. Finalising the WEB settings is principally used for forcing the inheritance of these settings into topics and subwebs, but a finalised WEB setting can still be overridden by a TOPIC setting in an individual topic.

DENY is evaluated first, but if a user passed the DENY check then the ALLOW check still applies to them. Thus DENY(A);ALLOW(A,B) will only allow B access, as A will be denied before the ALLOW is checked.

I don't understand what you mean by "For the top level topic for OneGroup". I would have expected that to be a group definition, but your description above suggests it is actually a web? Or maybe a topic? Either way, setting access controls in it will have no effect on other topics/webs. You cannot "inherit" ACLs from one topic to another.

-- CrawfordCurrie - 03 Mar 2010

No further feedback from asker, so closed.

-- CrawfordCurrie - 29 Sep 2011

You can put this in the preferences of the child topic you want to inherit the access preferences:

   * #Set DENYTOPICVIEW = %QUERY{'%BASEWEB%.%QUERY{'%BASEWEB%.%BASETOPIC%' / parent.name}%' / preferences[name='DENYTOPICVIEW'].value}%
   * #Set ALLOWTOPICVIEW = %QUERY{'%BASEWEB%.%QUERY{'%BASEWEB%.%BASETOPIC%' / parent.name}%' / preferences[name='ALLOWTOPICVIEW'].value}%
   * #Set DENYTOPICCHANGE = %QUERY{'%BASEWEB%.%QUERY{'%BASEWEB%.%BASETOPIC%' / parent.name}%' / preferences[name='DENYTOPICCHANGE'].value}%
   * #Set ALLOWTOPICCHANGE = %QUERY{'%BASEWEB%.%QUERY{'%BASEWEB%.%BASETOPIC%' / parent.name}%' / preferences[name='ALLOWTOPICCHANGE'].value}%
   * #Set DENYTOPICREVIEW = %QUERY{'%BASEWEB%.%QUERY{'%BASEWEB%.%BASETOPIC%' / parent.name}%' / preferences[name='DENYTOPICRENAME'].value}%
   * #Set ALLOWTOPICRENAME = %QUERY{'%BASEWEB%.%QUERY{'%BASEWEB%.%BASETOPIC%' / parent.name}%' / preferences[name='ALLOWTOPICRENAME'].value}%

-- PompetardO - 21 Dec 2011

Remove the # comment markers in the above example, Added so others can view this solution.

-- GeorgeClark - 22 Dec 2011