Why IAM-Projects fail

7+1 reasons and more to expect

There are several caveats to be aware of up front when starting a major IAM project. These useful hints are driven by experience from projects that went wrong due to some common misconceptions:

1. Sub-optimal assignment of responsibilities

corporate organisation needs a Business Owner

Complexity factors

• Identity Management is a management task.
• Identity Management means organising the enterprise.
• HR could be the natural owner - but often refuses.
• IT has the implementation capabilities but is not mandated to change the organisation.
• On the business side methodological and technical knowledge is lacking.

Possible countermeasures

• Shift the responsibility to the business side.
• Create a new cross functional function (group) for the doing.

2. Cross-company character

IAM-Projects touch multiple corporate functions

Complexity factors

• Identity-Management Processes are typically cross-company.
• There are multiple stakeholders from different corporate levels involved in a project.
• You need to expect a 3 to 5 times higher communication complexity compared to "normal" IT-projects.
• IAM-Projects show characteristics of typical Change Management Processes.

Possible countermeasures

• Strengthen the project management.
• Add an extra reserve for communication.
• Insist on a power sponsor for your project.

3. Differing Process maturity

There are no islands of order in an ocean of chaos.

Complexity factors

• At higher levels of maturity of the management processes (e.g. according to CMMi) the introduction of IAM- processes, -rules, -roles, -policies becomes easier.
• You can't implement mature IAM-processes in a low maturity process environment.
• E.g. the top-down definition of roles needs defined processes.

Possible countermeasures

• Only launch IAM-projects corresponding to the maturity level of the environment.
• Occasionally just say "no"!

4. Wrong Project scope

An implementation project cannot reorganise the corporation.

Complexity factors

• Implementation project will have a hard job when having to reorganise the corporation first.
• Process- and Role-Definitions require their own definition projects before or in parallel to the Implementation.

Possible countermeasures

• Define separate projects for the Definition of Processes and Roles before or in parallel to the Implementation.

5. Adverse effects of the market consolidation

acquired components don't necessarily combine to Suites

Complexity factors

• Mergers & Acquisitions often lead to less compatible product collections.
• The software of acquired companies is often not supported sufficiently.
• It may take a long while, until components fit together as promised.

Possible countermeasures

• Only a Pilot installation under real world conditions leads to the necessary evidence for a product selection.

6. Non-availability of domain knowledge specialists

persons with business domain knowledge are rare creatures

Complexity factors

• The availability of specialists with domain knowledge often turns out to be the bottle neck in role- und process definitions.
• Their involvement is essential for the requirements definition and the QA.
• Waiting times (for specialists) are driving the overall effort.
• While in projects they tend to disappear.

Possible countermeasures

• Assign the project responsibility to the business departments.
• Think of splitting projects into business definition and an implementation part.

7. Too deep vertical integration

don't try to reinvent the wheel

Complexity factors

• Only a fraction of the overall IAM-Processes is really enterprise specific.
• The adoption of processes and / or Roles from generic Models may speed up projects.
• Not always it is a good idea to start with a blank sheet of paper.

Possible countermeasures

• Ask your integration partner or consultant for consolidated models containing his experience.
• Participate in Standardisation initiatives (like GenericIAM.org).

8. Technical risks - they still exist

Technology often is more of marketing than reality

Complexity factors

• IAM-SW-Suites are complex and often not easy to handle.
• Without implementation experience in exactly the required environment risk of failure is high.
• "Minor" changes of the version number sometimes cover oft complete new developments.
• The support Matrix of environment components vs. versions often is only sparsely populated.
• Forced replacement of infrastructure components leads to higher effort.

Possible countermeasures

• Always test selected software in a pilot run before deployment.
• Only choose integration partners with true product experience.

apply & approve

Lately - well it is some four months ago already - I posted a simple model of the AM maintenance processes. Not covered at that time were the processes which lead to an assignment of roles to persons, respectively their digital identities - the mere act of authorization.

We still view this world on the essential level (see Modeling fundamentals). So as long as we just model the essence of systems we (still) need not to bother with such non-trivial artifacts like provisioning the business decision to the target systems. Those things will inevitably come later when we will be forced to step down from essential heaven to the cruel & dirty physical world.

Maintenance of "authorization"

Apply - approve - grant or revoke can in principle be understood as the maintenance processes (as in how to find roles) for the object "authorization". There may be other designations for this object like "assignment" or "essential account". In order to optimize the communication with your in-house or outside clients you may choose a more suitable name, if you like.

"authorization" as a derived object

Ok, as a maintenance process we would expect the CRUD crowd again: create - read - update & delete. However, "authorization" is not one of the fundamental objects. In fact it is a derived or relationship object and mostly consists of references to its constructing elements: "identity" and "business role". And this is where the necessity for an approval comes in.

Finding approvers

Why do we need approvals here and not before; when we considered the fundamental objects? The answer is: because the object "authorization" does not own all of its attributes. But instead references to other objects (identity and business role) attributes and their attributes. As a polite object it should ask for permission before doing so.

So, the rule we like to follow here is: "if one of the attributes of an object represents a reference to another object, this objects’ owner has to consent his object’s use." So on one side the object is the identity: Its "owner" is its superior.

