A recent comment I received made me go back and revisit my “Implementing Google Authenticator in PeopleSoft” post where I discuss the code involved to get Google Authenticator working in PeopleSoft. Revisiting this post made me realize that I never actually shared the source App Designer project with the community. I would like to use this post to share the plug and play POC project that I use to enforce component-level 2FA with Google Authenticator in PeopleSoft applications.
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.
The HTML element IDs that appear on PeopleSoft pages follow an officially undocumented naming convention. It would be nice to know the exact naming convention that is being used on these HTML element IDs so that there would be no uncertainty when it comes to DOM manipulation with injected client side code. Fortunately, there have been many PeopleSoft experts in the past that have demonstrated how the HTML element IDs on PeopleSoft pages typically have their record and field names present in the ID. It is worth noting that not all fields follow the RECORDNAME_FIELDNAME naming convention. This is true for fields that have a value set for the page field name in the page field properties in App Designer. An example of this would be the National ID field that appears on the relationships page.
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.
In this post I will provide a step-by-step tutorial on how to send SMS text messages in PeopleSoft. I will be consuming Nexmo’s SMS API to send SMS messages. There are many SMS API services similar to Nexmo and there is no particular reason that I chose Nexmo over the other providers for this tutorial. I have some experience with using other providers and the quality of service is comparable across the board. There will be four main steps in this tutorial: creating a Nexmo account, importing Nexmo SSL certificates, importing custom objects, and testing the service.
It should be well understood that you should never trust user input in your application. As an application developer, I always try my hardest to enforce very strict rules when accepting and outputting user inputted data. You can never really be too careful when it comes to handling data that you do not know (or can’t trust) the source of. Fortunately, PeopleCode is very robust in terms of providing built-in functions to safely handle the input and output of data. I would like to demonstrate an example of how a malicious user can execute a stored cross-site scripting attack on an insecure custom application within my PeopleSoft system. I will then show how to mitigate this attack by hardening the security of my custom application with a built-in PeopleCode function.
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.