Enabling Virtual Federation With OpenSSO, Part 1: Introduction

Print-friendly Version

As described in a 2007 commentary, identity federation is an approach that authenticates users across multiple sites within a company (intranets) or independent and disparate domains (extranets) through open standards. To quote Wikipedia, "The ultimate goal of identity federation is to enable users of one domain to securely access data or systems of another domain seamlessly, and without the need for completely redundant user administration." At its core, identity federation encompasses authentication, authorization, and audit (AAA), user identity data (attributes), user provisioning, and identity Web services. Identity federation is playing an increasingly important role in the identity life cycle of enterprises, thanks to its strategic business value across organizations. This article, Part 1 of a two-part series, elaborates on the challenges businesses are facing with identity federation. Also introduced are the virtual-federation capability and its benefits in OpenSSO, along with an example of the process flow. Part 2 provides an overview of the end-to-end virtual federation process and shows how to configure OpenSSO for virtual federation and for secure attributes exchange. Contents   -  Challenges -  Virtual Federation: Rising to the Challenge -  Example -  Secure Attributes Exchange -  Coming Attraction -  References -  Discussion

OpenSSO is a Sun-sponsored, open-source project that offers core identity capabilities, including security for Web applications, single sign-on (SSO), federation, and identity services. Based on Sun Java System Access Manager, the project is the foundation for Sun OpenSSO Enterprise 8, the commercial release. In addition to working with enterprise-focused standards like SAML 2.0, XACML, and WS-Federation, OpenSSO works with community-based subproject protocols like OpenID and Information Cards.

Over the recent past, federation has been gaining significant ground in identity and access management. Why? Because now, more than ever, businesses desire to accomplish these five goals:

• Federate multiple applications with external partners.
• Better synchronize user data with external partners.
• Secure federation and preserve user privacy.
• Reap the benefits of interoperability in federation.
• Centralize the businesses' internal identity and federation infrastructure.

Many businesses have already embarked on identity-federation projects in pursuit of the preceding goals. Upon closer inspection when deploying their solutions, however, those who "know" often discover a number of technical challenges, which fall broadly into two categories:

• Securely federating legacy applications that do not support federation — Businesses that want to enable identity federation must federate their existing applications, such as Web portals, e-commerce sites, HR systems, and other services. Regardless of whether those are commercial off-the-shelf or in-house applications, they require some type of integration for federation—called first-mile or last-mile integration in service-oriented architecture (SOA) terms.
  
  Furthermore, the integration must be secure. Paramount to any company relaying user identity information to an external partner is the security and privacy of that data.
  
  Finally, other challenges abound, such as those that relate to the exchange, synchronization, or replication of user identity data from the applications to their remote partners.
  
  
• Managing federation standards to external partners — Mature organizations are keenly aware of the benefits of interoperability and like to adopt the following:
  
  
  • Open federation standards to avoid vendor lock-in
  • Standards-based integration techniques that can sustainably and repeatedly be applied across applications that are slated to be federated
  
  However, federating applications to partners through standards quickly becomes horrendous to manage. Of strategic concern to most companies is the desire to reuse centralized identity infrastructure. Quite simply, we need one central federation solution.

Sun OpenSSO Enterprise, tailored for identity federation and Web access management, tackles the issues with a new capability: virtual federation. That capability federates legacy applications by enabling them to securely "push" identity information (authentication, profile, and transactional attributes) to OpenSSO, which then transmits the data to external partners through standard federation protocols.

Additionally, you can manage federated applications to external partners with OpenSSO as the centralized federation component in your company's identity infrastructure.

Benefits
At a high level, virtual federation is a simple, secure mechanism for one application to transfer identity information to another in a different domain with the Security Assertion Markup Language (SAML) 2.0 protocol. Subsequently, you can easily federate applications or services with external partners through a single OpenSSO instance.

Virtual federation brings a secure passage of identity information along with authentication to OpenSSO, which then acts as a proxy for the data transfer to external partners through common standards. Currently, virtual federation only works with the following but will work with other federated protocols and profiles in the future:

• SAML 2.0 browser-based transient federation and federated SSO
  
  
• Browser-based HTTP GET and POST binding mechanisms of the SAML 2.0 protocol

Virtual federation offers the following key benefits:

• A loosely coupled, federated application can extend identity federation capabilities to that application instead of following the more traditional model of extracting data from a preconfigured local repository.
  
  
• Only one OpenSSO instance is necessary to federate multiple applications.
  
  
• At a lower level, OpenSSO instances can act as a SAML 2.0 standards-compliant "protocol gateway." That means you can authenticate users and securely transmit identity information through the SAML 2.0 infrastructure.
  
  
• Because virtual federation is a lightweight OpenSSO component that requires only a small client API, you can save many integration efforts aimed at federating legacy applications or services that are not natively federation-capable.

Before-and-After Scenarios at a Glance
The following table lists the challenges and related virtual-federation scenarios, before and after.

Challenge	Before Virtual Federation	After Virtual Federation
Securely federated legacy applications	Complex, tightly coupled integration with a traditional solution for federation	Simple, secure, loosely coupled architecture for federation and integration
Centralized management of federated applications and the federation infrastructure	Deployment of multiple federation solutions, one for each application to be federated	A single OpenSSO instance for managing federation
Synchronization of identity information—user attributes and profile and authorization data—across disjointed data repositories in different companies	Use of provisioning or synchronization tools for exchanging identity information across repositories	Exchange of additional identity information in a simple, secure, and standardized manner; in some cases, elimination of such data in an application
Standards-compliant interoperability	"Unique" solutions that only work with proprietary, inextensible technologies	Standards-compliant interactions among identity providers (IdPs) and service providers (SPs) through SAML 2.0

Consider this example for virtual federation, as illustrated in Figure 1.

Figure 1: An Example of Virtual Federation

A bank's Web application for customers authenticates users and acts as an IdP that federates with a check-processing company, an SP. An application from the SP posts images of the checks it has processed, ready for user access.

Behind the scenes is this process:

1. A transaction transmits authentication, identity, and transactional data to and from the IdP and SP with SAML 2.0.
   
   
2. When the user clicks the number of the desired check, the bank IdP's portal application (IdP for short) requests the check image from the check-processing SP application (SP for short).
   
   
3. To identify that user, the IdP pushes the related account number (user attribute) and check number (transaction attribute) to the SP.
   
   
4. The SP validates the user's authentication (single sign-on or SSO) credentials and receives the attribute payload, all from the same SAML assertion.

Before virtual federation came into play, transmitting the account and check information from the IdP to the SP was problematic. Enterprises typically resolved the issue by provisioning or synchronizing the user data across repositories in different companies. With virtual federation, the data exchange is simple, secure, and standardized.

Virtual federation includes a unique component called Secure Attributes Exchange (SAE), which allows for secure first-mile and last-mile integration with OpenSSO, as follows:

• Secure first-mile integration (IdP perspective) — SAE "injects" identity information from the federated application to the IdP's OpenSSO instance. The identity information is then transferred from the IdP to the SP in the attribute statement of a standard SAML 2.0 assertion. Such a technique makes for a simple, standards-compliant integration, yielding plain SAML 2.0 "across the wire" between the IdP and SP.
  
  
• Secure last-mile integration (SP perspective) — SAE delivers a secure mechanism for transferring data from the SP's OpenSSO instance to the SP's federated application. In either case, SAE ensures security by means of symmetric or asymmetric cryptographic encryption.

Figure 2 illustrates the process.

Figure 2: SAE Process

Stay tuned for Part 2, which describes how to configure OpenSSO's virtual-federation capability and SAE for identity federation.

• Sun OpenSSO Enterprise
  • Main page
  • Support: Sun OpenSSO Express
  • Project OpenSSO Resource Center
  
  
• Related articles
  • Enabling Virtual Federation With OpenSSO, Part 2: A Tutorial
  • The Basics of Identity Federation (PDF)
  • From the Trenches at Sun Identity, Part 4: Virtual Federation, a Pioneering Way for Exchanging Data
  • The Fundamentals of Identity Federation
  
  
• Sun developer services
  • Support
  • Training and certification

We welcome your participation in our community. Please keep your comments civil and on point. You can optionally provide your email address to be notified of replies—your information is not used for any other purpose. By submitting a comment, you agree to these Terms of Use.