# Security Plugins Documentation

## Introduction

This document describes the structure and design of Qpid security plugins, for the Java broker. In particular, the new Access Control plugin, which implements the same ACL file syntax as the C++ broker, is examined in detail. The security plugins use the broker's OSGi bundle functionality to manage their lifecycle, and the `ConfigurationPlugin` mechanism to manage their configuration via the Apache commons configuration XML configuration file.

The Java interfaces and packages used by the security plugins are described here, although the Javadoc documentation generated from the source should also be consulted, and as always reading the source should provide further insight and information.

## Use Cases

The following use cases were identified and used to drive the design and development of both the security plugin mechanism in general, and the access control plugin in particular.

- Allow access to broker functions to be controlled by an ACL, with the checks being carried out independently of the mechanism used to access the broker. This would mean that a single `CREATE` permission would apply whether the queue was created when a user logged in and used it, or if that user connected to the broker via JMX or QMF and used the management operations to create the queue.

- Permissions must be definable at a virtualhost level, with fallback to global permissions. This allows access to be granted for operations only on a certain host, while global operations such as broker administration can be defined at the global level. It also allows default behaviour to be specified globally and then overridden on a per-host basis.

- The ACL mechanism controls access to operations on particular objects for all users, if at least one user has a rule controlling access to that operation on that type of object. This means that all users requiring access to a particular operation must be configured. The default behaviour will be to deny access.

- It should be possible for the addition of one access control rule to trigger the addition of other rules, to simplify creation of rulesets.

- The behaviour of the access control mechanism should be configurable.

- The Java and C++ brokers should share a common configuration file format.

- It should be possible to configure access to not just internal broker application objects, but to the management operations and attributes of the broker, as well as to external objects such as plugins.

- As long as a suitably authenticated channel is used to connect, access control rules should be applied when performing operations on broker objects. This does not hold when, for example, an operator has local access and is using JConsole to manage the broker.

## Java Interfaces, Packages and Classes

This section describes the Java artifacts that are involved in security plugin development. They are mostly contained in the package `org.apache.qpid.server.security` which is part of the broker code. It is recommended that a package prefix is chosen for new security plugins, and this should be used to form the packages for the implementing classes.

In general, when creating a new plugin, you need three classes. These would be the main `PluginName` class, which should implement the `SecurityPlugin` interface and have a public static instance of an anonymous internal classes that implements `SecurityPluginfactory`. Additionally, the `PluginNameConfiguration` class, which should implement the `ConfigurationPlugin` interface and have a public static instance of an anonymous internal classes that implements `ConfigurationPluginfactory`, and finally the `PluginNameActivator` class, which should extend the `SecurityPluginActivator` abstract class and implement the required methods exposing the factories from the other classes.

These classes need to be visible from the broker, so they should be placed in the `org.apache.qpid.server.security.pluginname.plugins` package, which should be listed in the manifest file. Any internal classes for the plugin should be placed in the `org.apache.qpid.server.security.pluginname.config` package which should be marked as provate in the manifest.

If logging using the actor and subject framework is required, the property file should be located in the `org.apache.qpid.server.security.pluginname.logging` package, and this should also be exported in the manifest file.

### OSGi

The security plugins are now loaded using the Felix OSGi container, which is started as an embedded process inside the broker. This loads all plugin .jar files from the directory named in the `plugin-directory` configuration element, cacheing them in the `cache-directory` directory. Note that, at present, the cache directory is cleared at startup, although this behaviour may change. To create OSGi plugin bundles, a manifest file - `MANIFEST.MF` is created that specifies certain attributes of the bundle. A sample manifest file for one of the security plugins is shown below.

    Manifest-Version: 1.0
    Bundle-ManifestVersion: 2
    Bundle-Name: Qpid Broker-Plugins PluginName
    Bundle-SymbolicName: broker-plugins-pluginname
    Bundle-Description: Name description.
    Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
    Bundle-DocURL: http://www.apache.org/qpid/pluginname.html
    Bundle-Version: 1.0.0
    Bundle-Activator: org.apache.qpid.server.security.pluginname.plugins.PluginNameActivator
    Bundle-RequiredExecutionEnvironment: JavaSE-1.5
    Bundle-ActivationPolicy: lazy
    Import-Package:  org.apache.qpid
    Private-Package: org.apache.qpid.server.security.pluginname.config,
     org.apache.qpid.server.security.pluginname.logging
    Export-Package: org.apache.qpid.server.security.pluginname.plugins

