(IdM-N) + (IdM-A) = IdM

Eric Norlin responded to my Identity Management for Networks post with some thoughts of his own. It sounds like we are mostly on the same page (i.e. he agrees sticking the “N” or “A” at the end might help) however he did point out some real challenges to the merger of the two spaces:

Sean sees identity management becoming a “single entity.” I’m not as optimistic. There’s an awful lot of legacy to get through here — legacy of job titles, legacy of how software and networking companies are organized, just plain legacy. Will IdM-N and IdM-A products and suites have to learn how to be intertwined? Absolutely. Will they merge? That sounds like a ten year job to me.

I actually think we agree here more than we disagree. I absolutely agree that this will take a while, perhaps not 10 years, but certainly more than a couple. Eric’s post and my conversations at the recent NAC conference got me thinking about the phases of integration. This certainly isn’t a binary switch-over and I doubt we’ll want to get to one solution from a vendor that addresses all your identity needs. Hopefully Eric will chime in here as I’m guessing I’m missing some steps, but these are the big stages of integration that jump to mind.

Networks and applications use the same back end directory for user authentication. I think we’re mostly here now, or very close to it. Whether it be through a meta / virtual directory or direct to an AD or LDAP store, the customers that I’m engaged with either are already using a single directory infrastructure or are rapidly moving toward it. Of course bridging across multiple directories, groups, and attributes will remain critical, but this will be pain experienced equally by the applications and the network.

Networks and applications trigger authorization policy based on the same groups and attributes. This isn’t yet happening consistently within applications so it certainly isn’t happening consistently between networks and applications. Getting this to happen has a lot to do with step three, below.

HR user provisioning systems create one user record which automatically has associated application and networking rights. This is another place where we have work to do. Today an HR provisioning system from one large vendor might only deal with rights and authorizations for that large vendor’s applications and not the rest of the infrastructure’s needs. However, creating the right workflow so that, say, the HR system can define a user as an employee, privileged employee, or contractor would allow the network to inherit those authorizations and enforce them within the network context.

Network and application policy decision points (PDPs) share policies or audit information. This is another area that needs lots of work. Standards like XACML make this easier, but there still needs to be a defined schema for the attributes and an understanding of why the policies would be shared. Two easy examples would be one, allowing an application to query audit data within the network to see that a given user has a secure network connection before granting access to a sensitive area. The second is the application PDP informing the network of the systems the user has access to; the network could then prevent IP connectivity to disallowed applications. (Note: server virtualization will make this tricky.)

A single PDP brokers policy decisions for networks and applications. I doubt we’d ever get here for all network and application requests (nor would we likely want to) but it seems likely that subsets of applications and networks will share a common PDP. This PDP could then share policies with other PDPs inside or outside the organization.

So as I was saying earlier, this isn’t going to happen all at once. I’d also expect different organizations to go different lengths down this road based on their culture, politics, and business needs. In general based on my dealings with customers, there is a definite desire to make this happen primarily for business efficiency and compliance.