Problem solve Get help with specific problems with your technologies, process and projects.

Limiting the risk and liability of federated identities

You'll learn the legal issues involved in federated identity and how to best manage them.

What you will learn from this tip: The legal issues involved in federated identity and how to best manage them.

Identity federation allows autonomous organizations to share information about their users' identities. By establishing...

trust and using protocols like the Security Assertion Markup Language (SAML), companies can support simplified sign-on, share account information to ease account setup, and overall, provide a more seamless experience as users move from site to site in the federation.

As protocols and standards like SAML 2.0 have become richer and more widely supported, federation has moved from being an interesting technical experiment to a real business opportunity. However, while the technology garners significant attention, one of the biggest challenges of making federation work is establishing the legal framework that allows partnerships to operate effectively. The business and legal issues surrounding federated identity are as important as the technology used to implement it. Organizations need assurances that each of the partners in a federation will play by the rules. The question is, "What rules?"

Understand and limit risk

Before engaging in a federated partnership, an organization should understand the benefits and risks of extending trust to others. This may sound straightforward, but truly understanding the degree an organization needs to trust its partners is the primary way to limit risk. It may be possible to get all the benefits of a partnership while sharing -- and exposing – a minimal amount of data. For example, a service provider may not need to know a customer's identity to provide its service. By restricting the sharing of sensitive information, risk and liability is significantly limited.

It is critical that organizations scrutinize the identifying information they share with partners. Social Security numbers, names, addresses and account numbers may offer identity thieves opportunities to use information stolen from a partner to perpetrate fraud in unrelated services. Federations can help protect against loss by mapping identifiers like social security numbers to other, less transportable, federation-specific names. Limiting sharing and thereby preventing loss is a far more effective method than defining legal agreements.

Understand the laws

Organizations need to understand the laws that apply to their partners. For example, financial service providers need to comply with the Gramm-Leach-Bliley Act, which requires that consumers be queried and notified when their personal information is shared with outside parties. Furthermore, organizations sharing such information need to be able to prove that they exercise due care in protecting their customers' private data.

Once partners identify applicable laws, they need to establish rules that describe each organization's responsibility for protecting sensitive data, document when and how it is shared, and notify the partners and users in the event the security of the information is compromised.

Federated partners need to maintain logs and audit records detailing when users log in and modify accounts. These records, along with the results of security audits and evaluations, are critical when breaches occur. In general, most partners attempt to limit their liability for other organizations' losses. However, the agreement must establish ways to assign responsibility when losses are incurred as a result of negligence. That's where establishing security standards comes in.

Establish minimum standards for security

Federated partners need to establish minimum standards for the policies, mechanisms and practices they use to secure their environments and information. Many organizations are looking to standards like ISO17799 or COBIT as frameworks by which they can measure the effectiveness of their enterprise security. Others state technical requirements directly, specifying the need for firewalls, how sensitive information must be handled and encrypted, access controls and physical security requirements, and separation of partner functions from normal business.

These specifications establish a set of rules for which partners can be periodically checked for compliance. These checks can take on different forms. Some organizations opt for mutual inspection of each others' operations, while others contract independent third parties to conduct periodic inspections based on an agreed upon set of evaluation criteria. The healthiest approach is a combination of both methods. Mutual inspection encourages discussion of best practices and helps develop trust. Third party critique helps provide a measure of objectivity while helping to avoid creating an adversarial relationship between partners.

Regardless of what mechanism the federation chooses, it is important that partners have a way of understanding the security stance of each others' operations and can quickly determine if problems exist.

Any business partnership requires carefully drafted legal agreements, and identity federations are no different. Companies considering identity federation should put strict bounds on the level of trust they extend to partners by limiting the kinds of information they share with partners. Once those bounds are established, the partnership agreements should define the standards each member needs to comply with, the measurements to verify compliance, the reporting requirements for the partners and remedies for lack of compliance.

  • Learn how to leverage the power of SAML for "federated" relationships in this on-demand webcast.
  • Learn how to guard against XML-based attacks.

Richard Mackey, Principal, SystemExperts, is an authority on distributed computing infrastructure and security. He has advised leading Wall Street firms on overall security architecture, VPNs, enterprise-wide authentication, and intrusion detection and analysis. He has been a frequent speaker at major conferences and has led numerous tutorials on developing secure distributed applications.

This was last published in June 2005

Dig Deeper on Web authentication and access control