Authenticating to PeopleSoft Enrollment Web Services (EWS)

Before you can call secured EWS operations like retrieving a student’s study list or processing enrollments, you need to authenticate the user of your application. This article covers how authentication works with the REST-based Enrollment Web Services.

Understanding the Authentication Model

In the default PeopleSoft security model, the PeopleTools user table handles user IDs and passwords itself. Many schools instead use custom SSO solutions, and there isn’t a single standard for SSO.

These articles will cover standard PeopleSoft authentication where there is a user id (OPRID) and password managed by PeopleTools (PSOPRDEFN). If your institution uses sign-on PeopleCode to integrate with LDAP or another method, this approach may still apply.

PeopleSoft can authenticate a user with a native PeopleSoft password. After authentication, PeopleSoft always controls authorization for which web services the user can access.

Security Model Of EWS

When designing web service in PeopleSoft or any server there are two basic security models that can be designed.

Super-User Access - In this model, certain operations may be performed by a privileged user (like an administrator) on behalf of other users. This requires additional security considerations to ensure proper authorization. In this case, the external application would authenticate as the super-user and specify the target user in the request payload.
- EWS does NOT support this model.
Anonymous Access - In this model, certain EWS operations (like course catalog browsing and class search) can be accessed without user credentials.
- I would not recommend using anonymous access for anything. Since the Catalog, Schedule of Classes and any other configuration data is not student specific, I would recommend creating an Peoplesoft user account that represents the external application and granting it access to the web services needed. This way, you have an audit trail of which application accessed what data.
- for the external application to use.
Authenticated Access - In this model, operations involving student-specific data (study lists, shopping carts, enrollment transactions) require valid user credentials. The system must verify the user before returning or modifying their data.
- EWS supports this model and it is the recommended approach.

Since most of the EWS operations involve student-specific data, authenticated access is the primary security model used. The external application must provide valid user credentials (typically via Basic Authentication) with each request to access these secured operations.

The first step is to ensure the users who will be accessing the EWS have access to the necessary web services in PeopleSoft.

User Authentication

First we will assume that the user has a valid PeopleSoft user ID and password. The external application will need to collect these credentials from the user (e.g., via a login form) and include them in the HTTP Authorization header of each request.

Here we assume that the user knows their PeopleSoft user (OPRID).
- Many times users are using an SSO system and this PeopleSoft account name is not known to them. In this case, you will need to have some way to map the external identity to the internal PeopleSoft user ID.
This would be a password that is either directly managed in PeopleSoft or integrated via an external identity provider (LDAP, SSO, etc.) and authorized by “Signon PeopleCode”.
- Many schools do NOT have this setup and your mileage may vary.

For these examples, we will assume the OPRID is JDOE and the password is CLAPPING5mullet6hackers*miracle.

The EWS servicee have a few different operations that can be used for authentication.

Looking at the SCC_USERREG_R service, you have three authentication-related operations:

Operation	HTTP Method	Purpose
SCC_CHECK_AUTH_R_POST	POST	Validates credentials only - returns a simple yes/no on whether the username/password combination is valid
SCC_USERREG_AUTHORIZE_POST	POST	Authenticates AND authorizes - validates credentials and returns user details like EMPLID, along with authorization information
SCC_USERREG_AUTH_GET	GET	Retrieves authentication/session status for an already authenticated user

Authentication a User - SCC_USERREG_AUTH

This is the most simple authentication operation. It simply validates the provided credentials and returns a session token (PS_TOKEN) that can be used in subsequent requests to act on behalf of the authenticated user.

This service operation is delivered as In-Active, so you have to activate it in PeopleSoft Integration Broker configuration before using it and ensure your target user group has access to it.

Inputs:
- PeopleSoft OPRID and Password
Outputs:
- PS_TOKEN - A token that represents the authenticated session. This is opaque and should be treated as a session identifier.
  - Do NOT log this value or expose it to end users.
  - Having this token means that you can impersonate the user for subsequent requests.
  - Sending this along in subsequent requests means your server is acting on behalf of the user.
  - Never send this in error messages or stack traces.

GET http://34.125.87.32:8000/PSIGW/RESTListeningConnector/PSFT_CS/SCC_USERREG_AUTH.v1/authenticate HTTP/1.1
accept: */*
authorization: Basic JDOE:CLAPPING5mullet6hackers*miracle

A successful response will resemble this the following.

HTTP/1.1 200 OK
connection: close
content-encoding: gzip
content-length: 20
content-type: application/xml; encoding=UTF-8
date: Sat, 06 Dec 2025 20:48:06 GMT
set-cookie: PS_TOKEN=oQAAAAQDAgEBAAAAvAIAAAAAAAAsAAAABABTaGRyAk4AaQg4AC4AMQAwABSmtkQfBXsxJRqRCWpV58Fub+8HEGEAAAAFAFNkYXRhVXicLYnNDkAwGASnJeLkTSpV/2dK4oCEu7N39HA+jT3szGZvII60UsJHE5IujGx4Es/KTLZzMHFyMYhVDoujxlAIjazm95yKTtrK+3lJSx/ICzZ6CsY=
x-oracle-dms-ecid: b518fc96-a79f-43d0-b527-6312383b1ace-0000003e
x-oracle-dms-rid: 0

If the authentication fails, you will get a 401 Unauthorized response like this:

HTTP/1.1 401 Unauthorized
cache-control: no-store, must-revalidate, private
connection: close
content-length: 0
date: Sat, 06 Dec 2025 20:51:59 GMT
www-authenticate: BASIC realm="PeopleSoft Enterprise PeopleTools"
x-oracle-dms-ecid: b518fc96-a79f-43d0-b527-6312383b1ace-0000003f
x-oracle-dms-rid: 0

This web service does not give you much information other than whether the credentials are valid or not and gives you a token. You will use this token in subsequent requests to act on behalf of the user.

Author Info

Chris Malek

Chris Malek s a PeopleTools® Technical Consultant with over two decades of experience working on PeopleSoft enterprise software projects. He is available for consulting engagements.

Work with Chris

Looking for pain-free PeopleSoft web services? 😀

PeopleSoft Simple Web Services (SWS)

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.

Contents