|
The identity federation segment of the identity management (IdM) market is a hotly contested but modestly lucrative space. Although vendors rushed to develop standards, competing standards, and products for crossdomain identity, most customers today deploy federation solutions without a formal request for proposal (RFP) process. Oftentimes, federation technology finds its way into enterprise deployment as a rider on the back of a more significant project, and so doesn't command the attention or funding vendors had hoped for. Customers generally view federation technologies as one of several technology options for solving access and single sign-on (SSO) problems. Federation products are roughly in the same class as enterprise SSO (ESSO) and web access management (WAM) products, with each category addressing SSO needs at different tiers in the network.
However, the real competition for federation product today is the myriad of proprietary solutions already in place on enterprise networks. Organizations with existing custom solutions for token exchange find it difficult to justify the switching costs that state-of-the-art federation deployments require. In rare cases, executive authority has backed federation projects in an effort to improve an organization's security and compliance objectives. In such cases, sponsorship at the executive level greatly improves the success rate of federation projects. So, despite the aspirations of vendors that federation technology would usher in an era of innovative business models, the market has so far not developed that way. New business models typically take a long time to develop, so the time-to-sales model for getting federation products into “greenfield” business opportunities is correspondingly drawn out and costly. Customers also have urgent, tactical needs for connecting with thousands of existing partners. So vendors and customers alike are now focusing on federation as a standards-based, security-conscious way to interact with existing partners. (For more information on how legal concerns affect federation adoption, see the Identity and Privacy Strategies overview “Business and Legal Issues in Federations .”)
The focus on the here and now is pragmatic and sound. Organizations have tremendous needs for access management with their partners. But it also draws into question whether the federation market will remain a segment (with stand-alone products delivering identity federation services) or whether it will fade into the IdM fabric as a component of a larger system. Most likely, both will occur. General-purpose products and hosted services will remain viable, while other types of federation will be blended with WAM and application server products.
In the meantime, organizations will continue to deploy federation services at various tiers in the network. This report helps architects understand how to evaluate products for use in a tiered model.
One of the themes explored in the Identity and Privacy Strategies report “Enterprise Identity Management Market 2006–2007: Not a Winner-Take-All Market,” is the tendency of the IdM market to resist vendor dominance. The federation segment is no exception. Several complications thwart vendors' attempts to capture the federation—indeed the SSO—market segment. Chief among these are the divisions that occur naturally in information technology (IT) infrastructure. These “natural domains” don't lend themselves well to centralized management. Large organizations span geographies, cultures, legal jurisdictions, and diverse resources. Limits of organizational scale necessitate compartmental and departmental approaches to management. Without the existence of a single natural domain to host the federation service, no single product (or instance of the product) can provide the breadth of coverage required.
Some domains exist artificially, but are equally difficult to converge. For both business and technical reasons, application silos and walled gardens are found everywhere on large networks. For example, organizations using Microsoft applications require some use of Active Directory Federation Services (ADFS) for cross-domain SSO, because the proprietor of that environment—Microsoft—has made it the gateway to integration. Similarly, customers using SAP products rely on the vendor for integration of federation standards to their environments at the NetWeaver junction point, but struggle when attempting to integrate federation directly into SAP applications. However random, contrived, or exploitive such synthetic domains may seem, they are nonetheless stable features of the landscape and further frustrate the desire for centralized control.
|
