Abstract:
A method, apparatus and computer program for controlling access to a publish/subscribe message broker. Publish/subscribe functions provided by the message broker are divided into function sets. Each function set is associated with a communication path. A request is received at the message broker via one of a plurality of communication paths and requests access to a publish or subscribe function provided by the message broker. It is determined which communication path is used and it is identified which function set the requested function is a part of. It is then determined whether the identified function set is associated with the communication path used; if the result is positive then access to the requested publish or subscribe function is provided.

Description:
FIELD OF THE INVENTION  
       [0001]     The invention relates to access control.  
       BACKGROUND OF THE INVENTION  
       [0002]     A server is often connected to two or more networks with each network connecting devices of a particular type to the server.  FIG. 1  shows an example of a Supervisory, Control And Data Acquisition (SCADA) system  10 . Devices  30 ,  40  and  50  are connected to an oil pipeline  20 . They may for example be sensory devices monitoring information such as oil flow rate and temperature. They publish information via network  60  to message broker  70 . Message broker  70  is connected to this network via a first network adapter card and is also connected via a second network adapter card to an enterprise intranet  95  containing devices  80 ,  85  and  90  (neither adapter card is illustrated on the diagram). Such devices subscribe to receive information from the publishing devices and use such information to monitor the oil pipeline operation.  
         [0003]     As shown in  FIG. 2 , the message broker  70  may be located in what is termed a “demilitarised zone” (DMZ) network  100 . This zone acts as a buffer between an external network (e.g. the Internet) and an internal network (e.g. an Enterprise Intranet). Machines on both the external and the internal network may connect to a server in the DMZ, but only on certain ports, controlled by firewalls  110 ,  120 . In the case of a publish/subscribe message broker used for a SCADA applications, machines connecting from the Internet may, by way of example, publish data, and machines connecting from the Enterprise intranet may, by way of example, subscribe to that incoming data. The broker will send such information over previously established connections between the broker and its subscribers. The DMZ may have a packet filter (firewall)  110  at the entrance that determines what IP addresses and ports in the DMZ an internet-connected machine is allowed to connect to. There is also a similar setup  120  between the message broker and the enterprise network.  
         [0004]     Thus it should be appreciated that firewalls that police the traffic to and from a machine are known. Firewalls can be of numerous types. For example, a network layer firewall can be configured to filter traffic on the basis of source or destination IP address and source or destination port, and protocol type. Application layer firewalls are also known and these can be used to filter the traffic to and from particular applications. They may be used, for example, to prevent inappropriate content from being displayed in a web page.  
         [0005]     A firewall is however just one part of a complete security solution. Other access control mechanisms are also well known in the art. For example, Virtual Private Networks (VPNs) provide trusted users with access to resources not available to general users. In the pub/sub arena Access Control Lists (ACLs) may be used to determine which users are allowed to publish on particular topics and which may subscribe to particular topics. Equally, access to a particular machine or application may only be allowed through a specific access port.  
         [0006]     Security is also an issue when a server is accessed via only one network.  
         [0007]     There is a need in the industry for an improved security mechanism addressing the situation where one server is being accessed by different devices. The server may be attached to one network only or may be connected to a plurality of networks, with devices on each network attempting to access the server.  
       SUMMARY OF THE INVENTION  
       [0008]     According to a first aspect, there is provided a method for controlling access to a publish/subscribe message broker, the method comprising: 
    dividing publish/subscribe functions provided by the message broker into function sets; associating each function set with a communication path;     receiving a request at the message broker, the request arriving via one of a plurality of communications paths at the message broker and requesting access to a publish or subscribe function provided by the message broker;     determining which communication path is used;     identifying which function set the requested function is a part of;     determining whether the identified function set is associated with the communication path used;     and responsive to determining that the identified function set is associated with the communication path used, providing access to the requested publish or subscribe function.    
 
         [0015]     In one embodiment, it is determined which port is used to access the message broker and it is then determined whether the identified function set is associated with the port used to access the broker.  
         [0016]     In one embodiment, it is determined which communication network the request originates from and it is then determined whether the identified function set is associated with the communication network from which the request originates.  
         [0017]     In one embodiment, the communication network from which the request originates is identifiable by an address comprising a network part and a host part. In this embodiment, the communication network with which the identified function set is associated is also identifiable by at least a network part. In order to determine whether the identified function set is associated with the communication network from which the request originates comprises, the network part of the communication network from which the request originates is compared with the network part of the communication network with which the identified function set is associated.  
         [0018]     In one embodiment a subnet mask is used to determine whether the network part of both communication networks are the same.  
         [0019]     In one embodiment, a request to connect to the broker is received. This results in a connection object being created for the connect request. Information contained within the connection object is then used to determine the communication network via which any future requests from the same requester arrive.  
         [0020]     In one embodiment, if it is determined that the identified function set is not associated with the communication path used, then the request is discarded. The requester may be informed that the request has been disallowed.  
         [0021]     In one embodiment access is provided to database functions on the basis of the communication path via which a request for a database function arrives.  
         [0022]     According to another aspect, there is provided an apparatus for controlling access to a publish/subscribe message broker, the apparatus comprising: 
    means for dividing pub/sub functions provided by the message broker into function sets:     means for associating each function set with a communication path;     means for receiving a request at the message broker, the request arriving via one of a plurality of communications paths at the message broker and requesting access to a publish or subscribe function provided by the message broker;     means for determining which communication path is used;     means for identifying which function set the requested function is a part of;     means for determining whether the identified function set is associated with the communication path used;     and means, responsive to determining that the identified function set is associated with the communication path used, for providing access to the requested publish or subscribe function.    
 
         [0030]     The invention may be implemented in computer software. 
     
    
     DETAILED DESCRIPTION OF THE DRAWINGS  
       [0031]     A preferred embodiment of the present invention will now be described, by way of example only, and with reference to the following drawings:  
         [0032]      FIG. 1  shows a server connected to both an external and an internal network in accordance with the prior art;  
         [0033]      FIG. 2  depicts the server of  FIG. 1  located in a demilitarised zone (DMZ) network in accordance with the prior art;  
         [0034]      FIG. 3  illustrates the componentry of the present invention, in accordance with a preferred embodiment;  
         [0035]      FIG. 4   a  depicts, in accordance with a preferred embodiment of the present invention, the format of a message received at the server of  FIG. 1 ;  
         [0036]      FIG. 4   b  illustrates, in accordance with a preferred embodiment of the present invention, the format of a connection object created when a device connects to the server of  FIG. 1 ;  
         [0037]      FIG. 5   a  and  5   b  depict tabular information mapping server application functionality to user profiles in accordance with a preferred embodiment of the present invention;  
         [0038]      FIG. 5   c  illustrates a Venn diagram of the function sets provided in an exemplary embodiment; and  
         [0039]      FIG. 6   a  &amp;  6   b  illustrate the processing of the present invention in accordance with a preferred embodiment. 
     
    
     DETAILED DESCRIPTION  
       [0040]     Disclosed is a mechanism for controlling device access to functionality provided by a server, based on the network location of the device.  
         [0041]     The invention will be described, in accordance with a preferred embodiment, with reference to FIGS.  3  to  6 . The figures should be read in conjunction with one another.  
         [0042]     A request to perform some function provided by message broker  70  is received at step  400  ( FIG. 6   a ). The request is received at a broker connection port (e.g. port 1883 which has IP address 9.2.3.4 on network 9.2.x.x. The format of such a request is depicted in  FIG. 4   a . The request has two parts to it: a network information part  30 O; and a request information part  310 . Part  310  comprises information such as: 
    i) A userid;     ii) A function code that maps at the message broker to a broker provided function. Such a function is provided by component  230 ;     iii) A message length;     iv) Flags that may concern themselves with information such as Quality of Service (QoS) and message priority;     v) A message topic; and     vi) The main payload of the message.     The network information part  300  contains lower level information such as:     i) Source IP Address;     ii) Source Port;     iii) Destination Address;     iv) Destination Port; and     v) The identifier of the protocol being employed (e.g. TCP or UDP).    
 
         [0055]     These elements are part of the protocol header. Note that the requesting device is not necessarily on the same network as that to which the broker is attached and thus the IP source address may be completely different.  
         [0056]     If it is determined at step  410  that the newly received request is a connection request, it is the network information, along with the userid) that is used to create (at step  420 ) a connection object  320  (essentially state information) as shown in  FIG. 4   b . This connection object is stored at the receiving connection port. Each connection object also has a socket ID associated therewith.  
         [0057]     Either way, processing reaches step  430  where the connection port sends the request on its way to broker interface  220 . The broker interface is used to make calls to the functions  230  provided by the broker  70 . At step  440 , the request is intercepted, on its way to the broker interface, by interceptor  200 , specifically intercepting component  270 . Connection Information Component  240  determines at step  450  whether connection information for the intercepted request is available locally. If this is the first request seen from this particular client for the current connection session, then there will be no connection information available locally. In which case, the connection object associated with the request is requested from the connection port from which the request originated (step  460 ). The received connection object is then stored locally to the interceptor component for use with future requests (not shown). In another embodiment, connection information may simply be requested from the connection port for each request.  
         [0058]     At step  470 , user profile and function table information  330 ,  340  (as shown in  FIGS. 5   a  and  5   b ) is consulted (using consulting component  250 ) to determine whether the requested operation is permitted for the particular requesting device.  
         [0059]     Function table  330  lists the broker functions provided by component  230  ( FIG. 3   a ). Thus devices may, by way of example only, request the following operations: 
    i) Connect     ii) Disconnect     iii) Publish     iv) Publish_ack (subscriber can acknowledge receipt of a message)     v) Publish_release (publisher can release a once-and-once-only message)     vi) Publish_complete (subscriber can confirm completion of a once-and-once-only message)     vii) Subscribe    
 
         [0067]     Request message function codes are each mapped by the table to one of the above operations.  
         [0068]     While a device may request any of the functions, the network location of the device has, according to the preferred embodiment, an impact on whether the broker actually fulfils the requested operation. The third column in the function table  330  indicates the user profiles of permitted users for each operation. Thus, only a user of type  2  may publish a message, whereas only a user of type  1  may request the subscribe operation. Thus in effect, the application functionality of the message broker is divided into function sets with only certain types of user having access to each function set. This is illustrated by the Venn diagram in  FIG. 5   c . From this figure, it can be seen that the following functions are part of function set  1 ; 
    i) Publish_ack;     ii) Publish_complete;     iii) Subscribe;     iv) Connect; and     v) Disconnect     In function set  2  are:     i) Publish;     ii) Publish_release;     iii) Connect; and     iv) Disconnect.    
 
         [0079]     Despite the fact that only two function sets are shown and that there are a plurality of functions in each set, this does not have to be the case, There may be more than two function sets. Also, a function set may only have one function.  
         [0080]     The user profile table  340  defines what is meant by a user of type  1  when compared with a user of type  2 . The table in the figure defines that the relevant information, when determining whether a requesting device is permitted to access a function provided by the broker, is the specified Net ID (network ID)/subnet mask pair, the destination port via which the broker is accessed and the name of the requesting user. It can be seen from the figure that some the entries in a user profile may be wildcarded. In other words, it does not matter who the user is in profile  1 .  
         [0081]     Referring back to the processing of  FIG. 6   b , the consulting component  250  extracts the function code from the request information part of the intercepted message. This is used to determine from the function table  330 , the operation being requested by the user and the user types permitted to perform such an operation. By way of example, function  7  is requested. This maps in the function table to the publish operation that is permitted by users of type  1  only. The profile table  340  is then accessed to determine the required characteristics of type  1  users. A logical AND operation is performed between the Source IP address of the request (e.g. 10.0.56.77) and the subnet mask (e.g. 255.255.0.0). An IP address typically consists of a net ID (i.e. network part) and a node ID (i.e a host/machine part). The AND operation is performed to extract the net ID part from the source IP address (in this example 10.0). This can then be compared with the Net ID specified in the profile. (The full address, 10.0.0.0, may be specified in the profile but the relevant (Net ID) part in this embodiment is the 10.0—note in an alternative embodiment, only the network part is specified in the profile.) If the Net ID extracted from the source IP address is identical to the Net ID part specified in the profile, then this part of the profile is matched. In other words, the request comes from an appropriate subnet. In this example there is a match and consequently the request comes from an appropriate IP address range. It may however also be necessary to access the broker via a particular port, in which case this is also checked Note, the connection object requested (if not already available more locally) at step  460  can be used to determine the requesting source IP address, destination port etc. Thus a value is retrieved from the relevant connection object for each column in the table. Some automated rules may be applied. For example, the user name field has a wildcard in it. Consequently, there is no need to retrieve this value from the connection object. Equally, if the source IP address is retrieved and it is determined that the device does not fulfil this characteristic, there is no need to retrieve values for the other columns.  
         [0082]     Note that the user profile table columns are exemplary only. The key point is that a user&#39;s access is to application functionality is being controlled based on one or more characteristics relevant to the network location of the user.  
         [0083]     It will be appreciated from  FIGS. 4   a  and  4   b  that the request message and therefore the connection object created there from does not specify whether the source IP address falls within the range defined by the Net ID and subnet mask combination specified in the user profile. A comparison of the source IP address of the request with the specified Net ID/subnet combination however, will determine if it does lie within the range (see above). Subnets and subnet masks are topics already well known in the art and so will not be discussed in any detail herein.  
         [0084]     Information obtained from consultation step  470  is passed on to Gate Keeper  260 ; in other words, whether or not the request fulfils the required criteria. Gate Keeper  260  then uses such information to determine whether the request is allowable (step  480 ). If the request did not fulfil the required criteria (for example, it originated from a different subnet to that specified in relevant profile information), the request is discarded at step  490 . This may mean that the request is simply not carried out, but more generally may also involve informing the requesting device that the request is not being allowed.  
         [0085]     If on the other hand, the request is deemed to be allowable at step  480 , then Gate Keeper  260  passes the request onto broker interface  220  through which the appropriate operation (publish in this example) may be requested. Hence forth the functionality of the message broker operates in a manner that is well known in the art.  
         [0086]     To summarise, the application level protocol of the server is segmented by function into sets. Each of these sets is then associated with a profile that describes the requirements for accessing this set of functions. Referring back to the example of  FIG. 1 , such an invention may be used in a SCADA type environment to great effect. To recap, in such an environment sensors may access a message broker via an external network, While monitors may access the message broker via an internal network. With such a setup, it may not be desirable to allow monitors to publish, and sensors to subscribe to receive information. Rather than having to list the userid of every device and its access permissions, it is possible to perform access control on the basis of network location of the requesting device.  
         [0087]     As indicated above, the use of source IP address, subnet, destination port and userid information in performing the access control is exemplary only. For example, destination port may be used on its own. In which case the functionality of the present invention may be built into firewall technology (e.g. the packet filters  110 ,  120  of  FIG. 2 ). It is already known to restrict port access using current firewalls. Such firewall technology however can be extended to specify the type of operations that may be requested via a particular port.  
         [0088]     Finally while the embodiment described makes reference to a server connected to two or more networks, the invention is not limited to such. For example, devices may access the server via a single network. The server may be listening on multiple ports on a single network. A firewall can be used to control which source IP address ranges are allowed to access which port on the server, in which case the consultation component only needs to consider the port number in its decision making. Alternatively the source IP address range and port can be specified in the profile and the consultation component can do the validation.