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.
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.
I previously demonstrated how I use Google Authenticator to protect sensitive resources in my PeopleSoft applications. I would like to share the code involved to get this to work. If you are unfamiliar with what Google Authenticator is and how it works, then I suggest reading about it here. A while back, I read a nice article that demonstrated a simple Java implementation of the Time-based One-time Password (TOTP) algorithm (specified in RFC 6238) that is used with Google Authenticator. After making slight modifications to the code, I was able to easily integrate this Java implementation in my PeopleSoft application. I packaged the code up into a JAR file that I will explain how to use in this post. UPDATE: I recently discovered that there are some other mobile applications that implement the same TOTP algorithm as Google Authenticator. Some examples of these applications are Duo, Authy, and even Oracle Mobile Authenticator. This means that any of these other TOTP-generating applications can be used with the solution that I am demonstrating in this tutorial.
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.
This is a demonstration of my Google Authenticator implementation in PeopleSoft. Google Authenticator is a free service that can be used to implement two-step verification in applications to add an additional layer of security. I decided to leverage the event mapping framework in PeopleSoft to enforce the two-step verification process at the component level, but this solution could just as easily be integrated into the PeopleSoft login page/process. If you are interested in implementing Google Authenticator in your PeopleSoft applications, then you can read how I implemented this project here.
The Event Mapping Framework is a new functionality introduced in PeopleTools 8.55. The framework provides a way to run custom code on delivered components without having to modify the delivered objects. I am going to demonstrate how the Event Mapping Framework can be used to enforce two-factor authentication (2FA) by mapping application class PeopleCode to component events. I have provided a proof-of-concept project that demonstrates this functionality.
In this part of the tutorial, I have expanded on what was done in the first part by adding additional logic to the Signon PeopleCode and adding more functionality to the 2FA page. I went ahead and created an app designer project that contains all of the objects and code that serves as a proof-of-concept of how the 2FA process works as a whole. The only functionality that this project does not contain is the ability to send SMS messages. You should be able to plug and play this project into your environment.
I am going to provide a tutorial on how to setup two-factor authentication (2FA) in PeopleSoft. This is going to serve as a technical demonstration (and documentation) of how I satisfied the project requirements that were outlined in this post. This tutorial will be split into a few parts.
Part 1 (this part) of the tutorial is to give you an overall understanding of how the 2FA process will work in your PeopleSoft environment. This part provides an overview of the necessary configuration and code changes that are needed to alter the application’s authentication process flow. Most of the information in this part of the tutorial echos what has been said in a post on Sasank’s PeopleSoft Log called Conditional Redirect in SignOn PeopleCode.
This post is to document my two-factor authentication (2FA) project that I have implemented in PeopleSoft. This project was done because there was a desire to add an additional layer of security to the application without having to worry about the costs associated with a vender-supplied 2FA solution. A customization like this would seem to be somewhat infeasible to build in-house, but leveraging some of Oracle’s delivered functionality coupled with a well thought-out design, made this project’s implementation quite simple. This is relatively speaking of course, after all, this project does add an entire new step to the delivered PeopleSoft authentication process. I am only going to talk about the requirements, specifications, and design in this post as well as provide a short demo. I am writing a tutorial here that shows the steps on how to implement this.