I have a potentially unique challenge at my organization, we have several PeopleSoft sources that contain roles that have additional layers of security that is not visible to SailPoint. Non role based functional security (Row-level security). This security exists outside of the normal tables that SailPoint uses to aggregate entitlements and is not role based and is cumulative, so a user could have any combination of Departments (HR, FIN, REG etc.), and Control access (READ, EDIT, DELETE, etc). Currently we handle that access via manual assignment, either by filling in comments in the requests within Sailpoint or having end users create a jira ticket for updates to those permissions.
We’d like to marry the solutions or come up with a more elegant way to request the access and subsequent changes to the access. Whether workflows or launchers or whatever, you name it, we have tried it. None of the straightforward approaches really seem to result in a solid solution. Is there anyone out there who has delt with this extra layer of security? Or has anyone with Peoplesoft sources successfully integrated functional security into SailPoint?
I think you’re not alone—PeopleSoft’s row-level security (dept trees, setIDs, control flags) lives outside the role/permission-list model SailPoint sees out-of-the-box. The clean way to bring it into SailPoint is to treat that layer as its own application with a thin REST API/db facade and model it as parameterized entitlements instead of trying to explode every combination into roles.
Below is a pattern I’ve seen that customer used in IIQ.
Ask your PS admin to expose three things (DB or REST; DB is usually simpler):
Grant proc grant_rls(oprid, dept_id, control) → inserts/updates row-level grant
Revoke proc revoke_rls(oprid, dept_id, control) → removes the grant
Read view v_rls_assignments(oprid, dept_id, dept_name, control) → one row per grant
Model a “PeopleSoft-RLS” Application in IIQ
Type: JDBC (or Web Services VA if you have REST)
Accounts: represent PeopleSoft users (OPRID).
Entitlements: a single multi-valued attribute, e.g. RLS_GRANT, where each value is <DEPT>:<CONTROL> (e.g., HR:READ, FIN:EDIT).
Alternatively, use the Groups schema and make each ManagedAttribute’s native identity <DEPT>|<CONTROL>.
Aggregation (read-back): point the Group/Entitlement aggregation at v_rls_assignments so IIQ pulls the exact dept/control combos each user has.
I believe the above combination marries request, approval, provisioning, and certification without blowing up your role catalog. Start with the JDBC path; you can drop in the stored procs and the view in a day, model the app in IIQ, and wire the LCM form + rules.