Runtime Configuration of Servlet Filtering Using Dynamic Injection

Abstract

Embodiments according to the present invention introduce a high-level abstraction for specifying and operating dynamic filtering at runtime without service interruption. A CustomFilterAdapter implementation of the javax.servlet.Filter interface is added to the target servlet's configuration. A configuration file and/or data structure are used to establish a chain of responsibility pattern and options for existing and for newly added or removed filters. When the chain of responsibility pattern changes, the filters are started and the CustomFilterAdapter reloads the chain of responsibility. When an HTTP request is received, CustomFilterAdapter processes the filters in the chain of responsibility in the chain order.

Claims

1. A method comprising: executing a Java virtual machine (JVM); executing an Open Service Gateway Initiative (OSGi) environment in the JVM; executing a Java-based application in the OSGi environment, the Java-based application receiving Hypertext Transfer Protocol (HTTP) requests; providing and executing a filter servlet in conjunction with the Java-based application, the filter servlet receiving the HTTP requests prior to the Java-based application and executing to perform filter operations on the HTTP request based on a chain of responsibility; and providing and executing at least one filter for execution by the filter servlet, the at least one filter executing when the filter servlet is performing a filter operation, wherein at least one filter is dynamically inserted into the chain of responsibility of the filter servlet.

2. The method of claim 1, further comprising: providing a configuration file containing an indication of at least one filter to be executed by the filter servlet, the filter indications contained in the configuration file being in chain of responsibility order.

3. The method of claim 2, further comprising: providing and executing a configuration program which executes to review the configuration file and develop and provide the chain of responsibility to the filter servlet.

4. The method of claim 3, further comprising: executing a container handling hot deployment of programs in the OSGi environment and providing a console interface, the container coupled to the configuration program to allow editing of the chain of responsibility using the console interface to add a filter to the chain of responsibility.

5. The method of claim 4, wherein the container is Apache Karaf.

6. The method of claim 3, further comprising: providing and executing a listening program which executes to determine that the configuration file has been edited and provides an indication of such editing to the configuration program.

7. The method of claim 1, wherein at least one filter is dynamically removed from the chain of responsibility of the filter servlet.

8. The method of claim 1, wherein the at least one filter has parameters and wherein the parameters can be dynamically changed.

9. A non-transitory computer readable medium or media having computer-executable instructions stored thereon for operating a computer system to perform a method comprising: executing a filter servlet in conjunction with a Java-based application, the filter servlet receiving Hypertext Transfer Protocol (HTTP) requests prior to being provided to the Java-based application and performing filter operations on the HTTP request based on a chain of responsibility; and executing at least one filter for execution by the filter servlet when the filter servlet is performing a filter operation, wherein at least one filter is dynamically inserted into the chain of responsibility of the filter servlet.

10. The non-transitory computer readable medium or media of claim 9, the method further comprising: providing a configuration file containing an indication of at least one filter to be executed by the filter servlet, the filter indications contained in the configuration file being in chain of responsibility order.

11. The non-transitory computer readable medium or media of claim 10, the method further comprising: executing a configuration program which reviews the configuration file and develops and provides the chain of responsibility to the filter servlet.

12. The non-transitory computer readable medium or media of claim 11, the method further comprising: executing a container handling hot deployment of programs in an Open Service Gateway Initiative (OSGi) environment to provide a console interface, the container coupled to the configuration program to allow editing of the chain of responsibility using the console interface to add a filter to the chain of responsibility.

13. The non-transitory computer readable medium or media of claim 11, the method further comprising: executing a listening program which determines that the configuration file has been edited and provides an indication of such editing to the configuration program.

14. The non-transitory computer readable medium or media of claim 9, wherein at least one filter is dynamically removed from the chain of responsibility of the filter servlet.

15. A computer system comprising: a processor; a network interface coupled to the processor; and a non-transitory computer readable medium storing computer-executable instructions for operating a computer system to perform a method including: executing a filter servlet in conjunction with a Java-based application, the filter servlet receiving Hypertext Transfer Protocol (HTTP) requests prior to being provided to a Java-based application and performing filter operations on the HTTP request based on a chain of responsibility; and executing at least one filter for execution by the filter servlet when the filter servlet is performing a filter operation, wherein at least one filter is dynamically inserted into the chain of responsibility of the filter servlet.

16. The computer system of claim 15, the method further comprising: providing a configuration file containing an indication of at least one filter to be executed by the filter servlet, the filter indications contained in the configuration file being in chain of responsibility order.

17. The computer system of claim 16, the method further comprising: executing a configuration program which reviews the configuration file and develops and provides the chain of responsibility to the filter servlet.

18. The computer system of claim 17, the method further comprising: executing a container handling hot deployment of programs in an Open Service Gateway Initiative (OSGi) environment to provide a console interface, the container coupled to the configuration program to allow editing of the chain of responsibility using the console interface to add a filter to the chain of responsibility.

19. The computer system of claim 17, the method further comprising: executing a listening program which determines that the configuration file has been edited and provides an indication of such editing to the configuration program.

20. The computer system of claim 15, wherein at least one filter is dynamically removed from the chain of responsibility of the filter servlet.

