How to Deploy Identity Federation
Deploying identity federation, like many technologies, requires a thorough analysis of business issues, as well as technical ones. However, unlike many other solutions, identity federation involves not only one's own enterprise, but also outside partners with whom one wishes to create a close and unique linkage in order to achieve synergistic benefit. This article will discuss some common and not-so-common considerations one needs to address in order to succeed.
Mutually Beneficial Objectives
First, an enterprise must consider clear business objectives for undertaking a federation project. This may seem like an obvious statement, but one needs to understand that these objectives must be both internally and externally oriented. If the objective is purely self-serving, then what appeal would this have to one's business partner with whom one is attempting to federate? While the objectives might be initially driven by internal goals, there must be an advantage for the partner as well. Otherwise, what would be the point of a company spending money in order to improve another organization's operations?
For instance, an internal goal might be to avoid the risk of managing nonemployee Personally Identifiable Information (PII). Whereas the benefit to the external partner firm would be increased privacy protection of PII for its employee data that is more securely shared using strong, market-proven federation protocols.
Another internal goal might be to drive down the costs of supply chain management through more efficient control and management of outside suppliers. For the external partner, the objective might be to establish a closer-and consequently, more profitable-preferred provider relationship. Therefore, one must first define a clear set of benefits for all parties that participate in the federation circle of trust.
Clearly Defined Responsibilities
Second, organizations must establish the contractual arrangement among the participating parties that will define clear responsibilities for all. The Liberty Alliance has published a document entitled "Liberty Alliance Contractual Framework Outline for Circles of Trust." This document describes three basic federation contract models: collaborative, consortium and centralized. It also details the roles and considerations that must be worked out for federation founders, membership, administration, jurisdiction, as well as several other important elements. Anyone thinking of establishing an identity federation arrangement, or participating in an already established federation, should be familiar with these models. They should also ensure that their own interests and business benefits are sufficiently addressed.
PII Protection Guarantee
Another significant consideration regarding identity federation is protection of PII. The Liberty Alliance has also published an educational document entitled "Deployment Guidelines for Policy Decision Makers." This paper poses questions and challenges for this very important and highly sensitive area that each participant in an Identity Federation must be able to responsibly address.
Among the areas for proper collection and management of PII are: business objectives, data protection, notice, consent, security, data access and complaint resolution. Again, those who are responsible for management of PII-whether or not they are actively participating in an identity federation-should be familiar with these considerations and should ensure that they have proper policies in place to manage PII. Moreover, they must ensure that these policies are thoroughly audited on a regular basis.
After these business issues are addressed, one should then ensure that the technology being deployed is open and standards-compliant. The predominant standard for identity federation is SAML 2.0. This protocol was developed through the input and extensive real-world experience of hundreds of deployers and dozens of vendors.
Whenever one partners with another firm, one can be assured that the partner will not have identical technology infrastructure deployed. Therefore, it is essential that one chooses a standard that has unquestioned market acceptance, such as SAML 2.0, in order to provide the easiest mechanism to bridge the disparate IT environments. In addition, one should ensure that the technology provider has proven its interoperability through rigorous testing. For five years, the Liberty Alliance has successfully managed such a program. This program has been recognized as the market authority on SAML conformance and virtually every vendor in the identity federation space has submitted its product for testing. By choosing one of these vendors, enterprises can significantly minimize the difficulties of federation deployments so as to focus on the business benefits.
The Bottom Line
In summary, identity federation is well established as both a technology and business process that can bring significant value to an organization. By focusing on the issues described in this article, doing one's homework and understanding benefits from a partner's point of view, one can more quickly achieve these valuable objectives.
Roger Sullivan is Vice President of Business Development within Oracle Corporation's Identity Management Development Group. Roger Sullivan is also President of the Liberty Alliance, a global alliance of vendors, enterprises and governmental organizations developing technology standards and deployment guidelines for identity federation. For the past several years, he has served in leadership roles within the Liberty Alliance. His blog can be found at http://blogs.oracle.com/rogersullivan/2008/02/21#a28.