Integration Broker

• 1: Web Service Operation Access Audit
• 2: IB Node Security Audit
• 3: Active ANY to Local Node Routings
• 4: Active Service Operations Report
• 5: Active Service Operations with No Routings
• 6: Unauthenticated Node Service Operations
• 7: Sync Operations Without Logging
• 8: Daily IB Volume/Usage Report

1 - 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 Count
        |
        v
4. Flatten into rows and sort by 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 Table with columns: Service Operation, Permission List, Role, Unlocked Users
  • Sorted by unlocked user count (descending) to highlight the most widely accessible operations
  • Permission lists with no roles show “(no roles)” in the Role column
• 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)” are assigned to service operations but not included in any role. They may be orphaned or misconfigured
• Roles with 0 unlocked users are granting web service access but have no active users. Candidates for cleanup
• Operations appearing many times (across multiple permission lists and roles) have complex access chains that may be hard 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

2 - IB Node Security Audit

IB Node Security Audit Report

Report ID: ib-node-security-audit Category: Integration Broker

Purpose

This report audits Integration Broker node user accounts for security issues that go beyond authentication configuration (which is covered by the Nodes with No Password report). It checks for elevated user privileges on nodes, shared user accounts across multiple nodes, and nodes with no active routings.

What It Detects

CRITICAL — Anonymous Node User Analysis

Checks the ANONYMOUS node’s associated PeopleSoft user account. Flags as HIGH RISK if:

• The user account is unlocked (can log into PIA directly)
• The user has PeopleTools access (Application Designer, Data Mover, etc.)

The ANONYMOUS node handles unauthenticated IB traffic. Its user should have minimal privileges and a locked account.

WARNING — Shared Node Users

Identifies cases where the same PeopleSoft User ID (OPRID) is configured on multiple active nodes. Each node should have its own distinct service account for:

• Audit trail — Knowing which node performed an action
• Security isolation — Revoking one node’s access without affecting others
• Least privilege — Tailoring permissions per node’s specific needs

WARNING — Active Nodes with No Active Routings

Finds active non-local nodes that have no active routings in PSIBRTNGDEFN. These nodes may be:

• Leftover from decommissioned integrations
• Candidates for deactivation to reduce attack surface
• Covered only by wildcard (~~ANY~~) routings (reported separately)

WARNING — Node Users with PeopleTools Access

Identifies node service accounts whose permission lists grant access to PeopleTools clients (Application Designer, Data Mover, Query, etc.). Node accounts should never need development tool access.

Tables Queried

PSMSGNODEDEFN — Message Node Definitions

PSIBRTNGDEFN — Routing Definitions

PSOPRDEFN — User Definitions

PSAUTHITEM — Menu/Tools Authorizations

Used to check if a permission list grants PeopleTools client access (APPLICATION_DESIGNER, DATA_MOVER, etc.).

Data Flow

1. Fetch ALL message nodes from PSMSGNODEDEFN
   (batches of 300)
        |
        v
2. Fetch ALL active routings from PSIBRTNGDEFN
   Build set of node names with active routings
        |
        v
3. For each unique UserID on active nodes:
   Look up user in PSOPRDEFN
        |
        v
4. For each unique permission list found:
   Check PSAUTHITEM for PeopleTools access
        |
        v
5. Analyze and categorize findings:
   - Anonymous node user privileges
   - Shared node users (same OPRID on 2+ nodes)
   - Active nodes not in routing coverage set
   - Node users with PeopleTools access
        |
        v
6. Generate Markdown report grouped by severity

Interpreting Results

• CRITICAL findings on the ANONYMOUS node indicate that unauthenticated IB traffic is processed under a user with elevated privileges. This is a significant security risk.
• Shared node users increase blast radius if one account is compromised and make it harder to trace which node performed specific actions.
• Nodes with no routings represent unnecessary attack surface. If a node isn’t routing any messages, it should be deactivated.
• PeopleTools access on node accounts means a compromised integration could potentially be used to modify PeopleSoft objects.

