Three Characteristics of a Mature Identity and Access Management Program

Identity and Access Management (“IAM”) as an industry started gaining significant recognition and momentum around 2003. During these last 12 years, we’ve seen product vendors come and go, we’ve seen industry consolidation, and we’ve seen important product innovation driven by real business need.

While all this has been going on, many companies have leveraged IAM products to achieve important and significant gains in security, efficiency and compliance enforcement. On the other hand, some companies have tried and tried to establish effective IAM programs only to fail in their attempts to affect real change.

What makes one company succeed and another one fail while attempting to leverage the same products and technologies? What are the characteristics of a truly mature IAM program?

Over the next few weeks, I will attempt to address these questions. I also hope to create an important dialogue among those of you who have “been at it” for the last 5-10 years and have seen and been part of great successes and colossal failures. Although I have been part of hundreds of IAM projects, and will lend my experience to the discussion, you, as the readers and contributors, may have much more to contribute to make this topic come alive. Will you help?

Let’s get started with three important characteristics of a mature IAM program. This list is not exhaustive but these capabilities are common among organizations that have made IAM a strategic part of the IT infrastructure.

#1 – User Identity Integration

Pieces and parts of a user’s identity can exist across many different systems in an enterprise. HR systems are an obvious source along with IT systems like Active Directory. Then there is the badge or physical access system, the phone system, and various business applications that become critical for a user to perform their role. Before long, keeping up with all these disparate systems and keeping user attributes current becomes unmanageable. Most organizations recognize the problem and also recognize the need for a consolidated view of a user’s identity. It seems simple enough, but it takes planning, time and good processes to move an organization down the road to centralizing processes, automating synchronization, and removing redundant identity attributes from across the enterprise.

#2 – Account Provisioning

Creating an account on an appropriate system with the correct permissions is a straightforward task when you’ve been given the right information and you have the time to get it done. When a company grows to around 3,000 employees, the enterprise reaches a tipping point where going about this using people and manual effort becomes untenable. Too many requests for new accounts, or too many changes to existing accounts, or repeated requests to remove accounts for terminated employees all begin to pile up. This creates a backlog delaying new workers from getting started, hampering productivity, or creating security exposures where accounts of terminated employees remain active far too long.   Centralizing and/or standardizing the process can help but adding technology that provides automation will speed up the process along with enforcing identity standards, access entitlements, and important policies and standards. Automatic account removal of terminated employees is also a significant gain. All accounts on key systems can also be tied back to a central, validated user account eliminating unknown, orphaned user ids from across the enterprise.

#3 – Password Management

Password management activities face a similar challenge as an organization grows and adds more and more people, systems and applications. Initial steps should be to provide tools to help desk personnel centralize and automate this activity. Ultimately an organization needs to move this function away from the help desk and enable the end user to manage his own passwords on key systems, including resetting their own Active Directory password. This is another step that seems simple on the surface but can actually take a significant amount of planning and coordination to get it right and keep it running smoothly. Organizations that make a misstep on their first attempt find it difficult to gain user adoption the second (or third) time around. Eventually, standardized help desk procedures can assist the user community in adopting the self-service approach to managing passwords.

 

Identity integration, provisioning and password management are three essential building blocks, but there are another 8 – 10 key capabilities we could discuss that should be considered when talking about IAM maturity. What other capabilities would you consider to be essential building blocks? Please contribute to the discussion.

Up next, let’s talk about the essentials for planning a long-term, mature IAM program. If you’re just getting started or have been struggling to make progress, what are some of the keys to putting plans in place that can be effectively executed?

Processing Multiple Attribute Values with the TDI 7.1 FOR-EACH Attribute Connector

In previous versions of the IBM TDI product the task of processing a report or directory integration has been a challenge when working with attributes that may have more than one value.

One such example that we see frequently with the ISIM product is the erroles attribute assigned to the ISIM Person record. Luckily with IBM TDI 7.1 we have a new connector type that allows us to easily process these called the FOR-EACH Attribute loop. The following is a demonstration of how this function connector works in a simple report generating TDI.

In this example we will be Iterating all Person records contained in ISIM. The connector looks like this:

image1top

The Search Base & Search Filter should something along the lines of:

image2

(Note: with a Search Filter of (erroles=*) only Person Records that contain at least 1 role will be selected).

The next step is to make use of the FOR-EACH Attribute connector. The iterator has already loaded the work.erroles object which may contain multiple values. This attribute contains the DN of the role assigned to the ISIM Person which we will need to translate into a Role Name (errolename).

We will need to define a Work Attribute Name & a Loop Attribute Name. The Work attribute is the incoming multi-value attribute from the iterator, in this case erroles. The Loop Attribute Name is the single value attribute at the coordinate for the current loop count.

image3

Once this has been defined, we can add connectors below to lookup & then record the data for each pass of the Role Loop. First we do a lookup using the DN of the role (loopRole) to resolve the role’s name (errolename).

image4

image5

Since the work.errolename value will be over-written with each pass of the Role Loop, we will need to store, or write the value to file before finishing the loop & moving on to the next value of erroles. In this example I have inserted a File Connector to write the report as it is being passed through the loop. However there are other options available such as storing the values in an array eg. work.errolename & then looping through them using JavaScript in a connector further on in the TDI.

image6

OIM User Attributes Modification

While integrating Oracle Identity Manager within a corporate environment, sometimes it is important to change some user attributes externally. OIM API provides simple means to perform these operations.

As is the case in any operation, a connection needs to be made to the OIM instance. This is a simple task, but one must ensure that credentials are properly stored and protected.

 

protected static OIMClient client;

private static String OIMInitialContextFactory = “weblogic.jndi.WLInitialContextFactory”;

 

public OIMConnect(String fileName) throws Exception

{

Hashtable<String, String> env = new Hashtable<String, String>();

env.put(OIMClient.JAVA_NAMING_FACTORY_INITIAL, OIMInitialContextFactory);

env.put(OIMClient.JAVA_NAMING_PROVIDER_URL, CONNECTION_URL);

client = new OIMClient(env);

System.setProperty(“java.security.auth.login.config”, AUTHCONF_FILE);

System.setProperty(“OIM.AppServerType”, “weblogic”);

client.login(OIMUSERNAME, OIMUSERPASSWORD.toCharArray());

return;

}

Read more