PeopleSoft Data Masking Options

PeopleSoft customers have several Data Masking options:

• App-specific masking,
• Data Privacy Framework,
• Page and Field Configurator,
• Event Mapping, and
• Bolt-on solutions, such as Pathlock's Security Solution for PeopleSoft.

Let's compare the various options.

Event Mapping

Event Mapping is the most flexible option, allowing us to use any masking character, from alpha-numeric to emoji. In fact, you may even combine the space character with custom CSS to leverage any character, including custom Fonts, such as FontAwesome. Relevant PeopleCode functions and methods include:

Field.SetDisplayMask
Field.AddFFClass
AddStylesheet

Check out this video to learn more about Event Mapping for Data Masking:

Page and Field Configurator

Page and Field Configurator is less flexible but easier to apply than Event Mapping. Page and Field Configurator offers a point-click interface to configure masking against page fields. Masking characters are limited to * and x (although this is configurable through masking profiles).

App-specific masking

The HCM team built its own registry of sensitive fields with a masking utility. You can learn more about this feature in the Quest blog post Maintaining Data Privacy in PeopleSoft HCM. What makes this option compelling is:

1. The HCM team wrote all the code. All we have to do is choose our sensitive fields, components, and roles.
2. If anything breaks, we file a ticket for the HCM team to fix. This is in contrast to Page and Field Configurator and Event Mapping, which are site-specific isolated customizations and, therefore, the customer's responsibility to fix.
3. This solution has broad coverage. If we choose to mask a sensitive field, such as birth date, then all HCM pages and components should mask that field. Event Mapping and Page and Field Configurator, on the other hand, only mask one component. If we used either of those solutions to mask the birth date field, we would need to apply that masking to all components ourselves.

Data Privacy Framework

The Data Privacy Framework allows us to apply masking to query results. This is not mutually exclusive. You may choose to apply the Data Privacy Framework along with any of the other options.

Bolt-on Solutions

My favorite data masking solution is Pathlock's Security Solution for PeopleSoft. Besides the basics of masking, Pathlock's solution also allows us to unmask using a variety of techniques, including:

• Click-to-view (a loggable event) and
• MFA-to-view (also loggable but requiring a second factor to confirm your identity).

Interested in learning more? We teach PeopleTools Tips like this every week at JSMpros! Check out our online schedule to see what we are offering next! Or do you have a specific topic you want to study? Subscribe to gain access to all of our on-demand content at a fraction of the cost!

TokenChpoken

Several years ago, ERPScan published a series of articles describing PeopleSoft security attack vectors. While reading the series, keep in mind it was written nearly a decade ago, and PeopleSoft has made changes to security to mitigate the issues raised by ERPScan. For example, their article about the Access Token ends with the note, "this vulnerability was patched in Oracle CPU for October 2014." Note to self: Apply CPUs! But the topic that keeps coming up is TokenChpoken.

What is TokenChpoken?

When you authenticate (log in) to PeopleSoft, PeopleSoft sends a cookie to your browser. Thereafter, PeopleSoft identifies you by that cookie. For every request, PeopleSoft asks, "who are you?" and that cookie supplies the answer. This cookie is critical to cross-product SSO for unified navigation, Interaction Hub, etc. TokenChpoken describes how to decrypt that cookie, change the OPRID, and assume the identity of someone else. Pretty scary! But is it legitimate? As described by the TokenChpoken write-up, someone leveraging this approach must know your user ID, the SSO node name, and the node password must be discoverable through a modern brute-force attack. If you renamed your nodes and use strong passwords, you are a long way from a TokenChpoken "vulnerability." But that doesn't eliminate the potential. It is now a risk calculation.

Is TokenChpoken still relevant for today's PeopleSoft? In PeopleTools 8.56, PeopleSoft implemented a "knock knock/callback" pattern with a check token. Dan Iverson has a great write-up on this 8.56 feature. Likewise, as of 8.56, if I restart my web server while browsing PeopleSoft, PeopleSoft renders the message "unauthorized token detected." It seems like PeopleSoft now keeps a list of issued tokens in memory, and a restart clears that list. These are fantastic safeguards against a potential TokenChpoken Switch User. My thought is,

"If PeopleSoft won't accept its own token after a restart, why would it accept a modified token?"

But is this enough?

