Tags:
access_control1Add my vote for this tag extract_idea1Add my vote for this tag create new tag
, view all tags
Sandbox.TWiki needs proper access control lists. The existing half-baked permissions system is just too difficult to use and unwieldy.

Proposal: refactor to implement access control lists, up to the POSIX 6 standard. Specifically,

  1. Access controls should be managed using an access control object. This should implement ACLS as per the POSIX 6 standard (summarised here)
  2. The object should be serializable to meta-data or to topic text to maintain compatibility with existing usage. The serialization method decision should be delegated to the Store wherever possible. e.g.
    • ObjectMethod serialize( \&archiveMethod )
  3. The object should be query-able to establish the access rights mask for a user.
    • ObjectMethod hasAccessRights( $user ) -> $rwx
  4. Access controls can be chained, to support access control hierarchies. For example
    • ObjectMethod chain( $acl ) -> $acl
  5. An access control editor should be provided that allows simple manipulation of a chain of access controls.
  6. The access control object should be totally agnostic; it should be possible to attach it to a topic, a web, a resource such as a plugin - or anything else you can think of.

-- CrawfordCurrie - 13 Jul 2005

This would also allow Sandbox.TWiki to delegate its object permissioning to an external system, such as that provided by an enterprise permissioning scheme. Using LDAP for permissioning is often a requirement for enterprises.

-- MartinCleaver - 13 Jul 2005

