Single Sign-On (SSO) to PeopleSoft using Reverse Proxy Setup

PeopleSoft tools technology does not natively support an identity federation protocol such as SAML for interacting with authentication and authorization services for single sign-on. Hence it has become a common practice with customers to implement single sign-on to PeopleSoft applications using Reverse Proxy configuration.This article explains in detail about this design approach.

Sequence diagram explaining sign-on process in reverse proxy configuration,


  1. PeopleSoft resources (URL) is exposed to end users via a proxy. When user requests a page, Proxy server intercepts and check if the user has been authenticated.
  2. If they have not been, then sign-on sequence is enforced.
  3. Proxy will redirect the user to the SSO login page
  4. User to provide their SSO credentials
  5. Proxy to invoke identity authentication service with user credentials
  6. Authentication to process request and respond with success or failure object
  7. If authenticated, then a session cookie is set on the client browser to manage specific session
  8. Proxy to invoke authorization service to check if user is allowed to access requested resource
  9. Authorization service will then return a success or failure.
  10. If successful proxy to access authorized resource (PeopleSoft). At this stage, proxy to pass user’s identity/authorization related attributes to PeopleSoft (typically via header parameters).
  11. Peoplesoft is configured to trust the authenticated credentials, map it to a unique Operator ID in PS, skip default sign-on process and respond to proxy with requested resource.
  12. Proxy passes response to the end user’s browser.

As explained above most activities in the sign-on sequence occurs outside PeopleSoft and the configuration may vary depending on the authentication and authorization services of the identity solution.

Once the reverse proxy setup is completed to invoke(or redirect) users to PeopleSoft with forwarded header parameters, final step of the authentication process that happens in PeopleSoft typically requires following build and configuration steps,

  • Create a FUNCLIB Peoplecode program to retrieve the forwarded header parameter, map it to a unique Operator ID in PS and authenticate user
Sample FUNCLIB PeoplCode function
Local string &userID;
&userID = %Request.GetHeader("X-PX-Shib-Staff-ID");
SetAuthenticationResult( True, &userID, "", False);
/* Assuming header parameter passed in PS Operator Id*/
  • Update ‘Signon PeopleCode’ configuration page to enable new FUNCLIB peoplecode


  • Create a new user profile e.g. SSO and associate a password with it but DO NOT assign any roles or permission to it
  • Update ‘Web Profile’ configuration to allow public access to the user profile created above


Note: After completing configuration steps in PeopleSoft, application and web servers needs to be bounced for changes to take effect.

Design considerations while implementing SSO to PeopleSoft,

  • Timeout settings due to inactivity needs to b synchronized between PS and SSO
  • Handling of ‘logout’ from PS. Default ‘logout’ action takes user to PS sign-on page, this link should either be disabled or updated to redirect user to SSO logout page.
  • Default PS Sign-in page can also be replaced to redirect users to SSO login page, just to cover scenarios where user inadvertently land in PS sign-in page.

PS: Feel free to share you experiences with implementing SSO to PeopleSoft, as this challenge is handled with varying design at customer sites.


15 thoughts on “Single Sign-On (SSO) to PeopleSoft using Reverse Proxy Setup

  1. Can you please provide more details? We would like to implement Okta for our Supplier Portal in Peoplesoft FS 8.56.


  2. Great article Thanks, Oracle EBS SSO Integrate with AD, Azure , Apache directory ….. without having OAM , OID work stuff? Yes, Here is the solution.


  3. Hi PeopleSoft SSO configuration, do anyone have step-by-step document can you please send it across?


  4. Hi Roland, If my memory serves right, SSO user profile is required to enable the ‘Public Access’ setting in the web profile. Public access is enabled to ensure the ‘Sign-on’ page is not shown when any deep link is accessed within peoplesoft. While the custom Sign-on peoplecode is responsible to set the correct user account based on the header information passed from SSO.


  5. Hi Logesh, thanks for this article. What I find, is that it a bit unclear why the SSO user profile is required. It doesn’t appear that the Proxy logs in with the SSO account, but rather the proxy is just setting the HEADER variable… Is that correct? Could you elaborate on if the proxy needs to login with the SSO user profile that is created, or if there is some form of mapping between the SSO account and the PeopleCode?


  6. Hi Mohammed and Logesh,

    I too wanted some urgent details on PeopleSoft SSO Integration in ADFS.
    Any update on this would be highly appreciated.

    Thanks in advance!


Comments are closed.