Topic protection policy for publish-subscribe messaging system

Exemplary embodiments of the present invention disclose a method and system for securing a message published to a topic by a publisher in a publish-subscriber messaging system with a topic policy for the topic. In a step, an exemplary embodiment establishes a topic policy for a topic. In another step, an exemplary embodiment associates a message published to the topic with a topic policy. In another step, an exemplary embodiment signs a message published to the topic by a publisher with a private key of the publisher if the topic policy directs. In another step, an exemplary embodiment provides a public key of a subscriber if the topic policy directs that the subscriber receive a message in encrypted form. In another step, an exemplary embodiment encrypts a message for a subscriber specified in a topic policy to receive the message encrypted with a public key of the subscriber.

FIELD OF THE INVENTION

The present invention relates generally to data distribution systems and more specifically to authentication and security issues related to the access of information that has been categorized into topics in topic-based publish-subscribe messaging systems.

BACKGROUND

A publish-subscribe messaging system is a data distribution system that connects a set of publishers to a set of subscribers. Senders of messages, called publishers, have no knowledge of specific receivers, called subscribers, which consume their messages. The messages of publishers are categorized into classes (topics) and subscribers receive the messages in the classes that they are interested in without knowledge of who the publishers are. In the publish-subscribe model, subscribers typically receive only a subset of the total messages published. The process of selecting messages for reception and processing is called filtering. There are two common forms of filtering: topic-based and content-based. In a topic-based system, messages are published to “topics” or named logical channels. Subscribers in a topic-based system will receive all messages published to the topics to which they subscribe, and all subscribers to a topic will receive the same messages. The publisher is responsible for defining the classes of messages to which subscribers can subscribe. In a content-based system, messages are only delivered to a subscriber if the attributes or content of those messages match constraints defined by the subscriber. The subscriber is responsible for classifying the messages in a content-based system.

Subscribers to a publish-subscribe messaging system may be classified into durable and non-durable subscribers. A durable subscriber is a message consumer that receives all messages published on a topic, including those published while the subscriber is not connected. The messaging server, often called a broker, maintains a record of the durable subscription and ensures that all messages published on the topic are retained until they are acknowledged by the durable subscriber or they expire. A non-durable subscriber is a message consumer that only receives messages that are published while the subscriber is connected. Messages delivered while the non-durable subscriber is not connected are lost.

Topics are typically organized into a tree data structure (root at the top and leaves at the bottom) in which a given topic is represented by a node and may be a subtopic of another topic that is higher in a tree. Access to topics in a tree of topics is controlled by administration nodes in the tree that control access to the topic nodes below them. An administration node includes an authentication function that determines whether a specific user has an authority to access the messages in and/or publish to a topic node that is below the administration node in a tree, i.e., farther from the root of the tree than the administration node. Security is a major issue associated with publish-subscribe systems. Efficient ways to authenticate messages posted by publishers, i.e., prove that a publisher of a message is the publisher that is claimed, and the securing of selected messages by means of encryption are active areas of research.

SUMMARY

Exemplary embodiments of the present invention disclose a method and system for securing a message published to a topic by a publisher in a publish-subscriber messaging system with a topic policy for the topic. In a step, an exemplary embodiment establishes a topic policy for a topic. In another step, an exemplary embodiment associates a message published to the topic with a topic policy. In another step, an exemplary embodiment signs a message published to the topic by a publisher with a private key of the publisher if the topic policy directs. In another step, an exemplary embodiment provides a public key of a subscriber if the topic policy directs that the subscriber receive a message in encrypted form. In another step, an exemplary embodiment encrypts a message for a subscriber specified in a topic policy to receive the message encrypted with a public key of the subscriber.

DETAILED DESCRIPTION

FIG. 1depicts an exemplary embodiment publication subscription system in accordance with an embodiment of the present invention. Publisher103, executing in computer101, publishes message104by sending message104to broker108that is executing in computer106. Broker108has a list of valid publishers, in publisher permission list118, a set of topic policies in topic policies105, and a list of valid subscribers in subscriber list117. A topic policy includes a topic and a policy associated with the topic that specifies a set of actions that broker108performs during a publication to a subscriber of a message that is associated with the topic. The policy includes a list of subscribers to the topic and specifies whether a message published to the topic should be encrypted. A message is associated with a topic and further associated with a topic policy if a content of the message is classified by broker108to a topic of a topic policy in topic policies105. Topic policies105may not include a topic policy for a possible topic and a content of a message may be classified to a topic by broker108that is not associated with a topic policy in topic policies105. Broker108stores a public encryption key in publisher/subscriber public keys110of a subscriber listed in a topic policy that is in topic policies105. Broker108classifies message104to a topic and accesses topic policies105to determine if there is a topic policy in topic policies105that is associated with the topic.

If broker108classifies message104to a topic that is not associated with a topic policy in topic policies105, message104is placed in message queue111and broker108notifies all active subscribers to the topic that message104has been published. An active subscriber to a topic is a subscriber that receives a notification of only those publications to the topic that are published during a time in which the subscriber is active. An active subscriber to a topic notifies broker108that the active subscriber is active. A subscriber that is named in a topic policy of a topic is a durable subscriber and receives notification of a publication to the topic of a message regardless of whether the durable subscriber is active or not. If a subscriber to a topic is both a durable subscriber to the topic and an active subscriber to the topic, the subscriber is treated by broker108as a durable subscriber to the topic and not as an active subscriber to the topic.

If broker108classifies message104to a topic that is associated with a topic policy in topic policies105, broker108validates publisher103by searching for publisher103in publisher permission list118and determining if publisher103has permission to publish to the topic. If publisher103is not in publisher permission list118, publisher103is an invalid publisher and an error is generated and logged by broker108. If publisher103is found in publisher permission list118, broker108accesses the topic policy to determine if message104should be signed, and if so, secure messaging component107of broker108requests publisher private key102from publisher103and signs message104with publisher private key102of publisher103. Broker108determines if message104should be encrypted for each durable subscriber to the topic by accessing the topic policy. A topic policy contains an identification of all durable subscribers to a topic associated with the topic policy and specifies whether a specific durable subscriber to the topic should receive a message published to the topic encrypted with the durable subscriber's public encryption key or should receive the message unencrypted. There are many possible encryption techniques that can be employed in accordance with techniques of the present invention and an example encryption method is employed in the exemplary embodiment. Broker108extracts a name of durable subscriber114to the topic from the topic policy and inserts it into subscriber list117. Broker108adds a name of each active subscriber in active subscribers115to the topic to subscriber list117. If the topic policy specifies that message104should be encrypted for subscriber114, secure messaging component107of broker108encrypts message104with a public encryption key of subscriber114that is in publisher/subscriber public keys110. Broker108then places message104, which is encrypted if an encryption is specified by the topic policy and is not encrypted otherwise, into message queue111and notifies subscribers to the topic on subscriber list117which includes subscriber114and active subscribers115.

When subscriber114is notified that message104has been published by broker108by placing message104in message queue111, subscriber114asks broker108for the message, which secure messaging component107decrypts with subscriber private key113of subscriber114and message104is delivered to subscriber114by broker108.

FIG. 2is a flow chart depicting a publishing of message104from publisher103by broker108. Publisher103decides to publish message104in step201and sends message104to broker108in step202. Broker108classifies a content of message104to a topic in step203and searches topic policies105for a topic policy associated with the topic in decision step204. If a topic policy is not found in decision step204, broker108stores message in message queue111in step211and notifies subscriber114and other active subscribers115in step212that message104has been published. If a topic policy is found in decision step204, broker108validates publisher103in decision step205by determining if publisher103is in publisher permission list118and has permission to publish to the topic. If publisher103is not in publisher permission list118, publisher103is not a valid publisher, and broker108generates and logs an error in step213and waits for another message from a publisher. If publisher103is in publisher permission list118, broker108queries the topic policy in decision step206to determine if message104should be signed by publisher103. If message104should be signed by publisher103, broker108signs message104with publisher private key102in step207. Broker108determines if message104should be encrypted in decision step208by querying the topic policy for message104in topic policies105. If message104is specified to be not encrypted, broker108stores message104in message queue111in step211and in step212notifies durable and active subscribers to message104that message104has been published. If message104is specified to be encrypted, broker108identifies valid subscribers, that are valid durable subscribers or valid active subscribers, for an encrypted message104in step209, encrypts message104for each valid durable subscriber with each corresponding valid durable subscriber's public key in step210, stores each encrypted message104in message queue111in step211, and notifies valid durable subscribers and active subscribers in step212that message104has been published.

A detail of step209, identify valid subscribers, is presented in a flow chart inFIG. 3. To identify valid subscribers to a topic with a topic policy, broker108initializes subscriber list117to empty in step301and extracts zero or more names of durable subscribers to the topic from the topic policy in step302. All names extracted from the topic policy in step302are added to subscriber list117in step303and a name of zero or more active subscribers to the topic are identified in step304and are added to subscriber list117in step305.

FIG. 4is a flow diagram of actions taken by broker108when subscriber114requests message104from broker108after subscriber114has been notified that message104has been published in step401. In step402, subscriber114requests message104from broker108. Broker108examines a topic of message104in step403and in decision step404determines if there is a topic policy in topic policies105for the topic. If there is no topic policy in topic policies105for the topic, and subscriber114is an active subscriber, broker108delivers message104to subscriber114in step411. If there is a topic policy in topic policies105for the topic, broker108queries the topic policy to determine if subscriber114is a valid durable subscriber to the topic in decision step405. If subscriber114is not a valid durable subscriber and not an active subscriber, broker108generates and logs an error in step412and then waits for another request from a subscriber. If subscriber114is a valid durable subscriber, broker108queries the topic policy to determine if message104is encrypted in decision step406. If message104is encrypted, broker108decrypts message104with private key113of subscriber114in step407. If message104is not encrypted broker108proceeds from step408. In decision step408broker108queries the topic policy to determine if message104is signed with publisher private key102. If message104is not signed with publisher private key102, broker108delivers message104to subscriber114in step411. If message104is signed with publisher private key102, broker108verifies a signature of message104with a public key of publisher103that is in publisher/subscriber public keys110in step409. If the signature is determined to be valid in step410, broker108delivers message104to subscriber114in step411and waits for another request from a subscriber. If the signature is not valid, broker108generates and logs an error in step412and waits for another request from a subscriber.

FIG. 5depicts a block diagram of components of computer system106in accordance with an illustrative embodiment of the present invention.FIG. 5can also depict computer system101and computer system112as well as computer system106. It should be appreciated thatFIG. 5provides only an illustration of one implementation and does not imply any limitations with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environment may be made.

The media used by persistent storage508may also be removable. For example, a removable hard drive may be used for persistent storage508. Other examples include optical and magnetic disks, thumb drives, and smart cards that are inserted into a drive for transfer onto another computer-readable storage medium that is also part of persistent storage508.

Communications unit510, in these examples, provides for communications with other data processing systems or devices, including resources of computer system106. In these examples, communications unit510includes one or more network interface cards. Communications unit510may provide communications through the use of either or both physical and wireless communications links. Broker108may be downloaded to persistent storage508through communications unit510.

I/O interface(s)512allows for input and output of data with other devices that may be connected to computer system106. For example, I/O interface512may provide a connection to external devices518such as a keyboard, keypad, a touch screen, and/or some other suitable input device. External devices518can also include portable computer-readable storage media such as, for example, thumb drives, portable optical or magnetic disks, and memory cards. Software and data used to practice embodiments of the present invention, e.g., broker108can be stored on such portable computer-readable storage media and can be loaded onto persistent storage508via I/O interface(s)512. I/O interface(s)512also connect to a display520.