We are currently running SailPoint IdentityIQ 8.5 and looking into implementing email-based approvals for our managers and application owners. Our goal is to allow users to approve or deny Lifecycle Manager (LCM) access requests simply by clicking a link and replying to their notification emails, reducing the friction of logging into the IIQ User Interface.
Since IIQ does not natively include an inbound email parser or a “reply-to-approve” loop out of the box, we are planning out a custom integration pattern.
Any architectural blueprints, sample code/scripts, or lessons learned from your own deployments would be greatly appreciated!
@jchinnapareddy You would need to create a plugin with necessary endpoints to make it work. Also, for clickable links to approve/revoke, user still need to authenticate themselves to have a user session, then only it’ll approve/revoke. Otherwise you’ll need a proxy application which can make API calls using service account to take the decision. I have worked on a similar project last year, if you have any specific technical queries, we can connect.
Best approach would be to create a custom Plugin or REST endpoint and include Approve and Reject links in the email. When the user clicks a link, it updates the corresponding LCM work item without requiring them to log in to IIQ.
If you want true reply-to-approve functionality, you’ll need an external email parser that reads the reply and calls the IIQ API or Plugin to process the approval.
JaganMohan - Create a plugin + use service account for API calls plugin REST endpoints in IIQ can be called without a user session if the plugin handles auth internally.
This is the approach we are thinking , But we still we are working on design
The email-approval solution lets approvers act on access requests directly from their inbox instead of logging into IdentityIQ. When an approval is needed, IdentityIQ emails the approver a message with two buttons, Approve and Deny, each carrying a secure, single-purpose link that hides all the sensitive request details. These links don’t point at IdentityIQ directly. instead they go to a lightweight proxy application that sits safely in the middle. When the approver clicks a button, the proxy application quietly unlocks the link, confirms it’s still valid and hasn’t expired, and then uses a trusted service account to record the decision back in IdentityIQ on the approver’s behalf. This keeps IdentityIQ protected from the public internet, ensures nothing private is exposed in the email or browser, and—if sign-in verification is enabled on the proxy—makes sure only the intended approver, not someone the email was forwarded to, can complete the approval.
I understand the concern. The goal is primarily to improve the approver experience and reduce approval delays for routine requests. However, we’re planning to integrate SSO so approvers must authenticate before any action is processed. The approval links will be single-use, time-limited, and won’t contain sensitive request details. All requests will be routed through a secure proxy rather than exposing IdentityIQ directly. With these controls in place, we’re aiming to balance usability with security. We’d be happy to discuss any specific concerns or requirements that should be considered.
@jchinnapareddy You need to handle partial decisions as well. Let’s say you have 4 items in approval, but approver need to approve just 1 for now. So you solution should take care of partial decisions and combination of approve+rejections as well.
We are exploring options to implement 1-click email approvals for IdentityIQ Work Items without implementing SSO for the landing action, while ensuring strict defense against link spoofing and replay attacks.
We have mapped out two potential approaches and would love the community’s feedback on best practices, security constraints, and maintenance overhead in a production IIQ landscape.
Approach 1: Tokenized Proxy Application (No SSO)
How it works: A custom workflow rule generates asymmetric, signed cryptographic tokens (using HMAC-SHA256) consisting of the WorkItem ID, Action (Approve/Deny), and an Expiration Timestamp. These are embedded directly as hyperlinks within IIQ HTML email templates.
The Interface: Clicks hit a secure DMZ proxy application that recalculates and validates the signature and check expiration. If valid, the proxy handles the transaction seamlessly on the backend using service account credentials via the IIQ SCIM/REST API.
Pros: True 1-click execution for the user; mathematically impossible to spoof links without the secret key.
Cons: Requires hosting, monitoring, and securing a lightweight custom proxy application middleware.
How it works: Email templates contain standard text-based replies (e.g., mailto links or simple “Reply with ‘Approved’”). A separate, scheduled system task or background process utilizes the Microsoft Graph API to poll and read an active inbox.
The Interface: The parsing script maps incoming text variations to the original transaction ID and processes the approval or rejection entirely behind the scenes.
Pros: No external-facing web proxy applications are deployed in the network architecture.
Cons: Email headers and display names are notoriously easy to spoof; users frequently alter email bodies or reply inline incorrectly, breaking regex patterns and parsing mechanisms.
My Questions for the Community:
Which of these approaches is more standard or commonly approved by security compliance teams for Identity Governance?
For those running Approach 1, did you use a custom REST plugin within IIQ to process the token payload, or did you leverage standard SCIM endpoints?
Are there hidden pitfalls with MS Graph API polling (Approach 2) regarding API throttling, concurrent execution, or email sanitization blockers?