One major drawback of the response-manipulating servlet filters that I have showcased on this site is that the delivered compression functionality needed to be disabled for them to work. This involved unchecking the “Compress Responses” checkbox on the web profile configuration page in the PIA. Disabling this functionality causes a performance impact because of the resulting large response messages that get sent to the client. I recently got a comment from Jonathan Rehm explaining how he has achieved GZIP compression within a custom servlet filter. I decided to integrate the code he shared into a standalone response compression servlet filter. This servlet filter can co-exist with any other custom filters that you may have deployed. I will demonstrate how to deploy this custom response compression servlet filter in this post.
Some of the servlet filters that I have previously demonstrated make use of configuration data that originates from the PeopleSoft application. This configuration data consists of things like which fields to mask and what components to restrict access to. This data is ultimately what controls how the servlet filters behave. In this post, I would like to discuss how I go about communicating configuration data from the PeopleSoft application to the web server and the techniques that I use to manage this data. First I will go over the design, installation, and use of a caching utility that I wrote to manage the configuration data. Last I will discuss how I integrate my servlet filters and PeopleSoft application with this solution.
I’d like to share a demonstration of a field-level data masking solution that I’ve created for PeopleSoft. This project showcases a lot of the techniques that I have discussed throughout the year on this blog with respect to creating a secure PeopleSoft application with a good user experience. This bolt-on solution provides a user interface to configure what fields to mask, the conditional ability for end users to unmask data, and a way to track the sensitive data exposure throughout the system.
Modifying or transforming response data generated by the web server is a great use of servlet filters. I read a nice Stack Overflow thread that discusses the idea of injecting text into the head of an HTML response using a servlet filter. The code provided in this thread is a great example of how to modify HTML response data that gets sent to the client. I made some slight modifications to this code so that I can inject custom scripts and styles in the HTML responses generated by the PeopleSoft web server. This servlet filter will be a bolt-on solution to achieve global script and style injection in PeopleSoft. Below are the steps to configure this servlet filter for the PeopleSoft web server.
I previously demonstrated how servlet filters can be used to view and modify HTTP requests that the client sends to the web server. This post will demonstrate how servlet filters can view and modify the HTTP responses that the web server sends back to the client. The servlet filter that will be used in this demonstration is one to mask social security numbers (SSNs) that appear in the response messages. Using servlet filters to perform sensitive data masking does not change the actual value of the data in the database, but it still protects the true values from being exposed through the PIA.
I developed a servlet filter that is capable of logging the request data that a client sends to the PeopleSoft servlets. I did this project to better familiarize myself with Java as well as to get more comfortable developing at the web-tier. This servlet filter can be useful for keeping track of what users are doing in your PeopleSoft applications. I will admit that the code that I am releasing here is pretty raw and should be used with caution. I am mostly putting this out here for documentation purposes.
I would like to provide a tutorial to show how redirection capabilities can be achieved with servlet filters. There are many use cases for why you would need to redirect a user’s browser with a servlet filter. For example, there might be some resources in your PeopleSoft application that you want to only allow access to under certain conditions. When these conditions are not met, then you might want to redirect users to a different page. Some example conditions can be things like: the user must be on an internal IP address, the user must present a valid secondary authentication token, or the time of the day must be between 8:00 am – 5:00 pm. Anything that is presented in an HTTP request can be analyzed to see if it meets a certain criteria.
Below is a presentation that I gave on how servlet filters can be used to enhance the security of PeopleSoft applications. In this presentation, I introduce what servlet filters are and how they integrate with the PeopleSoft architecture. I also provide a demonstration of specific functionalities that servlet filters can provide to protect PeopleSoft applications.