REST Security

Security in PeopleSoft REST web services are either:

• Public with no authentication
  • Technically, there is still an OPRID attached and it is pulled from the ANONYMOUS node. You can read the Properly Securing the ANONYMOUS IB Node for more information.
• Secured with basic authentication
  • I have NOT been able to get Signon PeopleCode to execute for a the RESTListeningConnector.
• Called using as valid PS_TOKEN cookie issued by the application server.
• REST does NOT use integration nodes, so you cannot use node security. (TODO - Link to the HTTP Node security document)

So what is basic authentication? It is a user name and password encoded in a special format and passed in an HTTP header. We will look at this in detail shortly.

How to Use Basic Authentication

Basic Authentication passes a PeopleSoft username and password base64 encoded in an HTTP header.

• Let’s imagine that you have an OPRID called TEST_WS_ACCOUNT that has the following characteristics:
  • Assigned permission lists with access to the target Server Operation.
  • A password stored on PSOPRDEFN with the value of figurine-filly-wainscot
  • Is unlocked.
• You then take the OPRID and password and concatenate it together with a colon. That will give you TEST_WS_ACCOUNT:figurine-filly-wainscot
• Now you BASE64 encode that string which will give you: VEVTVF9XU19BQ0NPVU5UOmZpZ3VyaW5lLWZpbGx5LXdhaW5zY290
• Now you pass an Authorization HTTP header in the request that looks like this: Authorization: Basic VEVTVF9XU19BQ0NPVU5UOmZpZ3VyaW5lLWZpbGx5LXdhaW5zY290

If you do not submit the correct Authorization header that maps to a valid user that has permission to the web service you will get an HTTP 401 (Unauthorized) status code back.

Service Operation Security setup

There is often a lot of questions and confusion about a setting on the service operation. There is a field poorly labeled called “Req. Verification” (PSOPERATION.IB_REQUESTSTATUS ) with these options.

At first glance, you might think that the value “none” means that the service operation is public and does not require any password or authentication. However, that is completely untrue. All code in PeopleSoft always runs under some valid OPRID. You can read the Properly Securing the ANONYMOUS IB Node section for more information.

The values can be confusing.

• I generally recommend that you use the value of “none” unless you have some strange edge case where you need one of the other ones.
  • You then only grant the service operation on specific permission lists to users who need it.
  • Using a value of “none” gives you flexibility in using Basic Authentication or a PeopleSoft Token.
• All the options with SSL can be problematic because I often see PeopleSoft administrators do SSL Termination at a firewall or proxy server prior to the traffic hitting Weblogic. In that case, PeopleSoft cannot detect if SSL is being used. Additionally, if your PeopleSoft system allows traffic that is not encrypted you need to fire your PeopleSoft administrator. HTTPS should be the only option to reach your PeopleSoft instances.

Best Practices in REST Security

When you are developing REST services at your organization you will likely have many different applications and departments that need to integrate and use your web services. Since we have to pass a user name and password as the security token for the REST services, it is a good practice to have a separate token/password for each application that is calling the web service.

Imagine that you developed a REST service that allows another application to pull employee information from PeopleSoft. Let’s imagine you have an accounting system that needs to use the web service and an IT provisioning system that also needs to call the same web service.

You have a few options here:

• Do not add security to web service and make it public.
  • I never recommend this method unless your integration gateway is very locked down with limited network access. This is probably still a bad idea as a network configuration mistake can expose sensitive data.
• Generate a shared OPRID and password and give it out to all teams / applications that need to call the web service.
• Generate a unique OPRID for each team that needs to call the web service.
  • This is the approach that I recommend.

Having a separate OPRID for each application:

• allows you to have granular access to each application. Each application may need to have access to a different set of web services under one API token/password. When the application goes out of service it is easy to remove the security objects related to that integration and not impact other departments or applications.
• You can coordinate password rotation with each application separately since each application has their own user name and password.
• Allows for better auditing of web service usage.
• Follows the least privilege model.
• If your application does updates with standard PeopleSoft methods like Component Interfaces then any audit records or fields like LASTUPDOPRID will be marked clearly with what application actually made the update. This can make research of data issues much easier since the LASTUPDOPRID field will be marked with the OPRID that maps to the unique application that did the web service call. This is subtle but can make product support investigation much easier.

I recommend setting up user name in some format like the following assuming that each user name you are generating is an application or server.

Let’s imagine that you have some internal application at your organization called ALPHA. We are going to use that in the naming of our security objects. Your organization also probably has some naming standard for security objects. I am going to use a CHG_ prefix in these examples for “Cedar Hills Group” but you can substitute whatever your organization uses.

• Create a permission list called something like CHG_ALPHA_WEBSERVICE_USER.
• Grant web service security permission on this new permission list. This permission list should not have any weblib security which will prevent the user from actually logging onto PeopleSoft via PIA. If the web services you are exposing use component interface then you need to add those permission as well. If the CI’s or web services uses any sort of row level or application level security then you need to think through that in your setup.
• Create role called CHG_ALPHA_WEBSERVICE_USER with only one permission list. The one we create above.
• Create a new OPRID called CHG_ALPH_WEBSERVICE_USER with only one role that we create above.
  • Add a very long secure password using a random password generator. We will share this password with the team members who own this application.
    • I have NOT been able to get Signon PeopleCode to execute for a the RESTListeningConnector so the password must exist in PSOPRDEFN