1dent1ty cHa0s

So yeah, I'm obviously biased towards an answer here, but I get this question a lot and many are surprised by my methods of recommending a platform - yeah I said it, a platform, not a product.  Let's first discuss what it means to be an Identity Management Platform.

Product, Platform or Suite

There are a plethora of products on the market today, sometimes referred to as boutique vendors which specialize in doing one thing very well; they are either provisioning or password synchronization specialists with synchronization and integration functionality added as an afterthought.  Some of the larger IdM suites purchased boutique solutions to round out their feature set or gain depth in a particular market segment.  This tends to make the suite's just a collection of individual products with specific strengths, little integration amongst themselves, and plenty of overlap. 

In contrast, a platform is something you can build on which implies a solid foundation.  But what makes for a solid foundation for Identity Management?  Let's come back to that in a minute...

Evaluation Time

We frequently come across customers who wish to evaluate several different products before settling on a solution.  They also love to dictate the requirements for the evaluation citing the features they think are most important in a solution which are invariably pulled from marketing materials provided by one of the vendors which stilts the results towards one product or another.  Let's get one thing straight, every one of the major players in the market today are equally capable at solving the requirements of IdM solutions today or they wouldn't be successful.  Even the boutique products do what they claim to do so I say for the sake of argument that all IdM products are equally able to get the job done.  And don't just take my word for it, according to InfoWorld's IDM Shootout back in 2005, all of their products evaluated completed the tasks set before them:

All of the solutions we tested met our essential requirements, but important differences emerged. Some products worked well on the back end but lacked a unified management and reporting interface. Others presented the slick front end but a problematic foundation. Moreover, some vendors did a better job than others of tying together the multiple tools for identity management into a single, unified solution.

That being said, what can we use to distinguish one from another?

I take a bit of criticism because I tend to distill all of those fluffy evaluation requirements down to just two:

1. What is your company's primary development platform?
2. Based on the answer for the former, choose the vendor with the best synchronization engine that supports your development standards

If you're a big J2EE shop then a Microsoft IdM solution isn't going to be for you, and likewise if you're a big .NET shop then a Novell IdM solution is going to be a poor fit. 

The Synchronization Engine

At the heart of all of the available solutions is an engine which is ultimately responsible for reading data in from one source, manipulating it and feeding it to other subscribing targets.  They come in all shapes and sizes with various backend models (DBMS vs Directory) and differing data paradigms (event based vs state based).  The engine is the true workhorse under the pretty veneer, so choose wisely.  It's much easier to build say, password synchronization on top of a robust sync engine than it is to build a robust sync engine behind an excellent password management portal.  The extensibility of that engine and the development flexibility for customizing how that engine processes data becomes the fundamental component of the equation.  So, why am I tying so much importance to the development standards?

The Identity Management Platform

Remember when I said that all IdM products were equally capable of satisfying your requirements?  It's also true that no products or solutions on the market encompass either a total solution or a full out-of-the-box solution.  All solutions require customization and tailoring for your unique business rules.  You see, it's nice and easy to require a product to connect to all of your data sources, but it's a completely different thing to expect any product to understand your business and even if those neat specialized provisioning tools solve all of your immediate needs, what they provide in robust account provisioning they lack in total flexibility.  It's the flexibility that is ultimately the most important goal for any solution and how do you achieve flexibility?  You guessed it, by having a platform that allows for complete customization - one that can grow and evolve with your evolving business needs.  It's important to note here that the InfoWorld challenge did not include extensibility as a weighted metric in their evaluation. 

People, Not Products

So, don't be fooled by fancy interfaces, glitzy wizards and hefty price tags because at the end of the day, it's not about what looks good now - it's about what is still going to be relevant in several years after the next big compliance mandate is applied shifting the focus of your IT compliance strategies yet again.  Invest in a platform with a robust sync engine - one that is capable of being easily extended and that is in line with the greater development standards of your company.  Furthermore, investing in a platform allows you to invest in the people that drive and define that platform - your developers, architects, and analysts.

Anyone that has attempted to do a "real" PKI deployment (i.e. not a "next, next, finish" deployment of Windows PKI) by runs quickly into the difficulties involved in defining PKI specific policy documents - namely the Certificate Policy and the Certificate Practice Statement (CPS).  For those of you that are not familiar with either of these, or if you've deployed your PKI and you've never heard of either of these then here is why they are important.  There are three documents that are really critical to PKI planning:

1. Security Policy - this is that "thing" that, if you're lucky you already have published, or if you're like many companies I come across you're still trying to get someone to sign-off on a real/well defined security policy.  The security policy is what you refer internal consumers of your IT to when they want to know either how something should be done or why they can't do what it is they are requesting.  The security policy is really the foundation of the next two documents which can't be built without it.
2. Certificate Policy - this is more or less an adaptation of or a more focused version of the security policy with special relevance to how the issuance and use of certificates are to be inside your company.  Where the security policy is broader, the CP focuses more on how certificates are issued, used/published and revoked.
3. Certificate Practice Statement (CPS) - this document focuses more on how the various policies in the CP are enforced - what are the processes for revoking a certificate, how are certificates validated, and what happens when a CA is compromised.  This document is especially critical in B2B situations where you need to make a decision whether or not to trust another company's PKI implementation - this is done by publishing the CPS externally (in fact your certs may have a public URL pointing to your company's CPS online).  If a company really hasn't thought things through you should be able to tell by looking at their CPS.

Now enter in the certificate management facilities in Identity Lifecycle Manager 2007.  As advertised, the certificate management capability of ILM 2007 is targeted at simplifying the enormous task of managing certificates for smart card devices.  This is most evident during the initial enrollment of a new person during your company's on boarding process - someone has to actually get the certificate on to the card, validate that the person they're giving it to is actually the person they claim to be, and then by some manner communicate the PIN.  While on the surface the product seems focused at this single critical event, much of its real value is realized after enrollment through ILM's policy enforcement.  Without a tool like ILM, there really isn't a way to enforce the practices you've outlined in your CPS - so in very simplistic terms, you can think of ILM's policy enforcement as Group Policy for PKI (not really, but hopefully you get the picture).

It's very satisfying to see that ILM is in line with a broader trend that ILM 2007 is spearheading which is really a desire to map your own internal policies and processes to policies and processes which can be managed and enforced through the ILM 2007 product set.  Being able to audit and report on the enforcement of your CPS will put you way ahead of most companies and will go a long way towards satisfying any compliance related restrictions you're currently dealing with.

If you have a Microsoft PKI environment today, or are contemplating one in the near future, I strongly recommend taking a look at ILM 2007 as a very necessary component of any Enterprise PKI - ILM 2007 ships May 1st!

I've posted the initial outline for my presentation entitled "Using SQL Reporting Services for MIIS Reporting" at this year's Directory Experts Conference on the DEC Wiki site in the hopes that everyone will help tailor the content to make it more effective. If you are attending the conference this year or just want to give your two cents, logon to the DEC Wiki site and please add your comments! Remember, you're paying for it (or you're lucky enough to have your company pay you sly dog you), so get as much value as possible!

Remember those atrocious ads in the back of comic books luring your money away for the promise of seeing through walls for a peak at confidential data?  Well, look no further, MIIS can do this right out of the box (cereal not included)! 

In a previous posting I talked about the Confidentiality Bit now available in Windows 2003 level Active Directories.  On a recent project I was frustrated by a set of attributes that were apparently empty but MIIS kept insisting there was data there.  No matter what I did or where I checked, MIIS kept importing the data even though ADSI Edit and LDP clearly showed this value was null.  After further investigation, remote consults (thanks Markus!) and much head scratching it was found that the attribute in question had the confidentiality bit set - MIIS was reading the data even though it was protected!  How can this be, and is it a security risk?

DirSync and the Replicate Directory Changes Right

Active Directory, being a robust directory service, has a facility for querying for changes called DirSync.  Once you have a full read of the directory, DirSync can be used to request only objects or attributes that have changed since the last query.  Prior to Windows Server 2003, DirSync only functioned in so called "regular" mode which exposed the attributes and objects therein equally and seemingly unprotected but looks can be deceiving.  Let's see what MSDN has to say about DirSync:

The DirSync technique is based on an LDAP server control that you can use through ADSI or LDAP APIs. The disadvantages of the DirSync control are that it can only be used by a highly privileged account, such as a domain administrator. The following is a list of limitations of DirSync control:

• The DirSync control can only be used by a highly-privileged account, such as a domain administrator.
• The DirSync control can only monitor an entire naming context. You cannot limit the scope of a DirSync search to monitor only a specific subtree, container, or object in a naming context.

By "highly privileged" we mean the Replicating Directory Changes right which can only be assigned at the root of the naming context (domain, configuration or schema).  You're already familiar with this right because MIIS requires it for the ADMA and MIIS can't even read the directory without it - go ahead, try.  As it turns out, it takes a very deliberate act from a privileged administrator to grant this right, but administrators will always want to be aware of what granting this right has the potential to expose.  Luckily for us, MIIS is generally involved with placing the confidential data in the directory, so reading it is a moot point - and remember, passwords are always hashed, so they are never exposed.  The point I'm trying to make here is that by default, the account you use for your ADMA doesn't need rights to read attributes protected by the confidentiality bit - partially because that bit is designed to protect from casual read access but mostly because they are protected by the Replicating Directory Changes right.  So, is there another option?

Per-object Security for DirSync

In Windows Server 2003 Active Directory there is an option to enforce per-object security through the DirSync changelog, but I'm at a loss as to how to enable it.  Furthermore, there is currently no option for the ADMA to operate under this environment, so for the time being you're still going to have to grant the right anyway; however the pieces are in place to further extend the reach of the confidentiality bit to the DirSync changelog.

Summary

The Replicating Directory Changes right trumps the confidentiality bit - at least until per-object security can be enabled in the DirSync.  Ensure that any identities or processes that are delegated this right are cleared to read any data stored in the directory that may be marked as confidential.