Access Control Policies

Inheritance of policies or usecases

One can block inherited policies for all usecases

<?xml version="1.0"?>

<policy xmlns="http://www.wyona.org/security/1.0" use-inherited-policies="false">

  <usecase id="view">
    <!--<world permission="false"/>-->
    <user id="lenya" permission="true"/>
  </usecase>

  <usecase id="open">
    <user id="lenya" permission="true"/>
  </usecase>

  <usecase id="write">
    <user id="lenya" permission="true"/>
  </usecase>

</policy>

or also for a particular usecase

<?xml version="1.0"?>

<policy xmlns="http://www.wyona.org/security/1.0">

  <usecase id="view" use-inherited-policies="false"
    <!--<world permission="false"/>-->
    <user id="lenya" permission="true"/>
  </usecase>

</policy>

Please note that the order in which the rights are defined matters. For example, imagine you have a group called "users" with access to a given set of resources. Now if you'd like to temporarily block a given user, you need to add the line revoking his rights to the top, as usually the policy manager uses the first line that matches for a user. Of course, if you use a custom policy manager implementation, it may behave differently.

Default usecases

The defaul usecases are currently hard-coded within org.wyona.yanel.servlet.YanelServlet and org.wyona.security.impl.PolicyManagerImplVersion2

view: Allows to access the resource generated content
yanel.resource.meta: Allows to access the meta data of resource (e.g. resource type)
open: Allows to access the source content of a resource
write: Allows to write/save data to the source content of a resource
delete: Allows to delete a resource
resource.create: Allows to create a resource
toolbar: Allows to access the Yanel toolbar
introspection: Allows to access the Neutron introspection of a resource
policy.read: Allows to view the access policy of a resource
policy.update: Allows to modify the access policy of a resource

Custom usecases

For example workflow transitions!

How it works

The access control directory mimics the data directory. Each file-or-dir-name.policy file sets the rules for its namesake in the respective data directory. If the filename is the name of a directory, it defines the access for the corresponding directory, if it is the name of a single file, it defines the rules for this file only. Definitions for directories are inherited by all subdirectories, exceptions need to be defined at the corresponding level (see the following example). The root policy that is installed by default and defines the rules for the whole realm is called .policy, and is in the root folder of the policies (realm-dir/ac-policies by default).

Example setup

Here is an example that shows what needs to be done to block view acces to all parts of a website except a special page (useful for production websites "under construction"). We will assume that the page that we want to show is realm-dir/data-repository/en/construction.html.

Leave the default policy open, i.e. in the file .policy in the root access control directory (realm-dir/ac-policies/.policy by default, defined in realm-dir/config/ac-policies-repository.xml), let everybody view everything:
```
  <usecase id="view">
    <world permission="true"/>
  </usecase>
```
Restrict viewing for everybody for the content (assuming it's all under data-repository/en/): create a policy file called en.policy and set
```
  <usecase id="view">
    <world permission="false"/>
  </usecase>
```

Make a directory for the path of the file you want to show, and a policy file for it:

mkdir realm-dir/ac-policies/en
vi realm-dir/ac-policies/en/construction.html.policy

and allow viewing:

  <usecase id="view">
    <world permission="true"/>
  </usecase>

You will also need to allow viewing for auxiliary files, like *.css. Assuming these can be found in the directory realm-dir/data-repository/app, create a file realm-dir/ac-policies/en/app.policy and set:
```
  <usecase id="view">
    <world permission="true"/>
  </usecase>
```

Similarly, you can now allow access to the whole site for a group of registered users by setting

  <usecase id="view">
    <group id="editors" permission="true"/>
  </usecase>

for the previously closed parts of the realm.

Policy Map

The "From Scratch Realm" contains an example of a policy map src/realms/from-scratch-realm-template/ac-policies/policy-map.xml which allows to define more complex rules to match requested resources with access policies. Please note that policy maps are currently only supported by org.wyona.security.impl.PolicyManagerImplVersion2.

The policy map also supports matching of query strings, e.g.

<matcher pattern="/*/projects/*/index.html?disable=*" path="/disable-enable-email_policy.xml"/>