This article can also be found in the Premium Editorial Download "Information Security magazine: Keeping on top of risk management and data integrity essentials."

Download it now to read this article plus other related content.

Making Federation Work

    Requires Free Membership to View

The most popular way to enable federation is with Security Assertion Markup Language (SAML), which provides a way for enterprises to assert the identity of their users to another trusted domain.

The standard defines the XML schema for assertions that carry the identity, privileges and other attributes of a subject. SAML also provides mechanisms for the authenticating party to sign the assertions.

In addition to creating and parsing the assertions, the federation has to define how the authenticating party will map into a particular domain. For example, a bank would authenticate an accountholder and create an assertion of the person's identity for a partnered retailer site. The bank might also assert that the person is a preferred-service member--such as gold club who have earned discounts with partners--through additional attributes. The retail site would be responsible for interpreting these assertions and deciding how they affect the privileges of the account-holder in its domain.

One of the bright spots of federation is that the protocol standards are rapidly converging.

SAML 2.0, approved in March, is the culmination of work to combine the features of SAML 1.1, the Liberty Alliance's Identity Web Services Framework (ID-WSF) and Shibboleth (a Carnegie Mellon University project). SAML supports features like single sign-on, single logout, and anonymous and pseudonym identities, and is designed to support both B2B and B2C interactions.

Another standard gaining momentum is Web Services Federation. This approach, which is closely tied to Web Services protocols (WS-Security), is likely to gain broad support because it's backed by Microsoft and IBM.

-Richard Mackey Jr.

For more about SAML, see "Key to the World," at www.infosecuritymag.com/saml.

Establishing and Maintaining Trust
Federation requires that an organization trusts another organization to authenticate its users and ensure that those users have rights to access data and resources. The more sensitive or valuable the applications or data, the more difficult it is to extend trust.

Enterprises shouldn't just open access through federation without first conducting a thorough risk assessment, looking into both the security protections of all parties involved and the value of the information and data being accessed.

Access control and authentication mechanisms must also be mutually acceptable. Enterprises with high-value assets should require their users to employ multifactor authentication, such as tokens and passwords, and won't want to access assertions from enterprises using a simple user name/password. The access granted to federated users should be commensurate with the level of trust associated with their authentication mechanisms and points of origin. For example, you could grant limited access to noncritical resources using only a password, but require multifactor authentication for restricted, sensitive applications.

The federated agreement should specify change control requirements. Employees constantly join and depart organizations; you must provide mechanisms that ensure former employees are removed from a host enterprise's identity directory, thus preventing illicit access to all linked federated accounts. Likewise, federating enterprises should conduct periodic audits of their identity stores to look for inactive accounts.

The security and integrity of the federation is largely dependent on the assertion keys. Consequently, federation partners need to agree on the processes for acquiring and managing digital certificates, and the group needs to agree on the certification authorities, key storage standards and revocation mechanisms.

To cover what is an acceptable level of security, many enterprises are requiring federated partners to adhere to third-party security audits and assessments based on ISO 17799 or COBIT. Whether the relationship is based on one of these standards or a homegrown requirement, the federation agreement should provide for periodic auditing of one another's security procedures and posture, and include requirements for reporting procedural lapses and security incidents.

All federations require legal agreements that establish the partners' responsibilities in authenticating parties, maintaining the security and integrity of their infrastructures and paying damages when a party doesn't fulfill its requirements. Federation partners need to establish the technical mechanisms to judge whether a party is complying with the practices laid out in the agreement. For example, organizations must be able to prove that authentication practices are followed, audit records are accurate, encryption keys are protected and the security infrastructure is maintained according to agreed upon standards.

Monitoring federated transactions will help ensure that service-level and trust agreements are being met by all federated parties. The best arrangement is when federated partners decide to establish a degree of transparency in their security operations. In addition, the partners should share audit records regarding events like logins, cross-site authentication assertions and privilege changes that affect each other. The participants can help each other ensure that the federation mechanisms are working correctly by comparing audit records.

Finally, federating enterprises must establish procedures for reconciling disagreements over policy implementation, access restrictions and denials, service outages, and incident response and procedural gaffs. No system is perfect, and incidents will happen. Establishing strict rules for notification of partners in the event of a suspected compromise, and documentation of incidents, the organizations' response, the suspected cause and the remedy should help preserve the federated relationship in the face of mishaps.

Before committing to a federation, organizations should understand and control the risks by limiting the services offered to a reasonable set. Also, they should establish the necessary legal protections in the partnership and recognize the effort it will take to maintain a long-term federated relationship.

This was first published in April 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: