Sean Convery

Eric Norlin over at Digital ID World is posting a bit lately about the identity elements of network access control (NAC). First making the case for identity being a component of NAC and later describing why static roles don’t cut it once you go beyond very basic policy with NAC. (Full disclosure, I’m speaking on a panel at this year’s Digital ID World about this very topic.) If you’ve been following the identity management space at all there is an implied prefix for almost all discussions on the topic: the word “application.” Whether it is single-sign-on, federated identity, or two-factor authentication; nearly all topics related to identity management are framed with respect to the application. This makes sense after all, as it is the application that is the only place–save a VPN connection–that a user has typically authenticated to.

This lack of focus on the network can be entertainingly exposed through a few google searches. Google (in quotes) “application identity management” and you’ll find a paltry 120 hits with both Eric’s and my passing use of the term on the first page. Google “network identity management” and the situation improves with about 10,400 hits. Now google “identity management,” the term typically associated with “application identity management,” and you get a number more like what you’d expect: over 35 million.

Times are certainly changing though as now Digital ID World, long a stomping-ground for the practitioners of identity management as traditionally defined, is taking on NAC. This either strikes you as intuitively obvious or completely wrong depending on your frame of reference. NAC as it was originally trumpeted by Cisco and others focused in on a very specific, albeit novel, application of NAC: validating the configuration or “posture” of an endpoint prior to connecting to the network. This functionality was called “network-node validation,” “posture checking,” and other similar terms. For obvious reasons given Cisco’s marketing budget, these checks became synonymous with the broader use of the term NAC.

However as Eric points out, NAC is anything but just checking patch levels:

Walking through NAC reveals this to be so: a person (identity) authenticates to a device (identity); device (identity) authenticates to the network (identity); network checks device for policy compliance – often individual specific policy compliance(identity); network enforces compliance upon person through a series of challenges, alterations to credentials or revocations of access to critical systems (all identity); network aggregates all identity data around devices, policies and individuals for audit purposes (who had access to what under what circumstances for what reasons and for how long — all identity); network helps person and device correct any policy violations (identity) and begin accessing (identity) applications with fine-grained authorizations (identity).

“Identity Management” is certainly the correct term without the prefix but it may take us a little time to get there. One practical impediment is that the network operations folks looking at identity are generally not the same people that would deploy a single-sign-on service for an enterprise’s web applications. However, these barriers need to be torn down because the potential applications are quite compelling. For example, imagine checking the integrity and identity of a laptop prior to allowing it to originate transactions above a certain dollar amount within an enterprise’s accounting system.

Until then, I welcome these early conversations concerning extending identity management to the network. NAC probably represents the best bridge between these two worlds and I look forward to more discussions with the application folks over time.

This entry was posted on Tuesday, July 25th, 2006 at 10:39 am and is filed under Network Authentication. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.