Web Service Operation Access Audit

Web Service Operation Access Audit

Report ID: security-ws-access Category: Integration Broker

Purpose

This report provides a consolidated view of which PeopleSoft service operations (web services) are accessible, through which permission lists and roles, and how many active (unlocked) users have access through each role. It answers the question: “Who can call our web services and through what security chain?”

What It Captures

The report traces the full security chain for every service operation authorization:

• Service Operation — The web service endpoint (from PSAUTHWS)
• Permission List — The permission list granting access to that operation
• Role — Each role that includes that permission list
• Unlocked User Count — The number of users with that role whose accounts are not locked

Tables Queried

PSAUTHWS — Web Service Authorizations

Maps service operations to the permission lists that grant access.

PSROLECLASS — Role to Permission List Mapping

Maps roles to their assigned permission lists.

PSROLEUSER — Role to User Mapping

Maps roles to users, filtered to unlocked accounts only.

PSOPRDEFN — User Definitions

Used as a subquery filter to count only unlocked users.

Data Flow

1. Bulk fetch ALL PSAUTHWS records (paginated, batches of 300)
   -> Build map: Service Operation -> Permission Lists
        |
        v
2. For each unique Permission List, query PSROLECLASS
   -> Build map: Permission List -> Roles
        |
        v
3. For each unique Role, query PSROLEUSER
   with subquery filter: ACCTLOCK = 0 on PSOPRDEFN
   -> Build map: Role -> Unlocked User IDs
        |
        v
4. Group by service operation and sort by unique user count (descending)
   -> Generate Markdown report

Report Output

The generated report contains:

• Summary with counts of service operations, unique permission lists, and unique roles.
• Access Details List grouped by service operation. Each section lists the service operation, its distinct unlocked user count, and a nested bulleted list of its granting permission lists, roles, and the actual active user IDs (truncated at 15).
  • Sorted by unique user count (descending) to highlight the most widely accessible operations.
  • Permission lists with no roles show “(No roles assigned)”.
• Recommendations for security review.

Interpreting Results

• High unlocked user counts on sensitive service operations indicate broad access that may violate least-privilege principles.
• Permission lists with “(No roles assigned)” are assigned to service operations but not included in any role. They may be orphaned or misconfigured.
• Roles with 0 unlocked users grant web service access but have no active users. They are candidates for cleanup.
• Operations with multiple permission lists and roles have complex access chains that are difficult to audit manually.

Use Cases

1. Security audit — Identify which web services have the broadest user access
2. Least-privilege review — Find operations accessible to more users than expected
3. Cleanup — Identify permission lists or roles granting web service access with no active users