Introducing a small but powerful PeopleSoft bolt-on that makes web services very easy. If you have a SQL statement, you can turn that into a web service in PeopleSoft in a few minutes.Read More & Purchase
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.
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.
ANONYMOUS node should have the following properties:
When the integration broker framework checks security on inbound web services:
ANONYMOUSnode is attempted.
ANONYMOUSnode specifically or by using an “any-to-local” routing.
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.
There is a potential security hole if a certain combination of configuration occurs on this node.
ANONYMOUSnode is a super user (For example, PS, VP1 or any user ID with a lot of Component Interface and Web Service Security.)
In this mis-configured state, service operations can be invoked by accident or someone with ill-intentions.
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:
USER_PROFILEservice operation routings are configured with an “any-to-local” routing
ANONYMOUSnode 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
<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.
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.
anonymousnode and ensure it only has Web Service Security to Service Operations that should be exposed to clients with no credentials.