Description

BRIEF DESCRIPTION OF THE FIGURES

[0066] The present disclosure has other advantages and features which will be more readily apparent from the following detailed description of the disclosure and the appended claims, when taken in conjunction with the accompanying drawings, in which:

[0067] FIG. 1 is a block diagram of servlet filter interactions.

[0068] FIG. 2 is a block diagram of the OSGi structure.

[0069] FIG. 3 is a block diagram of servlet operation with bundles.

[0070] FIG. 4 is a block diagram of chain of responsibility in OSGi.

[0071] FIG. 5 is an Apache Karaf block diagram.

[0072] FIG. 6A is a block diagram of an exemplary web server according to the present invention.

[0073] FIG. 6B is a block diagram of an exemplary application server according to the present invention.

[0074] FIG. 7 is a flowchart of operations to dynamically add a filter for use by CustomFilterAdapter according to the present invention.

[0075] FIG. 8 is operation using CustomFilterAdapter according to the present invention.

DETAILED DESCRIPTION

[0076] Referring now to FIGS. 6A-B, an exemplary web server 500 and an exemplary application server 502, such as an OpenDaylight® software defined network (SDN) controller, are illustrated. Each server 500, 502 is configured on system hardware 520 and includes an underlying operating system 530, Java VM 532 and OSGi environment and Apache Karaf 534 as discussed above. Network connections are not shown for simplicity. The application server 502 includes application software bundles 540 to provide the software for the desired application, such as OpenDaylight. The web server 500 includes web server bundles 542 to provide the desired web server functionality. Both the application software bundles 540 and the web server bundles 542 include custom filter software and files 536 according to the present invention. The custom filter software and files 536 are described in more detail below. These are very simple block diagrams and many variations and configurations can be developed, as known to one skilled in the art. It is also understood that each server 500, 502 includes a processor for executing software programs and RAM and non-volatile storage to provide operating memory and software storage, respectively. If is further understood that each server 500, 502 includes a network interface for receiving packets, such as HTTP requests, from a network-connected source.

[0077] The custom filter software and files 536 contain a number of different software modules and a file in the preferred embodiment. The software modules include CustomFilterAdapter.java 550, CustomFilterAdapterConfiguration.java 552, CustomFilterAdapterListener.java 554 and various CustomFilters 558. A filterchain.cfg file 556 is also present. Source code for CustomFilterAdapter.java 550, CustomFilterAdapterConfiguration.java 552, CustomFilterAdapterListener.java 554 are provided in the source code appendix incorporated above.

[0078] At a high level, CustomFilterAdapter.java 550 provides the mechanism to execute the desired custom filters, CustomFilterAdapterConfiguration.java 552 provides the desired custom filter CoR to CustomFilterAdapter.java 550 and initializes the custom filters, CustomFilterAdapterListener.java 554 detects changes in the filterchain.cfg file 556 to allow CustomFilterAdapterConfiguration.java 552 to determine the changes in the desired custom filters and filterchain.cfg file 556 contains a CSV (comma separated value) list of the desired custom filters in CoR order and with options indicated. Desired filter changes can also be provided directly to CustomFilterAdapterConfiguration.java 552 using an Apache Karaf console.

[0079] CustomFilterAdapter.java 550 is a customized implementation of the JDK (Java Development Kit) provided javax.servlet.Filter, and is used as the entry point. CustomFilterAdapter.java 550 is added to an HTTP/S Servlet in the relevant bundles 540, 542. CustomFilterAdapter.java 550 thus intercepts all HTTP/S requests and responses. CustomFilterAdapter.java 550 recreates a, or creates its own, Chain of Responsibility pattern for javax.servlet.Filter through CustomFilterChain. The CustomFilterAdapter.java 550 owns an optionally empty chained collection of CustomFilters 558. This is most easily understood by correlating filters as links in a chain. The chain is dynamically configurable through the Apache Karaf Configuration Admin service at runtime. Filters may be added, removed, and reconfigured dynamically without recompiling or restarting the HTTP/S Servlet. In other words, the chain may be lengthened or shortened with different types of links, and the individual links may be reconfigured at runtime, as explained more below. Links from different bundles (vendors) are permitted through using OSGi's Dynamic-ImportPackage functionality, so newly developed and purchased Filters can be added without stopping the server. This allows the system and its operators to configure filtering on the fly, enabling live debugging, security analytics, and on-demand service configuration. Service configuration includes (but is not limited to) whitelisting, blacklisting, rate limiting, analytics generation, load balancing and other common techniques often owned by external software or hardware entities.

[0080] Network and website administrators and operators may not be the only actor who has permission to configure the CustomFilterAdapter. In some embodiments autonomous services owned by the implementing system may dynamically configure Filters based off performance metrics, security threat level, desired accounting verbosity, or other measures of health of the server.

[0081] The Filters may be used to glean certain information from incoming HTTP/S requests prior to forwarding the request to the servlet. The gleaned information may be sent to an external source for offline processing. The server might also forward the request inline to external entity (i.e., firewall) to do enhanced filtering externally on the request.

