Most enterprise level technologies face the issue of scalability at some point. Most vendors try to support more and more protocols and similarly, more and more features, without changing the way in which their tool is managed, creating a significant issue for businesses that wish to scale at speed. HP believes that management and modeling technologies are critical for technology to deliver for business.

As a result, HP introduces the “Federation Router”, available in HP Select Federation 7.0.

The thinking here is that as the adoption of federation technologies has grown, it has become increasingly evident that that required pair-wise business and technical agreements between federating entities does not scale. Each federation relationship requires a business/legal agreement, meta-data exchange, determination of protocol usage, user mapping, etc. While these issues are manageable “in the small”, this complexity grows exponentially as the variety of federation protocols and number of federation partners increases.

Just as a network router simplifies the relationships between network entities by directing traffic, ensuring message delivery, providing protocol translation, and allowing for special handling of requests, a federation router simplifies the relationships between federated identity entities. The federation router will enable identity to be a more pervasive aspect of the enterprise infrastructure – transforming the enterprise and blurring the lines between the enterprise and extended enterprise.

Adopting the HP federation router architecture will allow enterprises to be more ready for organizational change; to be better integrated with customers, partners and suppliers; and to easily scale these capabilities as there electronic business relationships grow. The primary issue of deploying multiple federation brokers even is that a change in business policy requires IT administrators to change policy in all deployed federation solutions. By pushing links through centrally managed routers, changes can be managed and deployed simply and effectively.

Simply put, a federation router acts as an SP to an IDP on one side and then turns around and acts as an IDP to an SP on the other side. The Liberty specifications proposed the use of such “identity proxies” first in its Liberty ID-FF 1.2 specification, and it is now a part of the SAML 2.0 specification. However, the HP federation routers architecture takes the idea of identity proxies further by fulfilling the following purposes:

• Acts as an intermediary between multiple organizations, some of which are on the “inside” and others on the “outside”.
• Abstracts the details of each side for the other. Hides backend infrastructure (various Federation protocols, agreements, multiple IDPs, etc.)
• Maintains trust relationship with identity components on the inside and outside. This reduces the overall number of trust relationships that need to be managed.
• Maintains policy about which users on one side have access to which applications on the other side
• Transforms user identity representation so that applications can get all information they need about a user in the format they expect.
• Performs protocol translation, ensuring that federating entities receive messages in the format they support
• Possible to make internal changes without requiring communication to or coordination with external partners

Let me know if you’d like to talk more. In a follow-up post I’ll give some examples of how this works in real world applications.