Prioritizing Systems Integrations

Avoiding the biggest mistake

The biggest mistake that identity management implementers make is biting off way more than they can chew – we all have grandiose ideas of integrating all of the company’s systems and fully automating them, too! It never sounds that hard when the team is sitting around the conference room table, excitedly brainstorming.

Unfortunately, it doesn’t work that way but as it turns out, fully integrating every last system with identity management is a bad idea anyway – at best it will be costly, at worst impossible.

Reality is that most systems will not integrate out-of-the-box. For those that don’t, full integration means extensive custom coding to ensure a comprehensive two-way interface between the identity manager module and the target system. Legacy systems that are particularly “old” (in technology years, that is) may lack protocols in common with identity manager, making a full integration impossible.

The good news is that fully integrating every system with identity management is not necessary to have a successful implementation. The key to success is effectively deciding which systems warrant a full integration, where an indirect interface will work, and which systems do not require any interface at all.

It is important to carefully consider which systems will require integration at the beginning of the process –ideally before the product is chosen or design work is started – as this decision will drive many of the product requirements. This also focuses the data/process cleanup and other preparatory efforts on the right systems at the right time.

A proper prioritization now ensures maximum efficiency going forward.

But first, a few notes…

B2E and B2C

Much of the focus in this series is on B2E (business-to-enterprise) implementations – that is, identity management within the organization for employees and non-employees using company systems.

When appropriate, I will touch on B2C (business-to-consumer) implementations, but in general, from a process and data cleanup perspective, B2C implementations are much simpler. The typical B2C implementation may seem much larger because it has so many users (possibly millions) and there are some additional technology challenges (e.g., ensuring that the user interface works with any browser), but there is usually only one target system (or maybe a couple), and all users get the same permission set. In a B2C environment, it is important to get a few key decisions correct, and then apply them successfully – a lot.

B2E implementations on the other hand have comparatively fewer users but many target systems, and the complexity of permutations of access can be tremendous. Successfully solve the process and data problems in a B2E identity management implementation and there will be few new challenges with a B2C implementation.

Source of record

“Source of record” – sometimes also called “authoritative source” – is the system that is always “right” with respect to a particular data element. For example, the HR system is typically the source of record for employee numbers. If there is ever a discrepancy in someone’s employee number between HR and another system, whatever HR says is the right answer. Similarly, the email system is the source of record for email addresses. For userIDs, identity management is the source of record.

Although this may seem pretty obvious, it can get fairly complex – especially in organizations with multiple HR or email systems that do not interface with each other. Consider creating a map to identify different data elements that will be important in the identity management implementation, and specifying the source of record for each.

Source of record key point #1: Although one system can be the source of record for multiple data elements (e.g., HR is the source of record for title and employee number), there should NEVER be multiple sources of record for one data element (e.g., LDAP and Active Directory are both the source of record for John’s location).

So what is the source of record for userIDs if there is no current identity management system in the enterprise?

Since userIDs are central to identity management, the answer to this question matters tremendously. Maybe initially the “source” is a database or even a spreadsheet – it’s probably dirty data, but it may be all that’s available. Once the data is cleaned and identity management is implemented, identity management becomes the source of record for userIDs.

This brings me to the most important point about identity management…

Source of record key point #2: Just because it’s the source of record (or authoritative source, which makes it sound even more important) doesn’t mean it’s accurate! Identity management is only as good as the data it receives. A key failure of many identity management implementations is not the technology or even the efficiency of the underlying processes – it’s the lack of accuracy in the source data.

I cannot emphasize the importance of clean data enough, and that’s why the next couple of articles will be focused solely on data cleanup. Unfortunately, some data cleanup goes way beyond an identity management implementation. Many organizations find that HR or other source data is at best missing or outdated, at worst outright wrong. That’s a whole ‘nother can of worms that we’ll discuss later.

For now, let’s get back to this article – prioritizing systems for integration/interface with identity management.

Prioritizing systems effectively

Priority 1: Sources of record and other primary systems

There are several key sources of record that must fully integrate with identity management. Chief among these are:

• Human resources (may be multiple systems)
• Directories (LDAP, Active Directory, etc.)
• Email system(s)

Beyond these “universal” systems, each organization will have other essential systems to be integrated. A guiding principle for success is that any system that is a source of record for a particular data element required by identity management should be fully integrated, meaning that there is two-way communication between the target system and identity management, allowing for automation of data exchange, provisioning/deprovisioning, etc.

Any system that is a source of record for key identity management data is considered Priority 1. The list may stop here, or there may be other primary systems that warrant a priority 1 classification. Here are some criteria for categorizing other systems as Priority 1:

• easy to integrate out-of-the-box
• business critical
• large numbers of users with high user turnover

Selecting the right Priority 1 systems makes the project team more likely to experience an immediate benefit in terms of user experience, achieved ROI, and/or increased security/reduced risk.

Priority 2: Secondary, complex, legacy, or small – but still important

Priority 2 systems are on this list for one of several reasons:

• they meet Priority 1 criteria but the integration would be extremely complex
• they’re important systems but there aren’t *that* many users
• they’re important systems but too “old” to integrate

When faced with a Priority 2 system, consider these options:

• create a generic process that tracks what access is granted via identity manager
• identify the information that is needed and how frequently, and design a data export to a simple flat-file that can later be batch uploaded to role manager on a schedule
• spend the extra time and money on a custom integration

The first option – the generic process – combined with manual workflow and a one-time “dump” of users that already have the specified access allows for the tracking and automation of workflow tasks, which is a step in the right direction. But it is very important to know that this solution does not facilitate user recertification, because there is no interaction with the target system.

The second option – flat-file data transfer – is totally unglamorous, but viable. Careful analysis is needed in this case. In some situations, this option is fairly simple to implement, and provides a lot of benefit. In other cases, this option is not much less work than a full custom integration – if that’s the case, might as well go for the whole solution.

Both options preclude auto provisioning/deprovisioning. Only a full custom integration will allow for that, but from a user management perspective, the challenge is doing the right thing at the right time – especially as far as the auditors are concerned. Most often the problem isn’t administrators failing to do their job – the problem is administrators not knowing there is a job to be done. If identity management can initiate the right tasks at the right time, 90% of the problem is solved. Sure, having it happen “automagically” is better, but the most important thing is that it just gets done.

Leaving some out – at least for now

One of the main tricks in the successful implementation of identity management is to know when to say when.

Whether because they’re too old or too small, there will be some systems that just shouldn’t be on the integration list – certainly not now, maybe not ever. The interesting thing is that one or two of those may be “important” systems from an audit perspective.

For example, we have a financial application at my company that is largely automated so it only has three users – we’ve had one user change in the past two years on that system. But it’s on the SOX list and the auditors are always very interested in this application. Even though it’s a critical application, we have no plans to integrate it with identity management. This is an extreme example, but we have another application that is also on the SOX list with maybe 1-2 dozen users. This application is managed by a single administrator who knows every user personally. Any benefits we would gain from automation (user recertification, transfers, terminations, etc.) are negated by the administrator who often knows what needs to happen for each user before HR even finds out. It’s simply not worth spending the time and money to integrate with such an application because it is already so well controlled.

Populating the requirements list

Although we won’t be discussing requirements in detail until later this year, we’ll actually start building requirements along the way based on working discoveries.

After this month’s exercise, you should have a good idea about what needs to integrate, and to what degree. Ask your engineers to spend a little time examining the protocols that are used by your Priority 1 and 2 systems, as well as the APIs or other integration technologies that may be available on each system. These items will feed your requirements list – especially those pertaining to Priority 1 systems. If an identity management product cannot adequately “talk” to your Priority 1 systems, that may be grounds for instant elimination from the candidate pool.

Action Recap

This month, we covered the following key actions:

1. Identify data elements important to identity management and their source of record – create a map to determine which data elements come from which system, and make sure that none of the data elements have multiple sources of record
2. Prioritize systems to integrate with identity management – sources of record and high-volume systems come first; smaller and harder to integrate systems come second. Some systems should not be integrated at all
3. Start a requirements list – how could/would an identity management product integrate with the systems on your priority list?

How can I help?

Do you need some clarification or additional assistance? Do you have an experience to share with others? Leave a comment below so we can all improve together.