APACHE SOFTWARE FOUNDATION QPID PROJECT

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.

2

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

3

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.

4

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

5

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

6

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

7

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.

8

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