What comes after IDM?

People often ask me what comes after Identity Management? My answer is that it depends.

As I've discussed before, it's really up to what the organization requires and simply tacking on new workflows, approvals, and functionality is only really useful if it will actually be used.  However, I think we can make a few generalizations about what might occur as part of a far reaching and comprehensive IdM program.

Assuming that the initial project succeeded in its goal of creating an authoritative data store and basic provisioning, there's always the goal of adding more applications and additional attributes in existing applications that can be provisioned as part of workflow.

Password management is always popular.  If your application allows password provisioning or linking into a SSO or password management solution, this is a great place to add in further automation.  Your organization's help desk will appreciate it, I'm sure.

Adding in a compliance solution (sometimes referred to a certification or attestation) is always something organizations look into as a part of that overall IdM program. Some applications such as SailPoint IIQ have this built in, while others such as SAP GRC or Oracle Identity Governance are separate, but complementary modules to the Identity Management offering.

However what I think is one of the key places that the IdM program manager should be looking at is automation of IT processes. Every day the Help Desk and the System/Network administrators are using untrackable and un-auditable tools for editing user accounts. IT Management and Audit staff have no idea exactly what these people are doing as they are on the job.  At the very least, there is the possibility that users will be accidentally granted the wrong entitlements, and in the worst case, there could be the creation of undocumented SuperUsers. If we can direct these actions through the user provisioning application, then we can have an audit trail that tells us:

• Who was worked with
• What was done to them
• Who did the work
• When the work happened

It also becomes a lot easier to do these tasks when they are placed in the IdM solution.  This lets our Server Admin and Help Desk teams work on the more detailed analysis and troubleshooting that they were hired for rather than mundane user management, all while creating a more secure and audited environment.

The Stages of Identity

Recently I’ve been thinking about what happens to an identity through its life cycle and how the identity data is treated during this process.  I think you will also see that the Enterprise itself has differing methods of dealing with it as well. I am considering this to be the beginning of a framework and nomenclature that one can use for expressing how people relate to their Identity data on a number of different levels. I think we can pretty much consider this to be a “work in progress,” and I would greatly appreciate feedback.

So why do we need this, anyway? I have observed that organizations, consulting groups, and other industry experts relate to Identity based information. It seems that we all have our own set of assumptions about what is supposed to happen to this information based on our roles and responsibilities and that such a framework will help to organize our thinking a little better.

First off we have what I refer to as the Pre-Identity. During this time the data that will become the identity is in its most undefined form. Data in this stage might sit in a number of different silos or systems before moving on but is mostly used by Employment and HCM systems. Typically this data has some form in that it can identify and maybe even describe an individual in terms of the Enterprise, but it does not say anything about what it can actually do.  At this stage there are no entitlements that are associated with the user. The primary relationships held by this data are mostly legal ones as this data is used to connect with government and other systems to prove data on a legal / governmental level, such as the IRS, Department of Motor Vehicles, etc.

Once we have connected the data and accepted it into the Enterprise, the Identity information moves out of Pre-Identity systems into what I refer to as Dynamic Identity. This is the phase of Identity Management that most of us work with full time.  We will analyze this data, transform, populate (and de-populate) it in our Enterprise systems. This is also the time that we will grant, modify and revoke entitlements and apply that extra “dimension” that did not exist in the Pre-Identity stage. As the relationship between people, their Enterprise Identity and their organization(s) change, so will the Dynamic Identity. Systems and Processes will constantly be changing based on the need for access based on geography, roles, titles, responsibilities and other enterprise requirements.

Happening mostly at the same time as Dynamic Identity is that of Interrogative Identity. This stage of Identity encompasses some of the latest trends in the field of Identity Management. As there is an increasing need to clarify, document and ultimately define what an Identity has access to and ensure that the Identity is compliant with internal enterprise rules (governance) and governmental rules (compliance) it is essential that there is a defined set of processes that enable this to occur. There are now several sets of guidance on these practices established by governments and standards bodies and a growing set of application vendors to help navigate their processes.

As another dimension of Interrogative Identity, there is the constant need by the Enterprise to understand its own data. Access to data through Enterprise Systems and linking the elements of Pre-, Dynamic and even Interrogative Identities is increasingly being managed by Business Intelligence (BI) systems.  Our understanding of how the Identity and Enterprise are connected is being enhanced as BI is extended into Identity models. This trend will only continue to grow; however its management through will need to be maintained and monitored by Dynamic and Interrogative systems to ensure that Identity and Access data is properly protected.

Finally, we must define what happens when an Identity is no longer associated with the Enterprise. The Post Identity phase is one that is often overlooked, and is the cause of many exploits and Identity Management related crises. Ensuring that there are ways to properly separate the user from the Enterprise systems while maintaining their existence for ongoing Interrogative Identity practices is required properly complete Dynamic Identity operations.

Throughout this article I have made references to “the Identity” without going into much detail.  This is done this on purpose so that there are no preconceptions as to what can be managed by this model. Any type of Enterprise object could be managed in this framework, whether it is people, groups, roles, privileges or other objects such as systems, phones and other hardware, and the relationships therein.

I have also been somewhat vague about what constitutes the Enterprise.  For far too long, the field of Identity Management has been confined to the Corporate Enterprise. However with ongoing initiatives to “Cloud” and “Service” based systems, there is a greater need to manage and monitor these relationships as one would in a Corporation or Government system. Our increasing reliance on systems such as Google, Facebook, LinkedIn, Yahoo!, etc. to store our data and provide next generation service such as Federated access makes this all the more essential.

This does not mean that non-cloud methods and repositories do not benefit from this type of organization. These relationships are just as important when considering ERP, LDAP and other "classic" Enterprise systems as I have referenced earlier in this article.  The organization of this data is still among the leading determinants in the choice of both ERP and Identity Management systems. It is my hope that in defining and expanding this framework in terms of Pre-, Dynamic, Interrogative and Post Identity stages (PDIP) that we can find a way to address all types of Identities in all possible systems.

Fitting It Into the Schedule

This title applies to more than one aspect of my Identity Management life these days. I've been very busy which accounts for the lack of blog entries lately.  It's not that I don't have what to write about.  It's more about finding the time to do it.  

I was given an interesting challenge lately.  We have a number of tasks on the current project that only need to run once a month., which is not a frequency that is supported by the IDM scheduler. There's actually a few ways to handle this. Most of which revolve around finding the batch file that is created when job is first run and tying this into the scheduling utility of your choice.

However, I was really interested in finding a way that would work within the IDM framework. So I came up with this little script:

// Main function: scheduler

function scheduler(Par){

//Only run the task on a particular day of the month.

//Should only be called from the Initialization script of a maintenance job.

//Created by: Matt Pollicove 7/7/11

//NW IDM Functions used in this script:

//uStop();

//uGetPassSubject();

//uWarning();

//*****

//NOTE: Requires an external Job Constant called Runday that is set to the

//two digit day of the month that the task should be executed on or this value

//must be hard coded

//Parameters for the task.  Name of the pass/task and what the legal execution day is

var strJobName = uGetPassSubject();

var strRunOnThisDay = '%$runday%';

//What's today's date and what is the actual date.

var strDate = '%$ddm.date%';

var strToday = strDate.substring(3,5);

//Put it all together

if (strToday != strRunOnThisDay){

     uWarning(strJobName + " is not scheduleItd to run on " + strDate);

     uStop();

}         

}

As you can see, it's not terribly complicated, but let's break it down:

The task first grabs the name of the running task for informational purposes.  Then it goes out to find a local constant (feel free to make an adjustment so that it works with a repository or global constant) which holds the day of the month the task should run on.

Once we have this, we do basically the same day with the current date, by getting it from the system parameter %$ddm.date%, and retrieving the date part of the current month.

Then we can compare the two values. If they're equal go ahead, if not, we log a message (another thing that can be taken out if desired) and call uStop().

