Moving forward in IAM at your own pace

17.08.2011 by Martin Kuppinger

During the last years, there has been a lot of change in the Identity Provisioning market. Sun became part of Oracle, Novell is now NetIQ, BMC Control-SA is now at SailPoint, Völcker has been acquired by Quest, Siemens DirX ended up at Atos. These changes as well as other influencing factors like mergers & acquistions, failed projects, and so on lead to situations where customers start thinking about what to do next in IAM and around provisioning. Another factor is that sometimes provisioning solutions are implemented with focus on specific environments – SAP NetWeaver Identity Management for the SAP ecosystem, Microsoft FIM for the Active Directory world. Not that they only support this, but they might be just another provisioning system. In addition, especially in large organizations it is not uncommon that regional organizations start their own IAM projects. The result: There are many situations in which organizations think about what to do next in provisioning.

However, just moving from product A to product B is not the best approach. In most cases, the deployment of provisioning tools took quite a while. In many cases there have been lot of customizations been made. And even while there might be some uncertainty about the future of the one or other product (or, in some cases, the certainty that the product will be discontinued sometimes in the future), just migrating from one provisioning tool to another seems to be quite expensive for little added value.

From my perspective, it is important for organizations to move at their own pace. The approach to do that is to put a layer on top of provisioning systems. I’ve described several options in a research note (and some webinars) quite a while ago. The research note called “Access Governance Architectures” describes different approaches for layered architectures on top of provisioning products. I’ll write an update later this year but the current version illustrates the basic principle well. By adding a layer on top of provisioning, which might be Access Governance, a Portal/BPM layer, or IT Service Management (or a mix), organizations can deal with more than one provisioning tool. The architecture is more complex than just using one provisioning tool. But if you are not able to rely on one provisioning tool only, its at least an approach that works.

Organizations then can for example replace provisioning tools fully or partially. The latter is quite common if complex customizations have been made for selected target systems. Organizations can deal with multiple provisioning systems that “just appeared” for some reason - M+A, specific solutions for a specific part of the IT ecosystem, or whatever. And they can move forward more flexible than in a monolithic architecture. Yes, these approaches require some more architectural work at the beginning, but that pays off. It pays off by more flexible migrations, by avoiding migrations at all, by less “political” conflicts with some of the lobbies within IT. It even enables to change the integration layer without affecting the underlying provisioning systems. And for sure it allows to interface with target systems in a flexible way, not only using provisioning tools but service desks or other types of connectivity if required.

But, at the end, the most important thing is that it allows customers to move forward at their own pace. Thus, before you think about migrating away from your current provisioning tool, think about how you can save your investments and add value – by new functionality and by business-centric interfaces of Access Governance and the increased flexibility of your IAM environment.

Persons, Identities, Users, Accounts

10.08.2011 by Martin Kuppinger

Is there a mismatch between the reality in organizations and the implementations of at least several of the Identity Provisioning and Access Governance solutions when it comes to the representation of physical persons in IT? To me it appears that there is a mismatch.

The reality in all large organizations I know is that the real world is sort of 3-tiered:

  • There is a physical person – let’s call him Mr. X
  • Mr. X can act in very different contexts. You might call them roles or digital identities, however all of these terms are overloaded with meanings. I’ll give three examples for that. 1. Mr. X might be an employee of an insurance company and a freelance insurance broker for the insurance company at the same time. 2. Mr. X might be an employee of a bank and a customer. 3. Mr. X might be the managing director of both company ABC, Inc. and DEF, Inc., which both are owned by XYZ, Ltd where he is employed as well.
  • In each of these contexts, Mr. X might have more than one account. If he acts as external freelance insurance broker or customer, that might only be one account. If he is the managing director of some corporations within a group, he might have different Active Directory accounts, different RACF accounts, different SAP accounts, and so on.

You might argue that these are exceptions. However, being a customer of the employing company isn’t an exception in many organizations. And, by the way: A good and valid model has to support not only a standard approach but the exceptions as well. With other words: There are few situations in which a real-world model isn’t 3-tiered.

And there are good reasons to model the systems according to that. If someone is a customer of a bank and an employee, there are very obvious SoD rules which apply to this. He shouldn’t give loans to himself. If someone is a freelance insurance broker and an employee of the insurance, the same is true. He shouldn’t manage the insurance contracts he is selling. If someone is a customer and and employee, it’s the same again. He shouldn’t give discounts, grant consumer loans, or just change the delivery queue.

However, several tools follow a 2-tiered approach. They know for example an “identity” and “accounts” or “users” which are associated with the identity. If someone has more than one such identity, the problems begin. In some cases, it is very easy to adopt the object model. In others, you have to find workarounds like mapping the unique IDs of these identities into the other identities, which then might require a lot of additional code and is error-prone.

From my perspective, supporting a 3-tiered model out-of-the-box, with

  • Persons
  • Context, Identities,… (whatever term you prefer)
  • Users (in specific systems), accounts,… (again – choose your term)

is mandatory to reflect the reality in organizations and to support the business requirements – especially when it comes to SoD policies. If you don’t need three tiers, it is easy to just use two of them. But if your tool supports only two tiers out-of-the-box, it might become a tough task to implement your real-world model. Looking at that point is, from my perspective, one of the most critical aspects when it comes to technology decisions.

© 2014 Martin Kuppinger, KuppingerCole