REFERENCE TO PRIOR APPLICATIONSThis application is a continuation application of co-pending U.S. patent application Ser. No. 10/808,847, filed on Mar. 25, 2004, which is hereby incorporated by reference.
BACKGROUND OF THE INVENTION1. Field of the Invention
In general, the present invention relates to a method, system and program product for associating event categorization and routing with security authorization roles. Specifically, the present invention alleviates the need for separate processing to route events and to determine authorization rights for interacting with the event.
2. Related Art
As computer infrastructures have become more advanced, increased functionality has been provided. One function common within many infrastructures is the capability to generate alerts or events as changes to the resources within the infrastructures occur. For example, if a client or application within the infrastructure fails, an information technology (IT) event detailing the failure can be generated and transmitted to the server. Once received, the server handles the categorization and routing of the event to appropriate destinations (e.g., users or groups of users).
Current event management solutions separate the concepts of categorizing and routing events from the security of the events. Specifically, it is normally left up to secondary processing to determine whether a client application has the correct credentials to interact (e.g., read and/or write) with an event (or group of events). That is, the security authorization process is not performed at the time the event is received/retrieved or routed to the client. Accordingly, after an event is received and categorized, it is routed to the client where security permissions are determined and enforced. This not only increases the amount of processing that must be performed at the client side, but it could also lead to unnecessary routing of events to clients that are not authorized to interact therewith.
To this extent, no existing solution allows security authorization to be performed on the server side as categorization is occurring. That is, no existing solution allows security permission determination to occur prior to the routing of an event to its destination. In view of the foregoing, there exists a need for a method, system and program product for associating event categorization and routing with security authorization roles. Specifically, a need exists for a system whereby association of security authorization roles occurs on the server side. A further need exists for the association of security authorization roles to occur prior to the routing of events to the appropriate destinations.
SUMMARY OF THE INVENTIONIn general, the present invention provides a method, system and program product for associating event categorization and routing with security authorization roles. Specifically, under the present invention, when an event is received on a server, it is stored and then categorized. In being categorized, an event group pertaining to the event is identified. Based on the group of events, a set (e.g., one or more) of destinations to which the event should be routed can be determined. The group of events is then associated with an access control list (ACL) that contains entries identifying users (or groups of users) and their permissions to interact with events in that group. Once the association is made, the event (and optionally the ACL itself) is routed/published to the appropriate destinations. Based on the permissions contained in the ACL, the destinations will interact with the event accordingly. In addition, because the association is performed on the server side, the present invention also accommodates synchronous operations whereby a user or group of users can query the server about an event and interact therewith according to their listed permissions.
A first aspect of the present invention provides a method for associating event categorization and routing with security authorization roles, comprising: receiving an event on a server; identifying an event group pertaining to the event; determining a set of destinations associated with the event group for receiving the event; and associating the event group with an access control list (ACL) corresponding to the set of destinations, wherein the ACL includes a set of entries that each identify at least one user and a permission of the at least one user for interacting with the event.
A second aspect of the present invention provides a system for associating event categorization and routing with security authorization roles, comprising: an event reception system for receiving an event on a server; a categorization system for categorizing the event by identifying an event group pertaining to the event; a destination system for determining a set of destinations associated with the event group for receiving the event; and a list association system for associating the event group with an access control list (ACL) corresponding to the set of destinations, wherein the ACL includes a set of entries that each identify at least one user and a permission of the at least one user for interacting with the event.
A third aspect of the present invention provides a program product stored on a recordable medium for associating event categorization and routing with security authorization roles, which when executed, comprises: program code for receiving an event on a server; program code for categorizing the event by identifying an event group pertaining to the event; program code for determining a set of destinations associated with the event group for receiving the event; and program code for associating the event group with an access control list (ACL) corresponding to the set of destinations, wherein the ACL includes a set of entries that each identify at least one user and a permission of the at least one user for interacting with the event.
Therefore, the present invention provides a method, system and program product for associating event categorization and routing with security authorization roles.
BRIEF DESCRIPTION OF THE DRAWINGSThese and other features of this invention will be more readily understood from the following detailed description of the various aspects of the invention taken in conjunction with the accompanying drawings in which:
FIG. 1 depicts a system for associating event categorization and routing with security authorization roles according to the present invention.
FIG. 2 depicts the association of an event group with an ACL according to the present invention.
FIG. 3 depicts a method flow diagram according to the present invention.
The drawings are not necessarily to scale. The drawings are merely schematic representations, not intended to portray specific parameters of the invention. The drawings are intended to depict only typical embodiments of the invention, and therefore should not be considered as limiting the scope of the invention. In the drawings, like numbering represents like elements.
DETAILED DESCRIPTION OF THE DRAWINGSAs indicated above, the present invention provides a method, system and program product for associating event categorization and routing with security authorization roles. Specifically, under the present invention, when an event is received on a server, it is stored and then categorized. In being categorized, an event group pertaining to the event is identified. Based on the group of events, a set (e.g., one or more) of destinations to which the event should be routed can be determined. The group of events is then associated with an access control list (ACL) that contains entries identifying users (or groups of users) and their permissions to interact with events in that group. Once the association is made, the event (and optionally the ACL) is routed to the appropriate destinations. Based on the permissions contained in the ACL, the destinations will interact with the event accordingly. In addition, because the association is performed on the server side, the present invention also accommodates synchronous operations whereby a user or group of users can query the server about an event and interact therewith according to their listed permissions.
Referring now toFIG. 1, asystem10 for associating event categorization and routing with security authorization roles according to the present invention is shown. As depicted,system10 includesserver12 in communication withclients50A-C (operated byusers52A-C. It should be understood thatsystem10 is intended to represent only an illustrative computer infrastructure. To this extent, any quantity of clients and servers could be shown. In addition,system10 should be understood to include other resources (e.g., hardware and software) not shown.
In any event, communication betweenserver12 andclients50A-C could occur over any type of network such as the Internet, a local area network (LAN), a wide area network (WAN), a virtual private network (VPN), etc. Such communication could occur via a direct hardwired connection (e.g., serial port), or via an addressable connection that may utilize any combination of wireline and/or wireless transmission methods. Moreover, conventional network connectivity, such as Token Ring, Ethernet, WiFi or other conventional communications standards could be used. Still yet, connectivity could be provided by conventional TCP/IP sockets-based protocol. In this instance,clients50A-C could utilize an Internet Service Provider to establish connectivity toserver12. These concepts also apply to any direct (e.g., peer-to-peer) communication that could optionally be provided amongclients50A-C.
Server12 generally comprises central processing unit (CPU)14,memory16,bus18, input/output (I/O) interfaces20, external devices/resources22 andstorage unit24.CPU14 may comprise a single processing unit, or be distributed across one or more processing units in one or more locations, e.g., on a client and server.Memory16 may comprise any known type of data storage and/or transmission media, including magnetic media, optical media, random access memory (RAM), read-only memory (ROM), a data cache, etc. Moreover, similar toCPU14,memory16 may reside at a single physical location, comprising one or more types of data storage, or be distributed across a plurality of physical systems in various forms.
I/O interfaces20 may comprise any system for exchanging information to/from an external source. External devices/resources22 may comprise any known type of external device, including speakers, a CRT, LCD screen, handheld device, keyboard, mouse, voice recognition system, speech output system, printer, monitor/display, facsimile, pager, etc.Bus18 provides a communication link between each of the components inserver12 and likewise may comprise any known type of transmission link, including electrical, optical, wireless, etc.
Storage unit24 can be any system (e.g., database) capable of providing storage for information under the present invention. Such information could include, for example,events60, etc. Assuch storage unit24 could include one or more storage devices, such as a magnetic disk drive or an optical disk drive. In another embodiment,storage unit24 includes data distributed across, for example, a local area network (LAN), wide area network (WAN) or a storage area network (SAN) (not shown). Although not shown, additional components, such as cache memory, communication systems, system software, etc., maybe incorporated intoserver12.
Shown inmemory16 ofserver12 isevent handling system30. Under the present invention,event handling system30 allows the categorization and routing of events to be associated with security authorization roles onserver12. It should be understood that, as used herein, the term “event” is intended to refer to any type of behavior or message related thereto occurring withinsystem10 that requires notification ofclients50A-C and/or some type of corrective action. For example, if an application program loaded onserver12 that is used by one ormore clients50A-C fails, an event would be generated. Similarly, if a client or an application program loaded thereon fails, and event would be generated (and communicated to server12). Accordingly, in a typical embodiment, the term “event” refers to an information technology (IT) event occurring withinsystem10 and its corresponding notification/message detailing the failure.
As indicated above, previous technologies separated the categorization and routing of events from the security authorization process. To this extent, although event routing was handled on a server, the security authorization processing for the events occurred on individual clients. This required the individual clients to access various permissions for interacting with the events. In sharp contrast, the present invention merges the two processes so that an event is routed toclients50A-C along with any applicable permissions.
The functions of the present invention will be described in conjunction withFIGS. 1 and 2 collectively. As first shown inFIG. 1,event handling system30 generally includesevent reception system32,storage system34,categorization system36,destination system38,list association system40,routing system42,query reception system44 andevent retrieval system46. Assume in an illustrative example thatclient50C (or a system loaded thereon has failed). In such an instance, an event would be generated and communicated toserver12. The event would be received byevent reception system32, and then optionally stored instorage unit24 bystorage system34. As will be further described below, the storage of events allows for the synchronous access thereof in the future. Regardless, after the event has been received (and stored),categorization system36 will categorize the event by determining an event group pertaining thereto.
Referring toFIG. 2, the relationship betweenevent70 andevent group72 is shown in greater detail. In general, eachevent group72 has a group name field, a group description field and a selector expression field. Assume in this illustrative example that eachclient50A-C has itsown event group72. In a typical embodiment, the group name field of theevent group72 will set forth the host name of thecorresponding client50A-C. Accordingly, in this example, the name ofevent group72 could be the host name ofclient50C. As such, all events occurring onclient50C could fall underevent group72. The description field ofevent group72 allows a specific explanation of the event group to be set forth. Still yet, the selector expression field ofevent group72 allows certain criteria to be set forth for determining whetherevent70 is part of thatevent group72. For example, the selector expression could indicate that any events originating from aclient50C having a host name matching that set forth in the name field belongs to thatevent group72. In such a case, any event that occurred onclient50C could be categorized underevent group72.
Referring back toFIG. 1, once the event group for the event has been identified, a set (e.g., one or more) of destinations for receiving the event will be determined bydestination system38. As is well known, the failure of one system could have ramifications on other systems. Accordingly, such other systems should receive the event. Determination of the set of destinations is performed based on the event group. Specifically, each event group has a particular set of destinations to which event should be routed. A destination could include a single user/client or a group of users/clients. In this example, assume that the set of destinations includesother users52A-B. As such, the event will be routed toclients50A-B. Before the event is routed, however,list association system40 will associate/link an access control list (ACL) corresponding to the identified set of destinations with the identified event group72 (FIG. 2). Specifically, thelist association system40 will locate the one or more ACL(s) that correspond to the set of destinations and associate the same therewith.
Referring toFIG. 2, the association ofACL78 toevent group72 will be described in greater detail. As shown,ACL78 includes a list name field and a set ofentries80. In a typical embodiment,ACL78 will be associated withevent group72 based on its name field. Accordingly,ACL78 could be assigned the same name as event group72 (e.g., the host name ofclient50C). As further shown inFIG. 2, eachentry80 has a type field, an identifier field and a permission field. The type field indicates whetherentry80 pertains to a “user” or a “group of users.” For example,entry80 could be made applicable to bothusers52A-B, or only to a single user such asuser52A. The identifier field will specifically identify the user or group of users described in the type field. For example, the identifier could indicate users “52A and52B” (or a single user depending on what is specified in the type field). The permission field sets forth a permission for the applicable user(s) to interact with events falling within theevent group72. Such permission could be “read,” “write,” or “read/write.” The “read” permission would give the applicable user(s) the authority to subscribe to thequeue74 ortopic76 associated with thatevent group72. It also grants the applicable user(s) the authority to query events associated with thatevent group72. The “write” permission has no bearing onqueue74 ortopic76 forevent group72, but it grants the applicable user(s) the authority to update or delete events associated withevent group72. The “read/write” permission would grant the applicable user(s) both “read” and “write” permissions.
Referring back toFIG. 1, once the ACL78 (FIG. 2) has been associated with the applicable event group72 (FIG. 2),routing system42 will route the event70 (FIG. 2), and optionally the ACL78 (FIG. 2) associated withevent group72, to the set of destinations previously determined bydestination system38. Ifclients50A-B receive bothevent70 andACL78, this alleviates the need for eitherclient50A-B to query or otherwise independently accessACL78. Based on the permissions inACL78,users52A-B will interact withevent70 accordingly. Conversely, ifACL78 is not routed withevent70,users52A-B could access the permissions contained therein on a subscription basis (e.g., by communicating with server12). For example, upon receivingevent70,users50A-B could communicate withserver12. Such a communication could specifically identify event70 (e.g., according to a unique identifier assigned thereto byevent handling system30 upon initial receipt by server12). Sinceevent70 has been associated withACL78 onserver12, the permissions forusers50A-B are easily and efficiently determined. Similarly,users52A-C could subscribe to certain “topics” for which they will receive related events.
It should be appreciated that in addition to storingevent70,storage system34 could also store the determined set of destinations, the identifiedevent group72 pertaining toevent70 and/or the ACL78 (or its association with event group72) instorage unit24. This allows the present invention to easily accommodate synchronous querying of events (as well as the above example involving the asynchronous notification of events). Specifically,clients50A-C could also be provided with the capability to queryserver12 to further interact with events. For example, assume thatclient50A wishes tolater query server12 to interact with event70 (FIG. 2). In this case, the query would be received byquery reception system44.Event retrieval system46 would then retrieveevent70 and theACL78 fromstorage unit24. Based on the permissions inACL78,user50A could attempt to further interact withevent70.
It should also be understood that the present invention can be realized in hardware, software, or a combination of hardware and software. Any kind of computer system(s)—or other apparatus adapted for carrying out the methods described herein—is suited. A typical combination of hardware and software could be a general purpose computer system with a computer program that, when loaded and executed, carries out the respective methods described herein. Alternatively, a specific use computer, containing specialized hardware for carrying out one or more of the functional tasks of the invention, could be utilized. The present invention can also be embedded in a computer program product, which comprises all the respective features enabling the implementation of the methods described herein, and which—when loaded in a computer system—is able to carry out these methods. Computer program, software program, program, or software, in the present context mean any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: (a) conversion to another language, code or notation; and/or (b) reproduction in a different material form.
Referring now toFIG. 3, a method flow diagram100 according to the present invention is shown. As depicted, first step S1 is to receive an event on a server. Second step S2 is to identify an event group pertaining to the event. Third step S3 is to determine a set of destinations associated with the event group for receiving the event. Fourth step S4 is to associate the event group with an access control list (ACL) corresponding to the set of destinations. Fifth step S5 is to route the event (and optionally the ACL associated with the event group) to the set of destinations after the associating step.
The foregoing description of the preferred embodiments of this invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed, and obviously, many modifications and variations are possible. Such modifications and variations that may be apparent to a person skilled in the art are intended to be included within the scope of this invention as defined by the accompanying claims. For example, the illustrative representation ofevent handling system30 shown inFIG. 1 is not intended to be limiting. That is, the functions of the present invention described herein could be represented by a different configuration of systems.