Federated Identities: a one-stop hacking shop for all your credentials
Every user in today’s digital world has almost certainly encountered federated identities, but few are aware of the associated security risks. Tools we rely on everyday – like Google and Facebook – deploy federated identity management by linking a user’s digital identity across multiple service providers, allowing the user to login once and jump to another application or service without signing in again.
While this streamlines user experience, reduces attack surfaces, and improves productivity, if just one access point is hacked, all identities and the downstream applications or services linked within the system may become compromised. So, given the ubiquitous use of federated identities, what are the risks and best practices for federated identity management?
A history of federated identity
Federated identities date back over twenty years, when companies started to realize that they needed more efficient and secure ways to manage user identities across multiple systems and applications. The Liberty Alliance Project, which launched in 2001, aimed to develop open standards and technologies for federated identity management. It brought together companies and organizations, such as Sun Microsystems, Novell, and American Express, to create a common framework. The first version of the Liberty Alliance specifications was released in 2003 and defined a set of protocols and standards for exchanging authentication and authorization data between different systems and domains.
Many other initiatives and standards have emerged in federated identity management since, including Security Assertion Markup Language (SAML), OpenID Connect, and OAuth, among others. These technologies play a critical role in enabling secure and seamless access to resources across different systems and domains, while working to maintain user privacy and control over identity information. SAML, OpenID, and OAuth can also be used to implement a zero trust framework, which assumes that no user or device can be trusted by default, granting access only based on the context of the request and the identity of the user or device.
Significant benefits, but unseen risks exist
Federated identities offer significant benefits that many users may not even be aware of. The most obvious is an enhanced user experience; federated identity management allows users to access multiple applications and services using a single set of credentials. Anyone trying to juggle dozens of personal and work related credentials (e.g., usernames and passwords) can appreciate it when they have fewer things to remember and manage. Federated identities can also improve security by enabling stronger authentication methods, reducing the risk of password-related security breaches, and improving management of user access to resources across different domains.
While these benefits are important, the risks associated with federated identities are rarely assessed because using federated identities has become a normal practice. The real risk is that federated access management approaches have not kept pace with advancing cyber threats and increasing digitalization. When using federated identities, the identity provider is responsible for authentication and authorization, which limits the control organizations have over user access to internal resources and data. There are several capabilities that you would use if your identity store were local, but you often cannot use them when federating to other data sources, such as:
- Identity security events: any event that involves the compromise of or unauthorized access to a user’s identity information, including login credentials and personal information.
- Trust rating of the source: the level of confidence that you can place on the information provided by a given source.
- Source password rules: the policies and procedures that define the requirements for creating and managing passwords, such as complexity, change schedule, expiration, and so on.
- Stale accounts: user accounts that have not been accessed or used for an extended period, where the organization determines the timeframe for what constitutes a stale account.
- Source deprovisioning rules: policies and procedures defining the process for removing user access to systems, data, and other resources.
To some extent, organizations have chosen to secure non-federated identities locally using these capabilities, but when you assess whether your authentication tools treat federated identities as trusted users by default, the answer is almost always yes. Unfortunately, one of the many risks of allowing federated identities to be trusted by default is that you are allowing users with little security control to authenticate to your network, application, data store, or other IT asset. This means your organization may face risks to systems and applications, phishing attacks, and unauthorized access to sensitive data.
Best practices for federated identity management
Federated identities address many significant challenges, allowing users to authenticate to multiple identity providers with a single set of login credentials and access resources from anywhere and using a wide variety of devices. Reviewing access privileges regularly, implementing the principle of least privilege, and encrypting communication are all ways organizations can increase security for federated identities, but they may not be sufficient. In the future, federation must evolve to better address zero trust architectures and approaches, treating every authentication event as an untrusted security event, with pre- and post-authentication checks to continuously verify the security of any identity authenticating, particularly when receiving data from external sources.
About the author
Paul Trulove holds 15+ years of IAM experience in senior leadership roles, and as CEO of SecureAuth, he sets the vision and strategy. More recently, Trulove was CPO at SailPoint Technologies where he joined in 2007 as Head of Product, driving the product strategy, roadmap, and messaging for its market-leading identity management portfolio. He played a key role in taking SailPoint from an identity pioneer to its successful IPO.
Prior to SailPoint, Trulove gained extensive experience in formulating innovative product strategies, launching products in early-stage ventures, and growing products into category leaders at tech companies including Newgistics, Sabre, and Pervasive Software.
DISCLAIMER: Biometric Update’s Industry Insights are submitted content. The views expressed in this post are that of the author, and don’t necessarily reflect the views of Biometric Update.