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.

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.

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.

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.

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);

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;

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);

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();

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);

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);

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.

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

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. ${QPID_HOME}/etc/global-security-config.txt ]]>

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.

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

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"

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 }

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 />.