In my previous post on Federation, I noted that HP releases game changing "Federation Router" in Select Federation 7.0.

Federated identity technology is rapidly growing in adoption. New management challenges that never existed before are resulting out of its early success. Federation depends upon trust relationships (business policy) between independent entities; Trust between an Identity Provider (IDP) and Service Provider (SP); Trust between Web Service Provider and Web Service Consumer.

Common use cases of federation deployments today include allowing employees to seamlessly access their benefits information which is provided by independent benefits provider enterprises, or allowing consumers of to seamlessly access different services provided by independent divisions of the same enterprise.

Adoption of Federation technology and the evolution of federation standards have introduced a need to deal with issues that are not necessarily new to an organization, but are in a different context. These issues are not apparent in small deployments, when the number of federation partners is fairly limited or very uniform. Complexity of the deployment grows exponentially as the number federation partners increases and/or the number of federation protocols supported increases.

It’s a classic problem of scale that needs to be management up front, and over time.

Diagram 1 demonstrates the sets of relationships that might be required between federating entities from an enterprise (Employer) and outsourced employee service provider (Benefits Provider). In this example a large engineering enterprise has an aeronautical division, medical systems division and a financial services division. The enterprise as a whole has contracted with a benefits provider for health and dental benefits. However, since each of the divisions in the enterprise is independent, each has its own identity management processes. Further, the Benefits Provider is actually a merger between two benefits providers, one which provides medical benefits and the other providing dental benefits. As a result, the systems within the benefits provider are also independent. The enterprise has now mandated that all employees must receive seamless access to their benefits information. This means that each division would have to explicitly trust each service of the benefits provider so that employees from each division get seamless access to their personal medical and dental benefits information.

For each of the federation relationships depicted in the diagram 1, business and technical policy must be defined to address trust, protocol usage, attribute mapping, and security. Since trust agreements are based upon business and regulatory policies, they are typically legal documents requiring costly legal review. Thus, having a large number of legal agreements is less than desirable to simplify and reduce costs of governance and management of contracts. Furthermore, non-technology processes will lengthen the duration of federation IT projects adding further delay and uncertainty to the process. These issues become a hurdle for rapid adoption of federated identity management.

As new IDP’s and SP’s relationships are added to the federated environment, there will undoubtedly be new federation protocol requirements.

Diagram 2 depicts the complexity that can arise related to federation protocols and the need to match the capabilities of your partner. Either an IdP will need to add support for an additional federation protocol when interacting with the new partner (e.g. Aerospace division uses WS-Fed when interacting with the Travel Service Provider), or the SP will need to add support for a protocol that the IDP(s) already supports. Either way, this can become a hindrance to doing business, not to mention complicates configuration and support of the environment for any particular federating entity.

Simplifying Federation Management and Accelerating Deployments

In today’s TCP/IP networking environment, much of the work to get a message from one computer to another is done by routers, because they're the crucial devices that let messages transit between networking domains. These routers play the critical role of directing traffic, ensuring message delivery, providing protocol translation, and allowing for special handling of requests.

With HP Select Federation, HP is applying the same principles behind network routers to the processing of identity federation. HP Select Federation 7.0 has introduced a new capability that allows for its deployment as a federation router. A federation router simplifies the relationships between federated entities.

Diagram 3 depicts a view of how the federation relationships between federating entities from an enterprise (Employer) and outsourced employee service provider (Benefits Provider) have now been condensed, as compared to the pair-wise deployment without a router shown earlier.

With the federation router, not only are there less trust relationships, but the management of the relationships, including the information conveyed about users, authentication policies, etc. can move away from the individual divisions to being managed at the enterprise level.

NEXT…

This entry describes the basics of the Federation Router, and as with all things the real test is in the deployment and management. Fundamentally this model allows for some very interesting and time-saving deployments at scale. So, as I noted in my introduction, I will begin to detail deployment options for the Federation Router in upcoming posts that show clear benefits in terms of management and scale for any size deployment.