Qpid Security Review and Strategy

Andrew Kennedy <grkvlt@apache.org> January 2011

There's no art to find the mind's construction in the face:
He was a gentleman on whom I built an absolute trust.
—
Macbeth,
Act I, Scene IV

Introduction
This document provides a review of the security features in the current version of the Apache Qpid
Java broker and client software [0] and their interoperability with other implementations and
versions.
The discussion of security features should also be seen as outlining a strategy for improving Qpid
to the point where it can be seen as a secure Enterprise Messaging System fitting into a best-of-
breed deployment of related products for applications in a large bank or managed service
provider. It is acknowledged that this is not the position today, and implementation of the security
features described should help strengthen the ability of Qpid to integrate and interoperate in a
current mature enterprise software ecosystem.
Some familiarity with security terminology is assumed, but in-depth knowledge of concepts such
as cryptographic primitives is not required.

Security Requirements
By Security we mean the following three assurances - the Confidentiality, Integrity and Availability
of data stored, processed and used by Qpid.

Confidentiality
The data that is transmitted to or intended for a user must [1] not be available to any other user of
the software. This means that it must not be possible for unauthenticated users to read arbitrary
messages flowing through the broker, and that a client connected with a certain set of credentials
must receive data for that user alone. This can be achieved partially through the use of wire-level
encryption, such as SSL/TLS, to prevent eavesdropping, however the problem of access control for
trusted users is more complex.
This requirement involves the broker knowing who a particular connection represents and being
able to control access to data based on this knowledge. In particular, it should be possible to
verify the identity of the user of a connection (authentication) through various means, including
enterprise-wide federated services, and also to perform role based access control (authorisation)
based on the results of querying those same, or other services, with that identity. This can be as
simple as verifying credentials passed during connection initiation with the local system, but there
must be some shared concept of identity between all communicating parties in order to make
meaningful statements about confidentiality beyond protection against eavesdropping.
Further, it should be possible for a client to know or restrict the identities of those it is
communicating with, which again requires some form of identity management that is trusted by
both the client and the broker.

Integrity
The data that is sent by one client must be unchanged by its transit through the broker, and it
should be verifiable by any receiving client that the received data is the same as that which was
sent. This can, again, be partially achieved through wire-level encryption, but this is not always
the best mechanism.
The requirement is for an HMAC [2] or Hashed Message Authentication Code to be presented
along with each message. This provides a form of tamper-resistance for the message by allowing
a client to recalculate the code and verify that the message contents have not changed in transit.

APACHE SOFTWARE FOUNDATION QPID PROJECT

There are several standardised mechanisms to provide this functionality, including the MD-5 and
SHA-1 algorithms, and these must be made available as choices to the Qpid client software.
It should be noted that once the client attaches an HMAC to a message, it is establishing the
authenticity and integrity of that message, and the broker should play no part except ensuring
that the received data is not modified before delivery, and perhaps verifying it was not modified en
route. To provide for interoperability with other AMQP clients it is desirable that the HMAC is
computed on the actual data that makes up the AMQP message, rather than at the JMS level, since
byte-ordering and wire-formatting of data come into play. For this reason, standardised methods
of adding extensions to AMQP may be required to implement this requirement fully.

Availability
It must not be possible for the actions of one client to prevent another client from accessing Qpid
services, or to remove or reconfigure resources that are not owned by that client. A single client
must not be able to monopolise or consume all the resources available to a broker. This
requirement stretches beyond security into business rules about the usage of a shared service,
and mechanisms for implementing and controlling those rules. For example, slow-consumer
disconnection and producer-side flow-control, as well as message time-to-live properties all
enforce certain limits on resource usage on the broker.
To fully prevent denial-of-service attacks is a useful, but basically unattainable goal. The mix of
client types and traffic present in a production messaging system will normally preclude the
strictest enforcement, due to peak operating concerns, such as end-of-day processing in a trading
system. However, implementation of business rules as well as some additional network or system
level controls (IP firewalling and access control lists and operating system memory and file-handle
limits) can be used to give some degree of assurance.
If High Availability is desired, then other solutions, again outside of the security domain, must be
found. These would include load-balancing and clustering mechanisms, and fall outside the scope
of this document.

