Chris Malek is a PeopleTools® Technical Consultant with two decades of experience working on PeopleSoft enterprise software projects. He is available for consulting engagements.
About Chris Work with ChrisIntroducing 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 & PurchaseSecurity 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.
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?
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.
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:
When changing PeopleSoft permission lists, you should always ask:
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.
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.
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.
The other SSL and encryptions options I don’t see use very often for various reasons:
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.