Design Advantages

FioranoMQ allows developers to focus on building the application and not on implementing a security policy. Security operates independent of application code through an easy-to-use, central administration interface that manages Users, Groups, and Access Control Lists (ACLs). This design permits remote administration for all aspects of security. If security policies of an organization change, the system administrator can manipulate security mechanisms of FioranoMQ without requiring the application developers to rewrite any application code. By allowing security policies to change with business needs, FioranoMQ provides the flexibility that extends the life of an application.

Effective Protection of JMS Destinations

FioranoMQ achieves security by protecting the JMS Destination: Topics and Queues. This enables security to be addressed through the design of Topics and Queues Existing applications take advantage of new security features as soon as they become available in newer versions of FioranoMQ.

Centralized Control

The identification and authentication process is the only area where the client application must address security. The application developer is responsible for the task of soliciting and passing the username and password to FioranoMQ. This requires that the application access sufficient information from the User to allow FioranoMQ to authenticate the User. This is the only information the client application code needs for security. The system administrator uses an external Administration Tool to visually set the security policies, which FioranoMQ enforces.

FioranoMQ and its security subsystem do not require any pre-existing software to be installed by the client. All security functions are inbuilt in FioranoMQ and provided through standards-based Java Development Kit (JDK) interfaces. As such, security is built into each and every application or applet that is created by FioranoMQ. Moreover, a developer need not worry about whether the application runs locally or as a downloaded applet. The FioranoMQ security subsystem does not require access to any local (client-side) resources. The security subsystem uses either part of the Java runtime environment or classes downloaded with the applet to function.

Destination-based Security

In FioranoMQ, all the information flow is based on destinations, as explained below:

• Developers organize content based on destinations.
• Applications can register their interest in consuming the information by subscribing to a destination.
• Applications can produce information by publishing messages to destinations.
• The FioranoMQ Server routes information from publishers to subscribers based on the destination.
• The security subsystem takes advantage of the dependency of information flows within destinations. By protecting the destination, the flow of information can be precisely and dynamically controlled. FioranoMQ refers to this as destination-based security. FioranoMQ associates a security policy with every destination.

Authorization and Access Control

FioranoMQ provides the ability to control Users that can publish, subscribe, or request guaranteed delivery on a particular destination, through the use of Access Control Lists (ACLs). The system administrator uses the Administration Console to define ACLs for specific destinations. FioranoMQ automatically uses these ACLs as described in the following section.

The FioranoMQ Server performs access mediation on publish and subscribe operations of a client and on guaranteed delivery requests. For example, when the client subscribes to a destination, the server receives the policy for the destination and checks to verify whether the client is permitted to subscribe to that particular destination. If durable subscription is requested on the destination, an access check is also performed for durable subscription at the time the DurableSubscriber object is created. If either one of these checks fail, the subscription request is rejected and the client application throws an exception.

When a client publishes a message on a destination, the server checks to verify, whether or not the client is authorized to publish on that destination. If the client is not authorized, the publish request is rejected and the client application throws a JMS Exception. If the client is authorized, the server delivers the message to all the clients subscribed to the destination of the message.

Access mediation is performed on the server side. However, a client can check for permission to publish, to subscribe or to request a guaranteed delivery of messages to a specific destination by retrieving the appropriate ACL object and examining its contents.

The system administrator uses the administration console to add new Users and Groups and/or new policies for destinations.