[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE] [IMAGE] Living in a Federated World [IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
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...

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.

[IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE]
[IMAGE]

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

< PREV PAGE   |   1  |   2  |   NEXT PAGE  >