December 9

The First Brick: Understanding Identity Management

What is Identity Management?

Identity Management (IDM), or Identity and Access Management (IAM), is a suite of products that work together (more or less cohesively) to manage users and their access/passwords across the enterprise. Most identity management product suites consist of three or sometimes four parts:

-        Role manager

-        Identity manager

-        Access manager

-        Audit manager (sometimes)

Although most product vendors have adopted similar terminology for their components, there is no true standard naming convention nor is there a requirement that vendors use the same name for their corresponding products. My experience is largely with Sun Microsystems’ identity management suite, but this product is not necessarily the right choice for everyone. I will try to remain as neutral as I can, but I ask your understanding if my terminology and examples tend towards what Sun uses.

The Bumpy Road to Consolidation

Have you ever wondered why there are so many components? Why not just make one product that does it all?

The answer lies in the history of identity management.

In the beginning…

… each of the components were stand-alone products created by niche start-ups.

Over time, the larger companies (the usual big players such as Sun, Oracle, IBM, etc.) took an interest in providing their own identity management solutions, and thus began buying out the start-ups and their products to build integrated suites. For example, Sun purchased Waveset as their identity manager and Vaau as their role manager. Oracle purchased Thor (identity manager), Oblix (access manager), and Bridgestream (role manager).

Does consolidation matter?

Consolidation of the marketplace has advantages and disadvantages.

On the plus side is one-stop-shop convenience, and one throat to choke when things go wrong. On the down side, you are stuck with what your vendor of choice offers – maybe their identity manager component is brilliant, but their role manager module just doesn’t meet your requirements.

Given the choice between a hot-and-cold suite or a lukewarm suite (i.e., one whose components are all just average), which do you select? You may also face pressure from management to stick with the vendor partner of choice – if you happen to be an IBM shop, management may be reticent to allow the introduction of HP’s identity management suite, even if it better meets your requirements.

We’ll address these and other product selection issues next December in the last article of this series, which focuses on requirements and product selection (if you need to know sooner, drop me a note and we can discuss). I bring it up now, however, because it’s important to think about what’s really important to your specific implementation as you go, so that when you get to requirements, you know how to prioritize and choose. Please keep an open mind – what you think is very important today may turn out to be less important as you dig deeper – and document your thoughts as you go!

Another big consideration of consolidation is internal interoperability. Just because all of the components are now sold by one vendor doesn’t mean that they are really integrated. It takes time for a company to truly fold in one of these modules. For example, Sun purchased Vaau as their role manager product about a year ago, yet there are still some interesting gaps in the ability of role manager and identity manager to interact.

The biggest consolidation is still pending: Oracle and Sun Microsystems are in process of merging (or trying to, anyway). Both companies currently offer a full-fledged identity management suite. If the merger does go through, what will happen to those products, and how will existing customers be impacted? I would be surprised if they kept both suites, but who knows?

The good news is that while the current round of consolidation is sorting itself out, there is plenty of foundational work to be done to prepare for the selection and implementation – especially with the process and data cleanups.

However, before we even embark on the detailed cleanups and process improvements necessary for success in Identity Management, it is important to take a moment to review the components of an identity management suite and ensure a common understanding and vocabulary. This matters not only for our time together, but also for each project considering identity management.

And Now… The Components!

So what are these things anyway – identity manager, role manager…? Let’s take a brief look at each.

Role Manager: the brains of the operation

The role manager module is where roles, rules, and hierarchies are stored. Except for the most basic actions, it is the role manager module that gathers information on existing users and decides what action should be taken for a particular user – what access they should receive, to which groups they should belong, what segregation of duties rules apply, and how to handle an approval vacancy. This information is particularly important for handling terminated and transferred users to maintain audit compliance.

Fully populating all of the information required to make role manager effective is one of the biggest challenges of identity management, but this is also where some of the greatest benefits are achieved.

It is important to note that role manager can store information even if it cannot be auto-provisioned/-deprovisioned. For example, you may choose to role-base your electronic devices (e.g., desktop vs laptop; cell phone vs smartphone) for manual provisioning/deprovisioning.

Identity Manager: the braun of the suite

The identity manager component typically interfaces with the target systems to initiate auto-provisioning and -deprovisioning workflows, synchronize passwords, execute bulk updates, etc. The identity manager module will trigger some actions on its own based on pre-determined workflows, or it will confer with role manager to execute more complex provisioning actions. Identity manager can be configured to execute workflow tasks automatically, or it can assign tasks to specific administrative personnel for manual action.

Access Manager: simplifying sign-on

In this case, access mostly refers to authentication – the access manager component is what facilitates “single sign-on,” although some modules also mediate authorization, thus the term “access” manager. Of course, as we all know, there really isn’t such a thing as true single sign-on (yet – maybe someday we’ll get there). Although we call it single sign-on, it would be more accurately termed “reduced sign-on.” In any case, when access manager is implemented with a target system, it allows centralized authentication (and possibly authorization) with a source of record such as LDAP or AD, to eliminate the need for individual local accounts and password files on each system.

Audit Manager: reams of eye candy for the auditors

The audit manager component is basically the reporting capability, and is somewhat optional. Some products offer this as a separate module. Other products might include this within identity manager or even role manager. Still others leave it up to the individual organization to integrate their identity management suite with their enterprise reporting tool and generate reports as desired. The reason this component is called audit manager is that when offered, it comes with a variety of out-of-the-box reports that are of particular interest to SOX, PCI, and other auditors.

Action speaks louder than words…

Each month, I suggest a few practices I have learned that will bring quick benefit. For this month, the actions are (theoretically) minimal, since this was an introductory article aimed at simply setting the stage. Still, there is work to be done!

  1. Start an identity management journal. In this journal, document:
    1. Expectations of an identity management implementation: what needs to be accomplished? How long do you think it will take? (Hint: once you determine a timeframe, triple it, and you’ll be close =)
    2. What are the expected roadblocks? For example, any management or other influential people that are already leaning toward a specific product, or refuse to even consider a particular vendor? Knowing this information up-front will give you more time to build a strategy to influence, counteract, or otherwise prepare
  2. Start considering the team:
    1. Is there anyone in the organization who has implemented an identity management solution before? If yes, ensure their availability to help guide the process
    2. Are there team members interested in learning? This is a great career growth opportunity for smart, hard-working team members that need a new challenge
    3. Does the existing access management team have the bandwidth to embark on process and data cleanups? Most of the up-coming work will naturally fall on them, but if they’re already overworked, it may present a problem. Remember, much of the cleanup work is highly labor-intensive, especially for large organizations. If significant resource constraints are expected, start fighting that battle now
  3. Was any of the information in this article new or surprising? If so, spend a little extra time absorbing it or doing some online research.

I am here to help

Leave a comment or drop me a note to let me know how your effort is going. Does your journal reveal any interesting insights? Leave a comment to share with others or ask for guidance.


Tags

identity management, idm, security


You may also like

Are you using frameworks properly?

Leadership and communication are actually layers, not levels

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Subscribe to our newsletter now!