SSOGEN / PeopleSoft SAML SSO with a SAML 2.0 provider
Integration
PeopleSoft SAML SSO with a SAML 2.0 provider
SSOGEN is registered at your SAML identity provider as a service provider. PeopleSoft is registered in SSOGEN, so people sign in once.
A person opens PeopleSoft and is sent to SSOGEN. SSOGEN sends them on to the identity provider. It signs them in, and they come back to PeopleSoft through SSOGEN. The sign-in looks like the other apps that identity provider protects. People move between those apps and PeopleSoft without signing in again. SSOGEN is invisible to them on sign-in and sign-out. The PS_TOKEN weakness described on the PeopleSoft page is gone.
At the identity provider
Register SSOGEN as a service provider. If the provider takes a metadata file, use SSOGEN’s service provider metadata address. If not, enter the values. The Shibboleth identity provider calls this step configuring the service provider. The general requirements are on the SAML provider page.
| The provider asks for | Value |
|---|---|
| Entity ID | https://acme.ssogen.ai/saml/sp/partner |
| Assertion consumer service URL (HTTP-POST) | https://acme.ssogen.ai/saml/sp/partner/acs |
| Service provider metadata | https://acme.ssogen.ai/saml/sp/partner/metadata |
The provider must sign the assertion and send a stable NameID. Send the PeopleSoft user ID as an attribute or as the NameID.
In SSOGEN
Add the provider as a SAML identity provider with the connection ID partner. Import its metadata: one provider’s metadata, not a federation file. Then map the attributes, validate, test, try and activate it (Add a SAML identity provider in SSOGEN).
Then register PeopleSoft as an application. SSOGEN names people partner_<NameID>, which is not a PeopleSoft user ID. So on the Mapping step, keep the attribute that holds the PeopleSoft user ID as a custom attribute. Then set Identify the person by to it.
In PeopleSoft
Run the tool and finish the PeopleSoft setting as on the PeopleSoft page. Each person needs a PeopleSoft user profile with the user ID the provider sends.
What people see
Jane Doe opens https://hr.acme.example/psp/ps/?cmd=start. She signs in at her provider’s page and lands on the PeopleSoft home page.
If it does not work
| Symptom | What to do |
|---|---|
| Everyone lands as the public access user | The user name PeopleSoft reads is not the one SSOGEN sends. Check Identify the person by in SSOGEN and the custom attribute that holds the PeopleSoft user ID from the provider. |
| Sign-in works but PeopleSoft still shows its own sign-in page | The sign-on PeopleCode function is not enabled, or the public access user is not set in the web profile. |
| Integration Gateway calls stop | A service path was protected. Run reg again with -unprotect_path=/PSIGW. |
Sign-out
The PeopleSoft Sign out link ends the PeopleSoft session only. The Web Agent’s sign-out address, https://hr.acme.example/ssogen/logout, ends the web server session. For shared computers, see sign-out on every page.