A few years ago, Colton Fischer came up with a simple way to test functionality as a different user. You log into PeopleSoft as yourself, press a bookmark in your web browser, supply the node name, node password, and the target user ID, and instantly become someone else. You may find his project here. As a developer and tester, this sounds fantastic! Through a "master password," I can assume the identity of anyone for testing purposes, of course. How does it work? It is essentially TokenChpoken in the web browser. What does that mean? TokenChpoken is alive and well.

Mitigation

As documented by Dan Iverson, setting the Check Token and node password on your nodes, as well as changing node names from something other than the default PSFT_xx, is a great start. And that start may be enough. But you might want to try Colton's bookmarklet to see if you can become someone else. If so, here is another idea: Eliminate the PS_TOKEN cookie. Eliminating the PS_TOKEN is a bit controversial as this is the "key" to PeopleSoft SSO, and it may not be the right solution for you. But here is how it works: As a request leaves a load balancer or web server, the web server/load balancer replaces PS_TOKEN with a different, randomized cookie. On re-entry, the web server/load balancer maps that random cookie to the original PS_TOKEN. PeopleSoft is unaware and functions as usual. If all of your PeopleSoft instances are behind the same load balancer and use the same domain, then SSO may work as usual, and token replacement may be a great option. If you want an off-the-shelf solution, check out Pathlock's ERP Firewall, which has built-in TokenChpoken mitigation.

Since most PeopleTools classes involve nodes and security, we talk about TokenChpoken regularly. To learn more about this topic and other PeopleTools tips, check out our website to see what we are offering next!

Which Query Security Tree?

Here is the scenario:

A user needs to create a query, but doesn't have security access to view a record. The user asks you for help.

Before running or writing queries, a user must have access to records through Query Security Trees. We assign records to trees, trees to permission lists, permission lists to roles, and roles to users. The solution is trivial: grant security access through a security tree. The difficult part is deciding which tree and which permission list. When I receive a request like this, I have two groups of questions:

1. Is there already a query security tree that grants access to the target record? If so, which one and which permission lists? Would any of those permission lists be appropriate for this user?
2. Is there already a query security tree available to this user that would be a good fit for this record?

Here are some SQL statements I created to help answer these questions.

Find existing trees that include the target record:

Finding Permission Lists that grant access to a specific record is more challenging. Locating permission lists that contain a tree that contains a record is trivial. Narrowing that list based on Access Group is more challenging because Access Groups represent node hierarchies and therefore require recursive logic:

Do you have SQL statements and tricks to help you manage Query Security? If so, share them in the comments!

At JSMpros, we teach PeopleTools tips like this every week. Check out our website to see what we are offering next!

PeopleTools 8.59 new feature: Independent "AddTo" Security

Imagine having a PeopleSoft Favorites feature and no way to add Favorites. After 8.54, many customers found themselves in this situation. Fluid introduced "Add to Homepage" and "Add to Navbar" as fantastic personalization options. Our users love them. For example, I can "pin" my favorite classic components to my homepage for quick and easy access. For power users, this is terrific! And for self-service users? Every component a self-service user visits should already be represented through a Fluid homepage tile. For the casual self-service user, offering an "Add to Homepage" feature often causes more problems than it solves. With that in mind, customers often disable the "AddTo*" feature for self-service users. My friend Simon Chiu explains how in Section Four of his post PeopleTools 8.55 Features: How to Deploy Homepages, Tiles and Branding. From 8.54 to 8.58, disabling Add to Homepage also disables Add to Favorites, which is unfortunate. Favorites are the domain of the user. Nobody questions a user's favorites. Our friend Sasank Vemana shared a solution to "decouple" the AddTo options so we could disable these features independently. Likewise, My Oracle Support published Doc ID 2143709.1, showing how to customize the AddTo* features so customers can remove Add to Homepage while keeping Add to Favorites. Unfortunately, through 8.58, retaining Add to Favorites requires a customization.

What about PeopleTools 8.59? Oracle basically applied this customization to the base PeopleTools code. This feature is now built into PeopleTools. With PeopleTools 8.59, PeopleSoft added the following new roles:

• DisableAddToFavorites
• DisableAddToHomepage
• DisableAddToNavBar

To remove access to Add to Homepage, assign the role DisableAddToHomepage.

Here are a couple of interesting observations of this new feature. First, access seems logically inverted. To remove access, you must assign a role. Normally, we assign roles to grant access. In this case, we assign a role to remove access. Second, we noticed user PS has these roles in the latest HCM PUM, which means out of the box, user PS can no longer add to favorites, homepages, or Navbar.

What are your observations of this new feature? Share your thoughts in the comments. We would love to hear!

Are you interested in learning more about PeopleSoft security or fluid? Check out our latest course offerings at https://www.jsmpros.com/courses/ and events at https://www.jsmpros.com/events/.

Where do you terminate SSL for PeopleSoft?

Most PeopleSoft implementations have some sort of firewall/load balancer appliance in front of PeopleSoft. As an administrator, one question we have to answer is, "Where do we terminate SSL?" And the answer seems so obvious, most don't even ponder the question. What is the obvious answer? Terminate at the load balancer. Why? Because that is why they exist. SSL/TLS is what they do, and they do it well. What's the alternative? Carry SSL all the way to Weblogic, and terminate at the PeopleSoft web server. Weblogic is amazing at what it does, but it isn't a security appliance. And that is why the obvious answer is to terminate at the load balancer. But here is my question:

Are you reencrypting the traffic between the load balancer and PeopleSoft?

Do you encrypt all the way to Weblogic or do you terminate at the load balancer, thereby passing sensitive information in plain text behind the firewall?

Over the last several years I have heard fantastic security presenters recommend SSL termination at the load balancer level (for good reason). But they always end encryption at the load balancer. They don't encrypt behind the firewall. Why not? The most common reason is performance. Encryption isn't free. And if encryption is expensive, why encrypt behind the firewall? Here are two reasons:

1. Your network might not be as secure as you think it is. A great example is NASA's breach implemented through a Raspberry PI.
2. PeopleSoft-delivered service operations expect encryption.

As a developer, I defer to the network infrastructure design team. If they say the network is secure, I take their word for it. But take a look at reason #2. There are several PeopleSoft-delivered service operations that verify encryption at the Weblogic level. If I want to use those delivered service operations, I either need to:

• Carry SSL/TLS all the way to Weblogic or
• Modify the Service Operation.

Which would you prefer?

Security: The PeopleSoft Social Threat Vector

In the old Mission Impossible television series from the '60s and '70s, a team of expert agents socially engineer an incredible swindle to catch a bad guy, elicit a confession, release a hostage, etc. These deceptions often included room reconstructions, elaborate disguises, rerouted telephone calls, fake news broadcasts, etc. The con had to be so good the prey had no clue. If it weren't for the regular cut-aways to "reality," viewers wouldn't be able to tell fiction from truth. I remember one episode where the IMF (the Mission Impossible team) had to convince the "bad guy" that his plot succeeded (fake news broadcast). Another episode required making a person think his victim was still alive. Incredible social engineering. It is a lot of fun to watch this unfold when good guys are conning bad guys to preserve national security. But what about when the charade is run by a bad actor attempting to steal from our organization?

Imagine you are a manager, professor, grant owner, or someone else responsible for transactions in PeopleSoft. You receive a workflow notification e-mail requesting you to approve a PeopleSoft transaction. Since you receive these emails all the time, you don't think much of it. You click the link and see your usual login screen. You authenticate and continue processing the transaction. This is a regular, every day scenario, but let me tell you, IT SCARES THE DAYLIGHTS OUT OF ME! Why? Let's review:

• I received an e-mail with a link.
• I clicked the link.
• I entered my PeopleSoft credentials into the page that appeared.

It may really have been PeopleSoft or it may have been a Mission Impossible-style bluff designed to make me think I was logging into PeopleSoft. If the latter, I just gave away the front door key to my ERP kingdom and there is no telling what a bad actor will do. Actually, I can give you a couple of ideas of what they will do:

• Change your direct deposit to an off shore account,
• Use query to download sensitive information and sell it,
• Steal Accounts Payable information,
• Setup fake employees to be paid through the regular payroll,
• Setup fake vendors for payment, and
• Change bank account information for vendors.

How do I know this? Because I've seen it happen! This is not a PeopleSoft security issue, it is all about social engineering. It is about bad actors targeting individuals through phishing, spear phishing, and whaling. Every day good people are tricked into giving their credentials to bad people.

