SailPoint is exploring a new and exciting business problem to determine how we can get ISC customers up and running faster than ever before. To do so, we want your feedback on how clean you view your authoritative ID source data to be.
Business Problem
SailPoint and your authoritative source are like peanut butter and jelly. We are interested in understanding your current experience with data quality in your authoritative source. Do you view authoritative source data clean even when connectivity has been established to the governance tool?
Please fill out the below survey to provide your input and feedback on whether or not clean data affects your organization. Participants will receive 30 points to the Ambassador program.
As much as we want authoritative systems to be authoritative as policy and procedures should revolve around the authoritative data, it just isn’t a reality. Customers need compliance with an IGA system and can’t wait to cleanse their data. Often times cleansing the data, perfecting the processes and procedures is a phased approach.
The Identity System needs the flexibility to be able to massage the data when the source system isn’t able to. The Identity System needs to be able to be an Identity Vault and be an authoritative system where it needs to be.
A possible solution is to have a staging area for the aggregation can be manipulated. That staging area can be validated in the cloud and once it is ready, it can then store the data in the collector’s account source in the cloud.
The tooling needed to massage the data could be something similar to Python Pandas, where the data frames can be massaged, but also where logic additional data could be written to from a workflow. Example, HR isn’t allowing changes to their views currently. Allow a new account attribute to be created in the cloud in the staging area that would also sync down to the current connector account source. Let’s say a new field needs to be populated for immediate termination. Workflow is built to allow a form submitted by a manager to immediately term someone. The workflow writes the data to the staging area. Aggregation detects and event and automatically sends it to the account source and a refresh on the Identity happens. No need for having a third party JDBC database and separate UI to trigger an immediate termination.
HR source -->> first aggregation stage → > Staging Source allowing IGA authoritative attributes and manipulation of data similar to Pandas dataframe as well as allow workflows to update ISC authoritative data associated to the source -->> Event driven changes / aggregation to current account source – > Identity Profile Mappings and transforms handle Identity Attribute generation → Attribute synchronization to downstream systems.
This would also be ideal for entitlements. Often times a customer CSV data from an application does not conform to a standard where it must be cleaned up. As an application owner may not want to hastle with the data to conform it, this would be a good place to massage the data so that it conforms to the account schema.
I think this is highly dependent on the organization’s goals in implementing an IGA solution. If the primary goal is compliance, it’s critical that the controls the organization has in place account for the source of the data and put the onus on the owners of the authoritative systems to enforce data integrity. If my organization has SOX controls that say that ISC takes data from Workday and bases access on that Workday data, it is not the IAM team’s responsibility to correct that data on the SailPoint side - in fact, doing so could cause issues at audit time when there are unexplained actions taken by SailPoint admins. Conversely, if your organization’s goals put more emphasis on security rather than compliance, it is entirely reasonable to massage the data to get it into a more usable state.
Unfortunately, organizations tend to care more about one than the other: your program is either compliance-driven or security-driven, but realistically, not both. I prefer a security-driven approach, personally, as compliance doesn’t actively protect your organization from breaches in the way that the GRC team would have you think it does (Kevin Mandia made the point at his Navigate keynote that all of the companies that have high-profile breaches have passed all their compliance checks, and how much good did that do them).
The idea is to enhance the data where needed. Having it done through ISC would allow for reporting and auditing of any data manipulation. The modifying of the authoritative data, or adding to it would be policy based within the organization. An auditor would be able to see the source data, how it is manipulated within ISC, etc.
By not having the flexibility you may have customers manipulating the data through scripts or other methods before it touches ISC. My .02 cents would be that we would ingest the data regardless of format. Then allow the data to be manipulated if needed in a format that is controlled and reportable.
Another example: manager requestable form is filled out within ISC to immediate term someone. A workflow picks it up and validates the form, goes through approvals as needed and triggers the removal of requested roles, sends an email notification where needed, then sets the HR internal source attribute that is within ISC but not the Hr source for “IMMEDIATE_TERM”. That change triggers an event for the Identity to re-calculate the lifecycle state, it sets them to the appropriate LCS and that then triggers the various connector rules to remove entra tokens, disable account, etc. The possibility for the workflow to write directly back to an ISC account attribute for an internal ISC operation that is not modifying the Identity Data, but is updating a process. No need to wait for aggregation or to manually have someone go to each account to disable them as needed.
What if HR doesn’t have a preferred name Field but allow ISC to manage it. A form could be filled out, a workflow has an approval, and if management approves it we write to a new ISC account attribute for a preferred name that would be tied to that source, but not written directly to the source. Then if HR ever has a field for the preferred name, it can be authoritative. It could be a temporary stop gap if needed.
I don’t think the idea is for ISC to be authoritative for data that is currently coming from the source.