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.