The most common solution is to train employees to stop clicking links in e-mails. But what is a little awkward is that PeopleSoft comes preconfigured with workflow notifications that contain links. Doesn't it seem a little ironic that most of us have anti-phishing training and policies that tell our users not to click links and then our ERP system sends e-mails with links? To compound the situation, organizations create alerts, notifications, and scheduled processes that send e-mails with links. These links keep sensitive data out of e-mails and in controlled ERP systems. This was supposed to improve security. The problem is that bad people tempt good people into clicking fake links. So what can we do?

1. Stop sending links or
2. Protect PeopleSoft with multi-factor authentication.

I really don't like the first option. Removing links from all PeopleSoft notifications would be a significant modification. I know some customers that do this. It is manageable and I would rather do this than nothing at all. At least my PeopleSoft implementation would be in compliance with my standard corporate security policies.

But removing links from PeopleSoft e-mails doesn't fix the problem. Users may still receive phishing e-mails with links to pseudo-PeopleSoft signon screens and may still give away their credentials. This is where multi-factor authentication protects us, and is why I prefer option 2. Not only do we avoid customizations and improve the user experience through targeted e-mail links, we protect our Enterprise system in the event an unsuspecting user accidentally passes credentials to a bad actor. With multi-factor authentication, compromised credentials are useless. The bad actor still needs that extra factor to authenticate.

I have seen many different multi-factor authentication implementations using a variety of tools. Most of them are generic solutions retrofitted into PeopleSoft, and not built specifically for PeopleSoft. Occasionally I run into a multi-factor PeopleSoft retrofit written by someone that learned just enough about PeopleSoft to write a security "plugin" (Yikes!). If it were my system to protect, I would choose Appsian's Multi-factor Authentication. Appsian's product is deeply embedded in PeopleSoft, allowing us to protect sensitive information.

Social engineering is today's cyber crime threat vector. Strong password controls, secure networks, and education are critical to defending our systems, but can't protect against a well engineered social attack. It's time to do something about it.

Are you interested in learning more about PeopleTools and how you can protect your PeopleSoft implementation? Contact us to schedule your next PeopleTools training class.

PS: I really wanted to name this post PeopleSoft Social Security Attack Vector. You get it? PeopleSoft Social -- Security Attack Vector... oh never mind. You know what they say, "If you have to explain a joke..." ... and now you know why I titled it something different ;)

Unlimited Session Timeout

There are a lot of security admins out there that are going to hate me for this post. There are a lot of system administrators, developers, and users, however, that will LOVE me for this post. The code I'm about to share with you will keep the logged in PeopleSoft user's session active as long as the user has a browser window open that points to a PeopleSoft instance. Why would you do this? I can think of two reasons:

• Your users have several PeopleSoft browser windows open. If one of them times out because of inactivity at the browser window level, then it will kill the session for ALL open windows. That just seems wrong.
• Your users have long running tasks, such as completing performance reviews, that may require more time to complete than is available at a single sitting. For example, imagine you are preparing a performance review and you have to leave for a meeting. You don't have enough information in the transaction to save, but you can't be late for the meeting either. You know if you leave, your session will time out while you are gone and you will lose your work. This also seems wrong.

Before I show you how to keep the logged in user's session active, let's talk about security... Session timeouts exist for two reasons (at least two):

• Security: no one is home, so lock the door
• Server side resource cleanup: PeopleSoft components require web server state. Each logged in user session (and browser window) consumes resources on the web server. If the user is dormant for a specific period of time, reclaim those resources by killing the user's session.

We can "lock the door" without timing out the server side session with strong policies on the workstation: password protected screen savers, etc.

So here is how it works. Add the following JavaScript to the end of the HTML definition PT_COMMON (or PT_COPYURL if using an older version of PeopleTools) (or even better, if you are on PeopleTools 8.54+, use component and/or role based branding to activate this script). Next, turn down your web profile's timeout warning and timeout to something like 3 and 5 minutes or 5 and 10 minutes. On the timeout warning interval, the user's browser will place an Ajax request to keep the session active. When the user closes all browser windows, the reset won't happen so the user's server side session state will terminate.

What values should you use for the warning and timeout? As low as possible, but not so low you create too much network chatter. If the browser makes an ajax request on the warning interval and a user has 10 windows open, then that means the user will trigger up to 10 Ajax requests within the warning interval window. Now multiply that by the number of logged in users at any given moment. See how this could add up?