Enterprise Requirements
As a piece of Enterprise Messaging System software there are several security requirements that
should be fulfilled by the Qpid broker (and client) for it to be able to be regarded as a best-of-
breed system. These are basically integration requirements, and can be classified as
Authentication, Authorisation, Auditing and Accounting , with the Assurance of confidentiality,
integrity and availability being accounted for by the basic operation of the software.
Each requirement must be implemented using a mechanism that is secure in and of itself, and
there are many mature technology choices and third-party security libraries for Java. Since
functionality is a major concern here, security APIs with a wide range of implemented providers are
desirable. We need to allow third parties to add their own mechanisms simply and easily, via a well
documented API. Qpid should also support as wide a range of providers as possible, not only to
guide implementers, but to provide maximum out-of-the-box flexibility. The only caveat here is
that documentation and testing must be extensive for all security sub-system components to
ensure we maintain credibility.
This diagram illustrates
broadly how a service
plugin mechanism would
link both a Qpid client and
broker to an external
service provider, for both
authorisation and
authentication. For
example, a client for a
trading system could use a
Windows Active Directory
plugin to authenticate the
current user and send a
security token to the broker

2
to establish identity. The broker would use the same Active Directory tree to verify the token and
retrieve the roles and permissions available to that user, for use in further access control
operations.
In general, these are cross-cutting concerns that all parts of the broker must be able to access,
and OSGi plugins provide a good mechanism to allow activation of arbitrary code, however there
must be a well-established API and an ability to manage configuration more generally must be
developed. In terms of the client, the only concern is authentication, therefore a simpler activation
mechanism can be used, although if the client is already in an OSGi framework then this would be
ideal. It should be possible to develop plugin libraries that can be used both via run-time
reflection-based class loading on a client and OSGi on the broker, with suitable configuration.

Authentication
This involves management and verification of identities. On an isolated, single system this can be
accomplished with a local database of users and credentials, however in a large enterprise we will
require the ability to integrate with identity management and authentication services. This will
require the broker, and to a certain extent the client, to understand the concept of identity.
Currently, the broker associates a username with a connection, based on the credentials passed
during setup. We support a mixture of JAAS [3] and SASL [4], which currently allows both Kerberos
authentication and password file lookup of plaintext and Base64 encoded MD5 hashed passwords.
This must be extended to allow lookup and verification of credentials using a variety of external
mechanisms, from the local operating system to enterprise single-sign-on and also Internet
authentication mechanisms such as OpenId [5] and authorisation such as OAuth [6]. This identity
would then be associated immutably with a client connection, and part of the identity management
process will necessarily involve the client performing some part of the verification, for example
with Kerberos or Web-based Internet identity providers.

Authorisation
Once identity has been established, the broker must decide what that identity is able to do. The
current broker provides a security plugin mechanism, utilising OSGi technology, that provides for
access control lists in two formats as well as a rudimentary IP firewalling capability. However,
these do not tie into the, even basic, identity mechanisms provided except to assume that
usernames match. To fully integrate with an enterprise security infrastructure, we should be able
to access an entitlements system, and obtain the set of permissions that apply to the currently
active identity, or to query that system about particular combinations of identity and permission to
provide access control.
Although there is an API available for access control, which could be provided to third parties, it
relies on the plugin to determine identity based solely on a username, which is not satisfactory. It
would be desirable to extend the plugin mechanism, however, to encompass a broader concept of
identity and roles, while maintaining the simplicity of the auto-loading of OSGi bundles.
Configuration should be integrated into the existing XML files used by the broker, but using an
extensible and publishable mechanism, to allow validation of plugin configuration.

Auditing
Currently the only auditing mechanism provided is the standard logging of operational messages
and debugging information. The access control plugins do allow for the logging of either success
or failure of a rule, but this should be made available as a separate sub-system, which access
control systems could then access. Generally an auditing sub-system should be able to securely
notify some central recording authority that an event occurred. In order for the information to be
useful, the identities recorded must be correlated with the client connection information.

