SailPoint IIQ + Microsoft Teams Integration — How is Security Managed Between SailPoint IIQ and Azure?

IdentityIQ (IIQ) IIQ Discussion and Questions
, , , , , , ,
1

We are integrating SailPoint IdentityIQ (IIQ) with Microsoft Teams for notifications and approvals. We already have the SailPoint documentation covering the integration setup, so we’re good on the implementation side.

What we’re specifically looking to understand from those who have done this is how security is managed between SailPoint IIQ and Azure, particularly:

  1. Azure App Registration — What permissions (scopes) did you configure in Azure AD for the IIQ service account? Did you use delegated or application permissions for Graph API calls?

  2. OAuth2 / Client Credentials — How are the client ID, client secret, and tenant ID stored and referenced securely within IIQ (custom object, encrypted attribute, or external vault)?

  3. Token Lifecycle — How does IIQ handle Azure AD OAuth2 token refresh mid-workflow? Did you build a custom token management rule?

  4. Service Account Governance — Is the Azure service account used for Teams integration itself managed/provisioned back through IIQ, or handled outside?

  5. Audit & Logging — Are Teams-triggered approval actions (approve/reject) written back into IIQ audit logs for compliance traceability?

We have the integration working conceptually but want to ensure the security architecture between IIQ and Azure is solid and auditable before moving to production.

Any real-world experience, architecture decisions, or lessons learned would be very helpful!

2

@jchinnapareddy We don’t have the integration with Teams, but based on other docs/post sharing below details:

  1. Azure App Registration: you’ll need to configure below permissions in IIQ App register in the AzureAD.
    Chat.ReadWrite.All for sending approval notification
    ChannelMessage.Send incase sending it to channels
    User.Read.All for user details
    TeamsActivity.Send for activity feed notifications.
  2. OAuth2/Client : IIQ stores it in encrypted format in IIQ. In case you have PAM enabled in IIQ.. you can store the creds in vault and no need to store it in IIQ.
  3. Token Refresh should be an internal builtin functionality like it does for other API based applications/integrations.
  4. Governance: You might want to review your service principle and service account define in Azure periodically to make sure all permissions are still in place. no over privilege being done. You might want to setup a separate process to make sure only allowed users have access to the service account.
  5. There are OOTB audits available in LCM. Not sure about the exact key, but you should be able to see in Audit, if you have done testing.
3

Hello @jchinnapareddy, my answer will aim a different scenario but might point you to some direction.

We integrated Microsoft Teams with Moveworks; and we have set up an AzureAD connector on our Moveworks instance to do this process, the credential were stored in the Moveworks intance; however for your case my advice would be to set them in a vault(if your org have one).

My two cents is that the workflow should be the same, good luck and please do help me marking my answer as solution. :saluting_face: