• Provisioning and deprovisioning (which I abbreviate as de/provisioning)
• Non-employee management
• User or access recertification

This segment explores the first of these, de/provisioning)

De/provisioning is the most common of IAM workflows. Done right, this workflow delivers tremendous ROI, improved audit results and improved customer satisfaction by significantly speeding up the de/provisioning process. It is also the most complex, as a workflow has to be identified for each access or equipment type. Furthermore, for those access items that will be automated, instructions may have to be provided to the IAM system on how it needs to grant or remove access.

Let’s now run through the objectives outlined in this month’s Introduction segment for this set of workflows.

Objective 1: Determine the appropriate scope

A workflow can be created for just about anything, but does it make sense to create one?

To begin answering this question, refer back to the previous lists of systems (created about seven months ago). Begin with the primary systems and move on to the secondary systems. Chances are, some degree of workflow will be needed for each one of these systems.

Also consider what manual workflows might be appropriate – for example, for computers, mobile devices, application licenses, etc.

Another important input here is the company’s service catalog. If one exists and it has built-in workflow, a good portion of the work is already done. Not all of it, since the service catalog triggers tasks for manual de/provisioning only. But at least the workflows in the service catalog should give some sense of order of operations (i.e., which tasks can be performed concurrently and which must occur sequentially), and it should contain the names of the teams involved in each workflow.

For equipment workflows that will stay manual, the services in the service catalog may be replaced by or augmented with similar workflows in identity manager. For access workflows that will be automated, those teams will need to be engaged to better understand the technical details.

A note of caution – be careful when approaching teams with an offer of automation. Those teams that are overwhelmed with work will very likely welcome the offer, but those that are less busy or if they perceive that their entire job will be automated will be understandably reticent to participate. They will perceive that you’re coming in to eliminate their jobs. And yes, it will be that personal – anyone on the IAM team will become persona non grata, bringer of pink slips.

It is worth spending time understanding how the IAM team’s efforts will be received, and engage management appropriately. This may also impact the scope of work, as items that should normally be included in scope or fully automated may have their scope reduced or be eliminated from scope if the political situation gets too volatile.

The questions that need to be answered for this objective are:

1. Is a workflow going to be created for this item?
2. If yes, will there be automation, or manual task assignments?
3. What are the teams involved?
4. How will the teams receive our efforts?
5. Is there an existing workflow that can be leveraged?

Objective 2: Populate the requirements list

The requirements list must be clear based on the determined scope. If full integrations are expected with any systems, the technical expectations should be documented (if they haven’t been already). Remember, not all IAM products are created equal, so selecting the one that best meets the requirements is vitally important.

Objective 3: Identify prep-work

There is quite a bit of prep-work that can be done to speed up implementation once a tool is selected. For example:

• Working with the people familiar with the de/provisioning processes to understand and streamline those processes – are the processes usable as-is, or are they a mess or outdated?
  • In particular, it’s important to understand the deprovisioning process: can an account simply be deleted, or does it first need to be disabled for a time (e.g., to allow for data backups)? If there is a disabled status, what will be the duration for that one week? two weeks? a month?
  • Similarly, can a piece of equipment be taken away directly, or are there data backup needs there too?
• Cleaning up existing service catalog workflows so they can be more easily transitioned (if applicable)
• Preparing target systems – this is especially important on UNIX. Integrating UNIX systems will be much easier if the UIDs are already syncrhonized across the enterprise. If not, this is a good time to begin the cleanup effort. If this already got done as part of the March activity, great job!
  • Also consider if directly integrating each UNIX box with IAM is optimal, or if an intermediary tool will be used to manage UNIX access via LDAP, Active Directory, or the mainframe.

In the next segment, we’ll explore the user/access recertification workflow set.

This month, we continue down the workflow path by considering the more traditional workflows:

• Provisioning and de-provisioning (I like to abbreviate this as “de/provisioning”)
• Non-employee management
• User or access recertification

These workflows can be significantly more complex than the vacancy management workflows described last month. But as with vacancy management, decisions need to be made as to the level of automation that will be implemented as this may impact product selection. For example, if the organization relies heavily on mainframe applications and a high degree of automation is desired for mainframe de/provisioning, then this should be front and center on the requirements list, as not all products handle mainframe integration equally.

