The %metadata application package in PeopleSoft is very intriguing. This app package is unlike any other as we (PeopleSoft Developers) do not have access to the implementation of this package. When you try to open this package in App Designer, the IDE acts as if the package does not exist. However, if you correctly reference this package’s contents (sub-packages, classes, methods, properties, etc.) then App Designer does not bat an eye. It should be well understood that (our) usage of this package is not supported by Oracle as it is undocumented. However, there are currently no measures in place to prevent blind usage this app package. While I definitely do not advise the usage of this package in any legitimate PeopleSoft system, I thought it would be a fun educational exercise to try to understand this mysterious app package.
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 while back I presented a solution to manage configuration data on the web server. This solution involved a servlet-based cache managing utility that was responsible for the storage and caching of data to the PeopleSoft web server. I have been experimenting with ways that I can get custom data cached to the PeopleSoft web server without being so intrusive to the web-tier. I recently came across the PT_METADATA app package which can be used to create object types such as HTML, Style Sheet, and Images. These object types are nice because they are PeopleTools-managed and they have the flexibility to store custom data expressed in any form. Another great perk of these object types is that they can be cached to the web server using the %Response class. I am going to demonstrate a technique that I use to get PeopleTools to manage and cache my custom data.
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.
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.