Properly Securing the ANONYMOUS IB Node

In PeopleTools, all integration broker (IB) service operations (a.k.a. Web Services) are routed through a node. If the client application connecting to the integration broker does not specify its node name and credentials, the integration broker tries to invoke the service operation as the ANONYMOUS node as a “fall-back” and uses the security of the “default user ID” tied to that node.

The ANONYMOUS node is a delivered node that must exist in all PeopleTools databases. In addition to performing as the fall-back node, the ANONYMOUS node is used for retrieving XSD and WSDL schemas, test framework (PTF) services, and some other internal web services.

The ANONYMOUS node should have the following properties:

• Node Type - External
• Default user id - Some user ID with very limited security (see notes below)
• Authentication Option - None
• Active Node - Checked

When the integration broker framework checks security on inbound web services:

• It looks for a “from” node and authentication parameters in the request.
  • If these are not provided, then the ANONYMOUS node is attempted.
• The service operation being invoked must have routing configured against the ANONYMOUS node specifically or by using an “any-to-local” routing.
  • If this check fails, then the integration gateway will stop the request.
• If the routing check passes, then the service operation is invoked under the context of the default user ID on the node. The default user ID must have the web service security to that service operation for the invocation to continue and be passed to the application server.
• If the above checks passes, then the subscription handler peoplecode method(s) are invoked.
  • One final security check may exist if the subscription handler PeopleCode invokes component interfaces or has SQL Views that rely on some sort of application data security like Row Level Security. If this is the case, then the Default User ID must also have that security.

As you can see, there are several security checks that web services must pass before getting processed by the application server (integration engine) which has access to update or retrieve data from the database (the asset you are trying to protect).

The main point I want to make is that the ANONYMOUS node is the “fall-back” node that is tried if the client does not provide credentials to the Integration Gateway. Therefore, we need to be meticulous on how that node is configured. The ANONYMOUS does not have a password so we should be very careful as to what service operations can be invoked by that node (via routings) and default node user (via Web Service Security). Additionally, what is appropriate in your test and development environments may not be appropriate for your production environments. For example, it is probably a really bad idea to have your PTF (Test Framework) messages enabled in production. You don’t want a user inadvertently connecting to the production database and triggering their tests which would update production data.

Security Vulnerability

There is a potential security hole if a certain combination of configuration occurs on this node.

1. The Default User ID on the ANONYMOUS node is a super user (For example, PS, VP1 or any user ID with a lot of Component Interface and Web Service Security.)
2. There are sensitive Service Operations configured with “Any-TO-LOCAL” routings.

In this mis-configured state, service operations can be invoked by accident or someone with ill-intentions.

Misconfigured Node Example

Let’s look at what could happen with the USER_PROFILE service operation if the ANONYMOUS node was misconfigured. Again, this is an example of how NOT to configure your ANONYMOUS node. Let’s assume the following:

• The USER_PROFILE service operation routings are configured with an “any-to-local” routing
• The default user ID on the ANONYMOUS node is “PS/VP1” (Do NOT configure your system this way!)

A bad-actor posts a USER_PROFILE message to the integration gateway that looks like the following (Note: I have removed a lot of the boilerplate sections from the XML for clarity.) In the request, he does not include a “from” node or any authentication data. Therefore, this service operation is invoked under the fall-back ANONYMOUS node.

<USER_PROFILE>
  <MsgData>
    <Transaction>
      <PSOPRDEFN class="R">
        <OPRID IsChanged="Y">JDOE</OPRID>
        <VERSION IsChanged="Y">1</VERSION>
        <PSROLEUSER_VW class="R">
          <OPRID IsChanged="Y">JDOE</OPRID>
          <ROLENAME IsChanged="Y">PeopleSoft Administrator</ROLENAME>
          <DYNAMIC_SW IsChanged="Y">N</DYNAMIC_SW>
        </PSROLEUSER_VW>
        <PSCAMA class="R">
          <AUDIT_ACTN>A</AUDIT_ACTN>
        </PSCAMA>
      </PSOPRDEFN>
    </Transaction>
  </MsgData>
</USER_PROFILE>

If you look closely, this message is marked up to add the PeopleSoft Administrator role to the user JDOE. If we have our ANONYMOUS node configured incorrectly, this message would add the super user role to that user in the receiving system. If we assume that the bad-actor had control over that JDOE user, then he now can basically do anything in your system with the Administrator role assigned.

Replace the USER_PROFILE message with something like a hire, enrollment, or grades web services and you have some pretty potential for some bad stuff to happen.

Best Practices

• I recommend to never use an “any-to-local” routing for most service operations. You should create explicit routings with node x and node y as the publisher and receiver.
• Third party integrations should always have a node configured that represents that system. Do not share nodes. For example, if have a Java and .NET based systems both invoking the same service operation be sure each of those applications has an explicit node defined in the system.
• Create a new user profile for the default user on the anonymous node and ensure it only has Web Service Security to Service Operations that should be exposed to clients with no credentials.
  • Additionally, any Component interface or Application/Data level security should be given out with great care.