Using Event Mapping to perform field level data masking is an idea that I have toyed with since the release of Event Mapping in PeopleTools 8.55. Event Mapping is a desirable tool for field level data masking in PeopleSoft because it can allow for bolt on runtime application logic to determine if a user should have the ability to view a particular piece of data. I am unfortunately not here to say that Event Mapping can deliver us a (much needed) data masking framework for PeopleSoft applications. However, I have recently found that Event Mapping is capable of satisfying one particular field level data masking requirement that I threw at it. In this post, I will be sharing a proof of concept project that I’ve used to perform conditional data masking on a read only data field within a delivered Fluid page.
The Fluid Navigator is the new navigation technique that most closely resembles to old Classic style drop down menu navigation. If you have not yet had the chance to convert your entire menu structure to use more modern navigation techniques, then you are stuck having to rely on the Fluid Navigator to get you where you need to be in some cases. One major limitation of the Fluid Navigator is that is does not show you breadcrumbs when drilling down into the menu structure. Not having breadcrumbs displayed makes it much harder to quickly jump around the menu. In this post, I will demonstrate how you can add breadcrumbs to your Fluid Navigator.
I recently got my hands on a PeopleSoft environment running the new 8.56 PeopleTools. I have been most curious to see the advancements in the Related Content Framework Event Mapping functionality in the new Tools release. One huge limitation with Event Mapping in the 8.55 PeopleTools was the inability to inject custom styling into Fluid pages. The framework did not disallow this practice, but injecting custom styles into Fluid pages would generally result in the page becoming incorrectly rendered and unusable. One particular interesting use case of injecting custom styling with Event Mapping is to change the Fluid Homepage background. This use case was proposed by a member of the psadmin.io Community and I had previously tried this in 8.55 and it did not work well. However, it seems to work great in the new 8.56 PeopleTools. Below I will walk through how one can go about changing the Fluid homepage background with Event Mapping.
Menu pruning is the process of limiting the items that show up in a menu for a user. This process is desirable in situations where you want to prevent a user from accessing certain content references. An example scenario of this could be that you don’t want to let administrators access Query Viewer when they are not coming in from a trusted location. The fashion in which the administrator’s access is limited in this scenario is the process of location-based security. With location-based security, you can let the location that a user is coming from dictate the type of access that a user has in the application. So if we put these two terms together, we get location-based menu pruning. Location-based menu pruning is the process of limiting the items that show up in the menu for a user based on the user’s location. In this post, I will discuss how we can perform location-based menu pruning on the PeopleSoft Fluid Navigator.
A common desire among organizations that adopt the Fluid user interface (UI) is the ability to keep the Classic UI for administrative users. The loudest argument backing the need for the Classic UI for admins is that the Fluid UI does not have breadcrumbs. The response to this argument is that the adoption of Fluid is more than just mobile-enabling the application, but it also entails leveraging the new Fluid navigation paradigm which means using homepages, tiles, navigation collections, search, etc., to give users an avenue to perform the transactions that they need to perform. A proper adoption of the Fluid UI means leveraging these tools to “create your own navigation” for not only self-service users, but admin users as well. While I don’t necessarily have a dog in this fight, I would like to provide a proof-of-concept example on how one can go about keeping administrative users Classic in a Fluid environment.
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 wanted to share a proof-of-concept approach to creating a simple application layer firewall with event mapping in PeopleSoft. This post is similar to my Using the Event Mapping Framework to Enforce Two-Factor Authentication post, but this post highlights more on the general idea of using event mapping to extend the delivered PeopleSoft security model. What I will be showing is how you can conditionally reject requests to specific resources based on the IP address that the user is coming from. This is a simple way to add an additional layer of security to your PeopleSoft applications with very little overhead. This functionality will be accomplished with event mapping, which is a new feature in the 8.55 PeopleTools.
Keeping a record of the transactions that are occurring in your PeopleSoft applications is a great way to prepare yourself for the inevitable security investigations that will need to occur after a security-related incident. While most logging can be done at the database level with triggers and audit tables, there are still some transactions that the database is not capable of capturing. One example of this is a transaction where a user inputs data into a search record on a component. I would say that logging this information is very important for certain components in PeopleSoft. Even though users are not altering the data in these situations, just knowing what the users are searching for can be useful information.
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.