Accounting
This service is not provided by Qpid at present, but is similar to auditing. Managed service
providers and large enterprises have a requirement to track both events and resource usage,
based on the identity of the client. This information needs to be linked to the other services to
provide a basis for billing, resource planning or similar functions.

3
Secure Transit
The current mechanism used by Qpid to secure data in transit across the network is SSL/TLS [7]
however this is currently implemented in different ways, depending on the AMQP protocol version,
by both the broker and the client. The main benefit of SSL is the fact that it is and Internet
standard, and therefore interoperability is guaranteed between different implementations,
assuming of course that enough care has been taken to configure those implementations
correctly.
The protection of data in transit is an operation that is entirely independent of the underlying
application protocol being used, and in many cases SSL is implemented at the network level, either
using hardware that is part of the network infrastructure itself or cryptographic co-processors.
The fact that SSL is at this low level suggests that it should be implemented in the Qpid network
stack in a similar position. We use both SASL and Mina to provide SSL services, as well as rolling
our own secure socket connections. Out of all of these mechanisms, the best suited to provide SSL
is the network connection interface, however when using SSL for authentication SASL must be
used, and this is therefore probably the best choice overall, and other SSL implementations should
be removed. This is indicative of the lack of testing of SSL both for encryption and authentication.
It should also be possible to advertise the presence of an SSL encrypted AMQP service in a similar
fashion to HTTP and HTTPS, by registering well-known port numbers with IANA, as well as unique
protocol names and URI schemes. This would simplify interoperability with the C++ broker, as
well as providing an easy way to test connectivity with clients written in various other languages.
If we ensure that the SSL mechanics are contained at a low enough level in the Qpid network stack,
the only choice required when setting up connections to a broker is whether to enable or disable it
based on the connection endpoint URI. Similarly, a broker listening on an SSL encrypted port will
use the same network classes once the decryption has happened, and they will process and
interpret the stream of bytes exactly as though they had been sent in the clear.
Currently, because of the variety of implementations, it is not possible to have confidence in the
operation and interoperability of Qpid using SSL. Although cursory inspection of the code does not
reveal anything immediately remiss, a full code review an refactoring of the relevant parts of the
codebase is required. Additionally, the entire system test suites should be run using SSL
encryption, to give assurance that it does not interfere with normal broker operations.
Additionally, documentation on setup and maintenance of an SSL secured broker is required,
particularly with regard to maintenance of a keystore and integration with existing certification
authorities or importing and using existing certificates. This would be complemented by similar
information for client software. A good example of this in another product is Apache Tomcat.

Authentication
Currently SASL is used for authentication, with the ability to access Kerberos and client-side SSL
certificates (X.509) for identity purposes, as well as flat-file password databases with plain-text
and Base64 encoded MD5 hashed passwords. It would be useful to be able to add different
authentication providers at the broker side, still based on the basic SASL APIs, but dynamically
loaded using a plugin system. These authentication systems would include, along with the existing
mechanisms:
• LDAP or Windows Active Directory
• SecurID Hardware Token
• SiteMinder or Similar SSO
• SQL Database Table
• OAuth and OpenId Providers
It is envisaged that it may be possible to combine another security library with SASL to provide
many of these services, such as Apache Shiro [8] or Spring Security [9]. SASL does provide a good
base to build a fully integrated authentication system, particularly in view of its ability to process
SSL certificates and Kerberos, but the Shiro framework (for example) is a much more user friendly
and usable API than JAAS, and provides the capability to create an authenticated session per

4
connection, with full information about the authenticated identity and its capabilities or
entitlements.

Passwords and Policies

