Limiting the risk and liability of federated identities

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

    Requires Free Membership to View

(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.


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 first published in June 2005

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.