During a PeopleSoft SSO project using OAM, we came across an issue that there was not a lot of information on. When using PeopleSoft at our customer, they need to allow access for a particular group of users directly into PeopleSoft for administration / testing. This is normally fine and would just add the users to the enterprise store or could filter access to the server via source IP addresses. But, these were internal accounts in PeopleSoft that could not be added to the enterprise directory so there had to be a default login URL that was not protected by OAM and the users were spread across the globe with different IP ranges.
The problem is, with the SSO configuration in PeopleSoft,if you know the URL structure, you can just direct browse without being prompted to login. Additionally, with web profile / header editing tools you can impersonate any user in PeopleSoft by sending in the SSO headers PeopleSoft uses. The information below goes through the issue that was found with the default SSO configuration along with some additional checks that can be configured in the integration to ensure PeopleSoft and its information are protected.
When configuring OAM login to PeopleSoft, it was found that the default public access / virtual user can be used to login to PeopleSoft (which in this case didn’t have any rights so could not see anything):
But, by using an extension like ModifyHeaders in Firefox, you can add the SSO headers to the browser and be directed into PeopleSoft as that user:
The OAMSSO_AUTHENTICATION function in the FUNCLIB_LDAP record of Peoplecode is what defines the SSO authentication process, and by default does not include any checks to validate the SSO process or to fail in the event it is not a valid SSO session. This is only configured to look for the SSO header, and if it is not there, just uses the default virtual user account specified to login
To fix this, add some verification checks around the login process to the FUNCLIB_LDAP record and fail back to non-authenticated session the request does not meet the OAM SSO verification checks.
First, add a function to write an OAM access log so can log all the activity. This is more just for logging the OAM processes and is not part of the process. It is helpful to have this for troubleshooting and seeing the login activity.
Once this is added to the code, you can now add the OAM verification check. The example below looks for the OAM_REMOTE_USER, PS_SSO_UID (SSO header), and OAM_LAST_REAUTHENTICATION_TIME headers to do a basic check for other OAM default headers for verifying the session. This could be updated to add additional checks, but this is just an example.
Then, once this is added, you can update the default OAMSSO_AUTHENTICATION function to do the check, and if it fails, default to redirect to the main authentication page.
The important piece here is the ‘SetAuthenticationResult( False, Upper(&userID), &redirectURL, False)’ section when the process does not meet the verification check. By default, the authentication result is set to True in the original code with no other checks done. By setting this to False, and setting the &redirectURL, it will redirect to the default login page specified in the redirect page (see API documentation for SetAuthenticationResult.)
Once this is updated and saved, you need to restart the application server.
Now when accessing the main page directly (outside of OAM configuration), you will be directed to the login page which uses the default login configuration in PeopleSoft.
Now you can support OAM SSO along with default internal authentication for administrator / power user access if required.