An anonymous reader posted to the Network World forum asking about the Identity Bus: "Using LDAP as the name or protocol for the Identity Bus makes it sound like a virtual directory to me. What would be the difference? How would an Identity Bus be different than a virtual directory?" A perfectly good question, which shows the interest in the concept, but also the need to explain it all just a bit better.

Back in March when I first mentioned the “Identity Bus” as introduced by Microsoft’s Stuart Kwan I also mentioned that the concept I preferred could be called an “Identity hub” - a system to transform protocols and data from one format to another. In some ways, that’s what a virtual directory does.

Boiled down to essentials, a virtual directory is a database of pointers to various data repositories. Many of those repositories are identity datastores (LDAP directories, x.500 directories, Active Directory, username/password stores, etc.) while others (financial databases, e-mail address books, inventory lists, etc.) are data items that can be associated with an identity while not actually being identifiers. The virtual directory presents a single view of all of the data while at the same time relating the various bits of information to a particular identity. It does this by translating a request (via LDAP, SQL, ?ML, etc.) into the native protocol of the datastore from which the request is ultimately being made. It then takes the result and packages it in a format the calling application will understand. (Compare Identity Management products)

The Identity hub would also take requests from applications and services, translate them to the native protocol of the datastore and send them to their destination. The reply would undergo a reverse operation to send the result back to the requesting application or service. That sounds very similar, doesn’t it?

The most important difference, though, is the knowledge inherent in the service (the virtual directory or the Identity hub). A virtual directory, at it’s heart, is what’s called a “join engine.” Before it can successfully operate it needs to know all of the identities throughout the system and know which identifiers refer to the same entity. In other words, it needs to know that dkearns, davek, and DAK all refer to the same entity: me. Thus, it can serve up data from all the authoritative sources about me, when requested to by someone or something with sufficient rights to view the data.

Whitepapers

• Getting in Compliance With Government Data Regulations By Leveraging Online Security Technology
• How to Offer the Strongest SSL Encryption
• Maximizing Site Visitor Trust Using Extended Validation SSL
• Seven Steps to Reducing your Security Risk
• The Latest Advancements in SSL Technology
• Vulnerability Management For Dummies

View more SECURITY whitepapers

Webcasts

• Mobile Data Security
• Best Practices for Deploying WAN Optimization for Disaster Recovery
• Key Considerations for a Successful 802.11n Deployment
• Solutions to the Toughest IT Challenges in Remote Offices
• Lowering the Cost of Email Archives
• High Availability for SQL Server 2005 Using Array-Based Replication and Host-Based Mirroring Technologies

View more SECURITY webcasts

Special Reports

• The Evolution of Network Security
• Taking Virtualization Up a Notch
• The self-managed network

View more SECURITY special reports