Federated Identity Through the Eyes of the Deployer

 
 
 
By Eve Maler, with contributions from Marina Sum, February 29, 2008  

As a deployer, you manage a software application accessed daily by thousands of employees or millions of consumers. For every one of them you manage an account record, check credentials, control access to sensitive data or functions, and personalize the application's interface and behavior. For every one of them you go to a lot of trouble and expense to get identity, privacy, and security correct, not just because of the potential upside in user satisfaction and enterprise efficiency, but also because of the potential downside in business-threatening breaches.

Would you be interested in outsourcing a part of your identity management infrastructure—the authentication that begins user login sessions and even some user attribute data—to an external source? Conversely, would you be interested in exposing an interface to your user accounts for use by the applications that depend on that authentication and data? That's what federated identity is about: distributing identity information and tasks across security domains so that the parties involved can focus on the jobs they do best.

Contents
 
-  Job One: Single Sign-On
-  The Challenge: Speaking the Same Identity Language
-  Deployment Issues
-  Questions and Considerations
-  References
 
Job One: Single Sign-On

Why deploy federated identity? To date, it's mostly been used for cross-domain single sign-on (SSO) to save user time and hassle and to eliminate costly password resets. With SSO, users can authenticate at one location and subsequently access protected resources at other locations. For example—

  • Enterprises that outsource functions, such as human resources and health insurance, turn to SSO.

  • Many governments adopt SSO for citizen portals and cross-agency application access by civil servants.

  • Academic institutions often manage access to research databases at partner universities with SSO.

In all cases, the same players apply, namely:

  • Users and the agents, such as browsers, through which they communicate online

  • Service providers (SPs) that offer Web applications and rely on an external source for crucial input into their authorization decisions

  • Identity providers (IdPs) that authenticate users and manage attributes of common interest

Figure 1 illustrates the interactions.

Figure 1: SSO Players
 

To protect the identity and application data being passed around, IdPs and SPs typically establish a circle of trust with technical and business agreements that define their respective responsibilities. Often, a circle of trust assumes a star-shaped topology with a single IdP and many SP spokes that trust the IdP but not necessarily each other. The IdP role is more complex because it must furnish the authentication infrastructure along with most of the security measures. SPs, looking to simplify by outsourcing to the IdP, expect to be offered toolkits that ease deployment.

Which role is right for you? Depending on the business realities, the choice might be obvious or beyond your control. Consider these examples:

  • A human resources company that offers employee profile management applications to enterprises is a natural SP to its customers, who in turn serve as IdPs. Each IdP would make available its employee directory in a limited fashion.

  • A university might function as follows:

    • As an IdP for its own students and faculty when they access research data at partner universities
    • As a research repository SP for the students and faculty at those partner sites

    This arrangement would constitute a truly circular relationship of trust.
The Challenge: Speaking the Same Identity Language

The choice of federated identity protocol determines the language in which the parties communicate—the forms and meaning of the messages. However, again depending on the business relationships, the choice might not be up to you.

SAML
The most comprehensive and widely deployed protocol is the Security Assertion Markup Language (SAML, pronounced " sam-ul"), currently at version 2.0. The SAML 2.0 design resulted from a merging of the SAML 1.1 capabilities, the SAML-based Shibboleth protocol that's in use in higher education, and the Liberty Alliance protocols known as the Identity Federation Framework (ID-FF).

You might have come across some of those older protocols, which are still in active deployment. They represent unique languages because their syntaxes are mutually incompatible.

WS-Federation
A somewhat similar protocol that was developed independently is WS-Federation. Its Microsoft genesis makes it most often chosen for IdPs and SPs that share a Microsoft-based identity and Web services platform.

Microsoft's InfoCard protocol, which governs its Windows CardSpace implementation, offers a phishing-resistant means of Web authentication and attribute sharing that meshes well with the concept of SSO. To adopt the CardSpace paradigm, you must ensure that a special agent, called an identity selector, is deployed on your users' client systems.

