Information Security

Defending the digital infrastructure


Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Trust Us

It doesn't come easy when you federate identity management.

It doesn't come easy when you federate identity management.

Living in a Federated World
Federation isn't an all-or-nothing decision. It's quite common for businesses to offer limited services through a federated channel while offering full service through a directly authenticated connection.

It's a classic separation-of-duties scheme. We need only look at organizations and their relationships with companies that sponsor retirement plans.

A retirement plan's sponsor establishes a federation with the organization that allows employees to authenticate once to their company's network to gain access to their retirement accounts at the financial organization without the nuisance of signing in each time. Typically, the financial institution only allows the participants access to account information associated with their plans--even if they have other relationships with the institution. By limiting users' authorization based on how they are authenticated, the financial institution limits the risk that a compromise in the plan sponsor's environment would expose account information that isn't owned by the plan sponsor.

The main driver for authentication federation is simplifying the user experience. The question is whether the relationship between the institution, the customer (plan participant) and the company (plan sponsor) justify the institution extending trust to the sponsor company. In this case, the trust is warranted. The funds in the retirement plan are typically owned by the financial manager, who, consequently, has access to participants' plan information.

It seems appropriate that the institution would allow the company to authenticate and control employees' access to the account. However, employees may have other accounts bearing no relationship to the employer's retirement plan; these accounts wouldn't be accessible through federation. This approach helps protect the privacy of the employees' account data and helps to reduce the risk that the financial institution would be responsible for compromises occurring at the plan sponsor.

Compartmentalization is a necessary ingredient of any federated relationship. The partners benefit from the separation of information and control because it limits the risk of environmental compromise if a partner happens to fall victim to an attack. Users benefit from the separation because they can decide how much they're willing to trust each member of the federation. These levels of control provide an overall environment that's more palatable to all parties.

-Richard Mackey Jr.

Federation promises seamless access to users across domains, and helps organizations realize the potential of online business without the burdens of setting up and administering unwieldy one-off relationships with partners, suppliers and customers.

Every organization faces the challenge of managing user accounts that exist in different departments and outside service providers. These accounts are often owned by different entities, but need to be integrated to allow seamless use and consistent management. For purely internal applications and services, it's possible to merge the domains, manage a single set of identities, streamline the user experience and minimize the management--but even that's difficult.

Federation addresses the challenge of offering single sign-on and identity management for multiple domains. With XML-based standards, enterprises can map the identities of their users and customers to identities stored on directories belonging to federated departments and partners. Users can transparently pass from one domain to another without entering multiple credentials.

Standards such as SAML, The Liberty Alliance's ID-Web Services Framework (ID-WSF) and WS-Security provide the technical mechanisms for passing credentials between domains. But true federation is contingent upon the establishment of out-of-band trusted relationships. When federating, organizations need to decide how much information about their users and customers they wants to share with partners, how users will be involved in deciding what is shared, what risks are being taken by sharing customer data, and what legal agreements need to be in place for when things go wrong.

The challenge for enterprises building federated, cross-domain networks is managing these trusted relationships, and ensuring that they and their partners are living up to the security requirements that make federation work.

Federation is based on the concept that domains are autonomous entities that have their own identity and privilege systems. Federation doesn't subsume the need for creating, provisioning and maintaining user accounts; it's more of a cross-domain simplified sign-on mechanism.

In a typical federated scheme, one enterprise agrees to trust another enterprise's users' access assertions and to grant access to applications and other resources. Credentials are stored at both enterprises; the user only must assert his credentials once and only needs a single set of credentials to access one or multiple domains. In many cases, the user experience is akin to single sign-on.

An example of federation is an airline and rental car partnership. A frequent flier earns points for special rewards programs, and, since the airline partners with a car rental company, a federated relationship enables the airline to assert the user's identity to the car rental company to authenticate the user for reservations and discounts. Federation allows the customer to log in once and move seamlessly between domains, having a more integrated and simplified experience.

Sounds wonderful, but the process can be fraught with risk. If an organization places no limits on the users from other domains, and even one of the partners is compromised, it affects the entire federated group.

Federated partners can use three methods to protect themselves: place specific limits on what federated users can do, implement technical and procedural checks and balances to monitor the security of partners' domains, and establish legal agreements that make partners liable for damages resulting from a compromise.

Establishing boundaries and controls for federated relationships will guard your enterprise against being affected by problems in other domains. The basic rule of thumb should be to provide only access to resources that are commensurate with the value of the relationship. For example, if an organization federates with a customer's domain, it's reasonable to only provide access to resources owned by the customer. (See "Living in a Federated World," opposite.)

Making Federation Work
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

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.

Article 7 of 16

Dig Deeper on Web application and API security best practices

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

Get More Information Security

Access to all of our back issues View All