Here is the JavaScript:

(function (root) {
    // xhr adapted from http://toddmotto.com/writing-a-standalone-ajax-xhr-javascript-micro-library/
    var xhr = function (type, url, data) {
        var methods = {
            success: function () {
            },
            error: function () {
            }
        };

        var parse = function (req) {
            var result;
            try {
                result = JSON.parse(req.responseText);
            } catch (e) {
                result = req.responseText;
            }
            return [result, req];
        };

        var XHR = root.XMLHttpRequest || ActiveXObject;
        var request = new XHR('MSXML2.XMLHTTP.3.0');
        request.open(type, url, true);
        request.setRequestHeader('Content-type', 'application/x-www-form-urlencoded');
        request.onreadystatechange = function () {
            if (request.readyState === 4) {
                if (request.status === 200) {
                    methods.success.apply(methods, parse(request));
                } else {
                    methods.error.apply(methods, parse(request));
                }
            }
        };
        
        request.send(data);
        return {
            success: function (callback) {
                methods.success = callback;
                return methods;
            },
            error: function (callback) {
                methods.error = callback;
                return methods;
            }
        };
    }; // END xhr


    var timeoutIntervalId;
    var resetUrl;

    /* replace warning message timeout with Ajax call
     * 
     * clear old timeout after 30 seconds
     * macs don't set timeout until 1000 ms
     */
    root.setTimeout(function () {
        /* some pages don't have timeouts defined */
        if (typeof (timeOutURL) !== "undefined") {
            if (timeOutURL.length > 0) {
                resetUrl = timeOutURL.replace(/expire$/, "resettimeout");
                if (totalTimeoutMilliseconds !== null) {
                    root.clearTimeout(timeoutWarningID);
                    root.clearTimeout(timeoutID);
                    
                    timeoutIntervalId =
                            root.setInterval(resetTimeout /* defined below */,
                                    root.warningTimeoutMilliseconds);
                }
            }
        }
    }, 30000);

    var resetTimeout = function () {
        xhr("GET", resetUrl)
                .success(function (msg) {
                    /* do nothing */
                })
                .error(function (xhr, errMsg, exception) {
                    alert("failed to reset timeout");
                    /* error; fallback to delivered method */
                    (root.setupTimeout || root.setTimeout2)();
                });
    };
}(window));

A special "shout out" to Todd Motto for his Standalone Ajax/XHR JavaScript micro-library which is embedded (albeit modified) in the JavaScript above.

HOWTO: Generate GUID from PeopleCode

A few months ago I demonstrated a handful of ways to Base64 encode strings — none of them were delivered. That post generated some outstanding feedback. Customers, consultants, and Oracle employees pointed me at several other alternatives, including the delivered Pluggable Encryption technique documented in PeopleBooks. I hope this post generates the same amount of discussion.

First, why would a PeopleSoft developer generate a GUID? My motivation is a database cache. I have a transaction that inserts information into a cache Record and an IScript that reads values from that cache. Rather than pass transaction keys to the IScript, I just pass a GUID that identifies the transaction's row in the cache. Besides decoupling the IScript from a transaction, it provides a bit of security through obfuscation (see OWASP Top 10 2007-Insecure Direct Object Reference)

Now, how to generate a GUID from PeopleCode... PeopleBooks does not list any GUID generation functions, so the next place to look for this functionality is in related technologies accessible to PeopleCode. For example, the Oracle database provides the SYS_GUID function for generating GUID's in the RAW. Here is the SYS_GUID function in action:

Local string &guid;
SQLExec("SELECT RAWTOHEX(SYS_GUID()) FROM PS_INSTALLATION", &guid);
MessageBox(0, "", 0, 0, "GUID from DB: " | &guid);

If you are just looking for a random string, then read no further. If you want a formatted GUID, then you will need to add the dashes yourself. Microsoft SQL Server has a similar function that actually returns a fully formatted plain text GUID.

The problem with these SQL alternatives is that they are database specific. I'm not going to complain about a user taking full advantage of the database's features. But, if there is an alternative that may reduce future maintenance costs (like the cost of swtiching from one database to another), then I'll consider the low cost alternative.

