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
Function FORWARDED_HEADER_AUTHENTICATION()
Local string &userID;
&userID = %Request.GetHeader("X-PX-Shib-Staff-ID");
SetAuthenticationResult( True, &userID, "", False);
/* Assuming header parameter passed in PS Operator Id*/
End-Function;

• 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.