Recommendations

1. Lock the ANONYMOUS node user account to prevent direct PIA login
2. Remove PeopleTools access from node service account permission lists
3. Create distinct service accounts for each Integration Broker node
4. Deactivate nodes with no active routings if they are no longer needed

3 - Active ANY to Local Node Routings

Active ~~ANY~~ to Local Node Routings Report

Report ID: ib-any-to-local-routing Category: Integration Broker

Purpose

This report identifies Integration Broker routings where the sender node is ~~ANY~~ and the receiver is the default local node. The ~~ANY~~ sender is a wildcard that allows any external node to send messages to the local system for that routing’s operation, bypassing node-specific routing controls.

~~ANY~~ routings are sometimes intentional (e.g., for broadly available services), but if left active without review they let any external node send messages inbound. This report lists which operations are open to inbound messages from any node.

What It Detects

WARNING — Active ~~ANY~~ to Local Node Routings

Active routings in PSIBRTNGDEFN where:

• SENDERNODENAME = '~~ANY~~'
• RECEIVERNODENAME is the default local node
• EFF_STATUS = 'A' (Active)

These routings are currently allowing any external node to send messages inbound.

Tables Queried

PSMSGNODEDEFN — Message Node Definitions

Used to identify the default local node(s).

PSIBRTNGDEFN — Integration Broker Routing Definitions

Used to find inbound routings to the default local node.

Data Flow

1. Fetch ALL message nodes from PSMSGNODEDEFN
   (batches of 300)
        |
        v
2. Filter for default local nodes:
   LOCALNODE = 1 AND LOCALDEFAULTFLG = 'Y'
        |
        v
3. For each default local node, fetch inbound routings
   from PSIBRTNGDEFN where RECEIVERNODENAME = node
        |
        v
4. Filter for active routings where SENDERNODENAME = '~~ANY~~'
        |
        v
5. Generate Markdown report with findings

Report Output

The generated report contains:

• Header with database name and generation timestamp
• Summary with total nodes scanned, default local node name(s), and count of active ~~ANY~~ routings
• WARNING section (if any): Table of active ~~ANY~~ routings with routing name, receiver node, linked service operation, and description
• Recommendations if active ~~ANY~~ routings are found

Interpreting Results

• WARNING findings should be reviewed. Each active ~~ANY~~ routing means any external node can send messages for that operation to the local system. Determine whether this is intentional.
• No findings means all inbound routings use explicit sender nodes, which is the most secure configuration.

Recommendations

1. Review each active ~~ANY~~ routing to determine if a wildcard sender is truly needed
2. Replace with explicit sender node routings where possible to restrict which nodes can send messages inbound
3. Deactivate unneeded ~~ANY~~ routings to reduce the attack surface

4 - Active Service Operations Report

Active Service Operations Report

Report ID: ib-active-any-routes Category: Integration Broker

Purpose

This report lists all fully active service operations — those with at least one active version, at least one active routing, and at least one active handler — along with their permission lists that grant access.

What It Captures

For each fully active service operation:

• Operation metadata (service name, type, sync/async, REST method)
• Active handlers (handler name, type, application class)
• Active routings (routing name, sender node, receiver node, generated flag)
• Permission lists from PSAUTHWS that grant access to the operation

Tables Queried

PSAUTHWS — Web Service Authorizations

Bulk-fetched upfront to build a map of operation to permission lists.

PSOPERATION — Service Operation Definitions

Paginated to discover all operations.

PSOPRVERDFN — Operation Version Definitions

PSOPRHDLR — Operation Handlers

PSOPERATIONAC — Application Class Handlers

PSIBRTNGDEFN — Integration Broker Routing Definitions

Fetched with EFFDT logic disabled.

How It Runs

The report pulls all service operations with their child records (versions, handlers, routings) in a single paginated hierarchical query, then bulk-fetches PSAUTHWS to map each operation to its permission lists. Operations are filtered to those with at least one active version, routing, and handler before being written to the report. For a system with N service operations and A PSAUTHWS rows, expect roughly N/50 + A/300 API calls. A site with 500 operations and 2000 auth rows runs in about 17 calls.

