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.
It doesn't come easy when you federate identity management.
|in a Federated World|
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.)
This was first published in April 2005