This is a needed change (I'm struggling with Sandbox.TWiki permissions in our support system for our clients), so we shouldn't look back and preserve backward compatibility.

But for those poor TWikiAdmins that had to invest too much time setting up permission, we should also decide how the transition will be:

  1. UpgradeTWiki will scan all and every topic to for ALLOW* and DENY* to set the proper permission.
  2. Permissions will be upgraded "on demand"

-- RafaelAlvarez - 13 Jul 2005

What we need is ... heck there are any number of authorization models we can argue about.

The right way to do it is to do what we've done with authentication in Dakar and make it configurable.

That way we don't argue over how it should be done. If you don't like it, the come up with something else.

This is going to take a few changes, though. We're going to have to recognise a point I made many years ago, and that is that there are settings ... and there are access permissions. The kludge we have at the moment of using 'just another setting' to do this priveliged function is going to have to be revisited, and the implicaitons, semantic and other, investigated. Some access control methods may not be 'backward compatible'

All that's been said amounts to making that differentiation and hence, logically if not physically, moving access control "Out Of Band".

This should be considered a Good ThingTM. All databases and file systems store access control information separately from the data it controls. Again, a point I've made repeatedly for many years. That separation is fundamental to good security.

The move to 'out of band'-ness is just anpther thing to preserve the purity of our bodily fliud, the data - the content of the topic. Along the way we are also going to move METADATA out of band. That makes the topic very clean and will simplify loading and rendering. (You may not like the idea, but its going to happen - such streamlining is the only way we can significantly improve performance. It will also allow us to implement multiple forms per topic.)

In pre-Cairo days I did a few experiments. I stripped out all the non-data from a topic, put the settings - all of them, not just the access control - into a per-topic hash file, and similarly with the METADATA. I didn't use any of CrawfordCurrie's wonderful speedups for not re-reading the topics for perissions over and again, and I discarded the METADATA processing. The results were dramatic. Removing the parsing of topics other than the one being rendered, applying the pattern matching to extract the settings is a big speedup. They also showed the point that Crawford made early in the development of Cairo that it can take the reading of perhaps 12 topics just to render one topic. All of that is to read settings. Doing %INCLUDE%s makes the situation even more dramatic since they cause a cascade of access control checks as well.

In essence that this was doing was removing the parsing and building of the settings (inclduing access control settings) from the run-time.

The code I played with is way out of date and long gone, but it proved a point, once that Crawford made use of by caching settings. But if we didn't have to parse the topic to extract the settings in the first place, if we only had to, for example tie to a hash database, be it per-topic, per web or global, then the step-and-repeat would be eliminated.

Access control is just one of the things settings are used for. Before we rush of and start implementing other methods, we need to think of the implications to the semantics of Sandbox.TWiki and existing applications of implementing it in a different way. For example, we might break anything that does a %SEARCH{}% for ALLOW/DENY.

But yes, lets press ahead with brainstorming and trials on this. Access control is one of the big corporate selling points of Sandbox.TWiki.

-- AntonAylward - 05 Feb 2006

Time for brainstorming, yes. Speed can be improved with caching.

I see one big disadvantage if access control is moved out of band: No audit trail. The current in-band way of doing things might not be the norm for operaring systems, but it has the advantage that we have a complete audit trail through revision control witout doing anything extra. Clicking on the diffs link shows you who change what when, including access control.

-- PeterThoeny - 06 Feb 2006

That may be a requirement then: to have an audit trail for access control.

-- ArthurClemens - 06 Feb 2006

Peter, while your point about aaudit trail is valid, it is only valid from the point of view of exact compatability with Dakar and before.

There are many situations where users are to be allowed to access and edit the data but explicitly NOT to change the access control. The UNIX file system is a reay example of this.

This kind of thing will particularly apply to many businesses and business aplications. In fact having access control out of band may well be a requirement for just this reason.

There are many ways out-of-band access cotnrol can be implemented, handling defaults so that each topic does not need to have it set specifically on creation.

There is no reason that an audit tail of changes to the out of band access control cannot be implemented. It is all a matter of specification, design and implementation.

My feeling is that because of the possible performance enghancements and ebcuase of the managerial controls that are being necessited by regualtory compliance - such things as Sarbanes-Oxley, HIPAA, PIPEDA, FFIEC, BASEL-2, ISO27000 and their equivilents in other countries, the idea of having in-band access control and user editing will make Sandbox.Twiki unacceptable in many corporate settings.

But the key point is that making access control 'pluggable' and defining the plug-in API means that the flexibility is there. So long as the access cotnrol is in-band, that flexibility and ability to meet the corporate requirements demanded by modern use and regulations - regulations that are dealt with by auditors (such as myself!) - is lost.

Out of band access control and pluggable access control is going to be a necessity for the continued viability of TWiki.

-- AntonAylward - 06 Feb 2006

Pluggable Access control should be enough, as the default implementation could be the current one to preserve compatibility, and a more advanced implementation could use "out-of-band" information.

-- RafaelAlvarez - 07 Feb 2006

Right now there's semi-out-of-band ACL possible, by using manage?editsettings, which puts them in META:PREFERENCES instead of the text. It should be pretty easy to write a script to put them there.

-- MeredithLesly - 26 Mar 2006

No, Meredith, they are still in-band. Its still the one text file that has to be scanned and the fields extracted. You have to read the whole file whether or not there are any access control statements in it or not.

If you think of any other storage system - just take an ordinary file system - you can determine whether its possible to access the file (for read, white or execute) or create a new file without actually reading the file.

That's what I mean by out of band.

The real overhead is in reading the file, separating out the META and the topic and the settings. CrawfordCurrie improved matters by caching the settings so that it no longer takes twelve or more topic reads to determine of you can access a topic as it did with Cairo. That change was a dramatic speedup.

Making access control a META:PREFERENCES may be a Bad Thing in the long run as it persists in the confusion that access cotnrol is just another' setting like EDITWIDTH and SKIN or any topic defined setting.

Its not. It should be handled quite differently. Keep thinking the file system model of access control. That is out of band.

-- AntonAylward - 30 Mar 2006

Can anyone interested in this please comment on PluggableAccessControlImplementation? That allows us to push forward while maintaining backward compatibility.

-- RafaelAlvarez - 30 Mar 2006

Sure, I like PluggableAccessControlImplementation. Although I have observed many pluggable access control systems, and the pluggability not really being used.

In InterfacingToExternalAccessControlListManagers I start discussing what I need wrt managing access control. It could be built on top of PluggableAccessControlImplementation.

In DenyVsAllowWebChangeVsViewIsBroken I argue that we need separate read-only and read-write lists, not read and write. The read-set = UNION(read-only,read-write). Again, this could be built on top of PluggableAccessControlImplementation. But, in the long term, I argue that the existing Change/View access control lists are just plain broken. There is no need to use pluggability to maintain the old change/view and the new ro/rw; the only thing that pluggability gives is the ability to prototype without breaking existing stuff. Which is valuable.

I suppose that my meta observation is that pluggability can be used for prototyping, or to allow different security systems to xoexist. IIRC IBM did the latter in their VM systems. But very often pluggability is only used for prototyping, you end up choosing only one --- and you have this pluggable interface that confuses the code.

I wonder why I was inspired to this rant? Anyway, yes, I want to build stuff on top of pluggable.

-- AndyGlew - 14 Apr 2006

Yes, i'm "marketing" pluggability as a way to push forward while remaining compatible.

-- RafaelAlvarez - 14 Apr 2006

CategoryAccessControls

Edit | Attach | Watch | Print version | History: r16 < r15 < r14 < r13 < r12 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r16 - 2006-04-30 - SamHasler
 
  • 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.