In 2002, Microsoft released its Federated Security and Identity Roadmap, which outlined the corporation's grandiose plans for the future of Federated Security in the Microsoft product line. Microsoft predicted that a product line code-named TrustBridge would change the face of Federated Identity.
TrustBridge was touted as a set of technologies that leveraged WS-Security specifications, which would help provide a large footprint for Microsoft within the Federated Security world. It would allow many Microsoft and other applications such as .NET, Passport, and Active Directory to take advantage of the inherent benefits of a Federated Security model and help shape the face of the industry. It had the makings of something wonderful, or at the very least, unique.
And then silence…
TrustBridge dropped off the radar for almost two years. Now, after this inexplicable hiatus, TrustBridge has resurfaced. Reports from this year's Tech-Ed convention mentioned the comeback of TrustBridge. These reports indicate that Microsoft has merged its Federated Security teams into its Active Directory teams and begun to reinitialize its Federated Security plans. One thing is already clear: The term TrustBridge is no longer en vogue. Instead, ADFS, or Active Directory Federation Services, has become the latest buzzword.
In this article, I'll reintroduce "the product formerly known as TrustBridge." I'll spend some time trying to descramble the riddling enigma that is Microsoft's Federated Security/Identity plan and explain what it means to the security-conscious network administrator. However, before I do that, I'd like to talk about the history of Federated Identity.
Digital identity is certainly not a new concept. However, with the rapid promulgation of e-business and other Web-related technologies, the methods used by electronic identification needed improvement. Federated Security or Identity was designed with the mindset of creating a framework of standards and technologies that could be used to "federate" or establish trusts between companies…a cross-company trust, if you will—the operative word being trust. By creating cross-company trusts, Web-based services and business can become more extensible, flexible, and allow for the rapid proliferation of the Web-based services that have become increasingly popular.
User demand for easier-to-use, more mobile, and most important, more secure applications have driven the creation of such organizations as Liberty Alliance. Liberty Alliance is an open consortium of vendors, technologists, companies, and other assorted individuals with the sole purpose of helping to create a framework for the success of Federated Identity. The alliance is spearheaded by Sun Microsystems.
Not one to be left out of a good melee, Microsoft entered the fray with a roadmap describing its ideas on Federated Identity. An initiative or product line code-named TrustBridge was kicked off in 2002. A partnership of Microsoft, IBM, and VeriSign helped launch WS-Security, a competing set of standards that enhances SOAP messages by attempting to increase the quality of protection through better identity and improved confidentiality. WS-Security was and is a new model for security that helps bridge historically incompatible security techniques such as PKI and Kerberos. Developers and software architects alike can use this set of specifications to help craft the next generation of secure Web-based computing.
These competing Federated Security models appeared destined for a galactic battle of major proportions. However, all is well. In 2003, Liberty Alliance accepted certain aspects of the WS-Security standards and incorporated them into its specifications. Now Liberty Alliance supports what is commonly referred to as WS-*. Conversely, IBM and other major players have pledged their support of Liberty Alliance. Perhaps some convergence is possible after all!
While not much information is really available, it now appears that as a result of the merger between the Federated services and Active Directory teams, Microsoft intends to leverage its directory services with its new Federated Identity strategy. To date, I've only been able to distill two important ADFS characteristics:
- ADFS provides Federated Identity features to Active Directory via Web Services, with a richer feature set available to Web Services that follow the WS-Security specifications.
- ADFS will extend Active Directory to facilitate single sign-on to external Web applications and Web Services using pre-existing identities.
The brunt of Microsoft's Federated Identity efforts now appears to be primarily focused on ADFS, but there are rumors of Internet Information Server 6.0 enhancements and logon service improvements that provide a better, cohesive user interface that could authenticate users, generate security tokens, and even proxy different Web Services protocols.
Microsoft Identity Integration Server 2003 is tentatively scheduled to release a service pack later this year that will include some Federated Identity enhancements. And, of course, Longhorn, the eagerly anticipated next major OS release, will definitely have a lot of Federated Identity capabilities. Coincidentally, while I was writing this article, Microsoft released some improvements and add-ons to Microsoft Visual Studio .NET and the Microsoft .NET Framework via its Web Services Enhancements 2.0 Service Pack 1. This release contains support for WS-*.
Too soon to tell
Clearly, the roadmap for federation within Microsoft products was not as clear as we wanted it to be. Just try looking for current information on TrustBridge or ADFS, and you'll be hard-pressed to find much. And our friends at Microsoft have been fairly mum on the issue. With that in mind, the takeaway from this article is that Federated Security is a part of Microsoft's product future, but exactly how it takes shape is still somewhat murky. Stay tuned for more details.