Use cases outlined for federated directory

* At the heart of proposed federated directory is minimal disclosure and the ability to only release exactly the data that is needed

As I said in the last issue, one of the highlights of last week's European Identity Conference was Kim Cameron's presentation on his new project, federated directories. In the presentation he announced the imminent shipment (May 5) of Active Directory Federation Services (ADFS) version 2. With that, he said, that claims-based transactions within the enterprise were a done deal, a foregone conclusion -- an integral part of the plumbing. There are a few small details to work out, but it's time to set our sights on moving this technology across security domains, even into the cloud platform that XaaS (X=everything as-a-service) has created.

Cloud-based computing demands a strong, secure identity structure. In short, according to Cameron, it needs a claims-based system. But more than that it needs a federated claims-based system.

What's needed is for the relevant data from my enterprise directory to merge with the cloud provider's directory in such a way that it appears to be one unified directory. But this has to happen for all of the clients of that cloud service provider. Yet the privacy of each constituent user, the security of each client's data and even the knowledge of who the provider's clients are has to be managed intrinsically. Minimal disclosure, the ability to only release exactly the data that is needed, is at the heart of the system Cameron describes.

He listed a large number of use cases in which a federated directory system could play:

* Cell phone to enterprise directory -- All employees and their phone numbers immediately available when a phone is unlocked (but no other information), and immediately delisted when the employee is terminated.

* Departmental directory to enterprise directory -- Information kept on a departmental basis (e.g., sales contacts) are federated to the enterprise level and available to those who need them wherever and whenever the need arises.

* Cell phone to cloud directory -- cell phone address book is kept up to date by not only by corporate directory system but also by my federated (clients, vendors, family, friends, etc.) directory systems.

* Merger and acquisition -- A temporary federation of directories could occur within days -- even hours -- while a genuine merged system might take months.

This last use case necessitates the need for a schema transformation system. Not everyone uses the same vocabulary and lexicon for the attributes and values (or, as Cameron says, the "claims") within their directories. But building a engine that  translates and/or transforms these terms would be relatively easy. That transformation engine is also a necessary part of the system.

There were many more use cases presented.

But this is a project still in its formative stages. It's well funded, but still needs determined effort to succeed. I wish Cameron lots of success with it and I hope you do, too.

Related:

Copyright © 2010 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022