Anyone familiar with identity management is well aware that not all data is created equal. Many times we get data that isn’t exactly in the state we’d like it to be. One instance I’ve seen many times when working with data for SailPoint IIQ is to get data in what can be described as a horizontal format rather than a vertical format for a CSV file. A data file that would be very easy to aggregate within SailPoint IIQ may look like the following:
USERNAME, PROFILE, BUSINESSUNIT user1,Administrator,1 user1,Administrator,2 user2,Super-User,1
This data is fairly basic, there’s a username attribute, a profile attribute, and a business unit attribute that is multivalued. This data would be able to modeled in SailPoint using a basic delimited flat-file application by merging the data on USERNAME and marking BUSINESSUNIT as multi-valued. This is to me the easiest format when working with SailPoint IIQ. However, the same data could be expressed in the following format:
USERNAME,ATTRIBUTE,VALUE user1,PROFILE,Administrator user1,BUSINESSUNIT,1 user1,BUSINESSUNIT,2 user2,PROFILE,Super-User user2,BUSINESSUNIT,1
In this format, the attribute names and values exist on the same line. The attribute requires both entires in the line. To model this data in SaillPoint IIQ, we will transform the data from the horizontal structure of the second file to the vertical structure of the first. To make this even easier, we can do the transformation in a single line of code. To enable the transformation, we first need to modify the application’s schema. Rather than naming the ATTRIBUTE and VALUE, we create the schema to include the attributes USERNAME, PROFILE, and BUSINESS UNIT. Like the first set of data, we merge the data on USERNAME and mark BUSINESS UNIT as multi-valued. We then create a buildmap rule with the following line of code:
map.put(map.get(“ATTRIBUTE"), map.get(“VALUE"));
Using the example, the line of code will place Administrator as a value of the attribute PROFILE. Transforming the data makes it more readable and makes certification decisions easier. The only downside I’ve come across with this transformation is during provisioning. If you’re using the PIM to automatically provision accounts, then the data will have to be translated back before the provision event to match the initial input stream.