The complete list of packages to import will be determined by the actual operation of the plugin, however the number of exported packages should be kept to a minimum.

### Plugin

This is the main interface to be extended by all plugins. It contains a method that allows configuration via the `ConfigurationPlugin` mechanism.

    public void configure(ConfigurationPlugin config);

### PluginFactory and SecurityPluginFactory

These factories are used to initialise instances of plugins and configure them appropriately. The factories are managed by the OSGI framework started by the `PluginManager`, which is also used to retrieve the instances.

    public Class<P> getPluginClass();
    public String getPluginName();
    public P newInstance(ConfigurationPlugin config)  throws ConfigurationException;

### SecurityPlugin

This is the interface that defines security plugins. The `getDefault` method returns the default result for the plugin when no configuration is found for some situation.

The `authorise` method is the main entry-point to the plugin, and is called by the `SecurityManager` with the relevant paramaters. Similarly, the `access` method is used for the special case of controlling access to the entire virtual host, and the ``

    Result getDefault();
    Result access(ObjectType objectType, Object instance);
    Result authorise(Operation operation, ObjectType objectType, ObjectProperties properties);

### SecurityPluginActivator

The activator registers the factories with the OSGI framework, based on the implementations of the abstract methods.

    public abstract SecurityPluginFactory getFactory();
    public abstract ConfigurationPluginFactory getConfigurationFactory();

### AbstractPlugin

This is a simple parent class, which allows a common point of extension for shared plugin code. Currently it simply implements the interface with abstract methods.

    public abstract Result access(ObjectType object, Object instance);
    public abstract Result authorise(Operation operation, ObjectType object, ObjectProperties properties);

### AbstractProxyPlugin

This class is designed to be extended by plugins that only wish to take part in a subset of the possible security descisions. Normally, a call to the `authorise` method is proxied to one of the provided methods, based on the operation, for example a `CONSUME` access control check would be proxied to the `authoriseConsume` method with the appropriate paramaters set. The default behaviour is to return `ABSTAIN`, meaning the plugin does not handle this type of operation. If a method is overridden, it can then perform whatever security checks are required and return `ALLOWED` or `DENIED` as appropriate.

    public Result authoriseConsume(ObjectType object, ObjectProperties properties);
    public Result authorisePublish(ObjectType object, ObjectProperties properties);
    public Result authoriseCreate(ObjectType object, ObjectProperties properties);
    public Result authoriseAccess(ObjectType object, ObjectProperties properties);
    public Result authoriseBind(ObjectType object, ObjectProperties properties);
    public Result authoriseUnbind(ObjectType object, ObjectProperties properties);
    public Result authoriseDelete(ObjectType object, ObjectProperties properties);
    public Result authorisePurge(ObjectType object, ObjectProperties properties);
    public Result authoriseExecute(ObjectType object, ObjectProperties properties);
    public Result authoriseUpdate(ObjectType object, ObjectProperties properties);
    public Result accessVirtualhost(Object instance);

## Access Control Security Plugin

This security plugin implements access control using the same configuration file syntax as the C++ broker. The classes are all in sub-packages of the `org.apache.qpid.server.security.access` package. The exposed classes consist of the plugoin itself, its OSGi activator and the configuration plugin, as well as the properties file and generated code for logging. The private, internal classes, consist of the ruleset implementation for managing access control list rules. The plugin also makes extensive use of the enumerations provided by the broker as part of the security plugin interfaces, for operations, objects and permissions.

### Enumerations

These enumerations are used to define exactly what a security plugin can control.

The `ObjectProperties` and `ObjectProperties.Property` lalala

The `ObjectType`

The `Operation`

The `Permission`

### Configuration

Security plugins are configurable using the Qpid XML configuration file, under the `<security>` element. This can be either inside the main `<broker />` element, as a global plugin affecting all virtual hosts, or under a `<virtualhosts><virtualhost><name>` element, where the `<name>` element is the name of the virtual host that is to be configured. Each security plugin must register the elements it expects to process using a `ConfigurationPlugin`, which is documented elsewhere.

The plugins are checked in order, first for the virtual host, then globally, and the first `ALLOWED` or `DENIED` response is used.

The ACL configuration file is specified via the contents of the `<aclv2>` element. This is simply the path to the file, which is a plain text format, and is parseable by both Java and C++ brokers. The path can be specified with embedded property value interpolation, for environment variables or other properties defined in the configuration file.

    <security>
        <!-- global access control configuration file -->
        <aclv2>${QPID_HOME}/etc/global-security-config.txt</aclv2>
    </security>

#### File Format

The file format is described below.

- Whitespace is considered to be any ASCII byte with a value below `0x20`, and is ignored when it occurs between tokens.

- Continuations using the `\` character (ASCII `0x5c`) are allowed anywhere on a line, and can consist of a blank line with a continuation character as the last non-whitespace token

      group group1 name1 name2 \
                   name3 name4 \
                   name5
      acl allow group1 create queue \
      	property1 = "value1" \
      	property2 \
      		= "value2"

- Comments are line-style comments, and any text after an un-quoted `#` (ASCII `0x23`) are ignored, including continuations. The `#` charater may appear in a quoted string.

- Quoted strings consist of any ASCII inside matching pairs of `'` or `"` (ASCII `0x27` and `0x22`) characters, including any otherwise special characters.

- Tokens are NOT case sensitive, but quoted strings ARE.

- The `=` (ASCII `0x3d`) character is special, and is used to indicate property value assignment.

- Wildcards are specified using the `*` (ASCII `0x2a`) character in a property value string, which may be quoted.

- Empty lines and lines that contain only whitespace are ignored.

- The keyword `all` is reserved, and matches all individuals, groups and actions. It may be used in place of a group or individual name and/or an action - eg `acl allow all all`, `acl deny all all` or `acl deny user1 all`.

- Rules are interpreted from the top of the file down until the name match is obtained; at which point processing stops.

- The last line of the file (whether present or not) will be assumed to be `acl deny all all`. If present in the file, any lines below this one are ignored.

- Names and group names may contain only `a-z`, `A-Z`, `0-9`, `-`, `@`, `/` or `_`.

- Rules must be preceded by any configuration and group definitions they may use; any name not previously defined as a group will be assumed to be that of an individual user.

- `CONFIG` lines must have the following tokens in order:

  - The string literal `config`

  - One or more property name-value pairs, in the form `property = value` where value is the token `true` or `false`

- GROUP lines must have the following tokens in order:

  - The string literal `group`

  - The name of the group, which cannot contain `@` or `/` characters

  - A whitespace separated list of user and group names. User names are formatted as `username/domain@realm` and group names must have been defined earlier in the file

- ACL rules must have the following tokens in order:

  - An optional rule number, which should be expressible as a positive Java integer

  - The string literal `acl`

  - The permission, one of `allow`, `allow-log`, `deny` or `deny-log`

  - The name of a single group or individual or the keyword `all`

  - The name of an operation, which should be one of `consume`, `publish`, `create`, `access`, `bind`, `unbind`, `delete`, `purge`, `update`, `execute` or the keyword `all`

  - Optionally, a single object type or the keyword `all`

    Objects allowed are `virtualhost`, `queue`, `topic` and `exchange`

    Objects allowed are `virtualhost`, `queue`, `topic`, `exchange`, `link`, `route`, `method` and `object`

  - If the object is present, then optionally one or more property name-value pairs in the form `property=value`. The property and value can be separated from the `=` charater by any amount of whitespace, and the calue can be quoted if it contains special characters or whitespace.

  - Property values can add the wildcard `*` character at the end of the string to indicate that any string beginning with the characters up to the wildcard will match, or if the wildcard is the only character, that any string will match

This allows a rather looser and more readable style for ACL files, while still retaining the ability to read the stricter files accepted by the C++ broker. Bear in mind that the group declarations are to be deprecated, in favour of an external directory service, using a plugin mechanism.

The initial number is used to allow rulesets to be created which allow individual rules to be enabled and disabled using an admin interface, and an ACL file using numbered lines would be restricted to having increasing numbers per rule, although gaps would be allowed to enable rules to be inserted later, again using an admin interface. This administrative interface would also allow saving of a modified ruleset and re-loading.

#### Broker Access Control

The Java broker access control mechanism is used to protect internal entities used by the broker. These are virtual hosts, queues, topics and exchanges. The actual access control checks take place in the methods that carry out the operations on these objects, in order to ensure thatsecurity is both mechanism and protocol agnostic.

The Java broker does not support `LINK` or `ROUTE` object types.

An example of the various rules that can be specified follows:

    acl allow robot create exchange name="robot.*"
    acl deny kitten create queue
    acl allow guest bind exchange name=amq.topic routingkey="kitten.#"
    acl allow all create queue name="tmp.*"
    acl allow guest publish all durable="false"
    acl allow robot create queue name="robot"
    acl allow kitten consume queue durable="true"
    acl allow guest create all

#### Management Access Control

The management of the broker using JMX is also protected by the security plugins, in two ways. If the management interface is used to perform operations that would be access controlled normally, the same rules would still apply and be applied. However, this only occurs when the JMX connection was authenticated. If JConsole is used to connect directly to a broker process started by the same user, then no extra checks are made.

The management operations themselves are also able to be access controlled. This is done using the `METHOD` object type. A component name and method name are specified as properties, and these indicate the MBean type name and JMX method name respectively. If the operation is set to `ALL` then reading JMX attributes, writing JMX attributes and invoking JMX operations are controlled by the rule. Otherwise, the three operations `ACCESS`, `UPDATE` and `EXECUTE` control reading, writing and invocation respectively.

    ACL ALLOW user ALL METHOD
    ACL ALLOW user ALL METHOD name="method"
    ACL ALLOW user ALL METHOD name="prefix*"
    ACL ALLOW user ALL METHOD component="MBean" name="method"
    ACL ALLOW user ACCESS METHOD component="MBean"
    ACL ALLOW user UPDATE METHOD component="MBean"
    ACL ALLOW user EXECUTE METHOD component="MBean"

#### External Object Access Control

At the moment the C++ broker has an extension point to allow access control of external objects. This will be provided in the Java broker as well, using the `ACCESS OBJECT` rule, with package name and class name properties. The external object must be able to retrieve a reference to the virtual host it is running on, and then call the `accessObject` method. This must be the responsibility of the external object.

Note that this is not currently implemented in the `SecurityManager`.

    ACL ALLOW user ACCESS OBJECT package="com.example.application" class="Extension"

    if (!_vhost.getSecurityManager().accessObject("com.example.application", "Extension"))
    {
        // TODO reject access somehow - exception
    }

## Other Security Plugins

There are two basic plugins provided internally by the broker, which can be found in the `org.apache.qpid.server.security.access.plugins` package. These are `AllowAll` and `DenyAll`. The `LegacyAccess` plugin is not normally required, and simply ignores legacy elements of the configuration file. The other two plugins are activated by the presence of an element in the `<security />` section of the configuration or virtual hosts XML files. To deny all access by default, add the empty `<deny-all />` element, and to allow all access, add `<allow-all />`.