In part one of our series on data, we discussed how data is the lifeblood of any IAM system. To recap, IAM systems manage the authentication and access of users to organizational systems, applications, and resources. Each user has an account that’s used to log into different applications and systems. Depending on who a user is and his or her attributes, the IAM system determines what the user has access to and what he or she can do within those systems.
As such, your IAM system expects a certain amount of source data to be provided and for it to be clean, consistent, and complete. Any data irregularities can have an impact across the entire IAM system, creating significant challenges for your organization.
Now that we better understand how IAM systems leverage user data, it’s important to examine some potential data challenges and the effects they can have. And while there are many challenges on the data front, these are the top three issues we see; the ones that can have the biggest impact on your IAM implementation and operations.
The Top Three Data Challenges:
1) Bad Source Data and the Ripple Effect
The number one data challenge we see stems from pulling complete and accurate data from authoritative source systems. When there are unexpected changes in the source data schema or if the data is corrupt, this typically causes the IAM system to break or incorrectly process the data, resulting in unexpected behavior for users, applications, and systems. Because all policies and configurations inside the IAM system and downstream rely on that source data, if the IAM system receives bad or corrupt data or processes, there will be a massive ripple effect downstream.
Finally, when the authoritative data is not in a single system, but spread across numerous source systems that must be reconciled and associated, it is generally more difficult to resolve data challenges. This is because there are usually multiple systems owners, the systems are managed by different organizational departments, and other technical dependences among those data systems that indirectly prohibit effective data processing.
2) Managing Non-Identity Data with Your IAM System
So far, we have been using the term “data” in a general sense, but we need to clarify that only identity data should be processed by your IAM system. Your organizations has lots of data about your users in many different systems, but only a small fraction of that information is needed by your IAM system and target systems for identity management purposes.
When you start including lots of non-Identity, application-specific data in the identity system, you push the IAM system away from its core competency; the IAM system becomes a data processing system and the focus is moved away from identity management.
Instead, a separate data processing system should be used to manage non-identity data that works hand-in-hand with your IAM system. For example, in the education space, roster data is student, course, and related enrollment information that’s provisioned between various platforms, such as a student information system (SIS) and a learning management system (LMS). While this type of data is related to a user’s identity, it shouldn’t be part of the IAM system. In fact, we have a service dedicated to managing roster data in order to keep it separated from traditional identity data.
3) Poor Data Governance
Two specific data governance challenges are which system and/or attribute is authoritative for what data AND who should be able to access what data elements. A good data governance structure is crucial to making the right decisions when these scenarios are presented.
Many times, there is a debate within organizations about which systems and attributes will be authoritative for the different data elements needed for the IAM and integrated applications. A piece of data, like “First Name” seems simple to identify, but do you get it from the Employee Registration System, HR System, or Payroll?
Similar conversations center around which data attributes can be collected from which authoritative systems, what data should be visible to different users in the IAM system, and what should be allowed to be transferred to the different target systems (and by whom). And while these conversations can be amusing at times, they often significantly hinder implementation and integration efforts for IAM deployments.
Addressing Data Challenges
And there you have it—bad source data, non-identity data, and poor data governance—while hardly a comprehensive list of the data challenges your organization could face during an IAM implementation or even during the ongoing management of your IAM system, these are the big three we see that are most likely to derail your IAM project.
While the easiest way to avoid issues is to start with complete and accurate data, we all know that’s easier said than done. However, planning, open communication, and implementing good, consistent processes can go a long way towards mitigating these challenges and the associated risks.
Stayed tuned for the final part of our series where we take a deeper dive into the data best practices and challenges you should be following.