create new tag
, view all tags

Interfacing to External Access Control List Managers

PluggableAccessControlImplementation describes a code mechanism that can be used to create new access control systems.

Here, I want to talk about what I would need/like in one such system.

Background - what not

I'm not talking about identification or authentication. My sysadmins have set up a system to use the corporate wide domain/idsid/password. I am reasonably happy with that.

AccessControlLists is a generic discussion, that talks about other stuff like authentication as well as access control.

Although I am one of the world's leading exponents of non-access control lists security systems (e.g. dynamic capabilities), I think that I would be reasonably happy with access control lists in twiki. In DenyVsAllowWebChangeVsViewIsBroken I explain that I want a read-write access list and a read-only access list (or, equivalently, a list of users/groups, annotating each with read/write/rename).

The problem that I want to discuss here is, how the groups or lists are defined.

What TWiki has now, and its problems

As of today, April 2006, TWiki defines groups as lists of TWikiUsers. TWikiGroups greps out topics from the Main web, called Main.*Group.

(Each Main.*Group file has its own access control list - that's good.)

Problem 1: the users are TWikiUsers. They must be registered. The topic TWikiUsers establishes a mapping from whatever is used to login - in a public wiki, possibly an email address; in my environment, a domain/idsid - to a WikiWord user name.

This is a problem because my users do not want to register. They do not want to use TWikRegistration. I could force them to, but I would be lynched. They say "we already have registered in lots of other places - why do we need to register here?"

Call thw WikiWord user name an internal identity. E.g. AndyGlew. Call the login string the external identity. E.g. AMR\glew.

I want to be able to put the external identity into TWiki's AccessControlLists. E.g. I want to be able to say


rather than


and relying on TWikiUsers to do the mapping.

Problem 1.1: if I could put the external identification into the TWiki access control list, I could set up the access control lists for new webs in advance. E.g. I set one up for a project or working group, I could put all of the people invited to the working group into the web ACL in advance. As it is now, if I have to wait for them to choose their names when they register, I cannot do it in advance.

In fact, I have already tried doing stuff like automatically generating big chunks of stuff that I add to the TWikiUsers list. E.g. I take a mailing list, and create names. I've also pre-registered lots of people. Users complain, however, when I do things like putting the wrong name - e.g. AndrewForsythGlew rather than AndyGlew.

Similarly, I have tried putting external identifiers in TWiki's access control lists.


rather than

   * Set ALLOWTOPICVIEW = Main.AndyGlew

I won't trust this until I am told that it is supposed to work this way.

Problem 2: my main problem, however, is that I do not want to have to administer TWiki's own group lists.

In my environment, we automatically generate lots of lists.

  • E.g. we automatically generate mailing lists from UNIX groups. And vice versa.
  • We generate website access control lists from Majordomo mailing lists.
  • We have an orgchart tool, that generates mailing lists (and UNIX groups)
whenver there is a reorg. (And, yes, we have learned, in the 15 years we have run such tools, how to avoid problems such as denying a user access to his home directory just because he was reorged.)
  • Some of our tools do things like creating web groups that mrror Microsoft Exchange mailing lists.
  • Some of these tools use LDAP. Some use other directory services. Some don't.

What I think I want

Anyway... what I really want is the ability to use such an external access control list transparently inside TWiki ACLs. Like I said, I am reasonably happy with TWiki ACLs, once they are fixed. But instead of just listing TWikiUsers, I would like to be able to do something like

  • Set ALLOWTOPICREADWRITEACCESS = AndyGlew, Majordomo:!AnyoneInTheMeromProjectMailingList, Unix:!AnyoneInTheArchitectureUnoxGroup

Similarly, I might like to be able to define a TWikiUserGroup like FooProject to Orgchart:!FooProject + maybe a few others.

This can probably be implemented using Rafael'S PluggableAccessControlImplementation. Basically, standard access control list parsing is done (modified by the External: syntax). For each group source, the query IsMemberOf(!%USERNAMR%,!GroupServicePlugin) would be done. (Maybe with %WIKINAME% as an option, for sites not that worried about security.)

Problem the Last: performance. My TWiki site is slow enough as it is. I'd like to have some sort of caching rules, so that I would not, for example, constantly need to call some LDAP server.

-- Contributors: AndyGlew


Fixing escapes of ALLOWTOPICVIEW that broke the RSS feeds.

-- PeterThoeny - 15 Apr 2006

This is still more complicated and less flexible than RBAC.

-- AntonAylward - 16 Apr 2006

Andy, I solved all this once before with LDAP and a few lines of code in the core. A simple algorithm, looking at the Nick first and then the first name, usually solves the "wrong name" problem. I dodn't cache IDs, because I found that once sessions were established, the hit rate on the LDAP server plummeted.

SvenDowideit has already written code to abstract the user/group mapping out of the core; last I heard he was considering building it into a contrib.

Anton, yes, it's more complicated than just about any permission system you have ever seen. However it is a legacy inherited from a long time ago.

-- CrawfordCurrie - 17 Apr 2006

Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r7 - 2006-04-17 - FranzJosefSilli
  • 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.