I’m working with the Certification APIs in SailPoint IdentityNow (ISC) and facing a challenge around user context and audit attribution.
Current Setup:
I’m using a client credentials (service account) token to call:
Certification Decision API (/certifications/{id}/decisions)
Certification Sign-off API (/certifications/{id}/sign-off)
Both APIs are working as expected from a functional perspective
Issue:
All actions (decisions and sign-offs) are being recorded as performed by the service account
However, the actual decision is made by a reviewer (human user), and I need that user to be reflected in the audit report.
Requirement:
Execute both decision and sign-off actions such that they are attributed to the actual reviewer
Maintain accurate audit/compliance records/report showing the real decision maker
Challenges Observed:
Client credentials flow does not include user context
ISC workflows do not seem to expose the reviewer’s access token or session context
I don’t see a supported way to impersonate a user via the Certification APIs
Questions:
Is there any supported way to invoke the Decision and Sign-off APIs so that actions are recorded under the reviewer’s identity instead of the service account?
Can user context be passed or derived in any way (e.g., via identityId, headers, or workflow context)?
Are Authorization Code flow or PAT tokens the only supported approaches to achieve reviewer-level attribution?
How are others handling this in automation scenarios (e.g., workflows, external apps) where decisions are triggered programmatically?
Need to ensure that certification decisions and sign-offs are attributed to the actual reviewer, not a technical/service identity.
Any insights or recommendations would be greatly appreciated.
There is no supported way in SailPoint IdentityNow to have certification decisions or sign‑offs attributed to a human reviewer if you call the APIs using a client credentials (service account) token.
ISC always records the actor from the OAuth token, and service tokens will always show the service account in audit logs.
You cannot pass or override user context (identityId, headers, workflow data), and workflows cannot act as the reviewer. Impersonation is not supported.
The sign-off will always be attributed to the identity tied to the OAuth token making the API call. There’s no supported way to pass a different reviewer identity in the request.
Thanks for the clarification. I understand that using a client credentials token will always attribute the action to the service account in ISC.
I wanted to ask— is there any supported way to obtain or use a user’s OAuth token in IdentityNow, so that certification decisions or sign-offs can be attributed to the actual human reviewer?
In IdentityIQ, we’re able to establish user context for such operations. Is there any equivalent mechanism in IdentityNow to achieve this—such as obtaining a user-scoped token based on the user’s identity (e.g., login ID)—or is this completely unsupported in ISC?
No — IdentityNow (ISC) does not support user‑scoped OAuth tokens or establishing end‑user context for API‑driven actions. There is no equivalent to IdentityIQ’s “run‑as user” or user context execution model.
If this clarifies your doubt, you can safely mark this as the solution.
You can’t really do what you want to by using the user identity with the certification API. In ISC the sign-off is going to be attributed to the identity behind the token making the call, so if the call is made with a service account token, the audit trail is going to show the service account. You just want the service account to find the relevant items for you. When the actual reviewer approves, revokes, or whatever, make that API call using the reviewers own authenticated user context… although I’m not totally sure that this is within the parameters of what you are trying to design here. Does this make sense? Maybe someone else on this thread can add some more real-world examples on how to achieve this?
ISC doesnt do the same kind of “user impersination” that IIQ does, so you have to think differently when designing this sort of solution in ISC.