Report Output

The generated report contains:

• Header with database name and generation timestamp
• Summary with total operations and count of active operations
• Per-operation sections with:
  • Operation metadata (service, type, REST method, description)
  • Active handlers table (handler name, type, app class path)
  • Active routings table (routing name, sender, receiver, generated flag)
  • Permission lists table (linked to permission list detail pages)

Interpreting Results

• Operations with no permission lists may be inaccessible or may rely on other authentication mechanisms
• Operations with ~~ANY~~ sender routings accept messages from any external node. Review whether this is intentional
• Operations with no active handlers may indicate stale configuration
• Operations with many permission lists have broad access. Verify this is appropriate

Use Cases

1. IB inventory — Get a complete list of all active service operations and their configuration
2. Security review — Identify which operations are accessible and by whom
3. Cleanup — Find operations with no active handlers or routings that may be candidates for deactivation

5 - Active Service Operations with No Routings

Active Service Operations with No Routings

Report ID: ib-svcops-no-routing Category: Integration Broker

Purpose

This report identifies active service operations that have no active routing definitions. These operations have at least one active version but cannot process any messages because no routing is configured to direct traffic to or from them. Usually this means a half-finished setup or an operation that should have been deactivated when its routings were.

What It Detects

An operation is flagged when:

1. It has at least one active version (ACTIVE_FLAG = 'A' in PSOPRVERDFN)
2. It has zero active routings (EFF_STATUS = 'A' in PSIBRTNGDEFN)

The report also shows the count of inactive routings, which helps distinguish between operations that never had routings and those whose routings were intentionally deactivated.

Tables Queried

PSOPERATION — Service Operation Definitions

Paginated to discover all operations.

PSOPRVERDFN — Operation Version Definitions

PSIBRTNGDEFN — Integration Broker Routing Definitions

Data Flow

1. Paginate through all PSOPERATION records
   (batches of 300)
        |
        v
2. For each operation, fetch full details
   (versions, routings)
        |
        v
3. Filter to operations with at least one
   active version (ACTIVE_FLAG = 'A')
        |
        v
4. Exclude operations that have any active
   routing (EFF_STATUS = 'A')
        |
        v
5. Generate summary table of flagged operations

Report Output

The generated report contains:

• Summary with total operations, active operations, and count flagged with no routings
• Flagged operations table with operation name (linked to detail page), service, type, active version count, inactive routing count, and description
• Recommendations for remediation actions

Interpreting Results

• Operations with zero total routings likely never had routings configured. These may be newly created or inherited operations that were never fully set up
• Operations with inactive routings only suggest the routings were intentionally deactivated. Verify whether the operation itself should also be deactivated
• Async operations without routings are especially notable since they rely on routings for subscription/publication contracts
• Sync operations without routings cannot receive inbound requests

Recommendations

1. If the operation is needed: Create and activate routing definitions to enable message processing
2. If the operation is not needed: Inactivate all versions to keep the IB configuration clean
3. If routings exist but are inactive: Review whether deactivation was intentional or an oversight

6 - Unauthenticated Node Service Operations

Unauthenticated Node Service Operations

Report ID: ib-noauth-node-svcops Category: Integration Broker

Purpose

This report identifies active nodes with no authentication configured (AUTHOPTN='N') and then determines which fully-active service operations are reachable through those nodes. A service operation is considered fully active only when it meets all three criteria: an active version, an active routing, and an active handler.

Any operation reachable through one of these nodes can be invoked without credentials.

What It Captures

For each active node with no authentication:

• Node metadata (name, description, user ID)
• All fully-active service operations routed through that node
• The routing that links the operation to the node
• Operation type (REST/HTTP Post, Sync/Async)

Tables Queried

PSMSGNODEDEFN — Message Node Definitions

Paginated to discover all nodes. Filtered to active nodes with AUTHOPTN = 'N'.

