Why Exclude PSFT Auth Tokens in Integration Broker?

Praj over at the PeopleSoft Wiki has a good explanation of how to Exclude PeopleSoft Authentication Token for a PeopleTools Integration Broker Service Operation.

Let’s expand on this and explore the benefits and pitfalls of running a service operation this way. First let’s just clarify the situation. Let’s imagine that you have 3 PeopleSoft products running:

• HCM (publishing system)
• Campus Solutions (subscribing / target system)
• Interaction Hub/Portal (subscribing / target system)

Your systems have the USER_PROFILE service operation setup to sync from HCM to both the Portal and Campus Solutions systems.

• When a user changes their password in HCM, some save-time component level code triggers a USER_PROFILE Service Operation from HCM to those subscribing nodes.
• The default configuration of Service Operations are to include the current users “authentication cookie” with the message.
• This makes the service operation publish from HCM to Campus Solutions as the user who was active during the save.
• The subscribing system(s) will invoke the subscription code as that publishing user. This is not ideal for many reasons which we will dive into later.

Let’s look at an example:

• User JDOE logs into HCM and changes his password.
• The USER_PROFILE service operation is triggered to both Campus Solutions and the Interaction Hub (portal).
  • That USER_PROFILE message is published with the new password information about JDOE in the actual XML.
  • The service operation is also published with the “authentication token” of JDOE since that was the active user when the operation was triggered.
• When the HCM publication contract tries to deliver that message to the Portal integration broker, the portal integration broker will:
  1. Determine if JDOE is valid user and is unlocked in the Portal database
  2. Determine if JDOE has the web service security to invoke the USER_PROFILE service operation in the portal database.

If checks #1 and #2 above pass, then the USER_PROFILE message is published and the subscribing system will process the message. Additionally, the portal application will actually invoke the Subscription Contract PeopleCode as JDOE. Therefore, if there is any row level security or Component Interfaces used then JDOE will need that security in the portal or the subscription contract will error out.

If checks #1 or #2 above fail, then the USER_PROFILE publication contract in HCM will error out with message like:

User JDOE not authorized to invoke service operation USER_PROFILE

There are many reasons why JDOE may not exist in the PORTAL so this could be valid but you still may want the message to be delivered to the portal. There is no delivered way to force this one message through as an exception.

Excluding the Authentication Token

So what happens when we exclude the PeopleSoft Authentication Token for the USER_PROFILE service operation?

• In our example above, the JDOE user token would NOT be sent to the subscribing Portal system.
• JDOE user profile does NOT have to exist in the target systems.
• JDOE does NOT need the USER_PROFILE web service security in the target system.
• HCM will publish the message as the “default user” which is setup in HCM on the node that represents the portal.
• As long as the “default user” passes the authentication checks the message will be published as that user.
• The subscribing system (portal) will have no record that JDOE actually made the change in HCM.
  • Of course, if the XML payload data contains the LASTUPDOPRID field it will be there but that is just part of the data and not really part of the security of the service operations.

Security Implications

In my opinion, running service operations with the Tokens excluded is more secure in most situations and also simplifies your security because you have to grant less web service security grants.

Let’s look specifically at the USER_PROFILE service operation. If you give all your user’s web service security to invoke the USER_PROFILE service operation, then you have many more vectors for attack on your user profiles. A bad actor could attempt to change user profiles by submitting XML to the target integration broker systems if they took control of an account with USER_PROFILE web service security. This could allow a bad actor to grant any role they want to any user. It could be giving himself an administrator role or giving another user Payroll Admin access to issue checks. The delivered subscription code for the USER_PROFILE does not do any sort of checks on the person making the change which can be identified by the token sent by the publishing system. It trusts whatever is coming over the wire. If someone spoofs a USER_PROFILE integration broker message as JDOE to your Campus Solutions gateway they could basically take control over any account since the subscription code just takes what is in the XML and commits it locally with straight SQL. So if the spoofed xml says “Lock out the CEO account” that will happen if they can get the XML accepted by the gateway. If the spoofed XML says “Create a new super user account xyz” then it will be created.

As you can see you really want to limit what user’s can access these web services. We all know that most people (even IT employees) are careless with their passwords.

Pros and Cons of Token Exclusion

So let’s look at the pro’s and con’s of excluding the tokens.

Pros of Excluding Authentication Tokens

• The end user triggering the service operations does not have to exist in all databases.
• The end user triggering the service operations does not have to have web service security in the target system.
• This simplifies your Web Service security permission lists to all but the ones used by the Default users.
  • Web services potentially expose all kinds of sensitive data updates and reads like security, personal data, setup tables, etc, etc.
  • The less number of user’s allowed to invoke most service operations the better.

Cons of Excluding Authentication Tokens

• The LASTUPDOPRID stamps on the target system will not be listed as JDOE but as {default_node_user_name} which could cause some confusion with auditing.

Node Default User Guidelines

The default user ID that you setup on the nodes should have the following characteristics:

• It should be a generic account that is NOT someone’s day to day account.
• The password should be extremely long and complicated. (If you can commit it to memory, it is too simple.)
• It should NOT have any PIA access as you do not want anyone actually logging in and using this account in a web browser. This means it should not have any iScript security which will prevent PIA access.
• It will need grants to any Web Services that you are running.
• It will need Component Interface grants for any CI’s that are invoked in Subscription contracts.
• It will need any Application Level Security (i.e. Row Level Security) that may be invoked by CI’s in the subscription code.
• You should have a different default user ids for each node in some common sense naming conventions like: IB_NODE_HCM_USER, IB_NODE_PORTAL_USER, ETC.
  • This will be a quick flag in audit reports that the data was updated by an Integration broker message and give you a quick indication of what system it came from.

Additional Reading

• Getting Integration Broker Code to Run as a Different User
• Exclude PeopleSoft Authentication Token
• How to Change Search Records in Component Interface