Workflows, if designed and implemented correctly, can also provide significant ROI in terms of de/provisioning speed, reduced effort for audits, elimination of future user cleanups, and decreased costs for things like licenses and equipment.

Let’s look at the benefits of each workflow type in a little more detail.

De/provisioning

As discussed before, there are two categories of “things” when it comes to de/provisioning: those things that can be automated (e.g., access – it just depends how much money and effort you’re willing to spend on the automation), and those things that can’t be automated (e.g., equipment – a new laptop will never float down the hall to the waiting hands of a new employee, someone has to deliver it or at least call the employee to come pick it up).

Clearly, any de/provisionable items that are automated save time and effort if the system can automatically do something in a few seconds that might take a human being minutes to do. The trade-off is the complexity of the integration as compared with the expected usage. An application with ten users will likely never have de/provisioning automated – it’s probably too expensive. Then again, if it’s a critical application and likely to get overlooked since the access changes rarely, maybe it’s a prime candidate.

Items that can’t be automated are still great candidates for inclusion into a workflow, because it builds accountability and helps with tracking. The workflow would simply trigger manual tasks in this case, but by requiring the person completing the task to mark the item done in the system and tracking that, it helps with the following:

• Identification of what equipment was provided (or collected back)
• Monitoring of Service Level Agreements (SLAs)
• Accountability – the individual is less likely to mark the task complete if it isn’t, since they know it could come back to haunt them.

Although out of scope of this series, consideration should be given to integrating IAM with the asset management system to help with tracking of equipment and licenses over time.

Non-employee management

There are two types of non-employees at most companies: those that are there for a limited time (such as temps, consultants, etc.) to provide specific expertise on a project or act in a staff augmentation capacity, and those that are there indefinitely, because they are some sort of business partner (supplier, outsourcer, vendor technical support, etc). As such, workflows must be designed to support both conditions.

Ultimately, non-employee management is a special-case user recertification, which is discussed below. It’s helpful to begin with non-employee management for two reasons:

• It’s a relatively small and simple sub-set of user recertification, so it’s a good place to start and get some experience
• It’s a valuable quick-win, since non-employees tend to be a significant blind spot because non-employees are typically not centrally managed in an HR-like system as employees are.

In fact, managing non-employees will be of value not only to the access services or security group because it provides better control over a group of users that is generally less trusted, but it will also be of value to other groups – like HR if they’re trying to reign in management of non-employees from a presence perspective, and finance if they’re having trouble determining when non-employees come and go (to ensure they’re being paid – or not – appropriately).

User/Access Recertification

Many companies still do user or access recertification by hand – generating and emailing unintelligible spreadsheets to business managers asking them if the people on the list still report to them and if the access on the list is still appropriate. Not only is the initial data collection and distribution arduous, but the effort increases dramatically when the managers come back with countless questions in their attempt to understand the access listed, or when their frustration with the process leads them to become unresponsive, requiring repeated follow-up.

Many IAM products offer automation for recertification, but not all solutions are equally elegant. The top systems offer a variety of benefits:

• Web-based view of individuals and their access
• Individuals have already been compared against HR to ensure that they’re current (and if vacancy management is already in place, then the HR records can be trusted and “user” recertification is no longer necessary)
• Access is presented in business terms, not as technical permissions, so that reviewers understand what they’re certifying
• Whatever changes are indicated by the reviewer automatically trigger automated or manual implementation tasks which are tracked to completion and logged for easy reporting
• Non-responsive reviewers are reminded automatically, and the line management hierarchy is used for automated escalations
• Reports for the auditors are easy to generate

Sounds great, doesn’t it? At a large company, this workflow set can easily save several FTEs worth of work for several months each year.

Approach

This month, we’ll discuss each workflow set in part, with three objectives in mind:

1. Identifying ways in which the workflow set could be developed. There aren’t any right answers here. The goal is to ensure that some thought has been put into what the right answer is for your specific situation
2. Populating the requirements list accordingly – this is where a lot of ROI can be found, if the right product is selected that can support the requirements. It’s critical to make sure that the requirements list is well-updated this month
3. Considering some prep-work that could be done in advance of obtaining a system.

We’ll begin in the next segment by working on the de/provisioning workflows.

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.