IAM Myth: Indirect Access to Identity Resources

Worst problems with any system have origins in the very beginning. No, it is not the design of the systems that causes the worst problems. Most painful mistakes are made even before the first design diagram is sketched. The problem is not that the system is designed and built poorly. The problem is that an entirely wrong system is built. The problem is usually in the requirements, the specification of what system do we need.

Identity management systems designed and built since early 2000s focused on one part of identity management field: provisioning. We need to create accounts for new employees. We need to quickly grant new privileges to users with new job responsibilities. We need to deploy new application, creating accounts for all users. It was all about creating accounts, enabling access, granting privileges. There were some thoughts about deprovisioning. Yet, deprovisioning was seen as necessary evil, as some annoying requirement from those paranoid security people. Deprovisioning (if there was any) was all about deleting accounts when an employee left. There was next to zero considerations about revoking privileges, auditing, visibility, or information security best practices. That was "somebody else’s problem". As for personal data protection, as far as corporate IT was concerned, personal data were to be monetized, not protected. That was the life in 2000s, and to some extent in 2010s as well. These were the requirements for identity management solutions. It is perhaps no big surprise that identity management solutions did what they were expected to do. They were designed as write-only systems.

Early identity management solutions were build on an assumption that there is an absolute, authoritative truth, that needs to be propagated to all the applications. Many solutions were based on simple scripts that:

This process was repeated every day, or every hour. It worked, kind of. However, even the very first runs uncovered some problems. When it came to deprovisioning, simple overwrite is not enough. All the existing accounts must be deleted first. Except that one cannot simply delete all the accounts. Administration and application accounts must stay. Therefore, these were added to a whitelist, where they remain to this day. Then, deleting an account just be to re-created is not very efficient, it leaves a window when the account does not exist, and it cannot be used on systems where account delete is a complicated process. Simple overwrite has to be re-implemented using more complicated logic, but it still somehow worked. Then it turned out that there, in fact, is no single source of truth. There are several sources of almost-but-not-entirely authoritative information, that needs to be compared, merged, selected and post-processed. Therefore the scripts got more complex, more messy, while still not solving the root problem.

The vernacular identity management scripts were designed for a specific purpose, and they worked well for that purpose. They contained a simple "unified" view of the identity, usually in a form of database table or a CSV file. There is also a lot of knowledge about the target environment hardcoded in the scripts. It may be a very attractive option to re-use them in our new identity governance solution. Instead of dealing with all the messy details of directory service structure we can just make an SQL insert, and the good old script does all the work.

Well, it both does and it does not.

Root of the problem with write-only systems is, of course, missing feedback. The vernacular identity management scripts were good at writing the data. However, they were not designed to retrieve and analyze the information. They were certain that an account exist in that LDAP server, because they have just created it! They did not need to list all the accounts. They did not need to fetch all the attributes. They did not need to check that state of that LDAP server.

However, an identity governance system needs to list all the accounts, retrieve the attributes, checking state of the accounts. That is one of the primary responsibilities of identity governance. Even more than that, governance system needs to retrieve all the entitlements, analyze them, there may be interesting metadata or context, there may be identifiers assigned by the target system, there is so much data that a governance system needs. Write-only systems for indirect provisioning will not provide any of that.

Identity governance and administration (IGA) is all about feedback. IGA platforms are creating, updating and deleting accounts, but they also need to read the data. Typical process is to create an account, and then read it back. The target system sometimes assigns persistent identifiers such as entryUUID or GUID, there may be entitlements that are automatically assigned and so on. Even more importantly, IGA platform needs to list and scan all the accounts, identifying accounts that it does not know account, accounts that do not belong to anybody (glossentry:orphan-account[orphan accounts]), accounts with inappropriate entitlements and so on. Information retrieval is even more important than ability to write information.

Reuse of existing solution may be a very attractive option. Project manager could see it as saving of time and money, engineers would like to avoid dealing with the messy details already addressed in existing solution, or there may simply be a sentiment "we have always done it like that". However attractive it may be, it is always a good idea to carefully consider all the options:

There is one more whole dimension of problems caused by indirect access, albeit the underlying technology is all different. Traditionally, huge part of identity management effort is manual. Accounts are created manually by systems administrators, entitlements are requested by using general-purpose ticketing systems and assigned manually by operators, passwords are reset by helpdesk agents. As identity management (IDM) platform is deployed, some of that work is automated. However, there are always limitations. IDM projects is almost always underfunded and the follow-up activities are almost always under-staffed. Therefore, some systems in the organization are not connected to the IDM platform directly. Manual administration is still used to manage such systems, even though now the tickets are created by the IDM system, rather than the user.

There is nothing fundamentally wrong with such approach, if used correctly. There are indeed systems that are simply not worth the effort of connecting them to IDM system automatically. This may be a very specialized application that on a handful of users can access, with almost no fluctuation at all. It may be an obsolete system that is scheduled for decommissioning next year. There are valid cases for manual identity management. However, more often than not, the manual identity management is vastly over-used.

Development of fully-automatic identity connector is not an easy or cheap thing. Actually, connector is usually quite a small piece of code, and a developer who know what to do can develop the connector very quickly. The problem is to know what to do. The developer needs to know how target system works, needs to learn the interface, the procedures, limitations and peculiarities of target system. It takes time. And there is a large amount of testing, bugfixing and rework until the connector works well. The connector needs maintenance, it may need updates as the target system is upgraded. A connector is relatively small and simple piece of code, yet it is a code nevertheless. It needs development effort and long-term maintenance. It is not cheap.

However, we also have to consider the cost of not developing a connector. If there is no connector to a particular system, using manual provisioning (or rather manual fulfillment) is the next best option. There are costs associated with that, such as the time of system administrators creating the accounts. However, this is only a fraction of the real costs. The problem with manual provisioning is that it is effectively a write-only system. IDM system creates a ticket, but it has no idea what really happened in the target system, and it has no way to check. Therefore IDM system cannot be used to support auditing, audits must be made manually, the 20th century way. There are very likely to be security risks such as orphaned accounts. Orphaned accounts are surprisingly easy to create. It may be a testing account that was not deleted, or administrator deleted a wrong account by mistake, or perhaps a system was restored from backup, effectively rolling back the delete operation. Very limited visibility to target system is likely to be a source of misunderstanding, lot of time wasted in calls and meetings. However, perhaps the worst effect is lack of any meaningful analytics. As IDM system cannot see into the target system, at cannot analyze the data. It cannot issue warnings, there is no practical way for role mining, configuration of the system will never improve. It will be difficult to automate data protection policies. The system will be a liability, it will pull all other identity management and governance activities down. The costs will add up.

It may not be possible to create connectors for all the systems, especially at the beginning of IAM program. However, some IDM systems (such as midPoint) provide ability to use semi-manual connectors. Semi-manual connectors do provisioning activities manually, by creating a ticket for system administrator. However, they are able to read data from target system automatically. Semi manual connector may connect directly to a database table in target system. More often, the connector reads the data from CSV file, exported from the target system. Either way the data are delivered to IDM system in an automatic (albeit scripted) way. The IDM system may compare the data with policies, detect orphaned accounts and other policy violations. It can also detect errors that operators did when creating/updating/deleting accounts, and immediatelly create a ticket to fix the error. Simply speaking, it provides the missing feedback loop.

Semi-manual approach may be a temporary solution, or even a permanent one for smaller system. This is usually a low-cost solution, therefore there is seldom any real excuse not to use it.

However, for systems that are important, systems with higher rates of changes, or systems with complicated security models there is no substitute for a real connector. If the real, fully-automatic connector cannot be implemented now, make plans for the future: