By default, service operations include the current user’s authentication cookie (PS_TOKEN) with the message. This means the subscribing system processes the message as the user who triggered the event. There are significant security and operational reasons to consider excluding this token.
How It Works By Default
Consider this scenario with three PeopleSoft systems:
- HCM (publishing system)
- Campus Solutions (subscribing system)
- Portal (subscribing system)
When user JDOE changes their password in HCM:
- The USER_PROFILE service operation triggers from HCM to both subscribers
- The message is published with JDOE’s authentication token
- The subscribing system validates that JDOE exists and has web service security
- If validation passes, the subscription code runs as JDOE
If JDOE doesn’t exist in the Portal database or doesn’t have the right web service security, the publication contract errors out:
User JDOE not authorized to invoke service operation USER_PROFILE
What Happens When You Exclude the Token
When you exclude the PeopleSoft Authentication Token for a service operation:
- The user’s token is NOT sent to the subscribing system
- The user profile does NOT have to exist in target systems
- The user does NOT need web service security in the target system
- The message is published as the “default user” configured on the node
- The subscribing system has no record that the specific user made the change (though LASTUPDOPRID may still be in the XML payload data)
Security Benefits
Running service operations with tokens excluded is more secure in most situations and simplifies your security because you grant fewer web service security grants.
Consider the USER_PROFILE service operation: if you give all users web service security to invoke it, you have many more vectors for attack. A bad actor who takes control of an account with USER_PROFILE web service security could submit XML to change user profiles, grant roles, or lock out accounts. The delivered subscription code trusts whatever comes over the wire and commits it with straight SQL.
You really want to limit what users can access sensitive web services like USER_PROFILE. The fewer users allowed to invoke most service operations, the better.
Pros and Cons
Pros of Excluding Authentication Tokens
- End users triggering service operations do not have to exist in all target databases
- End users do not need web service security in the target system
- Simplifies Web Service security permission lists
- Reduces attack surface for sensitive service operations
Cons of Excluding Authentication Tokens
- LASTUPDOPRID stamps on the target system will show the default node user name instead of the actual user, which could cause auditing confusion
Node Default User Guidelines
The default user ID on your nodes should follow these guidelines:
- It should be a generic account, NOT someone’s day-to-day account
- The password should be extremely long and complicated
- It should NOT have any PIA access (no iScript security) so no one can log in with this account in a web browser
- It will need grants to any Web Services that are being run
- It will need Component Interface grants for any CIs invoked in subscription contracts
- It will need any Application Level Security (row level security) that may be invoked by CIs in the subscription code
- Use different default user IDs for each node with common sense naming conventions like:
IB_NODE_HCM_USER, IB_NODE_PORTAL_USER
- This makes it immediately clear in audit reports that data was updated by an Integration Broker message and gives a quick indication of which source system