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 future of SAP GRC

There has been quite a bit of  discussion about the potential futures of SAP IDM and SAP GRC. SAP has just started a survey so that they can get customer input. I would encourage all customers using or considering these products to take the poll.

I've worked with the integration between the two products several times now, and I can honestly say that I have never achieved the results that I wanted. As I've thought about the issues that have kept me from getting what I (and of course, my clients) want, it all seems to come down to the architecture.

The way SAP would have it, GRC is the brains, VDS the nervous system, and IDM is the muscle.  IDM workflow does all the work using the various frameworks (Provisioning, Exchange, GRC, Lotus Notes, etc.) while it checks with GRC via VDS to tell it what to do.

The problem as I see it is that there are:

• Too many moving parts -  IDM, VDS via WebServices to GRC, back to IDM
• Not enough information that passes back from GRC - We don't see why things are rejected and it's not clear what is happening.
• A lack of ways that conflicts can be addressed from IDM - This means that the "Security Desk" needs to get involved so they can fix the issue.

So how should this be addressed?  I think through either a tighter integration that is more direct and thicker, that is one where more information is passed, so that IDM becomes the "face" of GRC allowing for mitigation and remediation activities.  However I do not know that the current SAP architecture really supports this. therefore I think it makes more sense for IDM to "consume" GRC and make the GRC functionality part of IDM.

IDM already has a very basic concept of Segregation of Duties through Role Mutual Exclusion functionality.  Having logic that determines what should be "Mutually Excluded" from GRC type functionality makes sense.

However as SAP Roles map to IDM Privileges it would also be necessary for this concept to be extended to the IDM Privilege level.

Finally this new functionality would need to include the ability to implement periodic entitlement reviews (sometimes referred to as attestation or certification) Since in a typical SAP Landscape implementation IDM is connected to HCM with Manager and Organizational properties already defined, IDM is in an excellent position to use it's Presentation Layer, Notifications and Identity Store Database to support this.

This just my opinion and I have registered it via the survey posted above.  Go register yours!

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.

The meaning of Identity?

I’ve been involved in a number of conversations lately with colleagues and the Identity Commons mailing list about the nature of identity. The fact of the matter is that as far as the Information Technology / Information Security arena is concerned, there truly is no such concept as an identity. Rather what we truly have is a collection of descriptors or “attributes” that when brought together and agreed upon by an organization or group of organizations that describes what we choose to call the identity. Why the vagueness here? Well that’s because an identity can be more than just people, but that’s another story. Regardless, once we have determined what goes into an identity, we can begin to discuss how technology can process it.

The thing that I’m hearing more and more is that just having an identity is not enough. As mentioned previously, the identity is just an agreed on set of descriptors and does not really do anything. So how do we make this happen?

Well it is rather easy when everything is within the same domain. Agreements are easy (well, easier) to make when there is only one organization involved. Once we get outside of the domain, there greater complexity due to meeting the diverse needs of each organization, including (but not limited to) audit requirements, privacy rules, establishing common protocols and, of course, determining a description of what the identity is in the first place.

It’s great that we’re linking in tightly to ERP suites as Oracle and SAP tell us we should do. Leveraging repositories for use in authentication is great as Microsoft says we should do. Federation would be fantastic if we could get folks to come to quick agreements. What we really need is more actions that are associated with what we do with these identities. From what I’m seeing / hearing, there’s not enough being done with the actual identities once we’ve constructed them based on the authoritative sources in the organization’s IT infrastructure.

I think a great example of what can be done is shown in an article in CIO magazine that I saw on Jackson Shaw’s blog the other day.

We talk about these things all the time, but it seems many organizations barely get out of the Authentication / ERP stage since that’s perceived to have more direct impact.
I disagree. Truly actionable items that result in a direct decrease in getting employees functional should be the first effort in any Identity Management project after the data has been cleaned and a definition of what an identity is.

This is an ongoing discussion that’s not going away anytime soon. Not the definition of Identity, not what to do with the Identity, or how to protect the Identity.

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.

Intelligent IDM

Just read a great blog post (Thanks, Dave Kearns for posting in your newsletter) that I think anyone involved in Identity Management Architecture / Design / Management should be aware of.

Earl Perkins from Gartner Group has written a short piece on Business Intelligence information that can be obtained from an IDM solution.

We've spoken for years about making IDM a part of compliance and security, and certainly tools such as SailPoint Identity IQ help provide that data, but I think that all applications, particularly provisioning applications that are long on information and short on reporting and logging could do more to share this information not only with central BI repositories. Certainly there is information that is of interest to a BI warehouse. It would be interesting to see what such a model would look like.

I look forward to seeing what Earl and others develop in this concept.

"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.

More on SailPoint

In reviewing yesterday's post, I realized I got a little off my intended track of talking about my SailPoint training, and spent more time talking about IdM Architecture.

In light of that, let me talk a little bit more about SailPoint and what they have to offer.

The SailPoint product seems pretty darn interesting. It does a fantastic job of linking in to various types of repositories (LDAP, Database, ERP, flat files, etc) that are found in the Enterprise and brings them into a common repository known as the Identity Cube (love this name, BTW)

Once the data is in the Identity Cube, all the fun begins, we can then do Role Mining, Segregation of Duties and other forms of Compliance analysis, and most importantly, Certification/ Attestation. It's easy to do all sorts of searches and analysis on the information held within the Cube and produce everything from application centric user role reports to IT Security oriented Risk scores based on role, application and group membership.

I'm going to find it pretty darn hard to believe that Enterprise IT and auditing departments will be able to work without a tool such as this in the future. This application is a great add on to add to current Identity and Risk Management projects and I'm looking forward to working with it.

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.