At the recent Directory Experts Conference (DEC), Microsoft's Stuart Kwan spoke of what's been called the "identity bus." His contention was that the Microsoft Identity Metasystem was the perfect vehicle (pun intended) for this purpose.
At the recent Directory Experts Conference (DEC), Microsoft's Stuart Kwan (he's Director, Program Management for Identity and Access and an annual contributor to DEC) spoke of what's been called the "identity bus." His contention was that the Microsoft Identity Metasystem was the perfect vehicle (pun intended) for this purpose.
As Network World’s John Fontana, in his coverage of Kwan’s keynote, reported: “The end game for corporate identity architectures is an ‘identity bus’ that off-the-shelf applications can plug into in order to authenticate users and provide access control.” Stuart went on to champion the security token service (STS) part of the Microsoft Identity Metasystem as the “transformer” for the identity bus.
The vision is that the STS can take data (“claims” in Microsoft identity-speak) and transform them from one protocol (LDAP, SAML, etc.) into another (such as ADFS or WS-Trust, for example). But why stop there?
Back in the day when dinosaurs roamed the network, incompatibility was the standard, interoperability the “rara avis.” For the network itself there were hardware bridges to move packets between any two of Arcnet, Ethernet and Token-ring. But even more special were the data hubs we used for databases and e-mail.
Non-SQL databases were scattered all over our networks: dBase, rBase, Clariion, Btrieve, Foxbase and dozens more were in use – many within the same organization as departmental computing grew to support the enterprise. An innovative startup in Austin, Data Junction (now part of Pervasive Software), came to the rescue. The “Data Junction” was a hub, with spokes for all of the various proprietary databases. It could read the schemas and convert the data types while moving the data from one format to another. It was, at times, a life saver!
About the same time, people were trying to get e-mail from one system to another. Youngsters may scoff, but back in the day if you used cc:mail, your partner used Microsoft Mail and a client of both used DaVinci – then you couldn’t send mail to everyone involved in a discussion. E-mail hubs were the answer (see this 1996 Infoworld review of one. Think of this as a historical document!). In essence, though, the e-mail hub worked just like the data junction hub: spokes ran out to many different e-mail systems and a message simply came in one spoke, got converted, and was sent out another spoke.
It’s a lot like flying to a city more than 500 miles away. Fly to the hub, get processed, fly out of the hub.
Doing this for identity protocols should be easy-peasy. The protocols are well defined. The information in the packets is a relatively finite set of data. Encryption on each of the spokes is relatively simple. This is what the STS should be. Microsoft won’t build this (as we noted recently, they still haven’t committed to supporting all open protocols for identity). So it’s time for someone to step up. The identity world is waiting.
Upcoming events from the IdM Journal calendar:
April 22 - 25 2nd European Identity Conference, Munich, GermanyThe Single Sign-On Summit, Keystone, Colo.Digital ID World, Anaheim, Calif.
July 23 - 25
September 8 - 10