How to Set Up a Redirection Servlet Filter in PeopleSoft

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.

I previously demonstrated the redirection capabilities of servlet filters with the enforcement of two-factor authentication (2FA). In that demonstration, users that did not present a valid 2FA token when they attempted to access certain resources would be redirected to the 2FA page.

I am going to provide a proof-of-concept example of how to do the redirection portion.  What this example will be doing is checking if a user has a valid token when they attempt to access a resource in the PeopleSoft application where the URL contains “/psc/”.  If the user does not present a valid token, then the user will be redirected to a static html page where they can get a valid token.  Once the user obtains the token from the html page, the user will be redirected back to the resource that they were originally trying to access.  If the user loses or doesn’t present this token when they try to access any “/psc/” resources, then they will be redirected to get a new token.  Note: A “valid” token in this example is merely a correctly named token.  The actual value of the token is disregarded in this example for simplicity.

---

CLICK HERE to download the project.

Extract the zip and you should see the following files:

Take the folder named “custom” and place it in the following directory:

%PS_CFG_HOME%\webserv\*your_domain_name*\applications\peoplesoft\PORTAL.war\WEB-INF\classes\com\peoplesoft\pt

Take the folder named “RedirectFilter” and place it in the following directory:

%PS_HOME%\sdk

Take the file named “SetToken.html” and place it in the following directory:

%PS_CFG_HOME%\webserv\*your_domain_name*\applications\peoplesoft\PORTAL.war

Copy the text from the file named “Paste this into webxml” and paste the text into your web.xml file.  The web.xml file is located in the following directory:

%PS_CFG_HOME%\webserv\*your_domain_name*\applications\peoplesoft\PORTAL.war\WEB-INF

Depending on how modified your web.xml file is, you might want to paste the text in a different part than me, but I pasted it in as the first filter (just before the “psfilter”).

You will need to bounce the web server after you perform all of these steps.

After bouncing the web server, navigate to the SetToken.html file in your web browser.  You should be prompted to input a token name.  You need to input the same name that  was specified in the param-value of the “TokenName” parameter in the web.xml.  As you see, I set the token name to “MY_TOKEN” in the xml that I provided.

So I will input the value “MY_TOKEN” into the prompt.

You will obtain the token after clicking OK on the prompt. You can check the cookies in your browser to see this.

You should be able to login and use your PeopleSoft application like you normally would.  If you delete the token from your browser, then the next “/psc/” resource that you try to load will redirect you to the SetToken page so that you can get the needed token.  The SetToken page should then redirect you back to the resource that you were trying to access.

---

This is essentially how I enforce 2FA in my PeopleSoft application.  The SetToken page is like the 2FA page where the user has to input a time sensitive code.  The “MY_TOKEN” cookie in the browser is the 2FA token that gets issued to users that successfully perform 2FA.  So the “MY_TOKEN” in the user’s browser signifies that the user has done 2FA for the session.  This proof-of-concept can also be applied to a slightly different context of single sign on or using a third party to authenticate PeopleSoft users.  In this context, the SetToken page will be the third-party login page that will authenticate the user.  The user gets the authentication token and takes it over to PeopleSoft and this servlet filter can verify that the token is legit and allow access accordingly.  An additional sign on PeopleCode function would also most likely be needed to achieve this sort of SSO functionality.

One more thing that I would like to touch on is how you can enforce the redirection for as many or few resource in the PeopleSoft application that you want. You can set the url-pattern in the web.xml to “/*”.  This will fire the filter for every request.  If you are interested in enforcing the redirection at specific PeopleSoft components, then you can check (In the Java code) if the resource that the user is attempting to access matches the MENU.COMPONENT of the component that you would like to protect.  You can also achieve this same redirection functionality by mapping application class PeopleCode to components that you would like to protect with the use of the event mapping framework.

If you would like to see how to implement another PeopleSoft-related servlet filter, then check out Kyle Benson’s ps-eat-cookies filter.  This is a great example of how to modify the response that your web server sends to the client’s machine.  If you are interested in learning more about how servlet filters work in PeopleSoft, then I highly recommend listening to this podcast episode about WebLogic filters.