Status

2007-02-28 - The new security code is complete and checked in (available in 2.0.0.21 and later). Related bugs remain in the web application, but these should be resolved soon.

Security Rules

Security in FlexWiki 2.0 is based around a set of security rules. A rule is a statement that consists of a polarity, a principal, an action, and a scope.

The polarity is either "allow" or "deny". That is, rules can be set up to either grant a certain type of access or restrict it.

The principal determines who is allowed or denied access. There are five types of principals: users, roles, anonymous, authenticated, and all. A rule with a user principal grants/denies access to exactly one user. A rule with a role principal grants/denies access to any member of that role. A rule with an anonymous principal grants/denies access to users who have not authenticated. A rule with a principal of "authenticated" grants/denies access to any user that has authenticated...in other words everyone except anonymous users. A rule with a principal of "all" grants/denies access to everyone, regardless of authentication status. All is equivalent to anonymous + authenticated.

The action is either Read, Edit, or ManageNamespace. Read and Edit are fairly self explanatory - they grant/deny the ability to read and/or modify a topic or namespace. The ManageNamespace action allows a principal to modify the namespace definition topic (usually _ContentBaseDefinition) and to lock or unlock topics (topic locking is not currently implemented).

The scope is either Topic, Namespace, or Wiki. Rules can be stated at any of these levels (see below for how), although ManageNamespace rules are only valid at Namespace or Wiki scope.

Evaluation Model

To determine if a particular principal can perform a given action, all the rules are assembled and arranged into a single list. Wiki-scope rules are listed first, then Namespace-scope rules, then Topic-scope rules. Within each scope, rules are sorted lexically. That is, rules that appear near the top of a particular topic are sorted before rules that appear near the bottom.

Once the list is assembled, it is walked from beginning to end. A "granted" bit is initially set to false. For each "allow" rule, the bit is set to true if the user making the request matches the principal in the rule, and if the rule action is equal or greater than the requested action. That is, allowing Edit implies allowing Read, and allowing ManageNamespace implies allowing Edit and Read.

For each "deny" rule, the bit is set to false if the user making the request matches the principal in the rule, and if the rule action is equal or less than the requested action. That is, denying Read also denies ManageNamespace and Edit, and denying Edit also denies ManageNamespace.

The requested permission is granted if the granted bit is set to true at the end of the evaluation. Note that this means that in the absence of any rules at all, all permissions are denied. The default permission set in a newly installed FlexWiki web application grants the ManageNamespace to all users, effectively turning off the security module.

Syntax

TODO

Examples

TODO

Disabling Security

TODO