Setting Up Two-Factor Authentication in PeopleSoft (Part 2)

In this part of the tutorial, I have expanded on what was done in the first part by adding additional logic to the Signon PeopleCode and adding more functionality to the 2FA page.  I went ahead and created an app designer project that contains all of the objects and code that serves as a proof-of-concept of how the 2FA process works as a whole.  The only functionality that this project does not contain is the ability to send SMS messages. You should be able to plug and play this project into your environment.

I tried my best to explain what all is going on in the comments in the code, but here some important features that I would like to touch on:

  • The 2FA process is enforced only on users that have the Peoplesoft Administrator role that do not possess a valid 2FA cookie in their browser. The code can easily be changed to challenge users for 2FA with more or different roles.
  • The cookie name that gets written to the user’s browser will be in the form of PSM_2FA_TOKEN_%USERID_%DBNAME

The %DBNAME part of the cookie’s name allows the user to poses tokens for multiple environments if they wish. This assumes that this 2FA process is implemented on multiple environments.

The %USERID part of the cookie’s name is used to accommodate for multiple users that might be sharing the same browser.

  • The cookie that is written to the user’s browser has a value that contains a hash of the user’s %USERID, %IP_ADDRESS, and %DBNAME.

This is what will make the cookie only valid for a specific user logging into a specific environment from a specific location.  So for example, assume a user gets a 2FA token on their laptop at work to get into the CSPRD environment. The user goes home with their laptop and tries to use the previously obtained token to bypass 2FA from their home network when logging into the CSPRD environment. The user will be challenged for 2FA again since the token that they possess is only valid for their IP address at work.

Note: The details that I explained above are only really relevant if you use the “Remember This Device” functionality, otherwise the token will be deleted at the end of the session.  The “Remember This Device” functionality gives the user the option to not have to do 2FA on every login.  This functionality was provided for user experience purposes, but if you are looking to have a more secure solution, then do not provide this functionality to the users.

Below are the steps to get the project up and running.

UPDATE: It was discovered that this project has some compatibility issues for environments that are making use of fluid pages.  See the comments section for more details.

CLICK HERE to download the project. Unzip the file and import the project into app designer.

Login to PeopleSoft and add the following section to the Signon PeopleCode.

Sign On PeopleCode

Go to the web profile configuration and set the Signon Result Doc Page field to signonresultdocredirect.html.

Web Profile Configuration

Bounce the web and app servers and log  back into PeopleSoft.  You should see the following page.

Two-Factor Authentication Page

The email functionality will work if the SMTP settings are properly setup in your environment. The provided project does not include the necessary objects and code for the SMS functionality to work.  Nonetheless, you can select either delivery option. Click OK on the popup prompt.

Two-Factor Authentication Page

Since this is just a proof-of-concept, the application will automatically populate the code into the input box.  This is the same code that the user should receive to their email or cell phone. Once you are able to ensure that you can successfully send email and SMS messages, then the auto-populate functionality should be replaced with the user having to input the code themselves. You can check the Remember This Device box if you do not want to have to do this process again on subsequent logins.

Two-Factor Authentication Page

If you leave this box unchecked, then you will have to do this process again if you close the browser session and login again.  Clicking the OK button should take you to the homepage and grant you full access into the system.

Important Security Considerations:

While this project may serve as a solid proof-of-concept of how you can implement 2FA in your PeopleSoft application, there are some things that I would like to point out.  The first thing is that using email is not a very secure avenue to deliver the time sensitive codes.  This is because, much like username and password, a user’s email account is merely something the user knows (email address and password).  It is much more secure to deliver the time sensitive codes to a physical device that the user has like their cell phone or a security token (not demonstrated). The second thing is that using the “Remember This Device” functionality makes this 2FA solution less secure.  This is because if a “remembered” device gets stolen, then it will potentially allow for an impostor to gain unauthorized access to another user’s account with just their username and password.  It is much more secure to delete the 2FA token at the end of every session.  To delete the 2FA token at the end of every session, just add the following cookie rule to the web profile:

Delete 2FA Token On Logout



Sasank Vemana


This is great. I was thinking about something like this recently and you done a great job with a custom bolt on module.

I see that you are using SMTP for email. What are you using for sending the SMS? May be I missed reading something.

Thanks! Sasank


Once you’ve issued setauthenticationresult true, the user is authenticated, even if you redirect them to a custom page. At that point they can manually modify url in browser to go to another page, bypassing your 2fa. Or am I missing something?

Colton Fischer

When I did my testing with this project I did not find that the user could bypass the 2FA page in that manner. When you attempt to access a different URL from the 2FA page, the sign on PeopleCode fires again. The sign on PeopleCode sees that you do not have the 2FA token so it redirects you back to the 2FA page. Please let me know if your findings are different.


Signon peoplecode does not fire again. When you’re on the 2FA page, put the url for your default home in the browser’s address bar. signon code does not fire.

what version of PT are you on. We’re on pt8.55.06, and setauthenticaionresult() can no longer be used to redirect to specific page. Always redirects to home page no matter what url you use. Oracle told us that was by design.

Colton Fischer

I did my testing with this project on an 8.54.19 environment. When I pasted the homepage url (or any other PS url) into the browser at the 2FA page, the sign on PeopleCode would fire again and redirect me back to the 2FA page. I confirmed this by writing a row to the database when the 2FA sign on PeopleCode function would fire. An additional row would show up when I tried to do this. I specifically tested for this scenario when I developed this solution because it would not be very secure if the user could bypass the 2FA in this manner. It is possible that the newer tools release could’ve caused this to behave differently.

UPDATE: I decided to download the new CS PUM image with Tools 8.55.06 and see if I experienced the same issues as you. It turns out that the newer Tools version does indeed cause some issues for this project to work securely.

Here is what I found:

I can bypass the 2FA page by inserting a URL to a fluid page in the address bar. If I paste in a non-fluid page URL, then I am redirected back to the 2FA page. It seems that if I bypass the 2FA page by pasting a fluid page URL, then as soon as I attempt to access a non-fluid page from there, I am redirected to the 2FA page. So it seems that something with fluid is making this act strange. I will update the post with this information. Thank you Garth for bringing this to my attention.

As far as using the setauthenticationresult function in the sign on PeopleCode to redirect to a specific page in the 8.55.06 environment, I had no issues accomplishing this. Are you sure that you had the “Sign On Result Doc Page” set to “signonresultdocredirect.html” on the web profile’s look and feel tab?

Since you are already on 8.55, then I would suggest enforcing 2FA on your users at the component level with the use of the event mapping framework. One of Oracle’s intentions of the event mapping framework was for customers to use it to deploy 2FA. Enforcing 2FA at the component level will provide a much better user experience versus enforcing the 2FA at the login. However, this method will not be helpful if your requirement is to enforce 2FA at the login.

Colton Fischer

After activating the new sign on PeopleCode, I always bounce all of my app and web servers and clear my app/web cache. I believe that only an app server bounce is required for new sign on PeopleCode to work, but I just do it all for good measure. If you have already done this and it still seems that the sign on PeopleCode is not firing, then try placing a sqlexec statement in the sign on PeopleCode and writing to a temp table. This will ensure whether or not the code is firing. Also, you will only get redirected for 2FA if you are logging in as a user that has the “Peoplesoft Administrator” role on their user profile. Please let me know if any of this has resolved your issue.

AB Krishna

Great wealth of information - I appreciate for the explanation and providing all the detailed information We are testing 2 factor authentication on HCM 9.2 with PT 8.56.01 on SQL server 2014. (Fluid home page) It looks like we are having issue - looks like coming from Peoplesoft not able to handle redirect properly and both for PS and VP1 users it is failing with “ signonresultdocrredirect.html file does not exist in your web server” I have logged a case with GSC - Oracle support It appears that the returned value for the url does not seems to be complete - is it the Reason for failure ?????? Pasted small part of the trace file is pasted below -(but when I capture and write the URL value to a log file - that is a good URL and I can paste that URL with other user successfully logged and it provides the custom page and that sends the email nicely - of course all from your imported project . ) I am wondering anybody else has the similar issue or anybody else was successful with PT 8.56.01 ———————————————————————————- PSAPPSRV.4256 (128) 1-488674 08.29.57 0.000000 21: Return GenerateComponentContentURL(“EMPLOYEE”, “HRMS”, MenuName.PSM_CUSTOM, “GBL”, Component.PSM_2FA, “”, “”); PSAPPSRV.4256 (128) 1-488675 08.29.57 0.000000 return stack: PSAPPSRV.4256 (128) 1-488676 08.29.57 0.000000 UUUUUUUUUUU:ResultDoc PSAPPSRV.4256 (128) 1-488677 08.29.57 0.000000 Str[12]=GetResultDoc PSAPPSRV.4256 (128) 1-488678 08.29.57 0.000000 return value: PSAPPSRV.4256 (128) 1-488679 08.29.57 0.000000 Str[94]=http://gdcustst145.corp.towera PSAPPSRV.4256 (128) 1-488680 08.29.57 0.000000 16: Local string &URL = &obj.GetResultDoc();