1. Now to use this functionality we need to do the following:
2. Copy/Paste the script listing above into a NW IDM script.
3. Create the RUNDAY constant.  Remember if you choose to create this as anything other than a job constant, you need to edit the script accordingly.
4. This script could be used in either a managed task (yellow folder section) or a work flow task (although I'm not sure why). But the script should be placed in the "Initialization script" entry on the source tab of the first pass in the job. When running as a managed task, it should be scheduled to run once every 24 hours.

That's about it.  Hope this works for you.  Please remember to share any edits or improvements.

Setting up Remote Dispatchers

On the project I just wrapped up, we realized that we would need additional runtime dispatchers for load balancing. After taking a quick look at the environment, I realized that I did not have any current documentation on installing a remote dispatcher, so of course I needed to create some.  Based on the SAP documentation for creating a UNIX Dispatcher, I generated some documentation.  I've reproduced part of it here.  The documentation I did for the client included some extra content, but since they paid for this and you aren't, here's the bare-bones (but complete) process.

1. Copy the IC Runtime Folder from the IDM Server to the Target System. 
2. Go to the \setup folder and run setupwin32.exe. 
3. Go back to the IDM server create and create a new dispatcher, to create the new dispatcher, right click on the Dispatcher node of the SAP NW IDM MMC console, and select New and Dispatcher. 
4. The Dispatcher should be renamed to reflect the target system that it will be running on (e.g., IDM_SERVER2). 
5. After you have named the dispatcher it will be necessary to generate the dispatcher scripts by clicking on “Create dispatcher scripts…” button.
6. Navigate to the service scripts folder or wherever you installed the files. Copy these files to the other server, which will have the same name as the dispatcher node named in the step above. There will be three files generated that end in .BAT, .PROP and .SH. The files can be placed in the Program Files\SAP\IDM\Identity Center folder or in the folder of your choice. 
7. Make edits to the batch file that was just copied: The JVMDLL and MXDISPATCHERPROP lines will most likely need to be changed to reflect updated locations on the target server. 

There you have it, this is the basic process for setting up a dispatcher on a remote system.

It’s Iteration Time

Recently, I had an interesting problem presented to me today that I was able to solve using a seldom used piece of IDM functionality.

The project I am working on had a requirement to read some information in from Active Directory and write it into IDM, but with a twist,  we only needed to get information from certain OUs, about 30 of them.  With this many, it did not make sense to write a separate pass for each and every OU.  That would be unwieldy and a complete pain to administer you’d have to make a new copy of the pass for each OU to be added or delete the pass if it should be removed, too much room for making a mistake. Now if IDM could somehow iterate through the list, we'd be set!

Instead, one of the talented people on the project built a PowerShell script to create a list of OUs that need to be processed and dumps it to a text file. IDM can execute this script using a Shell execute pass.  When it’s done we take that output and dump it into the database using a From ASCII pass.  Now here’s where the fun comes in…

The next pass is a From LDAP pass as one would expect in a reconciliation process. However we’re going to set it up a little differently by using the “Advanced” button to set up a process by which we can iterate through the OUs that we just moved into the database table from the PowerShell script.

To start, configure the Pass as you usually would, set a repository; populate the login name, password and a starting point using one of the OUs that you will be reconciling from.  When it’s all configured correctly, go to the Destination tab and read in the Source Template, now come back to the Source Tab and hit the “Advanced” button.

Set up your database source and SQL statement as you would in any other task.  When you’re done, it should look something like this:

Note that I use a Constant to hold the database connection string.  It saves some time since I don’t have to keep generating it and provides an easy way to update everything when I move from DEV/TEST to PROD.

Now as you recall, up above we set a Starting Point based on one of the OUs from our list.  Now we’re going to change that.  Go back the LDAP URL configuration and replace the OU with the value from our query.  It will look something like this:

Now you might be wondering, why we can’t determine the Datasource Template with the dynamic configuration, well the simple answer is that you just can’t and if you try you’ll be told that it is not possible to discover the schema from a dynamic starting point. However, if you’ve configured everything correctly, go ahead and run the task.  You’ll see that you have just gathered AD User information from a number of different OUs.  Good work!

Some quick reads in SAP IDM and IdM in general.

Reporting, Metrics, Audit, whatever you want to call it, relies on being able to extract information from your identity management systems.  This article is a brief discussion on the topic.  I was fortunate to meet one of the authors, Gerlinde, during TechEd last year.

It's also nice to know our market is growing!

2010 and the Year in Identity

As the year draws down, I've been thinking a bit about the year and what's it's meant in Identity Management. There's certainly been a bit of discussion about the nature of Identity, authentication and authorization controls.  As technology, process and legislation grow closer, there's a greater need for Governance and Compliance controls than ever before.  We're also seeing the beginning of the Cloud truly being a part of the IdM solution.

We're also seeing consolidation on the business side in both the product and implementation branches with Oracle, SAP and Microsoft all making purchases.

Related to this, one thing I've been wondering is what will happen with SAP systems if you rely on either CUA or SUN Identity Manager. What are your plans, if any, for migrating off?  I've started a discussion on LinkedIn about this. Please take a moment and  share your thoughts about what you are considering or planning.

On a personal note, I wish all of my readers a happy and healthy New Year.

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.

Scripting Tips

A quick entry, but a couple of tips when creating SAP IDM scripts:

1. Do not put a space between a built in function and its argument.
2. Do not put a space between Par.get and the argument in a "To Generic" pass.
3. Be careful of infinite loops

Violating any one of these rules can start a java.exe process that will take 99% of CPU.

More about how I discovered all of this soon.

"Registering" Identity

Read an interesting article off of the UK’s Register site.

The article starts out by stating that Identity Management is both “Complex” and “a pain in the backside.”

While focusing on “classic IdM” issues like password control and provisioning, it also links in some interesting thoughts about linking Asset Management to Identity Management with the loss of a phone (or dare I say a laptop) and the fact that some assets are linked to the identity concept.

The article goes on to discuss some thoughts about preparing for identity related projects, offering some thoughts on an architecture that revolves around people, their roles and authorizations.

What really grabbed my interest about this article was a list of three assumptions, which I will paraphrase:

1. There will be Identity Assets and applications that the IdM team will be unaware of
2. Provisioning is event driven, and therefore your IdM procedures should reflect this
3. Provisioning is a process, not a onetime deal

The author has a nice wrap-up and words of advice which leaves the article on a high note. The point here is that these folks seem to get what IdM is all about.

• The IdM Technology doesn’t matter
• Directories doesn’t matter
• Databases doesn’t matter

What matters is that one understands the organization’s business and cultural needs. That will dictate how the technology, directories, databases, etc. are employed.

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?

Conflicting Views on IdM Acceptance

Within a span of a couple of days I saw an interesting contradiction regarding the adoption rate of Identity related technologies, particularly in Europe. This contradiction came through a couple of articles I found on Identity Management through my trusty Google Search agent.

The first article, basically states that adoption rates have not been as high as they should be since everyone is acknowledging their importance. Additionally the prevalence of cloud technology brings about a new wrinkle in managing Identity which has yet to be properly addressed and might be a way of pushing acceptance of IdM. It also states that the inherent complexity in IdM creates additional acceptance and execution barriers.

The second article, takes a more positive approach to the acceptance of IdM technologies. Particularly when considering Privileged User Management.

Interestingly enough, both articles referenced the same Forrester report, Identity and access management adoption in Europe.

What should we take away from these article?

1. While both articles mentioned that the Cloud could be a great IdM enabler, there was not much mentioned in the way of Architecture models by which this could be addressed. Guess you have to engage Forrester for that information.
2. Looking for IT and IS goals such as Privileged User Management can be a great way to gain additional acceptance for an IdM project.
3. Another issue that the articles do not mention is that acceptance can be promoted by leveraging established ERP application. Both Oracle and SAP now have Identity Management Systems that have specific functionality to provision in their respective internal landscapes as well as to the Enterprise in general. IBM also features similar tools for their infrastructure. Seems to me that along with Privileged User Management as discussed above, this could be another tool to gain IdM project acceptance (and more importantly, budget dollars) Quite a few project proposals I've come across lately are adopting this methodology.

Finally, I'd like to comment on the complexity issue. IdM is made complex when organizations do not execute from an agreed upon game plan. This plan does not need to be all that complex, and briefly consists of the following:

• Understanding the Identity related needs of the organization
• Prioritizing those needs based on potential return which could be based on, time savings, monetary return (ROI through reduced Help Desk calls) or consolidation of workflow, portals and other IT infrastructure, and ability / time needed to design and develop the parts of the solution
• Executing a Project Plan based on these criteria

Like I said it does not need to be complex, but does require a certain amount of Project Management and, perhaps more importantly, buy in from the various project sponsors. Avoiding complexity in determining objectives, results in lower complexity of the finished product.

Glad to see them getting into the act

It was fantastic to see SAP actively stepping into the Identity Management discussion in the article Better services in higher education? Without Identity Management: no chance!

I've long been a proponent of bringing IdM to Higher Education. With constantly changing user populations, complex access management needs, and many disparate systems to connect to, usage of an IdM system seems to be a no-brainer. Add on need for Compliance controls given HIPAA, Student Loans, etc, there's an even greater need.

Here in the US, it seems that Oracle has been the 500 pound gorilla pushing IdM in the Higher Education space. Nice to see that there is another vendor stepping up!

SAP Training, day 1

I'm attending a SAP Training Class on NetWeaver Identity Management 7.1 this week. So far I've been really impressed. SAP has done a great job updating the training materials and the trainer is knowledgeable and well prepared.

Been getting some nice tidbits on what's happening with the future of Identity Management at SAP. First of all, contrary to popular rumor CUA is not being directly "killed" by SAP anytime soon. CUA is being condemned to a slow death as SAP will no longer be updating the product. It would seem, based on some quick conversations I've had with some SAP customers. I also had an interesting chat with a SAP evangelist, who was quite excited about IDM replacing CUA. As we both noted:

· CUA only works for ABAP systems (Sorry Java, but there's no provisioning for you)

· CUA offers no Workflow and little audit tracking (Audit, we don't need no stinking audit!)

Based on this, why would anyone not be interested in upgrading? Well, it all has to do with change. These are some considerations when making a change your SAP infrastructure.

· Old methodologies need to be updated. If you have been running CUA via scripts, they will have to be evaluated for transformations into workflows and reconciliation processes.

· Help Desk and administrative users need to be trained to use the new technology. While the training will probably not be extensive, there's still a real cost in time and money to do this.

· It's not broken , why fix it?

At this point in time, I don't know that there is a compelling case to make immediate changes to an existing CUA implementation. However, if you are planning on making changes to your SAP infrastructure, this would be a good time to review your use cases and see if there is a good business reason for adopting NetWeaver Identity Management for your SAP infrastructure instead of CUA.

More tidbits as I encounter them...

News Update

I'm happy to say that I've started what I hope will be a long and successful association with Commercium Technology Inc. I am now working with them as a Senior Principal Consultant in the Identity and Access Management group.

I'm looking forward to working with SAP Identity Management, Virtual Directory and other exciting technologies like SailPoint. I'm looking forward to learning (and writing) about all of this in the weeks and months to come.

Please feel free to reach out if we can help you or your organization with your Identity Management or Compliance needs!

Managed Services Models for IdM: Slomin Shield or Roto-rooter?

One of the issues in handling Enterprise level implementations, such as Identity Management is what to do when the project is completed? The answer to that is to make sure it’s monitored and that there is a methodology to manage the implementation.

First of all we need to make sure that all connected sources and targets are up. Normally this is not a problem for most enterprise systems since they are monitored from Enterprise Management systems such as HP Openview, CA Unicenter or Microsoft MOM. It’s essential that in addition to making sure the systems are working, we also need to make sure that the systems are all talking to each other. This specific type of monitoring cannot always be done using these standard tools.

In addition to monitoring it is also important that we can manage the implementation for troubleshooting, maintenance and enhancement. When these concepts are combined, we have a recipe for the concept of Managed Services. When I consider the way that managed services work I see two basic models, which I like to call the Slomin Shield and Roto-rooter, two companies you may or may not have heard of.

• Slomin’s is an Alarm Company that offers central service monitoring. If they detect a problem, they call, assess the situation and take appropriate action.
• Roto-rooter is a plumbing company known for their quick response to service calls.

Both organizations represent effective, but different models for providing essential services, but which one is correct for Identity Management? They both have their pluses and minuses depending on the organization’s business drivers, staffing needs and high availability requirements. Based on some of my thinking this is how these models would work for Identity Management.

• The Roto-rooter model is a reactive model. When an organization sees that something needs to be done, a call is made for support services. More often than not, there is an arrangement for providing these support services. Engagement is made on an as needed basis for dealing with enhancement and upgrade processes.
• I would characterize the Slomin’s model as a more proactive model. In this model, there would be ongoing monitoring to make sure essential servers are responsive. As soon as incidents are uncovered contact is made with corporate IT to provide information on system status and likely causes of the problem. Resolved incident details would be entered into a knowledge base to provide historical data not only on what failed, but why it failed. Furthermore there is an ongoing review of needed enhancements and comprehensive review of patchers to determine applicability.

Like I said before, I don’t know that one model is inherently better than the other. The decision to embrace a particular model depends more on the organizations’ business needs and requirements. I hope to examine the pros and cons of each model in future entries.

Identity Management and GRC: The Analogy

I find it interesting how IdM implementations are no longer considered to be "complete" without considering the inclusion of GRC applications. Recent architecture discussions I've been in always seem to include mention of how the two applications should interact. It was not all that long ago that GRC was considered to be unhelpful in promoting security.

In discussions with other IdM and IT Security folks, the general consensus seems to be that IdM solutions should provide the provisioning "muscle" to provide the action and provide feedback along the workflow based "nervous system" to the GRC "brain" that decides what action should be taken and to record it in memory.

I find this analogy to be quite helpful when describing the roles (sorry for the pun) each application should take in the overall IT Security Architecture.

However, the questions do not end here. It will be interesting to watch over the next months and years to see if IdM becomes a subset of GRC or vice versa. What are the advantages? What are the disadvantages? How will SaaS affect these changes? Hopefully product announcements, briefings and real world experience will answer these questions soon.

UPDATE -- Just say this link which had some similar, interesting thoughts as well.

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.