IAM Best Practices: Initial Population Of ID Stores

Share on linkedin
Share on twitter
Share on facebook

At the heart of it, Identity Management solutions are intended to help make identity management easier, not more difficult. However, when not properly implemented, solutions that are designed to help can really seem more like a hindrance. Let’s talk best practices for ID stores, a basic component of a good overall IAM solution.

Why ID Stores?

Identity management solutions are designed to aggregate authoritative data on users and support the automation of the identity lifecycle, from the creation of the user’s digital identity for “joiners” to the removal of the user’s identity for “leavers” within an organization. Once established, a valid user account supported by proper identity management offers the following benefits:

Easy On-/Off-boarding of Users 

Simplifies the process of onboarding users to new digital services, because their identity has already been verified and synchronized to consuming applications and systems based on defined business rules. Likewise, access is automatically removed when the user leaves the organization.

Single Sign-on Authentication

When logging into existing services, the IAM solution manages the user’s  login information (username and password, and the second factor) for many different services.

Role Based Access Control

Once users log in, IAM evaluates the attributes on the user, such as job title, manager, and location to assign them to a role that defines the user’s level of access in the organization. This reduces the need for manual rights administration, supports the security principle of Least Privilege, and reduces the audit/compliance burden on the organization.

For organizations that have relied on manual processes, the complexity of shifting to the digital management of a large user population is mitigated by having a preexisting census of user data in an authoritative source. 

At the heart of the identity management solution is the central identity store that contains a record for every UserID under management by the organization (For example, employees, contractors, vendors, and partners). This central identity store is typically a directory (i.e., a type of database) that is populated with accurate user data. The initial population of the ID Store is one of the critical steps in setting up any identity management solution. 

Some pitfalls are well known, and attempts to shortchange the process and move forward with a simplistic view that HR has all the demographic data are especially treacherous. The 6 Steps outlined below will help you successfully set up your identity store.

  1. Identify Authoritative Sources

An authoritative source is a system or database that has accurate and up-to-date information on users. Human Resource systems are typically used for employees, since the HR team actively manages employee data for compliance and payroll purposes. For contractors, some organizations leverage their HRIS system, a vendor management system, or use their own custom database to track and manage contractor identities. 

  1. Define Schema for the Identity Store

The Identity Store is based on a directory, which allows you to more easily manage network resources such as users, servers, printers, and applications. Each resource has an object and each object has attributes that can store information about the resource that network systems and applications would find useful. For example, user objects can store names, mobile numbers, photos, Employee IDs, office addresses, job titles, departments, and manager information. The definition of the schema determines what data we will store and maintain on each resource. Identifying that data, or set of attributes, begins by asking the question, “What is important for our business processes, governance, and access management?”

Note that a flat structure is the best approach for designing the containers in your Identity Store. This approach eliminates the need to move users from one container to another and puts the emphasis on using attributes on the user object to manage access instead of where that object is located in the Identity Store.

  1. Create a Data Dictionary

For each attribute in the schema, we must identify the authoritative source for that attribute, the data type (string, integer, etc.), the field length, and understand how the data flows from the source, to the Identity Store, and then to consuming systems. We not only have to identify the source for each data element, we have to make sure that element is available for every identity. The importance of data quality (accurate, current, available, etc.) is a key element to consider when building the dictionary.

Think about defining a “minimum data set” to create an identity for an employee or a contingent worker. Typically, this is a set of 15 to 20 attributes that are required to establish a functioning identity. These attributes typically include first name, last name, email, manager, department, location, etc.

  1. Establish Unique Identifiers

Many organizations choose to use multiple Unique Identifiers from local systems and store those on the user object, to ensure the user account is properly identified. This tactic can be very useful in organizations that have historically managed user access through manual administration.

As an example, the EmployeeID from the HR system is a unique identifier in the HRIS which would be stored on the user record. The user’s email address, which is unique for the organization, would also be stored on the user object. If both identifiers do not match on a transaction (e.g. update, activate, terminate), then the transaction fails and an administrator will have to reconcile the issue.

  1. Initial Population in DEV Environment

Once the data sets have been defined, the next step is to prepare the initial data load and test out the results in the Dev environment. We recommend doing an ExtractTransform, and Load (ETL) to compare values across systems. For example, do your HRIS and Active Directory data stores have the same information on the user? Do the values match? Some organizations allow users to update profile information in AD, such as preferred name, office, mobile, and the like. In this scenario, AD may have more up-to-date information on the user that HRIS so overwriting user data from HRIS can cause problems by updating user profiles with bad values.

  1. Evaluate & Remediate Data Quality

Once the Identity Store has been populated in DEV, you can see if there are fields that are sparsely populated, improperly mapped, or have unexpected values. An unexpected value can occur when a field such as ‘Department’ has a value that did not originate from an authoritative source.  This assessment of data quality is where we learn what data is important and needs to be fixed right away.

Regulations – Always A Consideration

One final thought to consider is that there are now many regulations in place that govern user privacy and what data can be stored about your users. The purpose of these regulations is to protect individual’s privacy, their right to manage their digital identity, and to give some control to the end user. GDPR (General Data Protection Regulation) is probably the most well-known of these regulations and should be familiar to most organizations by now. GDPR regulates how organizations are allowed to collect, store and use personal information about individuals and will have an impact on what data you collect and store on your users; including where you are allowed to store that information (e.g., in a data center/Cloud instance hosted within the EU).

Still in need of some more knowledge or guidance on ID stores? Contact Idenhaus today!

Written By Hanno Ekdahl

Share on twitter
Share on linkedin
Share on facebook
Share on pocket
Share on email

Leave a Comment

Your email address will not be published. Required fields are marked *

About Idenhaus

Idenhaus is an award-winning Identity Management and Cybersecurity services firm based in Atlanta, GA.

Follow Us

Recent Posts

Newsletter Signup



top 25 iam blog idenhaus

Why You Need An IAM Roadmap

Scroll to Top