From the Trenches at Sun Identity, Part 4: Virtual Federation, a Pioneering Way for Exchanging Authentication Data

— Rajeev Angal, architect, access and federation management, Sun Microsystems

Rajeev Angal, an architect for access and federation management at Sun, started a stint in security software in 1999. He joined Sun about a decade ago and has closely followed the evolvement of proprietary and standards-based authentication systems, also the standards themselves: Liberty Alliance, Security Assertion Markup Language (SAML), WS-Federation.

Recently, I sat down with Rajeev, who invented virtual federation as a key capability in the upcoming free and open-source Sun Federated Access Manager, a merged version of Sun Java System Access Manager and Sun Java System Federation Manager. Specifically, I asked him for a rundown of virtual federation: the definition, the problems solved, the process, and the benefits.

"The advent and ubiquity of the Web, coupled with the economic gains from outsourcing, mean that all enterprises must federate," Rajeev observes. "In the identity arena, federation refers to the exchanges of both static information among applications, such as user names and passwords, and information 'on the fly,' such as a user's selection of a check number in an online transaction," he continues. "Often, those exchanges occur among partners, customers, and outsource vendors—scenarios that require that certain data be kept confidential." The reality is that even though an enterprise does not own all the applications with which it desires to federate, it must execute them as part of the transaction.

It follows that a federation protocol in the form of standards, such as SAML (versions 1.1 and 2), ID-FF, WS-Federation, and OpenID, becomes extremely handy in enabling secure data exchanges among applications. Just applying and complying with standards is not enough, however. Rajeev points out six major issues that confront enterprises in federation architectures:

• Legacy applications. What to do about legacy applications that have already established, for example, ways of authenticating users for years and that are humming along without a glitch?
  
  
• Transient and transaction data. What data to pass on and what data to hide? You must push the contextual data in your application but pull traditional user attributes from, say, a user repository.
  
  
• Protocol. Which federation standard to adopt? And which version, given that the releases are sometimes not backward-compatible? Remember that you must also consider the standards that are in use by your affiliates. Ideally, all applications support all standards, but that's seldom the case. For seamlessness, it's best to ensure that your applications need not be aware of the standard that applies to the remote applications concerned.
  
  
• Scalability. What bandwidth to plan for in the case of numerous applications to federate with and to maintain? Just consider that 100 trust relationships would result from the interactions of 10 applications in Enterprise A with 10 applications in Enterprise B. What about growth in the future? How do you establish trust among all the pertinent applications, legacy or not, all of which must support the standards that work for you?
  
  
• Solution requirements. What solution would be nonproprietary and simple? It should sidestep XML parsing and cumbersome XML signatures.
  
  
• Vendor lock-in. How to avoid being tied to a product? Inevitably, enterprises desire flexibility for switches to other systems as circumstances dictate.

"First, a tip of the hat to Sun's senior product line manager Daniel Raskin for coining the term virtual federation to describe a capability that answers the preceding questions," Rajeev continues. Virtual federation is a simple, viable solution that "eliminates complexity, reduces costs, and enables accurate and seamless data-sharing in a circle of trust."

Process
How does virtual federation work? Here's a typical scenario: A bank's portal application, which authenticates users, acts as an identity provider (IdP) that federates with a check-image company, a service provider (SP) hosted by a partner. When an authenticated user clicks the number of a check, a transaction starts and calls for the transfer of data—the user's account number (user attribute) and the check number (transaction attribute)—from the IdP to the SP.

Figure 1 and Figure 2 illustrate how federation of legacy authentications is accomplished without and with virtual federation, respectively.

Figure 1: Federation of Legacy Authentications Without Virtual Federation

 

Figure 2: Federation of Legacy Authentications With Virtual Federation

 

Figure 3 showcases the simple process, with SAML version 2 as the single sign-on (SSO) standard for transmitting attributes.

Figure 3: Virtual Federation Through SAML 2.0

 

Benefits
To Rajeev, scalability tops the list of benefits bestowed by virtual federation. "Connecting all the mechanisms in a liaghtweight manner and then putting in place a single trust relationship among partners heads off the mess and burden of having to handle multiple relationships," explains Rajeev. "It's neat; it's trouble-free; it's efficient."

The means by which transient or transaction data is transferred in virtual federation? That's a straightforward HTTP query-POST parameter, an off-the-shelf technology, followed by data signing with either a symmetric key or an asymmetric mechanism, such as Public Key Infrastructure (PKI). No APIs are involved. "APIs often spell labor-intensive tweaking," Rajeev grins.

Four other items on the list of benefits are noteworthy:

• Intuitive setup and deployment. Once you have downloaded and installed Federated Access Manager, federation setup and deployment are only a few clicks and keystrokes away.
  
  
• No effect on setup from protocol updates. Federated Access Manager handles the appropriate federation process with no involvement of the applications in question. That means no reconfigurations are necessary in conjunction with protocol updates and changes of trust relationships among enterprises.
  
  
• Smooth interactions with all applications. Because the authentication process involves only a passage of the identity and user attributes to Federated Access Manager, data transfers work even with SPs that are legacy applications.
  
  
• Simple execution of interenterprise federation protocol. All you need is one trust relationship per enterprise pair.

In short, federation through Federated Access Manager just means presenting a virtualized view to the application. "And the technologies involved are well known yet well tested. This is truly a classic example of the effectiveness of simplicity," concludes Rajeev.

For more details on virtual federation, see its design document (PDF) and documentation. Note that virtual federation was previously called Secure Attribute Exchange.

• Sun Java System Access Manager
  • Main page
  • Developer home
  • Software Forum
  • Documentation
  
  
• Sun Java System Federation Manager
  
  
• Upcoming Sun Federated Access Manager
  • Overview
  • Architectural Overview
  • FAMTalk
  
  
• OpenSSO
  
  
• Sun developer services
  • Support
  • Training and certification