As there is no Native Change Detection functionality in Identity now. Is there any other process that can be done for Native Change Detection in IDN?
If user account access has been created or removed or status changed or new account created in downstream application directly, outside of IDN then IDN should detect those changes and revert back the changes in the downstream Application. Is there any process we can automate this in IDN?
Thank you for joining our community @PabiMalla!
The best way to manage accounts and entitlements on a source is to let IDN do it through connectors. SailPoint’s official connectors should be able to provision accounts and entitlements without manual intervention, but you may have custom connectors for your SaaS apps or on-prem apps that don’t have the same level of functionality. If a custom connector for your source doesn’t support account provisioning, then next I would look into updating the connector code to support that functionality so source owners don’t need to manually provision accounts. If all of your sources in IDN can provision accounts, then there should be no need for source owners to manually create accounts directly in the source. To enforce IDN as the sole mechanism for managing source accounts, I would consider training application owners to use IDN for account management on their applications, and then restrict admin access on the sources to only those application owners that are trained on the proper process.
That being said, change detection in IDN is supported through our event triggers, which provide a real-time mechanism for detecting when changes are made within IDN. ETS can detect changes, such as identity created, and alert you in real-time. ETS is purely used for detection and has no mechanism for action, such as reverting a change. There are various ways you can consume ETS, such as custom applications, iPaaS platforms like Zapier and Workato, or our new Workflows tool within IDN. Each of these methods will allow you perform actions based on an event, but they will require some level of coding experience to implement. In theory, you could use one of the approaches I mentioned to detect when an change has occurred, figure out if the change came from IDN or from the source application, and then execute some logic to revert the change on the source application.
Thank You for your response. Does event triggers detect changes that happen in Active Directory(not authoritative source) such as new identity created or deleted or attribute change or entitlement removed or added directly in AD not through IDN?
Identity attributes are typically tied to authoritative sources, so the identity triggers probably won’t work for your non-authoritative sources. However, we are working on triggers for account created, account deleted, and account attributes changed, which will trigger on any source. These will be released in beta soon (exact date to be determined). The caveat here is that these triggers won’t indicate where the change originated, only that a change happened. You will need to use other IDN APIs to determine where the change originated.
I haven’t explore the workflows functionality yet. Can we do anything in workflows to detect the source where changes were happened? Can you please provide the IDN APIs to determine the
where the changes(like account create, deleted, attribute changed and entitlement changed) originated.
Thank You
We’ll have to wait and see what information the accounts trigger will provide, but I believe that account activities will be very useful in determining whether the change came from IDN or the source.
For example, if you receive an account created trigger event, you can cross reference the identity the event applies to with the account activities API. I think if the requesterIdentitySummary is null, then it’s likely that the account was created directly on the source, but you’ll have to test this theory to make sure it is valid.
Native Change Detection is now an officially supported feature of IdentityNow. Check it out here.