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
Security in PeopleSoft REST web services are either:
OPRIDattached and it is pulled from the
ANONYMOUSnode. You can read the Properly Securing the ANONYMOUS IB Node for more information.
PS_TOKENcookie issued by the application server.
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.
Basic Authentication passes a PeopleSoft username and password base64 encoded in an HTTP header.
TEST_WS_ACCOUNTthat has the following characteristics:
OPRIDand password and concatenate it together with a colon. That will give you
AuthorizationHTTP 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.
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.
SSLcan 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.
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:
Having a separate OPRID for each application:
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.
CHG_ALPHA_WEBSERVICE_USERwith only one permission list. The one we create above.
CHG_ALPH_WEBSERVICE_USERwith only one role that we create above.