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.

History

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!

TrustBridge (ADFS)

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.