Tags:
create new tag
, view all tags

Feature Proposal: Dynamic Access Control

Motivation

It's handy if access permission is determined dynamically instead of statically. With that, the following would be implemented elegantly.

  • Allowing a group to modify the child topics of a topic
  • On a survey web, allowing to see one's own entry while disallowing the others'

Description and Documentation

Currently, variables in access control variables are not expanded. If they are expanded, you can do a lot of fancy things with access control.

Implementing a complex access restriction in TWiki variables may take long to do it right. It may affect performance. So it will be an experimental feature for the time being.

As such, this feature should be turned off by default. It shall be turned on only if DYNAMIC_ACCESS_CONTROL is set on in the WebPreferences topic.

Accessibility to a topic is checked not only to display/edit/save the topic but also to process the following variables (this list is not comprehensive).

  • %SEARCH{...}%
  • %METASEARCH{...}%
  • %INCLUDE{...}%
  • %FORMFIELD{...}%
  • %META{...}%
There are two implications of above.
  1. The mechanism must be implemented efficiently. Caching during a session should be implemented.
  2. If you are not careful enough, permission check may cause an infinite loop. Let's say %FORMFIELD{...}% is in DENYWEBVIEW. This is to prevent others from seeing a topic of a user.
    Here's what would happen if implemented naively. To process %FORMFIELD{...}%, the topic must be read, which causes permission checking, which causes %FORMFIELD{...}% to be processed, which causes permission checking...

For access checking efficiency, the following improvement is desired. Currently TWiki::Access::checkAccessPermission() always checks if the user is an admin, which may cause LDAP lookup or something causing external resource access. Meanwhile, the vast majority of accesses to TWiki are topic viewing by non-admins. And the vast majority of TWiki topics don't restrict viewing. With topics not restricting viewing, checking if the user is an admin or not is redundant. Admin check should be done as the last resort before returning false.

Examples

Survey

  • Survey responses are stored on topics named ResponseXXXX.
  • Responder's wikiname is put on the Responder field.
  • A responder can see their response but not of others.
  • SurveyorGroup members can see all responses
    * Set DENYWEBVIEW = %IF{"'%CALCULATE{$FIND(Response, %TOPIC%)}%' != '1' OR '%WIKINAME%' ingroup 'SurveyorGroup' OR '%FORMFIELD{"Responder"}%' = '' OR '%FORMFIELD{"Responder"}%' = '%WIKINAME%'"
    then="" else="%WIKINAME%"}%

Impact

Implementation

-- Contributors: HideyoImazu - 2012-11-01

Discussion

Agreed on needs. Is the idea to expand all variables, or only a set of variables? For users it might be easier to understand that all avriables get expanded.

As stated, performance can be an issue. Is caching on session time the right way? Or done with a configure setting, set to say 1 day? Cache invalidation should be considered as well, such as on topic update. I like the fact to enable it on a per-web basis.

In regards to access check during variable expansion: Since the result is only used TWiki internally to deny/grant access I think it is overkill to check for permissions during variable expansion. If you omit access check you gain performance. Also you possibly don't need to worry about recursions?

Agreed on implementation detail of access check for admin user.

-- PeterThoeny - 2012-11-01

The idea is to expand all variables. To tell it simply, ALLOW* and DENY* variable values are handed to TWiki::handleCommonTags() before matching against the current user.

I implemented it on my TWiki 4.1.2 based installation 4 years ago and using it ever since for several bulletin board applications. They have hundreds to a thousand of postings. With permission caching in the TWiki::Access object (= caching during one script execution), it's performing fine.

I realized that by introducing $session->{checkingAccessPermission} attribute and having TWiki::Access::checkAccessPermmission() return true immediately if $session->{checkingAccessPermission} is true, you can easily omit access checking during a variable expansion in an access control variable.

-- HideyoImazu - 2012-11-02

Accepted by 7 day review period at JerusalemReleaseMeeting2012x11x09.

-- PeterThoeny - 2012-11-09

Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r8 - 2013-09-19 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2016 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.