OpenID
The OpenID protocol focuses on simplicity and ease of SP deployment, particularly for Web 2.0 sites. OpenID presumes a total lack of trust. That is, anyone can create an OpenID identifier (a URI) and host an IdP. SPs that choose to accept OpenID logins do so without setting up trust relationships with IdPs in advance. Such a setup avoids burdening the process of rolling out an SP but limits your options in terms of partner trustworthiness and system security.

Sun Solutions
To help deployers who need multiple protocols or flexibility, Sun Java System Access Manager and its open-source twin OpenSSO have become polyglots. Not only do they work with SAML, ID-FF, and WS-Federation, but OpenSSO also offers an extension for OpenID. Support for the InfoCard protocol through an extension is in the works. This broad coverage addresses many protocol-related concerns in federation and Web access management.

Note that, in an upcoming 8.0 release, Sun Java System Access Manager will be merged with Sun Java System Federated Manager to become Sun Java System Federated Access Manager.

To help smooth interactions among protocols, Sun cofounded and participates in a community called Project Concordia. This project looks into interoperability issues raised by deployers and collaborates with them and vendors alike to develop best practices and to document time-tested solutions.

Deployment Issues

Only rarely can you set up an application with an ideal set of federated-identity relationships at launch. Often, for example, while creating a portal that aggregates existing applications, you add SSO to an application environment that already manages its own "local accounts" and must continue to do so. You must then link each local account at an SP to an account at the IdP for the same user so that the user's logins at the IdP result in SSO into the correct SP account.

You can link the accounts—a task sometimes confusingly called identity federation—in a batch operation. However, for consumer applications, you would often perform the task interactively with the user's help and real-time consent. For example, if you're a Flickr user, you might recall how that site prompted you to link your account to your Yahoo! account.

A changeover from local logins to SSO might disrupt users if they must authenticate with a different user ID on a different site, possibly through a different process (say, with smart cards instead of passwords). In Flickr's case, users were given a grace period during which both logins worked.

Another consideration is the kind of browsing experience you want to offer users. Here are two common deployment styles:

  • Portal style (IdP-initiated SSO) — From a system perspective, this is the simplest scenario, whereby the user starts browsing at the IdP and simply follows a link to the desired SP.

  • Bookmark style (SP-initiated SSO) — In this scenario, the user visits the SP first and, when the user attempts to access a protected page or function, is sent to the IdP to log in, resulting in more message exchanges between systems. In addition, the SP must determine where to send the user to log in—a notorious conundrum called the IdP discovery problem.

    Solutions to this problem involve compromise, so you must figure out what matters the most to you: user convenience, architectural flexibility, or cost containment.
Questions and Considerations

Before making your SSO architecture choices, consider these three important questions first:

  • Will your solution involve walk-up Internet users, members of a paid service, employees?

    The answer will affect your ability to control users' client systems and will suggest strategies for data protection, privacy, and collection of user consent.

  • Will the transactions carry significant monetary value or will you be exchanging relatively trivial data?

    The answer will determine your security strategy and part of your strategy for establishing trust.

  • Do you need to establish trust with online partners beforehand? If so, what trust topology would make sense?

    The answer will determine your technology choice, business agreements, and coordination practices with partners over time.

A flood of other practical considerations will follow:

  • Do you have to link existing local accounts with the IdP's accounts? If so, do you have to establish each link with user input in real time?

  • What happens if an account on one side is terminated?

  • What authentication method do you require? Does your protocol support communications about that method?

  • What and when should user attributes be shared and with what model of user consent?

  • Do you want to adopt single logout? That is, when a user logs out, should the logout ripple throughout all the user's sessions at that SP or even all of the user's sessions at all the SPs based on the original login at the IdP?

    What about session timeouts?

Don't feel overwhelmed. Check out OpenSSO (and, soon, Federated Access Manager 8.0), which takes a wizard-like approach and walks you through configuration screens for a faster and more intuitive route to rollout. Distributing identity jobs and information efficiently can help users, account holders, and application owners alike. OpenSSO can help you help them all.

References
Rate and Review
Tell us what you think of the content of this page.
Excellent   Good   Fair   Poor  
Comments: