• E-mail
• Print
• Comment
• Font Size
• Digg
• del.icio.us
• Discuss article

What Is Federated Identity Management?

Posted on: Tuesday, 23 August 2005, 15:00 CDT

It's not just for Web services, and it could save your organization a lot of directory and security management hassles.

Federated identity management (IdM) is a hot topic right now in the world of network security. Although it has many definitions and applications, at heart, federated IdM refers to a new standards- based approach to directory services that streamlines and secures user access to networked resources.

It enables single sign-on (SSO), whereby users login and authenticate once, rather than every time they access a new resource, and it replaces network-level access controls with role- based access control (RBAC) and other access management functions across diverse organizations, security domains and application platforms.

Compared to previous access, authentication and directory integration approaches, federated IdM is a better solution. Many enterprises balk at sharing directory information with other organizations, and network-based access controls are too coarse- grained for cross-domain security.

Although federated IdM requires additional network security infrastructure components-notably the identity provider (IdP) and service provider (SP) functional components discussed below-each organization stores, manages and controls its own identity information, including user IDs, passwords and account profiles. Federation also allows organizations to reduce or eliminate the administrative burden of having to register external users in local directories.

When two or more autonomous organizations (or domains, in IdM- speak) decide to federate, they retain control of their respective identities and resources, but first they must establish trust relationships with one another. Trust relationships entail agreements on interoperability protocols, and on policies governing how the organizations will authenticate and authorize one another's users to access one another's resources.

For example, when a user in domain A wants access to the resources of trusted domain B, the two domains exchange information in which domain A vouches for the user's authenticity, role and access request. Domain B validates the information from trusted domain A, and does a database lookup to make sure a user with that identity, role and/or attributes is authorized to access the resource he or she requested. Then domain B either grants or denies the requested access, redirecting the user's browser to the requested resource (if granted) or to a "sorry Charlie" webpage (if denied).

A Net Manager's View Of Federated IdM

Federation isn't a bleeding-edge approach. Over the past few years, it has become the dominant approach in new IdM deployments, especially since industry ratification of the security Assertion Markup Language (SAML) standard in late 2002. Vendors including BMC, Computer Associates (which recently acquired Netegrity), Entrust, Entegrity, HP, IBM, Microsoft, Novell, Oracle (which recently acquired Oblix), RSA security and Sun have made standards-based federation the core of their IdM, trust and security infrastructure strategies.

Although Federated IdM is usually associated with the new world of Web services, it can be implemented in any network environment where users require access to resources that are controlled by external, autonomous, trusted domains. Federation-like concepts are already at work, and have been for years, in familiar telecommunications environments like automated teller machine (ATM) networks and cell phone networks. Mobile operators and Wi-Fi hotspot operators might also be able to use federation to enable hand-offs across their networks (see "Money Machines And Cellular Roaming").

From a network manager's point of view, federated IdM implies additional, linked authentications that take place at Layer 7 after users have authenticated themselves at Layers 1-3 during a network access attempt. Traditionally, network authentication has been handled in a centralized, non-federated configuration. Network access servers challenge users for their IDs and passwords, and only grant access if these credentials have been verified in an authoritative directory maintained by the carrier or enterprise that hosts the requested resources.

The same centralized approach also applies to traditional application-layer authentication methods. In network access environments, the typical protocol between the access server and the authenticating directory is RADIUS, whereas for application and operating system security the equivalent protocol is Lightweight Directory Access Protocol (LDAP).

Many organizations have consolidated their identity, access and account management into centralized LDAP directories, thereby streamlining IdM and reducing IdM lifecycle costs. In these organizations, much of the information an application needs in order to make authorization decisions now resides in these centrally managed directories. Other organizations still operate with multiple directories, each associated with one or more distinct applications and/or databases.

The persistence of multiple directories-hence multiple internal domains where users are registered and apps are controlled-creates the possibility that the organization might benefit internally from single sign-on, role-based access control and other aspects of federated IdM. However, there's a point beyond which enterprises, carriers and other organizations can't or won't centralize or federate their directories any further. Decentralization will persist as long as organizations need to maintain separate identity repositories to support various application domains, operating platforms, business functions and organizations.

In such cases, it may be impossible or very difficult-from a business, security, or technical standpoint-for diverse domains to synchronize their directories or pass RADIUS or LDAP calls across their respective firewalls. These enterprises must either live with the multiple authentications and passwords that characterize most corporate IT environments, or find a mutually acceptable approach under which users can authenticate in their home domains and then leverage those logins to access applications, databases or other resources in domains controlled by trusted trading partners. That's the core meaning of federation.

Why Federated IdM Makes Sense For B2B Apps

The value proposition of general-purpose, federated IdM environments is undeniable. Enterprises' ROI from federated IdM is in three principal areas: tightening security, reducing costs and improving user quality of experience (see "Internal Benefits Of Federated IdM").

Federation isn't the only approach for enabling diverse IdM domains to interoperate, but it is well-suited to the security requirements of today's decentralized B2B environments. Traditional IdM interoperability approaches-such as meta-directories, delegated directory administration and directory lookups-usually require that domains reveal or transfer some or all of their directory information to external domains. Many businesses understandably balk at allowing external domain administrators any degree of access and visibility into their identity information. With that access and visibility comes a loss of control over the data and an increased risk of fraud, security breaches, privacy issues and legal liabilities for the owner of the identity data.

Another disadvantage of traditional IdM interoperability approaches is that they require tighter protocol and schema integration between domains. They usually require that additional firewall ports be opened for cross-domain directory synchronization and administration.

Due to these limitations and risks, traditional IdM interoperability approaches have been implemented primarily inside enterprises, rather than in B2B environments. In addition, the complex data sharing scenarios of traditional approaches limit their scalability. Meta-directories just can't scale to support millions of identities and hundreds or thousands of partner relationships. The federated IdM architecture, by contrast, is designed to scale across increasingly complex enterprise and B2B environments.

Federated IdM Architecture

Networking professionals need to understand the mechanics of federated IdM, for two principal reasons. First, a growing volume of application-layer authentication, authorization, SSO and other security traffic relies on federated IdM protocols such as SAML 2.0 and Liberty Alliance Identity Federation Framework (ID-FF) 1.2. These are Web services protocols, and they have the traffic management, performance and capacity implications discussed in the BCR April 2003 article, "Web Services Work, But Will They Scale?;" BCR December 2004 article, "Wresting XML Down to Size: Reducing the Burden on Networks and Servers;" and BCR April 2005 article, "Enriched Browsers: Making Portals and Web Services More Bandwidth- Friendly."

FIGURE 1 Federated IdM Environment

Second, network managers are taking on more application-layer authentication infrastructure associated with the portals they provide for customers, partners and employees. In fact, the portal- coupled with Web access management proxy gateways such as Netegrity SiteMinder and IBM Tivoli Access Manager-is the principal access poin\t into many federated IdM environments.

Although much of this brave new world of federated IdM relies on the growing range of Web services standards and specifications, the architectural model revolves around two principal functional components that are deployed in federated domains:

* Identity provider (IdP): These functional components are typically configured into authentication portals and used to create, register, manage and authenticate the identities, credentials, roles, permissions and other network identity attributes associated with users. The typical IdP provides a capability for users to log in to the federated application environment and will usually also have an associated portal presentation interface, authentication service and user directory.

After validating user credentials against a trusted authentication service, the IdP transmits authentication and attribute assertion messages to the service providers (discussed next), which control access to the resources that users are requesting. The authentication and attribute assertion messages vouch for user logins and for various user attributes (such as roles and groups) that are also managed by that IdP. The user's credentials-such as passwords or public-key certificates-never flow outside the IdP's domain.

* Service provider (SP): These functional components provide the content, applications and other resources requested by the users. Typically, an SP is another portal or application platform (managed separately from the IdP). SPs usually have their own presentation interface, authorization service, and policy rulebase. The SP relies on the IdP's authentication and attribute assertion (i.e., voucher) messages, in addition to its own policy/rules database lookups when authorizing users to access a requested resource.

Figure 1, p. 59 illustrates a basic federated IdM environment, showing the main assertion messages or data structures interchanged between the IdP and SP. This diagram illustrates the components necessary for federated SSO and RBAC, but doesn't show the additional components that would be necessary for more complex interactions, such as federated account provisioning across domains. (Wireless carriers might use federated account provisioning to provide users with access to external content sites owned by the carriers' content partners. In such cases, user accounts would need to be provisioned-in other words, registered and, when necessary, de- registered-automatically across the carrier and all partners' sites.)

The figure also shows that federated IdM is an abstraction and, as such, it is largely agnostic to the underlying "plumbing" of the federated IdM environment, in terms of such enabling protocols as SAML, Liberty Alliance Identity Federation Framework (ID-FF), and WS- Federation, as well as the supporting network infrastructure.

If a federated IdM environment is essentially an abstraction layer over the legacy identity and security environments of diverse domains, and each domain retains their internal directory, metadirectory, account provisioning and PKI services, then what kind information do the trusted domains exchange? Each domain maps its local identities and attributes to agreed-upon schemas and syntaxes, either locally or at an intermediary identity mapping/ transformation/brokering node. Then they interface using common federated IdM protocols-such as SAML, Liberty ID-FF, or WS- Federation.

Essentially, SAML, Liberty Alliance ID-FF, and WS-Federation describe different approaches for structuring the message exchanges among federated IdPs and SPs. The payloads of these federated IdM protocols are the assertions and other data elements necessary to communicate authentication, authorization and other security context information between domains.

Questions For lmplementers

Federated IdM deployments differ widely in topology, as do their traffic patterns and network resource-utilization profiles. When exploring the network impacts of federated IdM, it's best to start with several high-level architectural factors:

* How many domains are being federated? Are they within a single intranet, or dispersed across an extranet, a managed supply-chain or the public Internet?

* How many of the domains are deploying IdPs, how many are deploying SPs, and how many are deploying both functional components?

* How many federated IdM application services-such as SSO, RBAC and account provisioning-are being implemented?

* What federated IdM protocols are being implemented? Which implementation profiles of those protocols are being used?

* What range of authentication, attribute, and other statements are encapsulated within assertions? Are the assertions digitally signed and/or encrypted for transmission over the network?

* Are the federated IdM protocol interactions being accelerated through co-processor or proxy appliances implemented in various domains at various IdPs and SPs?

The answers to these questions will help you begin to understand the impact of the IdM deployment on your network infrastructure. Needless to say, it will be a good idea to at least keep in contact with or, better yet, participate as a member of the IdM implementation team.

Conclusion

One critical gating factor on federated IdM adoption is the implementation of Web services standards such as Extensible Markup Language (XML) and Simple Object Access Protocol (SOAP). SAML, Liberty ID-FF, and WS-Federation all use XML syntax and SOAP enveloping. Without ubiquitous deployment of Web services, these federated IdM protocols can't achieve universal adoption.

The conditions for truly universal, mature IdM federation haven't yet emerged. Some federated IdM standards-such as SAML 1.1 and Liberty Alliance ID-FF 1.1-are being implemented widely. But others- such as SAML 2.0 and WSFederation 1.0-have not yet been adopted broadly within commercial solutions or real-world enterprise or service provider deployments.

Another sticky issue is the lack of widespread deployment of public key infrastructure (PKI) for cross-domain B2B trust management. Federated IdM doesn't require PKI, but it is recommended by SAML, Liberty ID-FF and WS-Federation for several reasons. First, PKJ is the basis for SSL, which is the principal protocol for securing Web sessions over which federated IdM assertions and data are exchanged. second, PKI is the basis for the XML Encryption and XML Signature standards, which are needed (and recommended in the federated IdM standards) for encrypting and digitally signing individual federated IdM assertions, thereby enabling further confidentiality, non-repudiation, integrity and so forth for federated IdM.

Unfortunately, it's often quite difficult for organizations to set up and administer all the requisite trust relationships among their various PKIs, especially in heterogeneous, multinational, business-to-business environments.

In the final analysis, trust is the basis for federated IdM. Federated IdM infrastructures can't create trust. They can only leverage pre-existing trust relationships into productive e- business interactions. For enterprise IT professionals, the roadmap to federated IdM requires close coordination of various business, technical and policy issues with established trading partners.

Trust depends on solid business relationships, not on technical protocol plumbing

Companies Mentioned In This Article

BMC (www.bmc.com)

Computer Associates (www.ca.com)

Entrust (www.entrust.com)

Entegrity (www.entegrity.com)

Hewlett-Packard (www.hp.com)

IBM (www.ibm.com)

Microsoft (www.microsoft.com)

Novell (www.novell.com)

Oracle (www.oracle.com)

RSA security (www.rsasecurity.com)

Sun (www.sun.com)

Success with federated IdM requires close coordination of business, policy and technical issues

This standards-based approach is better than directory sharing or synchronizing

Most businesses fear fraud and security risks if they give others access to their directories

Federated IdM is agnostic to the underlying network, but it can have traffic impacts

James Kobielus is a senior technical systems analyst at Exostar LLC, a business-to-business trading exchange based in Herndon, VA. He can be reached at (703) 924-6225 or james_kobielus@ hotmail.com. Tune into his blog at http://jkobielus.blogspot.com. The opinions expressed are his own.

Copyright Business Communications Review Aug 2005

Source: Business Communications Review

More News in this Category