Security in Service Operations

Security is always a complex and nuanced topic. It is heavily dependent on your installation and configuration of PeopleSoft and your network topology. Every installation is different. You have to think about security at every layer of the stack.

• Who and what can target your integration broker servers.
  • This is driven generally by your network security.
• Who and what can target specific web services / service operations.
  • This is driven by Service Operation and Node configurations.
• In a specific service operation, what can that user do with the services.
  • This is driven by the code in the specific service operation as well as data and component security.

All of these layers are often managed by different teams in larger organizations that run PeopleSoft. Therefore, you must work together to secure the integration broker. In my opinion, your integration broker security should start with the most restrictive model then slowly expand to more permissive as there are actual use cases. Why do I feel this?

• PeopleSoft has slow release cycles from Oracle. There are various software layers to the platform. As security issues are found, it takes time for Oracle (or any software) vendor to respond with patches.
• Clients often have quarterly or yearly update cycles. Even if a critical security patch is found, organizations need time to install, test and deploy these changes. This can lead to big gaps in time between the vulnerability being identified and it being deployed to your production instance. For large public companies that are subject to Sarbanes-Oxley, this can taken longer.
• The PeopleSoft product is constantly being changed and reconfigured with PUMS (patches), upgrades, customizations and configurations. These can all lead to opening your PeopleSoft product to data leaks and security incidents. I have seen many instances of misconfigured systems where very sensitive web services are either open to the world or a large user base when they should not be.
• It is hard to audit what web services are available to a user and the world in PeopleSoft. Oracle does not deliver any standard reports or audit dashboards to find issues. If you don’t have experts on your staff and have made it a priority to develop these audits your system could be at risk.
• Many of the delivered web services have zero documentation, so administrators may not know that certain web services expose very sensitive information.

Network Security

As a general rule, your organization should have the integration broker gateway locked down. There should be limitations on what can target it. This assumes that most of your integration broker clients are trusted servers coming from known and trusted data centers. In my experience, this is true 99% of the time.

• There should be limited IP addresses that can communicate with the gateway.
• If you are using web services that are invoked by the end user’s workstations then this could be problematic if your users are egressed from certain IP ranges. For example, if you have REST web services that a user’s web browser invokes directly against the integration broker this could be problematic if those user’s can be anywhere in the world.
  • In this scenario, I would recommend that you use some API proxy services (see section below)
• Your integration gateway should probably be reversed proxied behind a firewall. The firewall should be configured to:
  • limit the ports that can be addresses
  • limit the protocols that can be used
  • limit the payloads that can be used
  • potentially perform TLS/SSL termination so the firewall can inspect and block “suspicious traffic”. This also allows the SSL certificates to be managed in a central location by the network teams.

PeopleSoft Setup and Security

In the PeopleSoft security, you should also limit who can invoke web services. This is applied through standard permission lists. In most cases, web services are invoked by “trusted servers” and NOT end users. Therefore, you generally should NOT be assigning web service security to end users. I see this mistake at almost every client I work at.

I have some “Best Practices” sections in:

• REST Security
• Node Best Practices
• Anonymous Node Security

When changing PeopleSoft permission lists, you should always ask:

• What data is exposed with this web service?
• Is the security change using the “least privilege model”.
• If granting web service security to end users and not a “service account”, double check with the developer that is the assumed usage and not a mistake.

PeopleSoft Configuration Changes

There are many configuration options in PeopleTools. You should limit who has access to make configuration changes to the integration broker configurations. You should only have experienced people with access that understand the ramifications of making changes.

• Limit who can change permission lists
• Limit who can configure nodes and change password nodes.
• Limit who can configure service operation including:
  • Creating new service operations
  • Changing handler code
  • Changing routings

You should make sure all changes are reviewed by an experienced PeopleSoft person. I have seen many times in production environments, where non-experienced people have made configuration changes that have left systems open for attack and data leaks.

Service Operation Security Options

On the service operation configuration page there is an “Req Verification” option that often cause a lot of confusion.

I generally recommend that this value be set to “None” and the “User/Password Required” be un-checked. This does NOT mean that there is no password or authentication on the web service. All PeopleSoft code has to run under a valid PeopleSoft account. That account has to have a permission list with the web service in order to invoke it. It really depends on if you are using REST or the older HTTPListeningConnector method. Those all resolve the PeopleSoft OPRID to run the web service under differently.

• REST uses a “Basic Auth” header with a OPRID and Password in the header. See the REST Security Chapter.
• HTTPListeningConnector generally uses a “Node Password”. A PeopleSoft administrator has defined an OPRID on the node that PeopleCode runs under. See the Node Chapter

The other SSL and encryptions options I don’t see use very often for various reasons:

• They are not documented.
• Many clients use SSL Termination at a firewall prior to PeopleSoft.

Using an API Gateway

I would encourage your infrastructure team to evaluate an API Gateway to proxy all PeopleSoft web services through. This does add another layer and cost. However, there are many benefits to using a gateway in a production environment. These gateways products were serve as the “front end” to your integration broker. When using a gateway, no client can directly address the integration broker web server.