While examining the key characteristics and deployment scenarios of federation, we (Ping) discovered that federations typically occur in one of three profiles. Furthermore, we discovered that certain types of companies were more likely to engage in one type of federation than another (at least early on), and that Phase I of federation adoption, where companies engaged either as a consumer or an issuer, but not likely both at the same time, would likely give way to what is referred to as “Cross Domain” federation, whereby companies engaged in both consuming and issuing identity assertions simultaneously.
(C) Copyright 2003, Ping Identity Corporation | October 24, 2003
Profile 1: Service Provider Hub
Extending an enterprises reach and available resources to include outsourced and managed applications is a key directive to many extended enterprise initiatives. In each case however, the enterprise would like to enable seamless employee access to these managed applications — as if they were running on the company’s internal network. Said differently, once an employee is logged into the enterprise network, they should be able to access an outsourced service without performing an additional login or needing to maintain an additional account with the managed application provider. Less identity federation, employees are forced to maintain multiple ‘identities’ for each outsourced application. Possibly even more important, redundant and disconnected identities represent an enterprise security risk, as revoking an identity from accessing the managed application can no longer be performed within the enterprise’s existing authorization and policy infrastructure, but instead must be managed as a one-off process.
In a Service Provider Hub, one entity provides an outsourced service or web application (e.g. salesforce.com, travel.com, my SAP etc.) to enterprises that can be viewed as consumers of the outsourced application, service or web process. As the service is operated outside of the enterprises domain of control, yet the enterprise wishes to manage access to the application as if it was within the enterprises domain of control, a mechanism of extending the enterprises existing directory and security policy infrastructure is required.
In this model, the service provider can be seen as sitting in the middle of a number of surrounding enterprises. In order to enable more seamless and integrated access to its enterprise end-users, both the service provider and the enterprises surrounding it desire a mechanism of enabling more seamless access to the managed application via federated single sign-on.
In the Service Provider Hub federation profile, the service provider becomes a relying party to the identity assertions made to it by enterprise customers, who are in turn, identity providers to the outsourced application managed by the service provider.
· Service Provider wishes to enable federated SSO to a surrounding number of enterprises by relying upon the enterprise identity assertions relating to its employees.
· Authentication of end-users (e.g. employees) will take place at the enterprise, and then propagated via identity federation assertions to the service provider.
· Roles, credentials or even authorization policies may also be asserted from the enterprise to the service provider via identity ‘attribute exchange’.
· Service providers wish to better integrate and connect their managed applications or web services to an enterprise’s existing security, authorization and policy engines.
· Enterprises wish to enable easier access to managed applications and services by enabling single sign-on over the public internet.
· Fidelity wishing to enable federated SSO to its 401k management services.
· Salesforce.com wishing to enable federated SSO to its managed CRM solutions.
· A mortgage company wishing to enable federated SSO to applications which are accessed by financial services companies and mortgage brokers.
Profile 2: Identity Provider Hub
As a near mirror image of the Service Provider Hub, the Identity Provider Hub is designed to allow a central authenticator and identity provider to federate identity attributes to a surrounding number of service providers. Think of this as a mini Microsoft Passport, but one that extends only as far as a single companies domain.
Enterprises who have taken the time and expense to aggregate user identities into a single repository for the purposes of centralized authentication and customer relationship management, such as carriers, ISP’s and portals, typically fall into this category.
In most cases, we have found that Identity Provider Hub federations tend to be consumer-facing, where aggregation of consumers and end-user simplicity as enabled through single sign-on to a large number of services is highly valued.
We have also noted that Identity Provider Hub federations, and the carriers, ISP’s and consumer facing portals behind them, tend to view internally facing federations (e.g. federating services within their domain) as only phase I of their goals to extend federation to partners.
· A large number of service providers (consumers of identity attributes) wish to leverage the authentication mechanisms of a single and/or centralized authenticator.
· Authentication strength will be driven to higher and higher levels of assurance over time, as a result of the needs of the consuming service providers.
· Service Providers may over time, evolve into becoming their own identity providers, storing and propagating attributers pertaining to their users preferences and interaction history back to the central IdP over time.
· Desire to centralize authentication and the point at which CRM services are deployed, while still enabling a surrounding number of services to leverage the authentication services of a centralized IdP.
· Desire to build an Identity Provider with strong enough levels of identity assurance that service providers outside of the identity providers domain will be comfortable in consuming the IdP’s authentication assertions.
Profile 3: Cross Domain
Cross Domain federations are of particular interest because they exist in both internal and external (between company) situations. The primary characteristic of a Cross Domain federation is that each entity acts as both an issuer of identity assertions (an ‘IdP’) and also a consumer of identity assertions (an ‘SP’) at the same time. Furthermore, there is little discernable topology to a cross domain federation, as each entity can connect to every other entity within the federation, and both accept and transmit identity-related assertions.
The Internal Cross Domain
Many large, multi-national companies, through merger and acquisition, are now faced with having to manage several heterogeneous systems at the same time. This creates both a security challenge as the IT department attempts to assure the right user-level access to resources as well as a complexity issue for employees who must manage multiple accounts, one for each security domain within the company. Internally facing federation describes the process of leveraging the relatively new and open identity federation protocols (such as SAML, Liberty or WS-Federation) to ‘link-together’ redundant identities maintained in silo’d security domains.
The External Cross Domain
Topologically identical to the Internal Cross Domain federation, the External Cross Domain federation links identities across legal domains (between companies), and is therefore not limited to the linking of redundant identities between security domains within a single company. Many times, internally facing Cross Domain federation will occur as a pre-requisite to externally facing federation activities.
We expect that both SP Hub and IdP Hub federation profiles will give way, long-term, to cross domain federation, becoming increasing dynamic in their transaction behavior over time as trust networks are established a framework of assessing risk when engaging unknown partners is automated.
· Multiple entities engaging one another as both IdP’s and SP’s simultaneously.
· Likely the ‘resting-state’ for a mature identity infrastructure.
· Can be implemented in both internal and external (between company) situations.
· Will result when an SP in an IdP Hub becomes the center of their own federation.
· Within large enterprises, Cross Domain federation provides some key cost and complexity saving advantages in that it enables cross-domain access via SSO without needing to homogenize systems or authentication.
· As entities within both the IdP Hub and the SP Hub models engage multiple federations, they will become over time, both asserters and consumers of identity attributes, naturally evolving them to the Cross Domain profile.