Adopt a hierarchical "entitlements" based permissions model. This requires a highly generic data model, and will result in incredible flexibility later on. Many of the benefits only really come along when customisation is included, but here's something of an overview:
(I can't draw, so use your imagination). Start with a "top node" called System. System is an "entity". Below system are two countries, UK and US. Whilst they're called countries, they're just entities as well - we've just given them the name "country". The UK entity has the "UKP currency" entitlement, where as the US entity has "USD".
Below each country, there might be regions, or functional groups (eg. sales, technical etc). Below each ot those, perhaps more groups, or users. The key thing to note is that the hierarchy can be as high as you want, each entry is just an entity (although we may assign a name to an entity to make it easier for use to understand). The main difference between a "user" and a "group" is that the group does not have the "log on" entitlement.
As you go down the hierarchy, you only get access to the hierarchy of permissions enabled above you. For example, in this example, UK based groups get access to "Scottish Pounds" and "English Pounds". This means there must be hierarchical permissions, as well as a hierarchy of entities.
There's another complication... granting of entitlements. If a user in the UK is actually a manager, then she may be given the "grant" entitlement on a set of permissions (as well as the "create user" entitlement). Presumably, that manager would not be able to create more managers (so cannot grant the "create user") - that may take a "director" (ie. a manager with "grant create user").
The real complexity and power comes from the building of pages for users. Instead of simply writing a list of menu items, each item is entitled. If there's no entitlement, then you don't see the menu item. That same principle goes for all entities in a page, so in a Tiki sense, menus, modules, rss, etc etc.
Clearly, each page has to be built in a "generic" way that checks entitlements. Tiki is no where near that at the moment, because each PHP and TPL is written however the developer wants. With entitlements, all permissions code disappears from the PHP (and put into a library). The page output is less simple too, but once a framework is in place, making an entitlements based application is relatively easy (and as an application developer, you don't need to think about security!).
The main advantages are:
- Users get a view of the application that is completely geared to them. That is, a user can be created that (for example) only has "read blogs". That user will be completely unaware that there's also a Wiki on the system. Further, they might only have access to "UK blogs", so they would never know there were US blogs too (and unless they're hacking, will never see "permission denied").
- It is possible to delegate user administration to non-admin users. Those users may not have any other "write" capabilities, and could concievably be nothing except user creators or modifiers.
- It is possible to arrange that no user has overall, superuser access to the system (a bit like C2 security ;-)
- Application developers do not need to consider security
- All applications use a consistent security model and permission set (new applications can easily add permissions too).
- The features and facilities open to users are decided by the systems provider, not the application developer
- The scope for presentation customisation in association with entitlements is enormous. Much of this is in Tiki already.
- The scope for more complex applications (like business systems) increases.
- Security becomes incredibly fine-grained
I'll be honest, I'm not an expert on this subject, but it's well worth some looking into. The possibilities it opens up are incredible - most obviously, one "generic" application that users see as one thing or another. The devolved administration means that larger teams are supported, the only way to run a really big site. Also, each "page" or application will operate in the same way, and more code is shared in a library. Whilst "scope" is the most obvious benefit, without entitlements, Tiki may remain somehwat limited to "small" applications.
