Manage Learn to apply best practices and optimize your operations.

Can ADFS technology manage multiple-user authentication?

In this Q&A, Joel Dubin, expert in identity management and access control, addresses multiple aspects of ADFS systems, including the technology's ability to authenticate multiple users to a Web application.

Is Active Directory Federation Services (ADFS) technology mature enough for managing the authentication of remote customers to a Web application?
Active Directory Federation Services (ADFS) became a standard feature in Windows Server 2003 R2. The problem with ADFS is not so much the maturity of the technology itself, but rather the shifting landscape of standards for federated identity management and whether those standards are in line with your environment. Those standards underpin all federated identity management systems, including ADFS. Despite the name, ADFS isn't an extension of Active Directory; it's a Windows component that uses Active Directory.

There have been a few issues with ADFS, but let's first take a look at federated identity management, a technology...

still in a state of evolution.

Federated identity management is closely related to single sign-on, another technology for allowing authentication across diverse systems. Single sign-on allows a user with a single user ID and password -- or other login credentials -- access to multiple systems. The single user ID and password replaces multiple IDs and passwords a user might need to log on to different applications and systems.

The difference between single sign-on and federated identity is that single sign-on is for logging on within a single enterprise. Federated identity is used for logging in across several enterprises. Such a system could allow, for example, a company to directly access the systems of its suppliers -- different companies with different IT systems in different domains.

Communication among various enterprises with unrelated IT systems across corporate boundaries is the key to federated identity management systems, like ADFS. These systems can only play each other if they all abide by an independent set of standards -- agreed on by all members of the system -- for communicating authentication information to each other.

Microsoft and IBM compiled a set of standards using the WS-Federation protocol for message-based applications. Another standard is Security Assertion Markup Language (SAML), which is based on XML. Microsoft backed early versions of SAML, but broke with the standard in 2005 when SAML 2.0 was released. SAML 2.0 is backed by a consortium of companies and organizations, including the Liberty Alliance and the Organization for the Advancement of Structured Information Systems (OASIS). Both are heavily involved in setting federated identity management standards.

It's important to keep track of the different standards and platforms they work with, and the ever-shifting alliances backing each standard. Match these with your environment before making a decision on a federated identity management implementation.

Finally, Joe Kaplan, a Microsoft MVP in directory services, has reported a problem with the way ADFS handles cookies for maintaining authentication session state. Cookies are frequently used for managing such sessions, but can pose problems when used across domain and enterprise boundaries, as with ADFS. Kaplan has described workarounds and how to avoid common pitfalls with cookies and ADFS. The technology is sound, but it may need tweaking to handle cookies properly.

For more information:

  • Learn more about one of the most exciting features in Microsoft Windows Server 2003, ADFS.
  • In this Q&A, Joel Dubin explores the differences between local identity, SSO and federated identity management models.
  • This was last published in April 2007

    Dig Deeper on Web authentication and access control