Security in the Application Services Framework (ASF, introduced in PeopleTools 8.59) operates differently from traditional Integration Broker service operations. While standard IB relies on PSAUTHWS to grant access to individual service operations, ASF introduces its own granular permission structure (PSAUTHAS) while leveraging a generic Integration Broker transport behind the scenes.
In standard Integration Broker, you authorize a user by attaching a Permission List to a Service Operation in PSAUTHWS. In ASF, authorization is decoupled from the transport and enforced at the Application Service URI and HTTP method level.
sequenceDiagram
participant Client as External REST Client
participant GW as RESTListeningConnector (PIA)
participant PostHdr as Generic Dispatcher (PTCBAPPLSVCDEFN)
participant Sec as PSAUTHAS (Permission Lists)
participant AppClass as Application Service Class
Client->>GW: HTTP Request (Method + Path + Auth Headers)
GW->>PostHdr: Routes to generated *_ASF_POST Operation
Note over PostHdr: Framework resolves PTIBAPPLNAME & URI template
PostHdr->>Sec: Validate user CLASSID in PSAUTHAS
alt Authorized (Full Access = 4)
PostHdr->>AppClass: Instantiates class & calls invokeService()
AppClass-->>PostHdr: Response data & HTTP status
PostHdr-->>GW: Formatted REST response
GW-->>Client: HTTP 200 / 201 Response
else Unauthorized
PostHdr-->>GW: HTTP 403 Forbidden
GW-->>Client: HTTP 403 Access Denied
end
PSAUTHASASF permissions are stored in PSAUTHAS (“Authorized Application Service”):
| Column | Description |
|---|---|
CLASSID |
The PeopleSoft Permission List |
PTIBAPPLNAME |
Application Service ID (e.g. SSR_APP_SVC) |
PTIBURLPARAMNAME |
Operation URL segment (e.g. enrollment) |
IB_URI_SEQ |
URI template sequence number |
IB_RESTMETHOD |
REST HTTP method (GET, POST, PUT, DELETE) |
AUTHORIZEDACTIONS |
Access level (4 = Full Access) |
Unlike PSAUTHWS, where access is granted per service operation, PSAUTHAS allows security administrators to grant access to specific URI endpoints and HTTP methods independently within the same service (for example, allowing GET on a resource while restricting POST or DELETE).
To grant access to an Application Service:
PTIB_APPLSVC_SECUR).Alternatively, administrators can manage service permissions directly from the Application Service definition (PeopleTools > Integration Broker > Application Services > Application Service), where the Security tab allows inspecting and assigning permission lists across all defined operations.
To maintain compatibility with PeopleSoft’s existing gateway infrastructure, saving an Application Service automatically generates standard Integration Broker metadata:
<first 20 chars of PTIBAPPLNAME>_ASF (stored in PSSERVICE.IB_SERVICENAME).<service>_POST (stored in PSOPERATION).PSOPERATIONAC:
PTCBAPPLSVCDEFNPTCBSVCPostHandlerOnRequestWhen an inbound REST call hits the gateway, it is routed through this single generic handler regardless of the HTTP method or specific business logic. The PostHandler dispatcher:
PSIBAPPURI and PSIBAPPMETHOD.PSAUTHAS.PSIBAPPLOPR (which extends PTCBAPPLSVCDEFN:ApplicationServiceBase).invokeService() method and formats the response.PSAUTHAS, not PSAUTHWS.Authentication requirements are configured on the Application Service header (PSIBAPPLDEFN.PTIB_AUTHOPTION):
B): Inbound requests must supply HTTP Basic Authorization headers (username:password). The credentials resolve to a valid PeopleSoft OPRID.O): Inbound requests must supply a Bearer token issued by an OAuth 2.0 authorization server (configured under Integration Broker OAuth 2.0 setups).If an Application Service endpoint is configured without authentication or if a caller connects without supplying valid credentials:
ANONYMOUS node.PSAUTHAS, the request will execute under that user’s identity.ANONYMOUS node’s default user ID does not have permission lists granting access to sensitive Application Services. See Properly Securing the ANONYMOUS IB Node for hardening recommendations.Use this SQL query to inspect which permission lists and roles have access to Application Services:
SELECT A.PTIBAPPLNAME,
A.PTIBURLPARAMNAME,
A.IB_RESTMETHOD,
A.CLASSID,
R.ROLENAME,
U.ROLEUSER AS OPRID
FROM PSAUTHAS A
JOIN PSROLECLASS R
ON A.CLASSID = R.CLASSID
JOIN PSROLEUSER U
ON R.ROLENAME = U.ROLENAME
JOIN PSOPRDEFN O
ON U.ROLEUSER = O.OPRID
WHERE O.ACCTLOCK = 0
AND A.AUTHORIZEDACTIONS = 4
ORDER BY A.PTIBAPPLNAME, A.PTIBURLPARAMNAME, A.CLASSID, U.ROLEUSER;
Look up any record, field, page, or component, audit security, and monitor Integration Broker across every database — in seconds.
A web console built for the PeopleSoft community — operational monitoring, security auditing, and metadata browsing in one tool.
On-demand security and operational reports for your PeopleSoft environment — no client install required.
Research any PeopleSoft object and monitor system health from a single browser tab — no App Designer, no SQL.
Chris Malek is a PeopleTools® Technical Consultant with over two decades of experience. He is available for consulting engagements.
Work with ChrisSWS turns SQL into production REST APIs — ready for AI, modern apps, and partner integrations. One install, unlimited potential.
A powerful PeopleSoft bolt-on that makes REST web services easy. You bring the SQL, SWS handles the rest.
Traditional PeopleSoft web services cost $3,600–$13,000 each to develop. SWS deploys production REST APIs in under 5 minutes through configuration alone.
Turn PeopleSoft data into clean REST APIs for AI integrations, modern applications, and vendor data feeds. Configuration-driven — no PeopleCode required.