Connect sign-in

Sign-in needs three registrations in your identity provider and one setup in PeopleSoft. When they’re done, a user who opens the chat page gets a token for the Assistant service, and the service can exchange it for a token that PeopleSoft accepts, as Acting as the user describes.

Register with your identity provider

• The chat page is a single-page application, registered as a public client. It signs in with the authorization code flow and PKCE, and its redirect URI is the chat page’s URL, without parameters.
• The Assistant service is an API, with the identifier api://aipeoplesoft-assistant and a scope, such as chat, that the chat page requests. It’s also a confidential client, with a secret or certificate, which the service uses to exchange tokens.
• PeopleSoft is an API, with the identifier api://peoplesoft-hr, a scope, such as api, and a claim that identifies the PeopleSoft user.

The chat page’s URL is the chat component’s content URL, such as https://hr.example.com/psc/ps/EMPLOYEE/HRMS/c/ZZ_ASSISTANT.ZZ_AI_ASSISTANT.GBL. You create the component in Add the chat page, so register the URL now and create the component to match.

Allow token exchange

The Assistant service’s client must be allowed to exchange a user’s token for a PeopleSoft token. How depends on your identity provider:

• With the OAuth 2.0 Token Exchange grant (RFC 8693), enable the grant for the service’s client, and allow it to request tokens for api://peoplesoft-hr.
• With Microsoft Entra ID’s on-behalf-of flow, give the service’s app permission to call the PeopleSoft API, and grant admin consent.

Either way, the exchanged token is for the same user, and carries only the PeopleSoft scope.

Choose the user claim

PeopleSoft maps each token to a PeopleSoft user ID through one claim. Most organizations use the user’s sign-in name, with PeopleSoft user IDs that match it. If yours don’t match, add a claim that carries the PeopleSoft user ID itself, from your directory.

Set PeopleSoft up to accept the tokens

1. Create a service application. At PeopleTools > Security > OAuth2 Administration > Create OAuth2 Service Apps, choose Resource Only, and enter your identity provider’s details as the page asks for them.

2. Configure the gateway. Add the OAuth 2.0 settings that the REST listening connector uses to validate tokens to the Integration Broker gateway’s integration.properties file.

3. Map the claim to user IDs, using the claim you chose.

The fields differ between PeopleTools releases and identity providers. Oracle’s Service Application - REST Provider documentation covers them for PeopleTools 8.63. You’ll require OAuth 2.0 on the application service itself in the next step.

Check a token

Get a token for a test user for api://peoplesoft-hr, with your identity provider’s own tools, and check its claims on your own machine:

python3 - "$TOKEN" <<'EOF'
import base64, json, sys
payload = sys.argv[1].split(".")[1]
payload += "=" * (-len(payload) % 4)
claims = json.loads(base64.urlsafe_b64decode(payload))
print(json.dumps(claims, indent=2))
EOF

Check that:

• iss is your identity provider, and aud is api://peoplesoft-hr.
• The user claim holds the test user’s PeopleSoft user ID, or a value you’ve mapped to it.
• exp is in the future. Access tokens usually expire within an hour.

Keep tokens off the web

An access token lets anyone who holds it act as the user until it expires. Decode tokens locally, as above, and never paste them into online decoders or share them in tickets.