 | |
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
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 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 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 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 Sun Solutions 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:
Questions and Considerations
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. References
|
| |||||||||||||||||||||||||||||
| | |||||||||||||||||||||||||||||
| ||||||||||||
Print-friendly Version