It is desirable to have no plaintext passwords stored on the filesystem, however, for simple out-
of-the-box operation we do need a basic file-based mechanism to define identities for
authentication. We can specify that plaintext authentication is not allowed using SASL, and provide
sample password files using hashed passwords. Best practices would dictate that this be a Base64
encoded SHA-1 digest of the password, preferably with salting and multiple iterations. This is
easily supported by Shiro and the credential can be passed using SASL.
Password policies are another essential part of enterprise security, however this is not something
that we need to manage on the broker. Any sufficiently capable authentication system should
provide password strength, aging and other policies, which would be administered as part of that
system, rather than from the broker. This is an good illustration of the separation of concerns that
should be part of any security system.

Authorisation
We have a fairly comprehensive authorisation API, with support for dynamically loaded OSGi
plugins, which should serve as a model for other plugins. The entry-points to these plugins are
very comprehensive, however as mentioned above, there is no real integration with the identity
attached to the client connection. Also, we do not support a full, role-based authorisation system.
Ideally, an external API, such as JAAS or Shiro would be used to represent and load roles and
permissions for an identity (or principal) and query whether the identity has a particular
permission.
We could use the external APIs permission and role objects and initially simply substitute them for
the Qpid objects, loading the ACL and group information from the current files and eventually
move towards full separation of ACL definition and role and permission assignment. Once we have
achieved this separation, we would be able to leverage the ability to load roles and permissions for
the authenticated user from any configured external system.
The API would finally change to simply a mechanism for loading a set of ACLs from some location,
and could be used by any authorisation service provider plugin that linked roles and permissions
to authenticated users.

Single Realm
If we implement authentication and authorisation as described, this will allow us to associate an
identity with a session, and check permissions on that identity for all aspects of broker operation.
The use of role-based access control gives easy separation of administration and messaging
users, of course still allowing users to have any combination of permissions or roles desired. This
means a single authentication realm can be used to give access to the broker via JMS clients, JMX
connections or the QMF admin console.

Other Issues
All security interfaces should be defined and documented with example code for third-party
implementers. This would be made simpler if we use an existing package such as Apache Shiro,
JAAS or Spring Security. The addition of new authentication or authorisation realms should be
made automatic via OSGi on the broker, however attention must be paid to configuration and
management. It should be noted that, if we use external authentication realms, we no longer need
to have a user management facility in the broker, although tools would need to be provided to
administer any local file-based systems.
The configuration of broker and client side SSL/TLS certificates needs to be fully documented, and
a system test profile should be developed that enforces SSL at all times to properly exercise this.
Management and extension (Object/Schema) access control lists need further testing, particularly
with regards to compatibility between the ACL file formats on the Java and C++ brokers. The JMX

5
management permissions should also be applied to equivalent QMF operations, where this is
possible.
Consideration of filesystem security for data that is at-rest needs to take place, along with other
operating system level concerns such as access to processes and memory or configuration files.
Database encryption for the persistent store is a possibility here. Unfortunately this is not
currently possible with BDB although JavaDB and many other SQL databases do support encrypted
stores.
Interoperability between different clients written in various languages should be considered with
regards to support for different authentication mechanisms.
Use of AOP technologies [10] to implement security concerns is attractive, including annotation
based demarcation of access control list protected areas and audited subsystems. However, this
technology can have an impact on performance and make it difficult to reason effectively about
code-paths.
In general, the security status of Qpid and any desired new features and goals of the project
should be documented, and maintained, on the project web site. The design and implementation
details of new and existing security features should be openly discussed and documented and
changes tracked. Adherence to published security standards and integration with other projects
should be verified and publicised, to encourage community support.

Auditing
Auditing is a feature that is not well supported by the Qpid broker. There should be more, and
better quality, logging of security events, as well as the capability to write audit records of
significant broker events to other destinations. These would include JMX notifications, SYSLOG
logging, SQL database tables, SNMP traps, or even an AMQP queue on another broker.
Additionally, logging in the broker should be standardised to use SLF4J only, still with Log4J file
logging as the default configured logger. This would mean complete removal of custom Logger
code and System.err or System.out printing. The examination of both debug, informational and
operational logging should provide guidance as to where auditing should be performed.

