Dispatcher Tips

It’s one thing to build a system in a sandbox or lab environment and a completely different thing to run that system in a production environment. There are a number of things that system designers and architects need to consider. Some of these considerations are fairly obvious, such as RAM, processor, network configuration, whether or not to virtualize, etc.

However one of the things that sometimes gets forgotten in a NetWeaver Identity Management solution is the use and configuration of dispatchers. These seemingly small pieces of the configuration are responsible for a great deal of the operation of NW IDM, as they actually process and execute the provisioning jobs in the workflow.

There are a couple of basic rules of thumb that should be considered when planning for deploying dispatchers in a productive environment.

• There should only be one dispatcher per host. If anyone has any data on this, I’d love to see it. In an ideal world, it would be one dispatcher per physical host. I have not done any testing in virtualized environments, but I don’t see that as being a huge issue.
• Plan on one dispatcher per about every 25,000 users.
• If you have specific types of tasks and workflows that require special access, create a specialized dispatcher that supports them. Specific examples would include password management and deprovisioning.

It’s also important to consider that there are several options for tuning the dispatchers, which we will discuss in a future post.

Required Reading in Identity Management

If you have not read it yet, the latest Magic Quadrant from Gartner is out. I've taken a quick look at it and saw no real surprises. Look for a slew of marketing material to come out shortly based on this report.

In the past, I've found the IdM Magic Quadrant to be basically accurate, and pretty good at pointing out hidden truth and the seeds of potential excellence in the covered products.  This year appears no different.

Talk Down, Build Up

No, it’s not a new self esteem program; rather what I think is the best methodology for developing SAP NetWeaver Identity Management Workflows.

First, let’s review the basic components of a NW IDM Workflow

Screens represent the top most level and what most people routinely deal with. Here’s where we present the attributes (populated and empty) Descriptions and other UI related features. Starting with NetWeaver IDM 7.1, this is handled by the Web Dynpro engine. Before that PHP was used.

Tasks are what give the workflow their structure. Ordered Tasks, Un-Ordered tasks, Conditionals, Approvals, etc go here.

Action Tasks are the real muscle of the workflow. Action tasks execute the actual operations of the workflow. Writing information to a Target System, a Report or the Identity Store itself all gets done from these tasks.

Of course there are many workflows of various complexities that come with the SAP Provisioning framework, but as we all know this will not cover all circumstances and sometimes custom workflows will need to be created. Fortunately, NW IDM makes it rather easy since Screen, Tasks and Action Tasks can all be linked and re-linked together over and over.

Over time I’ve found that the design and creation of workflows can be best summarized by what I refer to as the “Talk Down, Build Up” approach.

When discussing the formulation of a workflow it is generally best to discuss the workflow top down. That is start with what the user sees and then what happens after they press “Submit.” People find it easy to follow the workflow and its branches (if any) when we start from this approach. Given the way that the workflows correspond to a flowchart, this seems to be somewhat of a no-brainer. The following screenshot, gives one an idea about this:

Development, however does not work the same way. Trying to develop top down becomes fairly confusing since the developer is linking to objects that might not exist yet. Development, it seems works best, from the bottom up. In general I recommend creating NW IDM workflow objects in the following order:

1. Action Tasks
2. Privileges
3. Roles
4. Conditional/Approval/Switch Tasks
5. Ordered tasks (I seldom make use of unordered ones)
6. Screens

As a general best practice, I also reccomend using folders as organizational containers to group related tasks together. Usually I like to do this by target system (AD, SAP, SunONE, NW IDM, Notifications, etc.)

So there we have it. We talk down about the structure, but we build from the bottom up. I’m wondering how other SAP NW IDM architects approach this. What about other IdM products?

Project Listening

At the end of my last post I made a reference to pay attention to the customer's needs when planning and executing an Identity Management project:

...Whether you are a consultant helping a client with their solution or an internal employee building your firm's Identity Management strategy, you still have a client, and their needs should always come first...

I recently took part in a Linkedin discussion where the person posting the question asked the question:

...I would be interested in your take on the latest and greatest products to implement for Identity and Access Management needs across the enterprise. Thoughts / comments...

I gave a pretty straightforward answer which covered some informative (in my opinion) basics centering on looking at the basic systems in the enterprise and advised the questioner to move forward from there.

There were a lot of people who went on another tangent, which was a more consultative answer... Find out what you need and then go to match technology.

Sounds like we have a chicken and the egg here.We cannot determine what technology fits until we determine how the technology is to be used. We also cannot determine how to use the technology unless we know what the technology can do.

Who is right? Who is wrong? I don't think either viewpoint is wrong. The fact is the first questions should have been along the lines of:

• Have you determined use cases?
• Have you begun to look at what technologies are out there?
• Who is using the system?

Nothing about management, systems, or anything else. The initial basic tasks must be this broad outline. Once these big questions are answered we can do to then fill in the holes and determine how to answer all the little questions.

Incidentally, my answer came from the fact that the questioner specifically wanted to know about technology. Since the initial posting he has not made any comments on which approach he needed, but I did see that my good friend and fellow blogger, Matt Flynn posted as well!

The Bigger Picture

In the Identity Management field, there's a lot of thought placed on how to provision users, and even more thought (rightly placed) on de-provisioning users. After all, if users can't get into the systems, you get no return from them since they are not as productive. Similarly, we also know that leaving user accounts active in the system leaves an organization open to data loss, financial and legal risk, and loss of productivity.

However, what of the middle of the user life cycle? User profiles and access need to be maintained as they change titles, departments and locations. It is also important to record this information for compliance/audit reasons.

IdM provisioning tools are probably the best tools for managing these changes in access for enterprise systems. While tools such as SAP's GRC are excellent for work in SAP systems, they are useless outside of them. Same goes for Active Directory / LDAP specific tools, PeopleSoft specific tools, etc. IdM systems have the ability to connect to all of these (and more) systems.

Leave the provisioning, role assignment and management to the IdM system and rely on specialty tools for specialty needs.

Central Management

One of the objectives in my trip to Europe is to consider what additional systems an Identity Management system should be supporting.

Perhaps the biggest area that is not being supported is security applications. One wonders why this is so. Being able to centrally manage Smart Cards, Certificates, and Tokens is critical in maintaining security and regulatory compliance.

Take this example, where Abdirahman Ismail Abdi, managed to resign and commit 9.2 million dollars in fraudulent wire transfers with his still active electronic key card.

From an IdM perspective, we need to realize that de-provisioning must cover all sensitive Enterprise systems in a prompt and thorough manner.

It's also not enough to say that an email notification issued by the provisioning/de-provisioning system is sufficient for anything less than a first phase in an overall Identity Management project.

By completely automating the process we make sure that everything gets done at termination time. Going with the classic provisioning arguments, we make sure it's done in a timely manner, without the chance of manual operator errors and recorded in the audit/compliance database for future reference.

Realistically, we make sure that the barn door is closed before the horse can get out.