The local identity model, as the name implies, refers to authentication of a local system only. Federated identity management, on the other hand, allows users to log on to different systems across different domains, like those of various companies, enterprises or suppliers.
A close relative of federated identity management is single sign-on (SSO). In many organizations, users have several applications that they need to log on to, each requiring distinct user IDs and passwords. SSO allows a user to sign on once with a single user ID and password, and still have access to these different systems.
The difference between SSO and federated identity is subtle. SSO unifies access management for disparate systems within an organization. Federated identity does the same, but across different organizations. In a sense, federated identity is SSO across company boundaries.
Federated identity is meant to be a more efficient way to access similar systems used by different enterprises. A bank, for example, might issue one-time password (OTP) tokens for customers looking to log on to its Web site. If several banks use these security devices, an individual user could have a pocketful of tokens. Federated identity is meant to circumvent such a hassle, and customers would only need one token for several banks.
Federated identity management is still in its infancy, and many organizations are skeptical of the authentication concept. Besides the technical issues of creating a centralized directory structure, there are the issues that come with sharing authentication information among competing organizations. This has probably been the biggest stumbling block to date.
Initiatives, however, are still continuing with such efforts as Liberty Alliance Project, Security Assertion Markup Language (SAML) Web Services Federation Language (WS-Federation) and the open source project SourceID.
This was first published in December 2006