SCIM reach

Which user groups can hit the most stuff? This is the audit question for “least privilege” reviews and for noticing when a temporary admin group ended up with permanent global reach.

Endpoint

GET /api/v1/analytics/scim-reach

Returns

type ScimReachEntry struct {
    ScimGroupID       string
    ScimGroupName     string
    PolicyCount       int
    SegmentGroupCount int
    SegmentCount      int
}

Sorted by SegmentCount descending. The “everywhere” groups float to the top.

How

1. Invert PolicyToScimGroups to get scimGroupID -> []policyID.
2. For each SCIM group, walk its policies and accumulate distinct segments and segment groups.
3. Count.

Use it for

• Least-privilege audits. The top of the list should be groups that should have wide reach (admins, monitoring, oncall). If a “marketing” group is in the top five, something is off.
• Group consolidation. Two SCIM groups with identical reach numbers might be a consolidation opportunity. Check the policy lists.
• Pre-deletion checks. Before retiring a SCIM group, this report tells you how many policies would lose a member. Combined with policy shadows, you can spot which of those policies are redundant anyway.

What it does not tell you

• Actual users in the group. ZPA does not expose SCIM group membership through the management API, and PainScaler does not yet integrate with IdPs directly. The “reach” here is “any member of this group can reach this much” - the count of members is your homework.
• Effective deny. A group might be granted access via one policy and denied via a higher-priority policy. This report counts the grant. To verify the actual decision, run the simulator with a specific user context.