Software Implementation
The current security features implemented by Qpid use
SASL, as this is a feature of AMQP, and this is essential
to retain. However, new features such as authorisation
realms and new authentication realms need not be
implemented from scratch. The standard Java security
mechanism and two other libraries were examined to
determine how they could be used to implement the
desired new features. JAAS is the existing Java security
mechanism, however this is simply an API and all
plugins would require to be written from scratch.
Instead, two ASF 2.0 licensed libraries were considered:
Spring Security and Apache Shiro.
Both provide similar functionality, but in terms of footprint, Apache Shiro is much more
lightweight, while still giving access to all the features that would be required. However, in the end
the decision to include this new library would be based on whether it was felt that it provided
enough benefit in terms of new functionality, depending on which features from this review are
chosen to be implemented. However it can be envisaged that interesting new applications would
be greatly simplified with this approach. For example, an Android based Qpid client could
authenticate a user using OpenId via the user’s Google account, and use the resulting credential
with a remote broker, to allow them to send messages to a queue permissioned with access
control lists, which is consumed by some other application.
An additional point to note in favour of Shiro is that it is currently used by other open source
enterprise messaging systems such as Camel, ServiceMix and Mule as well as being integrated
with projects like Maven, Hudson and many others. Shiro was previously known as JSecurity, and

6
has recently graduated from the Apache Incubator to become a top-level project in late 2010, and
released version 1.1.0 in December of that year.

Integration
The decision to implement security features using a project like Shiro will involve a large amount
of integration and refactoring work. However, the Qpid codebase will benefit greatly from the use
of a public API that is in widespread use, and with a variety of available security providers and
example code and documentation. The development and maintenance of sophisticated security
and cryptography features is not a core skill required by most of the Qpid committers, and they
should be able to concentrate on developing a high quality messaging system instead.
Due to the projects recent graduation to top-level status there are a number of informative
presentations on simple authentication with Shiro available [11] and they provide an excellent
getting started guide [12] as well as the usual API documentation [13].

The diagram above shows how Shiro fits into the existing Qpid and AMQP networking stack. Since
AMQP specifies SASL as the mechanism to negotiate security features, we simply leverage this to
call out to Shiro when required, and allow simple tasks such as SLL/TLS configuration to continue
to be managed and configured by SASL. Additionally, the broker will use the Shiro Session,
Identity, Permission and other model classes to implement new security mechanisms and integrate
existing facilities.

Conclusion
We have shown a set of security features that are desirable for a software product to be taken
seriously in the Enterprise Messaging System space today. The areas where Qpid falls short have
been highlighted, and then illustrated mechanisms that can be used to implement these features.
As well as new development, refactoring and redesign of existing features will have to take place.
It will also be necessary to carry out additional testing, documentation and other interoperability
tasks to maintain an acceptable security status for Qpid. We describe how the Apache Shiro
security library can be used to add many of the required features simply and easily, and how this
will benefit both users and third-party developers integrating with Qpid.

7
References
[0] http://qpid.apache.org/ Apache Qpid Home Page
[1] http://tools.ietf.org/html/rfc2119 Key words to Indicate Requirements Levels
[2] http://tools.ietf.org/html/rfc2104 Keyed-Hashing for Message Authentication
[3] http://download.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html JAAS
Reference Guide
[4] http://tools.ietf.org/html/rfc4422 Simple Authentication and Security Layer
[5] http://openid.net/ OpenId Authentication
[6] http://oauth.net/ OAuth Authorisation
[7] http://tools.ietf.org/html/rfc5246 Transport Layer Security 1.2
[8] http://shiro.apache.org/ Apache Shiro Home Page
[9] http://static.springsource.org/spring-security/site/ Spring Security Home Page
[10] http://www.eclipse.org/aspectj/ Aspect-Oriented Programming (AspectJ)
[11] http://www.slideshare.net/marakana/simple-application Simple Application Security Presentation
[12] http://shiro.apache.org/10-minute-tutorial.html 10 Minute Shiro Tutorial
[13] http://shiro.apache.org/static/current/apidocs/ Shiro Java API Documentation