Object reference not set to an instance of an object.
Object reference not set to an instance of an object.
FlexWiki Authorization
.

See Also

FlexWikiSecurity, FlexWikiAuthentication

Status

2007-02-28 - The new security code is complete and checked in (available in 2.0.0.21 and later).

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

At wiki scope, authorization is expressed via the rules in the flexwiki.config file. Currently, that format looks as follows:

 <configuration>
  <FederationConfiguration>
    <AuthorizationRules>
      <Rule Type="Allow" Action="ManageNamespace" Principal="all" />
      <Rule Type="Deny" Action="Edit" Principal="user:candera" />
      <Rule Type="Allow" Action="Read" Principal="role:managers" />
      <Rule Type="Deny" Action="ManageNamespace" Principal="anonymous" />
      <Rule Type="Allow" Action="Edit" Principal="authenticated" />
    </AuthorizationRules>
  </FederationConfiguration>
 </configuration>

Which demonstrates each of the various values of each attribute. Note that with the exception of the value of the Principal attribute, case is significant. In the future, editing this section of the config file will be enabled via the /admin web share - this is not currently implemented.

The syntax for principals is consistent throughout. User principals start with "user:", role principals start with "role:", and the generic principals are simply "all", "authenticated" or "anonymous".

At the topic and namespace scopes, authorization rules are expressed via TopicProperties. The name of the property indicates the polarity and the action, and the value of the property indicates the principal or principals who are being granted/denied authority. Topic-scope rules are simply properties of that particular topic, while namespace-scope rules are properties in the namespace definition topic (usually _ContentBaseDefinition). Note that this means that it is not possible to set specific permissions on the namespace definition topic - it will always have the same permissions as the namespace itself.

Multiple principals can be listed by using comma-separated lists. For example:

 AllowRead: user:candera, role:managers, anonymous
 DenyEdit: all
 AllowManageNamespace: authenticated, user:dornstein

Note that the ManageNamespace action is only meaningful at the namespace level (i.e. when it appears in the namespace definition topic), and will be ignored when present on any other topic.

Examples

Allow everyone to do everything

Put this in the flexwiki.config file:

 <configuration>
  <FederationConfiguration>
    <AuthorizationRules>
      <Rule Type="Allow" Action="ManageNamespace" Principal="all" />
    </AuthorizationRules>
  </FederationConfiguration>
 </configuration>

Note that this is the default configuration for FlexWiki.

Allow everyone to read, but only authenticated users to do anything

In the flexwiki.config file:

 <configuration>
  <FederationConfiguration>
    <AuthorizationRules>
      <Rule Type="Allow" Action="Read" Principal="all" />
      <Rule Type="Allow" Action="ManageNamespace" Principal="authenticated" />
    </AuthorizationRules>
  </FederationConfiguration>
 </configuration>

Allow only authenticated users access to a particular namespace

In the flexwiki.config file:

 <configuration>
  <FederationConfiguration>
    <AuthorizationRules>
      <Rule Type="Allow" Action="ManageNamespace" Principal="all" />
    </AuthorizationRules>
  </FederationConfiguration>
 </configuration>

In the namespace definition topic for some namespace:

 DenyRead: anonymous

Note that anonymous users won't even be able to find out that this namespace exists - without Read permission at the namespace level, a namespace disappears entirely.

Allow everyone to read a namespace, but only authenticated users to edit

 <configuration>
  <FederationConfiguration>
    <AuthorizationRules>
      <Rule Type="Allow" Action="ManageNamespace" Principal="all" />
    </AuthorizationRules>
  </FederationConfiguration>
 </configuration>

In the namespace definition topic for some namespace:

 DenyEdit: anonymous

Other users will still be able to read any content of this namespace (and edit content in any other namespace).

Stop a particular user from reading a particular topic

In the topic in question:

 DenyRead: user:candera

Note that the user will still be able to tell that the topic in question exists (assuming they have read access to the namespace), but that they will not be able to tell anything else about the topic. For example, they cannot determine by whom or when the topic was last edited.

Disabling Authorization

It is very easy to lock yourself out of the wiki..simply put a "DenyRead: all" in the wrong place. If this happens, or if you need to disable FlexWikiAuthorization for any other reason, you will need to edit the flexwiki.config file. For each namespace that you want to disable security on, add the "Security.Disabled" property and set its value to "true" (case-insensitive). For example:

 <configuration>
  <FederationConfiguration>
    <NamespaceProviders>
      <Provider Type="FlexWiki.FileSystemNamespaceProvider" AssemblyName="FlexWiki">
        <Parameters>
          <Parameter Name="Namespace" Value="SampleNamespaceOne" />
          <Parameter Name="Root" Value="Namespaces\SampleNamespaceOne" />
          <Parameter Name="Security.Disabled" Value="true" />
        </Parameters>
      </Provider>
    </NamespaceProviders>

This will make all authorization properties no-ops, allowing full control to everyone (modulo any ASP.NET or filesystem security that has been set up).

Object reference not set to an instance of an object.