|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 infrastructurethe authentication that begins user login sessions and even some user attribute datato 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|
|-||Questions and Considerations|
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
In all cases, the same players apply, namely:
Figure 1 illustrates the interactions.
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:
The choice of federated identity protocol determines the language in which the parties communicatethe forms and meaning of the messages. However, again depending on the business relationships, the choice might not be up to you.
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.
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.
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.
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.
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 accountsa task sometimes confusingly called identity federationin 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:
Before making your SSO architecture choices, consider these three important questions first:
A flood of other practical considerations will follow:
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.