Patent Application
20070294209
Examples of embodiments of the invention will now be described in greater detail with reference to the accompanying drawings.
The enterprise system 22 includes one or more application servers 32, an application platform 34 operatively coupled to the application server(s), a gateway 36 operatively coupled to the application platform and to the communication network 12, one or more user systems 38 operatively coupled to the application platform and to the gateway, an identity system 40 operatively coupled to the application platform, to the user system(s), and to the gateway, and an application manager 42 operatively coupled to the application platform and to the gateway. Other components or systems, such as firewalls located on either side of the gateway 36 to provide a DeMilitarized Zone (DMZ), may also be deployed. The enterprise system 24 may have a similar structure.
In the application system 26, an application platform 44 is operatively coupled to the communication network 12 and to one or more application servers 46. The remote user system installation 28 includes an application proxy agent 48 operatively coupled to one or more user systems 49.
Although many enterprise systems, application systems, remote user system installations, and possibly other types of systems may be provided in a communication system, only illustrative examples of certain types of systems have been shown in
It should therefore be appreciated that the communication system 10 of
Those skilled in the art to which the present invention pertains will be familiar with many different types of communication networks, including overlay networks such as application layer networks and more traditional infrastructures. The present invention is not limited to any particular type of communication network. In one embodiment, the communication network 12 is the Internet or some other public network.
Many examples of access technologies through which the systems 22, 24, 26, 28 access the communication network 12 will also be familiar to those skilled in the art, and accordingly have not been separately shown in
Considering first the enterprise system 22, an application server 32 supports applications that may provide functions, illustratively services, for use by at least the local user system(s) 38. Where multiple application servers 32 are deployed, each server supports a respective set of functions or services, which may or may not overlap the services supported by other servers.
In some embodiments, these functions are also made available for use by external user systems, such as user systems in the enterprise system 24, where owners or operators of the enterprise systems 22, 24 have an agreement for inter-system access by their users, and/or the user system(s) 49 at the remote user system installation 28.
References herein to use of applications are intended to convey the notion of any such function. Generally, an application server 32 executes a software application to provide these functions. A service, such as a web service, is an example of an application function that is exposed to user systems, in the context of the present disclosure. Any references to applications, functions, and services should be interpreted accordingly.
An application server 32 may include such components as one or more processors, one or more memory devices, and an interface for exchanging application transaction information, such as service request messages and corresponding responses, with user systems. Memory devices in an application server 32 may be used to store operating system software, application software, etc., for use by the application server processor(s). Enterprise systems such as 22 are often implemented as a network, in which case a network interface enables the application server(s) 32 to communicate with the user system(s) 38 and possibly other components of the enterprise system. In another possible implementation, an application server 32 includes separate interfaces for communicating with different enterprise system components.
A user system 38 may similarly include one or more processors, one or more memory devices, and some sort of interface(s) for communicating with the application server(s) 32, and possibly other components of the enterprise system 22. Operating system software, client software for interacting with the application server(s) 32, and/or other types of information may be stored in user system memory devices.
Those skilled in the art will be familiar with many different types of systems that provide and/or use network applications. Embodiments of the present invention relate primarily to monitoring the use of and restricting access to network applications, as opposed to how these applications are actually supported, and accordingly the application server(s) 32, the user system(s) 38, and their operation are described only briefly herein to the extent necessary to illustrate aspects of the invention.
The identity system 40 represents another component that is commonly provided in enterprise systems such as corporate networks and will be familiar to those skilled in the art. Access to services or other functions supported by the application server(s) 32 in many cases must be restricted to a particular set of users. The identity system 40, which may authenticate users and/or user systems through interaction with a Lightweight Directory Access Protocol (LDAP) directory or other type of user database, for example, supplies a digital identity that may be used for authorizing or denying access to network services.
In terms of structure, the application platform 34 includes application server interfaces that are compatible with the user system interfaces, illustratively Application Programming Interfaces (APIs), of the application server(s) 32, one or more interfaces compatible with the application server interface(s) of the user system(s) 38, and components for processing messages or other information received and/or transmitted through these interfaces. As described in further detail below, external user systems may be able to access the application server(s) 32 through the gateway 36, in which case the user system interface(s) of the application platform 34 may also enable the application platform to communicate with the gateway 36. However, in some embodiments, a separate gateway interface may be provided for this purpose.
The gateway 36 would also include one or more internal interfaces compatible with interfaces of other components of the enterprise system 22, one or more external interfaces for enabling communication signals to be transmitted and/or received through the communication network 12, and intermediate components for processing signals received and/or transmitted through the interfaces.
The application manager 42 represents a control or monitoring element that might not itself perform real-time processing of information as it is transferred between the application server(s) 32 and the local user system(s) 38 or external user systems. The application manager 42 may communicate with the application platform 34 and the gateway 36 through compatible interfaces, to perform such functions as configuring the application platform and/or the gateway, illustratively by downloading application session policies to the platform and/or the gateway for enforcement, accessing application session information that is collected in accordance with embodiments of the invention, etc.
The internal components of the application platform 34, the gateway 36, and the application manager 42 may be implemented in hardware, software, firmware, or some combination thereof. A monitoring system, as described below with reference to
In a traditional deployment of a so-called Service Oriented Architecture (SOA) for an enterprise network, SOA components are individually deployed and integrated on each application server. Publishing a service for use on a network, within the enterprise system 22 for instance, would require a service registry for discovery and management of service offerings. Although web service standards address the need to restrict service access to authorized users, a web services policy server would be needed to store and provide this information. Enforcing these policies can also be a challenge, in that software vendors may require substantial changes to applications and servers in order to adapt to enterprise systems.
All of this can represent a significant project for an enterprise, and may well have a relatively long implementation cycle. In addition, the skill set required to implement such a project is highly specialized, which might make an SOA implementation not economically feasible.
When extending web services or other types of applications to partners, between the enterprise systems 22, 24, for example, even more challenges exist for an SOA infrastructure deployed on application servers. For instance, applications deployed at partner sites might use diverse security mechanisms that cannot share user identity information freely, requiring translation of security tokens for users. Placing the burden of security token translation, or other security functions, on each application server tends to be costly and inefficient.
Data privacy requirements are also very difficult or even impossible to enforce at each application server since application servers themselves might not be aware of whether a user system, or more generally a consumer of its service, is external to its enterprise system.
XML-specific denial of service (XDoS) attacks, and possibly other threats, may be particularly problematic in application server-based SOA implementations. Web services, for example, are open to XDoS attacks, which cannot be effectively dealt with on application servers.
The migration of server-based SOA to a web services model to achieve application interoperability via loosely coupling applications necessitates the need for additional messaging, illustratively in the form of SOAP headers and XML messages, as well as additional processing requirements for managing these messages. This additional overhead consumes network bandwidth and can result in significant new requirements for application server hardware.
An alternate model for deployment of an SOA infrastructure is to integrate the SOA components into enterprise network elements, as shown in
Deploying the SOA infrastructure separately from the application server(s) 32 may provide several benefits: the SOA infrastructure is then application agnostic, applications require minimal modification, the SOA infrastructure is an end-to-end integrated solution, application server processing overhead is minimized, and network bandwidth can be optimized.
With an enterprise system-/network-based SOA deployment, any message translations required for applications to interoperate can be performed according to policies set within the enterprise system, not by the applications themselves. This allows translations to be defined independently of applications, removing the reliance on application vendor implementations.
The business logic required to adapt message format and content is thus provided by the enterprise, not by the application, minimizing application modification. Web services messages, for example, can be adapted within an enterprise network to achieve application interoperability. As new interoperability requirements arise, perhaps due to merger, acquisition, or the need to integrate with a new partner, no application modification is required. New policies for message translation can instead be defined to provide for the new interoperability.
An SOA infrastructure deployed as an integrated enterprise network solution can provide a single monitoring, control, and consolidated reporting point, illustratively the application manager 42. This can be important to enable proper corporate governance, continuous corporate improvement, and the ability to demonstrate compliance with regulations concerning data privacy and network security, for instance.
Application server processing requirements for application interoperability can be significantly reduced for two reasons: application server offload and a reduced number of required translations. Translations can be done once, at the application platform 34, for example, and then forwarded onto multiple destinations rather than each application performing its own translation.
The network bandwidth consumed by additional message traffic can be reduced by routing packets to the application server(s) 32 based upon inspecting the message SOAP headers, XML tags, or other message content. Routing can be sensitive to application contexts rather than based on static IP addresses, for example.
If application server functions are to be extended to partner enterprise systems, an SOA infrastructure deployed as enterprise network infrastructure may provide many further advantages. Translation of security tokens can be done once at the demarcation point between the partners' networks, illustratively at the gateway 36 for external accesses to the application server(s) 32, providing a single enforcement point for security policy. Data privacy can also be enforced at the point where data leaves a security domain, again at the gateway 36, for example. This drives efficiencies and reduces costs. In addition, denial of service attacks targeted at corporate web services can be defended at the gateway 36, the enterprise network edge, which is perhaps the most secure place to deal with this issue.
The application platform 34 provides an SOA infrastructure for integrating applications that traditionally have run as stand-alone applications, and may enable such capabilities as controlling and monitoring all activity initiated by a validated user to thereby allow generation of a consolidated audit trail, translation for message and document formats, managing the life cycle for applications including the staged rollout of web services and rollback to previous versions in the event of unexpected behavior for instance, and monitoring application/service performance to ensure that applications/services meet internal corporate requirements.
This listing of example functions of the application platform 34, like other functional examples noted herein, is by no means restrictive or exhaustive. Many functions may be implemented independently, every embodiment need not necessarily provide all functions, and other functions may also be or become apparent to those skilled in the art.
Benefits of the application platform 34 may include reduced application integration cost through minimum change to existing applications, as noted above, ensuring that access to corporate applications complies with Government regulations, a central monitoring and control point for employee access to web services, and continuous corporate improvement through consolidated reporting.
The gateway 36 effectively extends an intranet SOA provided by the enterprise system 22, through the communication network 12, into an extranet, allowing seamless integration with customers and partners without compromising security or privacy. Functions of the gateway 36 may include, possibly among others, any or all of extending applications to a partner extranet and branch locations, providing seamless mobility for partner access to applications, ensuring partner access to corporate applications complies with Government regulations, and maintaining privacy of corporate identities without compromising traceability.
In providing mobile access to the application server(s) 32 from any partner sites associated with the enterprise system 22, the gateway 36 may allow the secure identification of partner institutions and acceptance of identities between different security domains. Application message and data translations, for user systems associated with external partner sites, may also be provided by the gateway 36, while ensuring that all data remains private as per corporate policy. A consolidated audit trail of all application access may be collected and provided to an external partner enterprise system by the gateway 36, to demonstrate conformance with regulations for instance.
The application manager 42 provides a central point for monitoring and control of the application platform 34, the gateway 36, and any other platforms and gateways (not shown) in the enterprise system 22. Globally consistent policies for all applications, so as to ensure improved corporate governance and/or compliance with Government regulations, can also be established in some embodiments through the application manager 42 and distributed to the application platform 34 and to the gateway 36 for enforcement. The central application manager 42 may also provide for globally consistent application change management.
As noted above, the enterprise system 24 may be substantially similar to the enterprise system 22.
The enterprise system 22 includes both application server(s) 32 that support applications and one or more user system(s) 38 that may use those applications. However, it should be appreciated that application servers and user systems need not necessarily be co-located. The application system 26, for example, includes one or more application servers 46, but no local user systems. Although only an application platform 44 is shown in the application system 26, some implementations of an application system might also include a gateway. Whereas the application system 26 as shown might be suitable, for example, for a remote data center that is associated with a primary data center as the enterprise system 22, a stand-alone or “unaffiliated” application system that hosts applications for use by external user systems might also include a gateway for handling authentication of the external users for instance.
The application platform 44 in the application system 26 may interact with the application manager 42 of the enterprise system 22, or more generally the application manager of its affiliated enterprise system. In the case of a stand-alone application system, a local application manager may be provided. In some implementations, an external services controller interacts with SOA infrastructure components in multiple different domains. For example, an external services controller that is operatively coupled to the communication network 12 might configure the gateway 36 and a gateway in the enterprise system 24 to collect and exchange application performance statistics.
A user-only deployment is shown in
In operation, a user system 38 that wishes to make use of an application provided by an application server 32 is first authenticated by the identity system 40. Those skilled in the art will be familiar with many security schemes that may be used for this purpose, such as username/password authentication. Where remote access to an application server 32 is supported, user authentication may be handled by the gateway 36, possibly through interactions with an external identity system. The gateway 36 may also be involved in authentication when a user system that is associated with a partner enterprise system or site is locally connected to the enterprise system 22 and wishes to access an application server 32.
When a user has been authenticated, messages or other forms of information may be exchanged between a user system and the application server(s) 32. A user may be allowed to access multiple applications after a single successful authentication. In this case, tracking user activity at the application level can present a significant challenge.
In accordance with embodiments of the invention, new techniques for monitoring, controlling, and reporting on application/service access by individual users are provided.
User-specific application-level session records, described in further detail herein, represent a novel concept in accordance with which application access operations, illustratively web service transactions, initiated by a validated user are grouped together to provide a consolidated view of that user's activity on a corporate network. The term “session” is not intended to refer to a Transmission Control Protocol (TCP) or other networking protocol session, but rather to a contiguous period of time that a user spends accessing applications on a network, such as a corporate network.
Application-level session record functionality may be implemented, for example, at any of a series of subsystems in an SOA architecture, which includes the application platform 34, the gateway 36, and the application manager 42 in the system 10. The application platform 34 and the gateway 36 are network nodes or components that process application access operations, illustratively web service messages, in real time in order to facilitate application integration and to enable rapid and cost effective deployment of SOAs, and therefore may be a logical point for implementation of application session information collection. The application manager 42, which is a network and application management element that can be deployed by an enterprise in order to coordinate any number of application platforms and/or gateways in its network, might provide subsequent access to application sessions for reporting, historical analysis to confirm or demonstrate policy or regulatory conformance, etc.
Benefits of multiple-application session records may include the ability to manage user-specific sessions in real time via policy or administrative action in order to ensure proper corporate governance and the ability to enable demonstration of conformance to regulations via a consolidated audit trail of user activity. Dynamic creation and real time management of application session records can provide a powerful tool that enterprise network administrators do not currently have at their disposal, and represent strong differentiators over conventional systems.
As noted above with reference to
The application access detector 57 for instance, although shown as a separate component in
The types of connections through which the components of
Hardware, software, firmware, or combinations thereof may be used to implement components of the apparatus 50. Processing elements such as microprocessors, microcontrollers, Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), and other types of “intelligent” integrated circuits may be suitable for this purpose.
The apparatus 50 may interact with other components of a communication network through the interfaces 52, 54, 66. These interfaces may be of the same type or different types, or even be the same interface where the same communication medium is used for information transfers with all other components. However, in many implementations, it is likely that the user system interface 52 will differ from at least the application server interface(s) 66, and that application server interfaces will be different for different application servers. The control/management system interface 54 may be another different interface, although in some cases the apparatus 50 interacts with user systems and an application manager through the same enterprise network interface.
The user system interface 52 enables the apparatus 50 to exchange application access information such as requests and corresponding responses with user systems. Each application server interface 66 similarly allows the apparatus 50 to exchange application access information with a respective set of one or more application servers. This type of architecture for the apparatus 50 might be appropriate, for example, when the apparatus is implemented at an application platform for monitoring all application usage or at a gateway for monitoring usage of applications from partner user systems, since these components process all application access information for an enterprise system. However, it should be appreciated that other implementations are also possible. A monitoring apparatus might instead passively “listen” to application access information, in which case it need not be actively involved in transferring application access information between application servers and user systems.
Through the control/management interface 54, the apparatus 50 may exchange information with a control or management system such as the application manager 42 (
The structure and operation of the interfaces 52, 54, 66 will be dependent to at least some extent on the communication media and protocols used in application information access transfers. Those skilled in the art will be familiar with many types of interfaces through which application access information may be received and/or transmitted by the apparatus 50.
Each of the databases 58, 62, 64 may be provided in one or more memory devices. Solid state memory devices are common in electronic equipment, and each database may be implemented using one or more memory devices of this type. However, other types of memory devices, including memory devices for use with movable or even removable storage media, may also or instead be used to store the databases 58, 62, 64.
The user database 58 stores user information such as usernames and passwords, which can be used to authenticate a user attempting to access an application server. The session database 62 is used to store records of application access operations performed by a user. Policies such as the particular information to be recorded for an application session and/or user, restrictions on how long a session may be maintained before a user is required to re-authenticate, the number of access operations that may be performed by a user before the user is asked to re-authenticate, etc., are stored in the session policy database 64. Policies may include any or all of user-specific policies, application-specific policies, global enterprise-wide policies, and possibly other types of policies.
Application sessions for which records are stored in the session database 62 provide a historical account of application activity, such as to verify whether application accesses satisfy requirements or regulations, whereas enforcement of session polices stored in the session policy database 64 stops users from performing application accesses that would violate such requirements or regulations.
As noted above, components of the apparatus 50 may be implemented using hardware, software, and/or firmware. These components are therefore described herein primarily in terms of their function. Based on the functional descriptions, a person skilled in the art will be enabled to implement service monitoring techniques according to embodiments of the invention in any of various ways.
In operation, the authentication module 56, the application access detector 57, and the session management module 60 facilitate consolidated application activity monitoring using application sessions, as described in further detail below. Application sessions are dynamically created and maintained by the session management module 60, and are uniquely identifiable containers used for monitoring, controlling, and reporting on application access activity of users as detected by the application access detector 57.
Several functions may be involved in the implementation of application sessions, including session authentication, session monitoring, session policy and control, and session reporting. In the apparatus 50, these functions may be supported by the authentication module 56, the application access detector 57, and the session management module 60. Other embodiments of the invention may provide a different division of these and possibly other functions between further, fewer, or different components.
Session authentication refers to the ability to detect application access by users and create application sessions based on the identities of the users. This may involve, for each received application access message or other form of application access information based upon which the application access detector may detect access to an application by an authenticated user, establishing an identity for the originating or destination user by whom access to the application was initiated. The session maintenance module 60 can then use this identity to determine whether an active application session exists for the user. Although the authentication module 56 might authenticate a user, through interaction with an identity system of an enterprise for instance, before initially granting access to applications, and possibly re-authenticate the user at a later time, the authentication module need not necessarily be involved in identifying the user for each message. The application access detector 57 or the session management module 60 could determine the user for each message from message header information, for example.
The session management module 60 determines whether there is an existing active application session record for the user in the session database 62, as could be determined by searching the database based on user name or some other user identifier. If an active application session record exists, then the session management module 60 applies any associated policies, which are stored in the session policy database 64 and might be searchable depending on the specificity (global, application, user) of session policies, to the received message. Policies could be global or specific to users, user groups, applications, locations, etc. In some embodiments, policies are defined within a policy definition hierarchy, with the most specific applicable policy being applied. A policy generation system, for example, might allow an administrator to define application- and/or user-specific policies that include, or at least do not violate, global enterprise session policies. In this case, the session management module 60 might identify and apply the most specific policy for a user.
Provided a received message is in compliance with the appropriate policies, the session management module 60 updates the existing application session record with a new activity entry to reflect the received message. The session management module 60 could store the actual received message, a hash, digital signature, or other transform of the message, the time at which the message was received, and/or other information associated with the user, the application, and/or the message. The types and formats of the application access information stored in an application session record may also be specified in a policy.
Where it is determined that no active application session record for the user exists in the session database 62, the session management module 60 still determines the appropriate application session policy to be applied, based on the user identity for instance, and applies that policy to the message. A new application session record, indexed by user identifier or possibly a unique session identifier, is created. A creation timestamp could also be generated and stored in the session database 62. An activity entry is added to the new application session record to reflect the received message.
By default, a new application session record may be created for each user that can be uniquely identified. However, an administrator may prefer in some cases to aggregate all activity from all users in an identified user group into a single application session to best suit their needs. In this case, even though a more specific identification can be made, an application session record might be created based on authentication of a group identity or any user within the group.
In the event that a received message does not comply with session policy, the message may simply be dropped. However, it may also be desirable to track session policy violations. A record of non-compliant access attempts could be stored in an application session record or separately. Other actions, such as terminating further access by a user and/or raising an alert or alarm to a system administrator, could also or instead be performed.
Message-based operations as described above are illustrative of operations that may be involved in detecting access to applications in a network and maintaining consolidated records of access by a user to multiple applications. Other embodiments may use similar or different techniques to detect and/or record application access by a user.
Session monitoring refers to the ability to provide relevant details of active and historical application session records to a network or application administrator. In the apparatus 50, this reporting is enabled through the control/maintenance system interface 54. This interface allows an administrator to be authenticated by the authentication module 56 and subsequently access the session database 62. Active application session records are created and maintained in the session database 62, as noted above. When access to a network is terminated, either voluntarily by the user logging off or forcibly in the event of a re-authentication failure or timeout, the formerly active application session record for that user is no longer active, but may remain in the session database 62 as a historical application session record. Session monitoring on an application manager or other control/management system may involve the retrieval, presentation, and possibly remote storage of active application session records and historical application session records from network devices such as application platforms and gateways that it manages.
A manager or other monitoring device may access the session database 62 directly or through the session management module 60. The manager or the session management module 60 may be configured to automatically delete historical records from the session database 62 when the historical records have been accessed, in order to conserve memory space. Deletion of the historical records may instead require an explicit command or other action by the manager or the session management module 60. In some embodiments, at least the active application session records remain in the session database 62.
Active and historical application session records may be stored in different memory devices or areas. In this case, active records are moved to the historical record store upon termination of an application session.
Automatic application session record reporting is also contemplated. Active application session records could be reported to a control/management system by the session management module 60 upon session termination, at certain times of day, or periodically, for example. This may avoid the need for local storage of historical logs at a monitoring apparatus, or at least reduce historical record memory requirements, although complete historical records could still be stored as a backup measure.
One possible benefit of some embodiments of the invention is the ability for administrators to create policies for how various types of users can access applications on their network and how their application utilization is logged. Session policy and control describes the functionality for application session policy creation and enforcement, as well as administrative override capabilities. Session policy enforcement and administrative control could be performed by an application platform and/or a gateway, for example, while an application manager provides functions for the creation of application session policies, illustratively corporate-wide policies, and the downloading of these policies to other components for enforcement.
In the context of session reporting, application session records group together multiple application access transactions initiated by a validated user for different applications, and therefore provide a consolidated audit trail of all user activity. Based on active and/or historical application session records, reports that summarize application usage over a period of time can be generated. These reports can be used, for example, for general reporting and/or for demonstration of regulatory compliance.
Embodiments of the invention have been described above primarily with reference to the communication system 10 of
The method 70 illustrates operations involved in creating and maintaining application sessions, and subsequently accessing application session logs.
At 72, application access information, illustratively an access request message from a user system or a response message to a user system from an application, is received. This message is proxied at a network node where application session monitoring is implemented. The user from whom a received request message is received or to whom a received response message is destined is identified at 74, and may be authenticated at least initially, and possibly re-authenticated at a later time. This authentication may be performed by comparing user credentials against information in a user database.
The access by the user is recorded at 76. If no active session record exists for the user, an application session is created. Otherwise, a new session record would not be created at 76; the existing active session record is updated with an access entry reflecting the received message.
Once the existing session record has been identified or a new session record has been created at 76, the appropriate application session policy is identified and applied to the message at 75. If the message violates the application session policy, illustratively due to a maximum threshold for messages per session being exceeded, the message is discarded at 77. However, if the message does not violate the application session policy, the message is dispatched to the destination service or user system at 78.
The method 70 is illustrative of one embodiment of the invention. Other embodiments may involve performing fewer or additional operations, and/or performing operations in a different order than shown.
For example, administrator functions may entail reporting more than one set of session logs at 79. An administrator might view all active and/or historical application sessions, for instance. Active session termination by an administrator might also be supported using an application session policy and control subsystem, which could be part of the session management module 60 (
As noted above, embodiments of the invention may use techniques other than message processing to detect and track access by a user to multiple applications.
Further variations of the method 70 may be or become apparent to those skilled in the art.
In accordance with other embodiments of the invention, a data structure might include fewer, further, or different data fields than shown in
There are no available products that allow application and service accesses of a validated user to be monitored, controlled, and reported on in a consolidated manner. Embodiments of the present invention may provide this capability and a useful tool for network and application administrators that need to control, monitor, and report on user access to applications and services on their network.
Application session records allow enterprises to provide corporate governance, to demonstrate compliance with regulations, to provide continuous improvement in their business processes, and to integrate with the business processes of partner organizations. Service providers may also be enabled to generate new revenue from the sale of managed partner extranet equipment and services. A complete shared SOA infrastructure that is application agnostic, and requires minimal modification to existing applications while optimizing network bandwidth and application server processing consumption, also becomes possible.
Monitoring, controlling, and reporting on application access by individual users as disclosed herein may be valuable to network and application administrators in order to provide proper governance of their network and systems as well as to demonstrate compliance with governmental regulations. Tremendous amounts of manual effort involved in conventional techniques for collecting application activity records from multiple applications can be avoided. Application session records, which provide a consolidated audit trail of user activity for reporting requirements, and the dynamic nature of application session creation and maintenance, allow real time control and monitoring of users by network and application administrators. The ability to manage application sessions dynamically, via policy and/or administrative action, is a powerful tool that is not currently available to enterprise system administrators.
In summary, embodiments of the invention can be used to provide the complete functionality of a full service SOA infrastructure as follows:
These and other functions have been disclosed herein, and/or in one or more of the above-referenced related patent applications.
What has been described is merely illustrative of the application of principles of embodiments of the invention. Other arrangements and methods can be implemented by those skilled in the art without departing from the scope of the present invention.
For example, as noted above, the present invention is in no way limited to the particular divisions of functions, method steps, and data structure contents shown in the drawings and explicitly described above.
In addition, although described primarily in the context of methods and systems, other implementations of embodiments of the invention are also contemplated, as data structures and/or instructions stored on one or more machine-readable media, for example.
The present patent application claims the benefit of U.S. Provisional Patent Application Ser. No. 60/815,099, entitled “COMMUNICATION NETWORK APPLICATION ACTIVITY MONITORING AND CONTROL”, and filed on Jun. 20, 2006, the entire contents of which are incorporated herein by reference. The present patent application is related to each of the following provisional patent applications, which were filed on Jun. 20, 2006 and are entirely incorporated herein by reference: United States Provisional Patent Application entitled “NETWORK SERVICE PERFORMANCE MONITORING APPARATUS AND METHODS”; United States Provisional Patent Application entitled “SECURE DOMAIN INFORMATION PROTECTION APPARATUS AND METHODS”; United States Provisional Patent Application entitled “SECURE COMMUNICATION NETWORK USER MOBILITY APPARATUS AND METHODS”.
| Number | Date | Country | |
|---|---|---|---|
| 60815099 | Jun 2006 | US |