AB Krishna

The error I get during log-in process for (PS and VP1 users )
UnAuthorized Token has been detected by the System. Please signon with your User ID and Password

John S

I’m running tools 8.55.17 and when I login I get the custom page, but the PeopleCode doesn’t seem to be firing. If I select email or text nothing pops up. If I login first and navigate to the 2FA page via menu it does work, so not sure what the difference is. Also I am able to specify a different page in the address bar and get there, but I think that’s because no PeopleCode. Any thoughts on what may cause this?

Colton Fischer

Hi John. The issue with the PeopleCode not firing behind the buttons on the custom page might be occurring from the page not being served properly from the web server. If you open up the developer tools console in your web browser, are you seeing “403 Forbidden” messages? I recall this happening to me before and the 403’s caused the PeopleCode behind the page’s button’s to not fire. I believe a web server bounce and cache clear resolved the issue for me.

As for being able to bypass the custom page after sign in by pasting in a different URL in the address bar, this seems to be an issue that surfaced in the 8.55 PeopleTools. The issue seems to be applicable for Fluid-enabled environments. You can read the comment exchange from Garth and I in the above comments for more details on this. Is the URL that you are pasting into the address bar and URL to a Fluid component or content reference? Are you able to bypass the custom page by pasting in a URL to a non-Fluid component or content reference?

Kim O'Connor

Hey Colton, I actually sent a message earlier and I found some information basically answering that message. I also see a post in the stream from my colleague AB Krishna. It is appears that he may have a different question. But I see that the companies using 8.55 tools are experiencing a similar problem that we noticed; which is, if a user has successfully logged into the PSoft login page and gets redirected to the 2FA page they are able to paste a URL up in the browser and get out of the 2FA page. I am curious as to whether or not it will make a difference if the pages we use for self-service are only classic or classic plus pages. Will this prevent someone from getting too far into the application. We are using the Fluid Homepage but maybe if the other permissions are for classic pages maybe that is all the further they could get if they try to bypass. Just wondering if you have seen any other results or if you have come up with anyways to block it. We are on 8.56.01

Colton Fischer

Hi Kim. Yes, unfortunately something with newer Tools releases has caused this solution to be insecure. My previous findings indicated that the insecurity only seemed to revolve around Fluid pages. I was never able to bypass the 2FA page when pasting in a URL to a Classic page. However, given that you are on such a new Tools version, I would not recommend that you use this solution. It does not seem that Oracle intends us to use the SetAuthenticationResult function’s ResultDoc parameter as a protection measure for application access (even though this technique seemed to work very well in older Tools).

In 8.55+ Tools, I recommend using Event Mapping to inject Component Pre-Build code to enforce 2FA at the Component-level rather than at login time. This technique may not be very feasible to adopt depending on your business requirements. Another (more challenging) option is to use a servlet filter to redirect users to perform 2FA when they request URL resources that require an additional authentication factor. More on servlet filters here.


Hi, Can you please show me the screenshot that has all 7 entries in the Signon PeopleCode page? I am primarily interested in the first line. Thank you.

Colton Fischer

Hello Yong. The first Signon PeopleCode entry is the delivered function for enforcing password controls.

Record: FUNCLIB_PWDCNTL Field: PWDCNTL Event: FieldChange Function: Password_Controls

Colton Fischer

I have the Enabled checkbox unchecked and the Exec. Auth Failed Checkbox checked. However, I would not advise for you to mimic what I have in my system if it is different than the way yours is currently configured. The technique demonstrated in this post does not rely on these values being set to a certain value.

Leave a comment

Your email address will not be published. Required fields are marked *