On the other side of the equation there is the business role. Having a closer look to it however reveals that the business role itself represents a relationship. So we have to go even further. The "business role" is the intersection of the privilege determining dimensions. These dimensions are first of all the "functional role" and second all those which are subsumed under "constraints". These depend on the organization in focus, e.g. region, organizational unit, customer group, contract type. As an example we determine the permissions of a contract administrator in the US, in the headquarters, for whole sale customers if he is a fixed term employee. So the "business role" primarily consists of references to the "functional role", the various "constraints" and the assigned "permissions".

"Every object has an owner" I once (2010-08-17: objects, subjects & actions) stated in my BLOG. And I went on, that owners are prime candidates for actors to act on their objects. At least when it comes to the approval of requests to access objects, it is up to the owners to decide (unless the delegate it to clerks).

Who now are the owners to ask for their approval? For the "functional role" as well as for the various "constraints" it should be a "business architect" or - even better - a "process owner". For the set of "permissions" there should be an owner of the "information object" be defined. Often this position is known as the "data owner".

So these are the authorities to approve the formation of a business role. As the "business role" per se is neither sensitive nor does it contain much substantial information but rather references to other objects, its use may be pre-approved by policy. The same is true for two of its referenced objects: "functional role" and "constraint".

But for the "Information objects" things are different. Information objects always need some level of protection. They may be classified due to their level of sensitivity (separately determined in the categories authenticity, availability, confidentiality and integrity) into levels like low, medium, high and very high.

Whereas in cases of low protection needs access to the resources may be pre-approved via policy information objects attributed with high protection needs require the case-by-case approval of the owner (or his delegate).

So at the end of this long story it turns out, that there will be two approvers during privilege assignment to a digital identity: the superior and the information owner.

Process variations

There are several processes for granting authorization found to be in use.

1. Grant authorization
2. Withdraw authorization
3. Deactivate authorization
4. Reactivate authorization
5. Instantaneous withdraw authorization
6. Change of position
7. Deploy temporarily

The most common are grant and revoke (withdraw). But as authorization should be granted with and end-date of its validity set while approval, the reverse action can be done as well: deactivate an authorization for a given period of time (e.g. planned absence). A reactivation process then cares for the case when deactivation period is meant to end ahead of schedule. Temporary deployments offer more complex cases (to fill an own BLOG post) as usually no clear cut can be done.

A process which appears quite often is something like "Instantaneously withdraw authorization". However in an essential model (remember, we have perfect technology!) it simply collapses with "Withdraw authorization". Only if by technical restrictions it becomes necessary to be a bit faster than in the standard process, a separate (physical) process is justified.

But what to do, if an individual changes its position within a corporation?  This process is often explained as a combination of a preceding revocation followed by a subsequent assignment of new privileges (grant). But this picture seems not to reflect reality properly. Quite often there is the necessity of an overlap of privileges of the old position and those for the new position - unless they are in conflict with each other’s. So the change process still may be a combination of revoke and grant - but rather running in parallel instead of being executed sequentially. However as an invariant to the parallel execution of both (sub-) processes the integrity (e.g. being free of SoD conflicts) needs to be checked after each step in the out-phasing of the old and in-phasing of the new position’s roles.

Triggering events

And what are the triggering events? Well, in general processes are triggered by one of the following events.

1. created by an subject,
2. triggered by time,
3. fired by embedding business processes,
4. fired by state transitions.

The 4^th one can be debated, as it can be argued, that a state transition only occurs in embedding processes.

Process composition: grant authorization

"Grant authorization" can be imagined as being composed of the following activities:

1. apply
1. Select identity
   Usually either the applicant himself or one of this subordinates.
2. Select business roles(s)
   1^st the functional roles should be selected, 2^nd constraints should be assigned (based on rules) and / or selected. Rules may restrict the focus of the selectable roles.
3. Check Validity
   Validity is an invariant - it should be checked during each change - even when withdrawing roles. If rules are violated the choice could be disabled (strict rules) or an alert could be raised to allow for branching into a resolving (sub-) process. SoD rules for example can be imposed as a strong recommendation ("to be separated in general"), as a mandatory requirement or even with special emphasis ("to be separated up to the C-level"). At least in case of a mandatory SoD conflict a compensating control can be implemented to restore validity. But getting compensating controls approved may be a lengthy process, return in the "go" / "no go" after some days only - during which the application will be pending. When withdrawing roles an implemented compensating control may no longer become necessary. That’s why the validity check should be invoked in this case too. So "check validity" may look innocent. Nevertheless it introduces the bulk of organizational complexity to this activity.
2. approve
1. Usually the choice which has been made has to be approved.
2. It is possible however to pre-approve it via a policy, if appropriate.
3. Typical approvers are the superior of the identity (for contractors this may be the contracting counterparty) and the information object owner.
4. In case of unresolvable SoD conflict leads to compensating controls, more approvers can be involved.
5. Usually a time limit is set after which an escalation is triggered.
6. The approver has to name a deputy in case he is unable to perform the task himself.

Well, that's certainly not all. It is just one important process. But it is enough for today. More to be seen here soon.