Federated identity
A federated identity in information technology is the means of linking a person's electronic identity and attributes, stored across multiple distinct identity management systems.[1]
Related to federated identity is single sign-on (SSO), in which a user's single authentication ticket, or token, is trusted across multiple IT systems or even organizations. SSO is a subset of federated identity management, as it relates only to authentication and is understood on the level of technical interoperability.
Federated identity management
In information technology (IT), federated identity management (FIdM) amounts to having a common set of policies, practices and protocols in place to manage the identity and trust into IT users and devices across organizations.[2]
Single sign-on (SSO) systems allow a single user authentication process across multiple IT systems or even organizations. SSO is a subset of federated identity management, as it relates only to authentication and technical interoperability.
Centralized identity management solutions were created to help deal with user and data security where the user and the systems they accessed were within the same network – or at least the same "domain of control". Increasingly however, users are accessing external systems which are fundamentally outside their domain of control, and external users are accessing internal systems. The increasingly common separation of user from the systems requiring access is an inevitable by-product of the decentralization brought about by the integration of the Internet into every aspect of both personal and business life. Evolving identity management challenges, and especially the challenges associated with cross-company, cross-domain access, have given rise to a new approach to identity management, known now as "federated identity management".
FIdM, or the "federation" of identity, describes the technologies, standards and use-cases which serve to enable the portability of identity information across otherwise autonomous security domains. The ultimate goal of identity federation is to enable users of one domain to securely access data or systems of another domain seamlessly, and without the need for completely redundant user administration. Identity federation comes in many flavors, including "user-controlled" or "user-centric" scenarios, as well as enterprise-controlled or business-to-business scenarios.
Federation is enabled through the use of open industry standards and/or openly published specifications, such that multiple parties can achieve interoperability for common use-cases. Typical use-cases involve things such as cross-domain, web-based single sign-on, cross-domain user account provisioning, cross-domain entitlement management and cross-domain user attribute exchange.
Use of identity federation standards can reduce cost by eliminating the need to scale one-off or proprietary solutions. It can increase security and lower risk by enabling an organization to identify and authenticate a user once, and then use that identity information across multiple systems, including external partner websites. It can improve privacy compliance by allowing the user to control what information is shared, or by limiting the amount of information shared. And lastly, it can drastically improve the end-user experience by eliminating the need for new account registration through automatic "federated provisioning" or the need to redundantly login through cross-domain single sign-on.
The notion of identity federation is extremely broad, and also evolving. It could involve user-to-user and user-to-application as well as application-to-application use-case scenarios at both the browser tier as well as the web services or service-oriented architecture (SOA) tier. It can involve high-trust, high-security scenarios as well as low-trust, low-security scenarios. The levels of identity assurance that may be required for a given scenario are also being standardized through a common and open Identity Assurance Framework. It can involve user-centric use-cases, as well as enterprise-centric use-cases. The term "identity federation" is by design a generic term, and is not bound to any one specific protocol, technology, implementation or company.
One thing that is consistent, however, is the fact that "federation" describes methods of identity portability which are achieved in an open, often standards-based manner – meaning anyone adhering to the open specification or standard can achieve the full spectrum of use-cases and interoperability.
Identity federation can be accomplished any number of ways, some of which involve the use of formal Internet standards, such as the OASIS Security Assertion Markup Language (SAML) specification, and some of which may involve open-source technologies and/or other openly published specifications (e.g. Information Cards, OpenID, the Higgins trust framework or Novell’s Bandit project).
Technologies
Technologies used for federated identity include SAML (Security Assertion Markup Language), OAuth, OpenID, Security Tokens (Simple Web Tokens, JSON Web Tokens, and SAML assertions), Web Service Specifications, Microsoft Azure Cloud Services, and Windows Identity Foundation.[3]
Examples
Digital identity platforms that allow users to log onto third-party websites, applications, mobile devices and gaming systems with their existing identity, i.e. enable social login, include:
- Microsoft account - Formerly Windows Live ID
- Yahoo! - not only can users use their Yahoo! ID to log onto other sites, but users used to have the possibility to log onto Yahoo! with their Google or Facebook IDs.
- PayPal
- Foursquare
- MySpace
- AOL
- Mozilla Persona
- Amazon - Login With Amazon
In many cases there is also the possibility to exchange profile information about the user with the third-party site, for example name, address, email, and photo. Nowadays, services like Gigya, Janrain, Loginradius have simplified the implementation of social login a lot. Along with social login, they provide additional features like Single Sign-on and others.
Note: Facebook Connect is a delegated ID, not a federated ID[citation needed].
See also
References
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ http://net.educause.edu/ir/library/pdf/EST0903.pdf 7 things you should know about Federated Identity Management
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