PSOPERATION — Service Operation Definitions

Paginated to discover all operations.

PSOPRVERDFN — Operation Version Definitions

PSOPRHDLR — Operation Handlers

PSIBRTNGDEFN — Integration Broker Routing Definitions

Data Flow

1. Paginate through all PSMSGNODEDEFN records
   -> Filter to active nodes with AUTHOPTN = 'N'
   -> Build set of no-auth node names
        |
        v
2. Paginate through all PSOPERATION records
   (batches of 300)
        |
        v
3. For each operation, fetch full details
   (versions, handlers, routings)
        |
        v
4. Filter to "fully active" operations:
   - At least one active version
   - At least one active handler
   - At least one active routing
        |
        v
5. Check if any active routing references
   a no-auth node (as sender OR receiver)
        |
        v
6. Generate report grouped by node

Report Output

The generated report contains:

• Header with database name and generation timestamp
• Summary with counts of no-auth nodes, total operations checked, and matching operations
• No-Auth Nodes table listing each unauthenticated node with its user ID and count of reachable operations
• Per-node sections with a table of all service operations accessible through that node, including operation type and routing name
• Recommendations for remediation

Interpreting Results

• Nodes with many accessible operations are higher risk and should be prioritized for remediation
• The User ID on each node indicates what PeopleSoft user context is used for operations through that node. Review its privileges
• REST operations are typically more easily exploitable from external systems than HTTP Post (SOAP) operations
• If no nodes are found with AUTHOPTN='N', the report exits early with a clean result

Recommendations

1. Configure authentication (AUTHOPTN = 'P' or 'C') on all active nodes
2. Set internal and/or external passwords on nodes that require password authentication
3. Review the PeopleSoft user ID associated with each no-auth node for excessive privileges
4. Consider deactivating routings that should not be accessible without authentication

Related Reports

• Nodes with No Password — Identifies nodes with missing authentication or passwords
• IB Node Security Audit — Audits node user accounts for elevated privileges
• Active Service Operations Report — Lists all active service operations with full details

7 - Sync Operations Without Logging

Sync Operations Without Logging

Report ID: ib-sync-no-logging Category: Integration Broker

Purpose

This report identifies active synchronous service operations that have active routings where message detail logging is disabled. When logging is off on a sync routing, transaction data is not recorded in the IB logs, making it impossible to troubleshoot failures or audit message traffic.

What It Detects

A routing is flagged when all three conditions are met:

1. The service operation is synchronous (RTNGTYPE = 'S' in PSOPERATION)
2. It has at least one active version (ACTIVE_FLAG = 'A' in PSOPRVERDFN)
3. An active routing (EFF_STATUS = 'A' in PSIBRTNGDEFN) has logging disabled (LOGMSGDTLFLG = '2')

Tables Queried

PSOPERATION — Service Operation Definitions

Paginated to discover all operations, filtered to synchronous only.

PSOPRVERDFN — Operation Version Definitions

PSIBRTNGDEFN — Integration Broker Routing Definitions

Data Flow

1. Paginate through all PSOPERATION records
   (batches of 300)
        |
        v
2. For each operation, fetch full details
   (versions, routings)
        |
        v
3. Filter to synchronous operations with at
   least one active version
        |
        v
4. Check each active routing for LOGMSGDTLFLG
   Flag routings where value is '2' (No Logging)
        |
        v
5. Generate table of flagged routings

Report Output

The generated report contains:

• Summary with total operations, active sync operations, sync with active routings, and count of routings without logging
• Flagged routings table with operation name (linked to detail page), service, routing name, sender node, receiver node, and description
• Recommendations for enabling logging

Interpreting Results

• High count of flagged routings may indicate a blanket policy of disabling logging. Consider enabling it at least for critical operations
• Generated routings (auto-created by PeopleSoft) often have logging disabled by default. Review whether these carry important traffic
• Custom routings without logging suggest an intentional decision that should be validated with the integration team

Recommendations

1. Enable logging: In PeopleTools > Integration Broker > Integration Setup > Routings, set the “Log Detail” flag to “Header Only” (0) or “Header & Detail” (1) for each flagged routing
2. Performance consideration: Header-only logging has trivial overhead. Header+Detail can balloon the IB log tables on high-volume routings — turn it on for the ones you actually want to troubleshoot
3. Review periodically: Logging may be intentionally disabled during high-volume batch processing. Re-enable after batch windows complete

8 - Daily IB Volume/Usage Report

Daily IB Volume/Usage Report

Report ID: ib-daily-volume Category: Integration Broker

Purpose

This report shows Integration Broker message volume for a configurable date range. It breaks down traffic into four categories:

1. Async Operations — publication headers (PSAPMSGPUBHDR), the top-level async message record
2. Publication Contracts — per-subscriber delivery records (PSAPMSGPUBCON)
3. Subscription Contracts — subscription handler execution records (PSAPMSGSUBCON)
4. Synchronous Operations — logged sync transactions (PSIBLOGHDR). Only operations with logging enabled appear here

Each category shows counts grouped by operation name and status (Done, Error, New, etc.), sorted by total volume descending.

Parameters

Leave both parameters blank to report on today’s traffic. Set a range such as from_date=2026-01-01 and to_date=2026-01-31 for a monthly view.

Tables Queried

PSAPMSGPUBHDR — Async Operation Headers

The master record for each async IB message (one row per publication).

PSAPMSGPUBCON — Publication Contracts

One row per subscriber for each async publication.

PSAPMSGSUBCON — Subscription Contracts

One row per subscription handler execution.

PSIBLOGHDR — Sync Operation Log Headers

Logged synchronous transaction records. Only populated when message detail logging is enabled on the routing.

Data Flow

1. Fetch async operation summary (PSAPMSGPUBHDR)
   GROUP BY IB_OPERATIONNAME, STATUSSTRING
        |
        v
2. Fetch publication contract summary (PSAPMSGPUBCON)
   GROUP BY IB_OPERATIONNAME, STATUSSTRING
        |
        v
3. Fetch subscription contract summary (PSAPMSGSUBCON)
   GROUP BY IB_OPERATIONNAME, STATUSSTRING
        |
        v
4. Fetch sync operation summary (PSIBLOGHDR)
   GROUP BY IB_OPERATIONNAME, STATUSSTRING
        |
        v
5. Pivot each dataset into a per-operation table
   with status columns, sorted by total descending

Report Output

The generated report contains:

• Summary table with total message counts for each of the four categories
• Async Operations table — one row per operation, columns for each status (Done, Error, New, etc.) plus Total
• Publication Contracts table — same format
• Subscription Contracts table — same format
• Synchronous Operations table — same format, with a note that only logging-enabled operations appear

Interpreting Results

Async Operations

• Done — successfully processed and delivered
• Error — failed; check the IB Monitor for details
• New — queued but not yet processed (may indicate a stuck dispatcher)

A high Error count relative to Done signals a systemic integration problem. A high New count with no decrease over time indicates the IB dispatcher may be stopped.

Publication vs Subscription Contracts

• Each async publication spawns one publication contract (PSAPMSGPUBCON) per subscribing node
• Subscription contracts (PSAPMSGSUBCON) represent individual handler executions
• If pub contract count is much higher than sub contract count, some subscribers may not be processing

Synchronous Operations

• Only operations with logging enabled on their routing appear here
• A missing operation does not mean it had no traffic. It may have logging disabled
• Cross-reference with the Sync Operations Without Logging report to identify gaps

Recommendations

1. Monitor daily Error rates — set a threshold and investigate any day where errors exceed it
2. Watch for New status growth — a queue of unprocessed messages indicates a dispatcher or handler problem
3. Enable sync logging for critical operations to get visibility in this report (see Sync Operations Without Logging)
4. Compare day-over-day volumes — sudden drops may indicate a sending system stopped, not just low traffic