Dynamically Define Access Request Segments

SailPoint Human Fabric (SHF) SHF Discussion and Questions
,
1

Hi All,

I would like to know if there is any best practice to handle addition/removal of access profiles, entitlements, and roles to the segment. As far as I know, addition/removal of access in the segment can only be done manually via UI/API.

This is related to the nature of my current Access Matrix, where we mostly define what access a segmented group cannot access rather than what they can access. In the current state, we need to modify the segment access every time there is a new role/entitlement added.

Any comments are appreciated, thanks!

2

@b-julian Segments are assigned based on identity attributes. For example, if a segment is configured using a specific identity attribute such as Department = IT

Currently, SailPoint ISC does not support automatic modification or re-assignment of roles and entitlements when the segment configuration itself is modified. Any changes made to the segment’s assigned roles or entitlements are not automatically propagated to users who are already members of that segment. In your use case, you can leverage a SailPoint ISC Workflow along with the Update Segment API (https://sailpoint.api.identitynow.com/segments/v1/:id) to automate segment updates based on changes in your access matrix.

Whenever there is a change in the matrix, the workflow can invoke this API to update the relevant segment and add or modify the required entitlements, access profiles, roles, or groups. This approach helps maintain segment membership and associated access dynamically without requiring manual updates to the segment configuration. It provides a scalable and automated solution for keeping segment-based access assignments aligned with business requirements.

3

Hello Bintang. Segments in ISC are inclusion-based. When an access item is assigned to a segment, only users in that segment can see and request it. Any item not assigned to any segment stays visible to everyone. There is no native way to say “hide this from group X.”

Since your access matrix defines what groups cannot access, that is an exclusion model, and it does not map directly to how segments work. That is likely why you end up modifying segments every time something new is onboarded.

There is no native deny-list model, so additions and removals would still need to be maintained through the UI or API. A practical approach would be to invert the matrix: if group X should not see an item, assign that item to every other segment except X. That mapping could be built into your access-item onboarding and decommissioning process, or handled by a scheduled script that checks for items missing their segment assignments and patches them.

4

The segments field on access profiles, roles, and entitlements is patchable through their respective PATCH APIs (Patch Access Profile, Patch Role, Patch Entitlement).

To add a segment without overwriting existing assignments, /segments/- should work:

[
  {
    "op": "add",
    "path": "/segments/-",
    "value": "segment-id"
  }
]

For removal, you can retrieve the current assignments with a GET on the access item (for example, GET /v2026/access-profiles/{id}), remove the unwanted segment ID from the array, and send the updated list back:

[
  {
    "op": "replace",
    "path": "/segments",
    "value": ["segment-id-1", "segment-id-2"]
  }
]

If the item is made requestable before the segment assignment is completed, it may briefly be visible to everyone. Keeping it non-requestable until the segment PATCH succeeds should help avoid that gap.

The public Patch Segment endpoint updates segment properties such as name, description, owner, visibility criteria, and active status. It does not modify the access-item assignments. For a consistent approach across roles, access profiles, and entitlements, updating the segments field on the access item itself would be the way to go.

Segments only control Request Center visibility. They do not automatically assign or provision access to matching users.

5

"those roles and entitlements will be automatically assigned to users who meet the segment criteria."

Hi @vikaspawar0303 , I may be interpreting this differently, but I wanted to add a small clarification in case we are referring to Access Request Segments.

My understanding is that segments determine which roles, access profiles, and entitlements a user can see and request in the Request Center. Matching the segment’s identity criteria does not automatically assign or provision those access items. The access would still need to be granted through an access request, role membership, lifecycle state, or another configured assignment mechanism.

6

this is :100: accurate. @vikaspawar0303 I suggest you update your response so that future users will not be mislead. Appreciate your understanding

7

I see, so it is build with inclusion model in mind. Will work on revising the matrix then. Thanks all for the feedback!