[0082] This does not need to apply to just HTTP/S. This same pattern may apply to SDN controller southbound protocols as well, such as OVSDB (Open vSwitch Database Management Protocol), NETCONF (Network Configuration Protocol), and OpenFlow®.

[0083] Some examples are provided here.

[0084] Debugging: A filter is chained to provide enhanced information on the incoming request headers, payload, IP address, or other HTTP attributes.

[0085] Timing statistics for how long the request took to process by the server (i.e., how long RESTCONF takes to process request through MD-SAL), in order to optimize internal services based on minimizing process time.

[0086] Security: Whitelisting, blacklisting, rate limiting, forwarding requests to an external entity for processing, security auditing, accounting, active/passive IdP, etc.

[0087] Server health: rate limit to stop someone from killing the server with (D)DOS.

[0088] Pre-processing and post-processing Translation Services: Modify incoming requests or responses in order to better interact with established protocols. For example, modifying payloads to comply with established YANG schemas, modifying replies to provide enhanced information to client consumers, etc.

[0089] Dynamic Professional Services: Allow the system or operators to decide what to turn on and when in order to gather information. During low loads, perhaps this means logging with great verbosity. During high loads, this may mean limiting logging verbosity. If security threats are determined externally, enhanced security features may be enabled. If new Filters are discovered from external vendors (i.e., some other project provides a cool filter), it can be added at runtime without stopping the server and interrupting provided service.

[0090] Health over time: Stats generated from filtered information may be processed and plotted over time to determine if server capacity is adequate for server load. This also allows for operators to determine the performance effects of injecting a new filter by comparing against a baseline.

[0091] FIGS. 7 and 8 illustrate operation of the preferred embodiment. In step 702 a new custom filer NewFilter 1 is obtained, either by development or downloading from a source. In step 704 NewFilter 1 is installed as a bundle using Apache Karaf. In step 706, a choice is made on using the .cfg file method or the Karaf console method. If using the .cfg file method, in step 708 the filterchain.cfg file is edited using any suitable text file editor. An example filterchain.cfg file is provided here in Table 1 for reference.

TABLE-US-00001 TABLE 1 Example filterchain.cfg file customFilterList=com.brocade.bvc.filters.SSLHostnameIPMismatchFilter,com.brocade.bvc.filters .RequestResponseLoggingFilter com.brocade.bvc.filters.RequestResponseLoggingFilter.maxOutputLength=4000 com.brocade.bvc.filters.SSLHostnameIPMismatchFilter.hostname=test

[0092] In the example, two filters, SSLHostnameIPMismatchFilter and RequestResponseLoggingFilter, are indicated, with the values separated by a comma. Parameters for each filter are provided in the lines following the filter list.

[0093] In step 710 Karaf fileinstall, part of the Karaf suite, detects the editing of the filterchain.cfg file and notifies CustomFilterAdapterConfiguration.java 552. In step 712 CustomFilterAdapterConfiguration.java 552 initializes all filters in filterchain.cfg, recreates the CoR into a filterlist and notifies CustomFilterAdapter.java 550 of the updated CoR via CustomFilterAdapterListener.java 554. Alternatively, CustomFilterAdapterConfiguration.java 552 can initialize just NewFilter 1. In step 718 CustomFilterAdapter.java 550 reloads the filters according to the CoR as indicated in the provided filterlist.

[0094] If the command line option was selected in step 706, in step 714 the operator uses a Karaf console, such as the webconsole, to indicate the use of NewFilter 1 to CustomFilterAdapterConfiguration.java 552. In step 716 CustomFilterAdapterConfiguration.java 552 updates the filterchain.cfg file to include NewFilter 1 as indicated, initializes all filters in filterchain.cfg, recreates the CoR into the filterlist and notifies CustomFilterAdapter.java 550 of the new filterlist through CustomFilterAdapterListener.java 554. In step 718 CustomFilterAdapter.java 550 operates as above.

[0095] Removal of a filter is similar except that instead of adding a filter to the CoR, a filter is removed from the CoR. Reconfiguration of a given filter is also similar, except only the parameters for the filter are changed.

[0096] In step 802 an HTTP/S request is received. In step 804 AAAfilterchain, the default filter chain, processes the HTTP/S request using its filter. In step 806 CustomFilterAdapter.java 550 receives the HTTP/S request from AAAfilterchain and processes the request through each of the filters indicated in CustomFilterChain value in the CoR as established in the CustomFilterChain value, basically in the order listed. In an alternative embodiment, AAAfilterchain can be included in the CoR executed by CustomFilterAdapter.java 550 as a first filter, thus removing step 804. In step 808 CustomFilterAdapter.java 550 provides the filtered HTTP/S request to the destination servlet.

[0097] For further details, reference to the incorporated source code listing is recommended.

[0098] Therefore, by maintaining a CoR of filters as a value that is updated dynamically, filters can be added or removed without restarting the system or recompiling the system. This greatly improves overall flexibility and uptime of the system and eliminates service interruptions.

[0099] The above description is intended to be illustrative, and not restrictive. For example, the above-described embodiments may be used in combination with each other. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of the disclosure should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein.”