Since all PeopleSoft application servers run Java, we can use the JRE's GUID methods to generate a GUID. If you are on PeopleTools 8.49 with Java 1.5, then this short PeopleCode snippet will give you a fully formatted GUID:

GetJavaClass("java.util.UUID").randomUUID().toString();

On my laptop, the code above generated d65ca460-fc93-4420-a889-8b36311ee4a0.

What if you are using an older version of PeopleTools (prior to 8.49)? The Apache commons id project has a UUID Java class that is similar to the delivered Java 1.5 UUID class. For more information about Java GUID generation, see this java.util.UUID mini-FAQ.

Who knows, if you dig through your application's PeopleCode, you might find an undocumented method for generating GUID's ;)

Base64 Encoding with Pluggable Encryption

I dedicate this post to Chris Heller since he is the person that pointed me at PeopleSoft's pluggable encryption in his comments to my last post on Base64 Encoding for PeopleSoft. I had not considered PeopleSoft's pluggable encryption for base64 encoding. Thanks Chris!

Before we can base64 encode strings with PeopleSoft's Pluggable Encryption, we need to create an Algorithm Chain and an Encryption Profile. PeopleBooks does an excellent job of explaining each of these terms as well as telling how to create each of these components. Since PeopleSoft delivers the base64 encryption algorithm with the PSPETSSL encryption library, we can move right into defining the Algorithm Chain. To define the chain, navigate to PeopleTools > Security > Encryption > Algorithm Chain. Add the new value BASE64_ENCODE and add the following Algorithms in order:

1. PSUnicodeToAscii
2. base64_encode
3. PSAsciiToUnicode

Be sure to set the sequence number for each row (1-3). Save and navigate to PeopleTools > Security > Encryption > Encryption Profile. Add the new value BASE64_ENCODE. Specify the algorithm chain BASE64_ENCODE and save. We can now test this pluggable encryption profile with a little PeopleCode:

Local object &crypto = CreateObject("Crypt");
&crypto.Open("BASE64_ENCODE");
&crypto.UpdateData("Hello World");
MessageBox(0, "", 0, 0, "Encrypted: " | &crypto.Result);

And, the result should be: SGVsbG8gV29ybGQ=. I am sure you will all agree that this solution is much simpler than the ugly Java Reflection I previously demonstrated. Furthermore, this method is well documented in PeopleBooks and supported by PeopleSoft.

If I am reading PeopleBooks right, Pluggable Encryption only works with ASCII text. That is why we have to use the PSUnicodeToAscii and PSAsciiToUnicode algorithms in our algorithm chain. What this means is that we still need to use an alternative for base64 encoding binary data, a requirement when embedding binary data in XML documents.

PeopleSoft as a Password Authentication "Ticket" Server

My post Generating an AuthToken for SwitchUser demonstrates how to acquire and expire PeopleSoft authentication tokens. Using this approach, you could hook any custom application into the PeopleSoft security model, allowing PeopleSoft to manage security for many of your custom enterprise applications. Continuous token (ticket) validation could be implemented through a very simple web service that calls SwitchUser and returns the result. If SwitchUser returns true, then the token is valid.

Really, if you are interested in a centeralized, integrated security solution, then you should speak with your Oracle rep about Oracle's Identity Management Suite.

Generating an AuthToken for SwitchUser

As the name implies, the PeopleCode SwitchUser function allows developers to switch the logged in Operator ID from one user to another. For security reasons, you can only switch identities if you either have another user's operator ID and password or another user's valid authentication token (AuthToken). While I'm sure there are numerous uses for this function, here are my top two:

• Presenting a sign on Pagelet to a GUEST user
• Switching the runtime context of Integration Broker PeopleCode

In both of these scenarios, PeopleCode is already running as one user, but you need to switch the runtime context to a different user. For example, if we build a web service that exposes Approval Workflow Engine (AWE) approvals, we must authenticate the caller to ensure the caller has access to a specific approval.

The PeopleCode SwitchUser function takes four parameters. If you use the first two parameters, UserID and Password, then you don't use the third. Likewise, if you use the third parameter, AuthToken, then you don't use the first and second. They are mutually exclusive. The fourth parameter is irrelevant for this discussion. Since the first two parameters are self explanatory, the remainder of this discussion will focus on the third parameter, the AuthToken.

Let's further consider the AWE example. Here is the scenario:

Managers want to approve AWE transactions from their mobile devices (BlackBerry, iPhone, etc). PeopleSoft, however, does not support mobile browsers. One method to enable mobile access is to create a stand alone web application that communicates with PeopleSoft using web services. The initial page for this web application will prompt the user for a PeopleSoft user name and password. The second page of this web application will display information about an approval and provide the manager with action buttons to approve, deny, or push back the transaction. When the manager selects one of the action buttons, the web application will use web services to update the PeopleSoft AWE transaction.

The process flow in this scenario requires the web application to call at least two PeopleSoft web services. Since web services are stateless, we need to authenticate the user on each call. Because these web service calls span multiple request/response cycles, the web application will need to store that authentication information between mobile client requests, making session variables the logical place to store this information. At this point, the question we need to ask is, "What authentication information do we want to store in a session variable?" User name and password? As an alternative, we could store an AuthToken in a session variable and use that as a parameter to SwitchUser. Unlike user names and passwords, authentication tokens can be invalidated and are subject to configurable expiration rules.

How do you generate an AuthToken? Here is the method I use: I create an HTTP connection to my PeopleSoft server's sign on URL and then parse the returned cookies. Here is an example that uses Java and Jakarta Commons HttpClient:

HttpClient client = new HttpClient();

// Posting to the PS login URL
PostMethod post = new PostMethod("http://my.ps-server.com/psp/hrms/?cmd=login");
post.addParameter("userid", username);
post.addParameter("pwd", password);

// expect redirect response code
if(client.executeMethod(post) != 302) {
    throw new Exception("Expected a redirect response code.");
}

Cookie[] cookies = client.getState().getCookies();
Cookie pstokenCookie = null;
String pstoken = null;

for (int cookieIdx = 0; cookieIdx < cookies.length; cookieIdx++) {
    Cookie cookie = cookies[cookieIdx];
    if (cookie.getName().equals("PS_TOKEN") && 
        cookie.getDomain().equals(".ps-server.com")) {
        pstoken = cookie.getValue();
        pstokenCookie = cookie;
    }
}

if (pstoken == null) {
    throw new Exception("Ack! Didn't find PS_TOKEN cookie");
}

With my AuthToken (PS_TOKEN) identified, I can store it in a session variable, pass it along to Integration Broker, and then invalidate it when the mobile user logs out. Here is some sample code that demonstrates how to invalidate an AuthToken:

HttpClient client = new HttpClient();

client.getState().addCookie(pstokenCookie);

GetMethod get = new GetMethod("http://my.ps-server.com/psp/hrms/?cmd=logout");

int httpResponseCode = client.executeMethod(get);
// TODO: validate response code

Desktop Integrated Signon

Several months ago I had the opportunity to configure a PeopleSoft system to "trust" users' desktop credentials. Some would call this single signon or even Desktop Integrated Signon. Implementing desktop integrated signon requires some configuration and a small amount of development. The process looks like this:

1. Download the JCIFS NtlmHttpFilter,


2. Modify the filter to pass the desktop user name to the app server as a request header (compile and deploy included, of course),


3. Write some signon PeopleCode,


4. Enable public access,


5. Enable signon PeopleCode, and


6. Configure your web server to use your new filter (see the JCIFS NtlmHttpFilter documentation for configuration details as details will differ depending on your environment).

After downloading the filter and filter source code, open the NtlmHttpServletRequest and implement the getHeader and getHeaderNames overrides with the following code.

    public String getHeader(String name) {

        if(name.equals("XX_REMOTE_USER") {
            return getRemoteUser();
        } else {
            HttpServletRequest req = (HttpServletRequest)this.getRequest();
            return req.getHeader(name);
        }
        
    }
    public Enumeration getHeaderNames() {
        Vector headers = new Vector();
        HttpServletRequest req = (HttpServletRequest)this.getRequest();

        for (Enumeration e = req.getHeaderNames() ; e.hasMoreElements() ;) {
            headers.add(e.nextElement());
        }

        headers.add("XX_REMOTE_USER");
        return headers.elements();
    }

Next, put the following PeopleCode in a FUNCLIB:

Function WWW_NTLM_AUTHENTICATE()
   Local string &userName = %Request.GetHeader("XX_REMOTE_USER");
   Local number &foundSlash = Find("/", &userName);

   REM ** remove the NT/AD domain;
   If(&foundSlash > 0) Then
      &userName = Substring(&userName, &foundSlash + 1, Len(&userName));
   Else
      &foundSlash = Find("\", &username);
      If(&foundSlash > 0) Then
         &userName = Substring(&userName, &foundSlash + 1, Len(&userName));
      Else
   End-If;

   If(Len(&userName) > 0) Then
      SetAuthenticationResult(True, &userName);
   Else
      SetAuthenticationResult(False, &userName, "Web server authentication failure");
   End-If;
End-Function;

Like I said, it has been a few months since I wrote this code, and, unfortunately, I'm typing it here from memory. Please correct any mistakes I've made. Refer to PeopleBooks for enabling signon PeopleCode and enabling public access. Both are documented in the Security Administration PeopleBook.

A couple of issues I've found with this approach:

• If you are using Enterprise Portal and want to allow desktop integrated signon to both the portal and to the content provider apps, then you will need to further customize the filter to skip NTLM on your content provider web servers when the client is the portal server. Otherwise, the NtlmHttpFilter will not allow portal to access those web servers (this only affects homepage creation when you have pagelets that come from a content provider). If you only access your PeopleSoft systems through Enterprise Portal, then this is not an issue. Likewise, if you are configuring this solution on your PeopleSoft applications and you do not have Enterprise Portal, then this is not an issue.


• In this scenario, your app server trusts the security information provided by the web server, bypassing the app server's standard authentication routine. This may pose a security threat if users can gain access to your app server. To mitigate this risk, you may want to either hide your app server behind a firewall or perform additional validation/authentication (digitally encrypt the user ID request header on the web server with a certificate and decrypt it on the app server, pass the NTLM authentication token on to the app server and validate it again, etc).


• Since this solution requires your web server to trust your desktop, make sure your organization has a strong password policy forcing strong passwords. If you use a desktop integrated sign on solution, then any user that can gain access to a desktop by cracking a password can also gain access to your Enterprise applications. As an alternative to passwords, consider key fobs.

If you would like to allow administrators to log in as someone other than their desktop user (psadmin, for example), then you can add an "if" test to your signon PeopleCode that compares %SignonUserId to the public user name. If the user name is the same as your public user name, then log the user into the application as the user given by the web server. Otherwise, return from this function and allow the standard signon processing to authenticate the user.

Network Enabling Technologies

Besides my OpenWorld presentation on Wednesday, I'm also staffing demo pod 15 Monday, Tuesday, and Thursday. Today, while discussing PeopleTools with our customers at pod 15, a brilliant gentleman asked me, "How can I encrypt and digitally sign e-mails sent by the PeopleSoft process scheduler and the workflow engine?" My first answer? "Hmmm..." My first action? Turn to legendary Chris Heller, who happened to be standing near me, to ask him what he thought. The three of us, along with my pod mate Rahul, discussed some options and came up with the following ideas:

• If your SMTP server can be configured to do so, then have it digitally sign and encrypt your e-mails.


• If your SMTP server can't handle this task, then setup a secure e-mail relay between PeopleSoft and your SMTP server for the purpose of encrypting and signing e-mails.

This question reminded me of another networking related enabling solution. This problem and solution relate to Integration Broker's proxy settings. If your Integration Broker resides behind a proxy server and you have configured Integration Broker to use that proxy server, then you may have noticed that Integration Broker will send all requests through your proxy server. This is good, if the request target resides outside your firewall. This may not be good if the requested resource is inside your firewall. The problem is caused by the fact that Integration Broker cannot be configured to bypass its proxy server for specific hosts. If you find yourself in this situation, then here are a couple of solutions:

• Configure your firewall proxy server to be an Intercepting Proxy. From a PeopleSoft configuration perspective, this solution is the easiest because it allows you to ignore the proxy issue.


• Use a forwarding proxy server. Apache's mod_proxy is the first that comes to mind. If you use a forwarding proxy, then be sure to secure it. The last thing you want is for your forwarding proxy to become an open proxy.

Another option is to configure your proxy server to connect to both internal and external sites. I do not recommend this for a couple of reasons:

1. You may inadvertently make a path for other, external programs to access your internal servers.


2. You unnecessarily increase the amount of traffic your firewall proxy server has to handle.

Before choosing a solution to either of these network related issues, be sure to discuss your options with your network security staff.