IAM System - Targets inconsistency policies

I’m joining Matt Flynn discussion on “Extending the ROI on Provisioning”, where he highlights an intriguing problem: how to manage direct modifications on the targets, where a IAM solution is in charge of providing approval workflow, synchronization, compliance, etc..…

Yes. Most organizations we work with are quite concerned about managing direct access to target resources, getting around workflows and central management (e.g. a profile assignment to a user directly on a target).

They confirm that despite all the precautions, it is always possible for inconsistencies to be created in their IT systems, causing authorization misalignments between the target systems and the IAM system.
Moreover, it is not possible to automatically classify and correct in advance all types of inconsistencies that can occur. However, it is certainly possible to provide a tool to detect and manage misalignments.

In our solution (the IDEAS suite), this problem is referred to as "Inconsistency Management". Within IDEAS' internal multilayer model, such actions can lead to the modification of many relations with decisions depending on many factors that must be shaped into appropriate policies.
Thus, whenever an inconsistency occurs (an offset between the IDEAS core repository and a generic target system) the Inconsistency Role Engine goes to work to repair the offset.

But what is the meaning of repairing?

Often there are difficult decisions to be made.

For instance, an authorized administrator accesses target1 and removes Profile1 from user John. Unfortunately Profile1 was assigned to John via a higher level Role: "Role1", which is actually composed of many other profiles on several targets (including of course Target1). Thus how should the IAM solution react?

The simplest policy could be to state that the central system is authoritative and thus everything must be reset back to original settings.
Another alternative policy could state that if the administrator is trusted, the modification must be accepted. But in the central repository of reference, John is assigned Role1, NOT Profile1. So alignment could mean the following:

• remove the entire Role1 from John, or
• verify if there is another available Role composed of all Role1 profiles except Profile1 (e.g. name this Role 2). If so, remove Role1 from John and assign Role2. If Role1 is part of a hierarchy and a lower level Role without Profile1 is available, it could be possible to assign this Role to John instead of Role1. In this case, while there is no impact on compliance, there could be a possible limitation on user access rights
• Notify the relevant people (e.g. IAM administrator, Role1 owner and all actors involved in Role1 authorization workflow, etc..) that there is an offset between the central DB and the target. The policy could state that if there will be no remediation activities within a defined time period, the original settings will be restored.

If the Administrator, again directly on a target, adds a profile to John, this would be even more difficult to manage as there could be a huge impact on Separation of Duty verification. I'll try to write a specific post on this item very soon.

P.S: IDEAS ( IDEntity and Access management Suite) is a solution addressing the full gamut of Enterprise Role Management needs in multiple IdM solutions.