Rich Wolski of Eucalyptus had some very interesting insights to share about the role of identity federation among public and private clouds. You'll see those thoughts when my Network World article publishes on February 9.
What Rich said reminded me of this article, which I published in Business Communications Review in fall 2006. It's about the need for multi-layered federation infrastructures for IP networking. It reminds me of the fact that clouds (aka "everything as a service") will also have to federate on every level.
***************************************
New Federation Frontiers in the IP Networking World
Federation is a concept much in vogue these days, and it is being applied to a growing range of telecommunications and computing infrastructures.
Where telecommunications is concerned, federation refers to an established industry practice: interconnection, routing, billing, clearing, revenue settlement, and other negotiated arrangements among affiliated service providers. Network federation allows subscribers to authenticate to their primary carrier and thereby gain single sign-on (SSO) access to services, applications, and content controlled by affiliated service providers. The alternative to federation is centralization—in other words, the long-discarded “Ma Bell” approach of one carrier controlling everything in the connected universe.
If you think of it, the Internet is the most successful network federation of all. It is a global federation of separate, cooperating networks built on universal adoption of the Internet Protocol (IP), Domain Name Service (DNS), Uniform Resource Locator (URL), and other core standards developed under the auspices of the Internet Engineering Task Force (IETF) and other groups. In addition, as noted in “What is Federated Identity Management?” (Business Communications Review, August 2005), federations have been implemented widely in other telecommunications and distributed computing environments. For example, federated location-registry and roaming services enable interconnected cellular carriers to authenticate client devices, route incoming calls, apply appropriate calling features, and bill subscribers correctly. Furthermore, multi-institution automated teller machine (ATM) networks—such as Cirrus--operate under a type of federation, enabling users to login remotely to their bank accounts from any affiliated institution’s machines.
In addition to these long-established approaches, new frontiers in standards-based cross-carrier federation are opening up. Many of those new federation initiatives fall under the broad architectural umbrella of IP Multimedia Subsystem (IMS). Increasingly, network industry standards groups are using the word “federation” to describe their cross-carrier IP interoperability frameworks. The IMS community is referencing federation identity management (IdM) standards—such as those developed by the Organization for the Advancement of Structured Information Standards (OASIS) and the Liberty Alliance—to facilitate convergence among diverse IP-based services. But they’re going beyond the Web services world’s federation protocols to define federation environments that build on IETF specifications such as Domain Name Service (DNS), Session Initiation Protocol (SIP), and Electronic Number (ENUM).
Figure 1 illustrates several layers of federation that are possible in a cross-carrier IP internetworking environment: federated IdM (user and device authentication, SSO, and roaming); federated service creation, provisioning, and coordination; and federated service provider peering (interconnection, policy declaration, addressing, and routing).
The industry is implementing IP federation in all of these areas. Recently, federation has popped up in several new industry standardization efforts, though not all of these new federation approaches have yet been implemented in production carrier internetworking environments.
Most notably, infrastructure vendors are integrating federated IdM SSO protocols within IMS’ Home Subscriber Server (HSS). In addition, the IPsphere Forum is developing commercial and technical frameworks to support federated cross-carrier service provisioning, signaling, and management, incorporating federated IdM standards plus a broad range of WS-* standards. Furthermore, an Internet Engineering Task Force (IETF) Working Group is developing standards under which Voice Over IP (VoIP) service providers will be able to flexibly federate amongst themselves through the DNS and ENUM infrastructures.
Federated Identity Management
Many people in the information technology world associate federation primarily with IdM. Federated IdM refers to standards-based approaches for handling authentication, SSO, role-based access control, and session management across diverse organizations, security domains, and application platforms. The most widely implemented federated IdM/SSO protocol standards include Liberty Alliance Identity Federation Framework (ID-FF), OASIS’ Security Assertion Markup Language (SAML), and WS-Federation.
Within a typical cross-carrier internetworking environment, federated IdM may be implemented in layers. For converged IP services, federated IdM may involve separate authentications at the application layer and network layer.
Increasingly, the application-layer authentications are relying on any or all of the federated IdM standards mentioned above. In fact, telecommunications carriers in many nations are among the most active implementers of the Liberty Alliance specifications, having deployed Liberty-based IdM services for application-layer account linking, SSO, and trusted attribute sharing across their catalogs of federated third-party services.
Application-layer federated IdM relies on carriers maintaining authoritative directories of user identities, credentials, roles, personalization settings, user preferences, and other attributes. Generally, each federated carrier and service provider operates as an identity provider (IdP), managing the master directory of its own registered subscribers along with their account profiles. Carriers may also provide real-time subscriber session state information to federated partners, thereby facilitating targeting and personalization of service delivery.
Within the underlying IP networking environment, network-layer authentications will increasingly rely on IMS’ HSS infrastructure. HSS is IMS’ principal network-layer IdM environment. Within each carrier’s IMS network, the HSS is a master directory that supports user authentication and authorization, subscriber profile management, session setup and management, call routing, and user roaming within carrier networks. There are no standards specifying exactly how the HSS must interact with its underlying user directory or database repository. Consequently, IMS infrastructure providers and carriers may rely on prevalent directory-access standards, such as the Lightweight Directory Access Protocol (LDAP), or WS-* standards, such as XML Query, for query, update, and management of their HSS repository.
The HSS is a master directory of device and user identity information relevant to network-level authentication, authorization, and roaming. For wireless networks, the HSS manages device and user identities such as International Mobile Subscriber Identity (IMSI), Temporary Mobile Subscriber Identity (TMSI), International Mobile Equipment Identity (IMEI), and Mobile Subscriber ISDN Number (MSISDN). With IMS, the HSS manages additional identities, including IP Multimedia Private Identity (IMPI) and IP Multimedia Public Identity (IMPU), which are URIs associated with single or multiple client devices.
To enable cross-carrier interconnection, SSO, and roaming, HSS environments must be federated through various approaches.
At the network layer of the IMS architecture, cross-HSS federation requires that each carrier also implement a Subscriber Location Function (SLF), and that each HSS and SLF implement the DIAMETER protocol (RFC 3588) for authentication, authorization, and accounting (AAA). Essentially, the HSS/SLF infrastructure in IMS environments is equivalent to the Home Location Registry (HLR) and Visitor Location Registry (VLR) services in cellular networks (one big difference is that the HSS/SLF is a media, network, and device-agnostic functional evolution, hence a functional superset, of the cellular-specific HLR/VLR infrastructure).
DIAMETER is an important piece of the IP networking federation equation. DIAMETER—the IMS successor to the widely adopted Remote Access Dial-In User Service (RADIUS) protocol--may be used for cross-carrier federated AAA in conjunction with the HSS. Wireline and wireless ISPs authenticate users at the application layer through DIAMETER/RADIUS servers that interface to authoritative directories of user identities, passwords, and other credentials. DIAMETER/RADIUS servers can serve as proxies, mediating between a front-end authenticating server and one or more back-end directories. As proxies, these servers can be set up to forward authentication and accounting messages to peer authentication servers in other application domains, which is essentially a federated IdM scenario.
In addition, DIAMETER is the principal access protocol that allows distributed IMS functions, no matter what carrier’s domain they happen to deployed within, to interact with the carrier’s master HSS. Within the IMS infrastructure, the Interrogating Call Session Control Function (I-CSCF) queries the HSS using DIAMETER to retrieve the user location, in order to route a Session Initiation Protocol (SIP) request to its assigned Serving CSCF (S-CSCF). The S-CSCF uses DIAMETER to download user profiles from and upload user profiles to the HSS. And an IMS Application Server—controlling caller ID and other enhanced services—can use DIAMETER to query the HSS for subscriber presence, location, and other account profile data.
Industry efforts are underway to integrate IMS’ federated IdM infrastructure—centered on HSS and DIAMETER—with the Web services world’s IdM environment, in which application-layer directories and federated SSO protocols are predominant. In separate recent initiatives, both Sun Microsystems and Microsoft are positioning their federated IdM platforms and protocols as SSO adjuncts to carrier HSS infrastructures.
In April 2006, Sun and Lucent Technologies announced joint development of infrastructure products that provide standards-based SSO access to federated IMS services. Sun is providing its Sun Java System Federation Manager product to the initiative, whereas Lucent has provided a full IMS product suite that includes HSS and other IdM functionality.
Under this joint development initiative, Lucent is providing a suite of IMS infrastructure products to support federated IdM functionality. The following set of products is indicative of the functional components necessary for federated IdM over HSS in an IMS environment:
Lucent Datagrid: This product integrates the diverse, federated carrier databases that contain subscriber data relevant to call processing, session management, messaging, and customer care.
Lucent Unified Subscriber Data Server (USDS): This product provides HSS, HLR, and AAA functionality. It enables HSSs to be deployed in a centralized or decentralized/federated fashion. It allows access to subscriber profile data that is hosted inside or outside of a service provider's network and on diverse network platforms. It also enables operators to provide subscribers with a single service presentation environment even when roaming to another carrier’s network.
Lucent Session Manager: In conjunction with the USDS, the Session Manager supports SSO, presence management, and session management across diverse, federated IMS-based services. It allows operators to provide integrated voice, data, video, multimedia, and other capabilities over IMS sessions. Through embedding of Sun’s technology, the Session Manager is implementing the Liberty Alliance federated IdM protocols, which provide SSO within multilateral federated environments. In addition, the product leverages the Liberty protocols to allow subscribers to selectively disclose particular profile information—such as current locations and previously stored preferences—to particular federated application and content providers. Furthermore, the Session Manager can be deployed for several core IMS functional roles, including Call Session Control Function, Service Broker, Service Capabilities Interaction Manager (SCIM), Policy Decision Function (PDF), and the Breakout Gateway Control Function (BGCF).
Lucent Communication Manager: This product provides a unified portal presentation view for subscribers to access their IMS-based converged services from wireline or wireless clients. It supports integrated session control that is agnostic to the underlying application servers serving the subscriber and is agnostic to the client devices through which services are being accessed.
Lucent Vortex: This product provides a policy engine that may be distributed throughout a network to support personalization and customization of end-user views of federated IMS-based services. It allows network operators to quickly modify network behaviors to serve the special requirements of particular customer segments and ensure guaranteed quality of service.
Separately, Microsoft has been working with carriers throughout the world to integrate its own application-layer federated IdM stack with their IMS environments. Microsoft published its federated IMS vision in a June 2005 whitepaper called “Connected Services Framework and IMS: A Partnership for Success.”
Microsoft’s and Sun’s visions for federated IdM have many common themes, such as promoting IMS service convergence and aggregation, enabling SSO with trusted user attribute sharing, and implementing WS-* standards pervasively throughout carrier infrastructure. Both of them promote IMS convergence visions under which network-layer IdM services—such as the DIAMETER protocol interfaces—could conceivably be exposed as Web services and invoked from application-layer IdM services (though neither Microsoft nor Sun has committed to exposing DIAMETER APIs as Web services). In other words, they both point to the eventual unification of IMS application- and network-layer federation within a common service-oriented architecture (SOA) framework.
However, their approaches differ in two important respects.
First, Sun has been promoting the Liberty Alliance protocols in its carrier-federation roadmap, and implementing them in its work with Lucent. Microsoft, by contrast, has been implementing the rival WS-Federation protocol, as well as other WS-* specifications—such as WS-Trust—that it has a key role in developing. It’s important to note that the functional differences between the Liberty Alliance protocols and WS-Federation are not great, and that they both support federated account linking, strong authentication, SSO, trusted attribute sharing, privacy protection, and session management over multi-organization circles of trust.
Second, Sun has been working with Lucent to embed federated IdM protocols into the underlying IMS HSS/SLF infrastructure. Microsoft, by contrast, has focused on connecting its federated IdM infrastructure to IMS as an Application Server. In the IMS architectural framework, an Application Server is a functional component that hosts and executes calling and application services. In addition to application-layer SSO, other services that may be implemented as IMS Application Servers include Caller ID, Call Waiting, Push To Talk, Voice Mail, Short Message Service, Presence, and Location-Based Services. From the subscriber’s point of view, an Application Server may be located in the subscriber’s own home carrier’s network, or in a federated third-party network or service provider environment.
It’s not clear which, if either, of the two approaches—Sun’s embedding of federated IdM in IMS HSS vs. Microsoft’s integration of federated IdM as an IMS Application Server—is best. Embedding of industry-standard federation protocols in HSS may pay off for Sun/Lucent if other IMS infrastructure providers and carriers follow their lead.
Integration of the WS-Federation protocol as an IMS Application Server may pay off for Microsoft if it can convince IMS infrastructure providers and carriers to implement this protocol. However, it should be noted that Microsoft’s three-year-old WS-Federation specification has not achieved much adoption in the mainstream federated IdM community.
Federated Service Creation, Provisioning, and Coordination
The IMS framework is missing an important component: specifications that describe how IP services can be flexibly created, provisioned, and coordinated across federated carriers, application partners, and content publishers.
The IPsphere Forum is a telecommunications industry initiative to fill in this missing piece. The forum is an international consortium of service and infrastructure providers developing both the commercial and technical frameworks for federated cross-operator service delivery. The group, which has been in existence for more than a year, has established a formal liaison with the International Telecommunications Union Telecom Standardization Sector.
The IPsphere frameworks, still under development, implement SOA principles within the IMS architectural model. Leveraging WS-* specifications such as UDDI, IPsphere is defining a standards-based environment for provisioning network infrastructure, application, and content services—composed of modular “service elements”--to carriers, endpoints, and users across federated IP networks. Each service element is a software method or module that is hosted by a provider and published to a UDDI registry as a Web service. End-to-end IP voice, data, and multimedia services may be created from diverse service elements hosted by many federated providers. Providers link the services to their respective network and policy management infrastructures for runtime administration, optimization, and control.
Under the IPsphere commercial/technical framework, application-layer IdM services—such as Liberty Alliance-based SSO—are just one category of infrastructure interactions that may be federated across a “pan-provider” IMS environment. Boundaries between federated providers sit at the intercarrier interface (ICI), as defined under the IMS model. IMS defines Call State Control Function (CSCF) points that can be deployed at network boundaries, such as ICIs, for enforcing federation policies—such as security, trust, quality of service, revenue settlement, and service-level agreement (SLA) accountability--defined by cooperating IP service providers.
Across these network boundaries, federated service provisioning and coordination take place across the following functional service layers, or “strata,” as defined by IPsphere:
Packet handling stratum: This corresponds to the seven-layer Open Systems Interconnection protocols, as implemented in the IMS model.
Policy and control stratum: This corresponds to such IMS functional components as the “Policy Decision Function,” “Proxy Call Session Control Function,” “Policy Enforcement Point,” and “Common Open Policy Service.”
Service signaling stratum: This stratum has no counterpart in the IMS model. It is the IPsphere layer at which federated pan-provider services are created, provisioned, and coordinated from elements hosted in diverse provider environments. Across this layer, the providers’ service creation environments exchange structured messages to manage the phases of federated service setup, execution, and assurance. IPsphere defines several models of federated message-driven service creation, including permissive Internet-like interactions among providers, policy-database-mediated linking of services at the ICI, and explicit linking of services at the ICI by the providers’ respective network management systems.
Under IPsphere’s commercial model, each federated service provider may perform one or both of the following functional roles: “Partners” or “Sellers.” Partners contribute resources in the form of registered component service elements from which Sellers assemble end-to-end services that are sold to users, who are also known as “Buyers.” Partners publish only those services/elements that they want Sellers to deliver to Buyers, using UDDI and other Web services standards for messaging-based service provisioning interactions with Sellers. Partners receive revenues from Buyers via settlement payments rendered by Sellers, who validate, authenticate, and bill the Buyers. Partners may also assemble component services contributed by various federated “Sub-Partners.”
Of course, negotiated contractual relationships determine how Partners, Sub-Partners, Sellers, and Buyers interact throughout the federated service provisioning and delivery life cycle. The flexible IPsphere federation framework allows participating organizations to offer whatever resources they choose, at whatever price the market will bear, under whatever federation partnering arrangements make business sense.
Federated Service Provider Peering
Within the fast-evolving world of IP networks, cross-provider federations are being established to facilitate end-to-end service interoperability.
In their drive to establish a end-to-end alternative to the public switched telephone network (PSTN), VoIP service providers (VSPs) are establishing their own federations. Federation—also called “VoIP peering”--enables VSPs to offer end-to-end “on-net” VoIP calls and other IP multimedia communications services to their own customers and to the customers of ay federated VSP. As more VSPs federate with each other—preferably in multilateral arrangements--their collective on-net customer base will reach a critical mass under which VoIP becomes a cost-effective, full-service alternative to the PSTN. The number of calls that a VSP can complete on-net is directly proportional to the number of other federated VSPs and their customers.
Founded in 2004 and headquartered in London, XConnect is the world’s largest VSP peering/federation community and operates the world’s largest international private ENUM registry. XConnect provides VSP federation services to more than 150 VSPs and 123 million unique VoIP telephone numbers worldwide. Its VSP services include address protocol interoperability, ENUM interconnect call addressing and routing services, and authentication and identity services. In addition, XConnect provides multi-protocol interoperability, VoIP call security, and Spam over Internet Telephony (SPIT) prevention services to VSP members.
Separately, the IETF’s Session Peering for Multimedia Interconnect (SPEERMINT) Working Group is developing standards under which VSPs will be able to flexibly federate amongst themselves. The SPEERMINT specifications leverage the basic VoIP standards: SIP, Real-time Transport Protocol (RTP), and H.323. In addition, SPEERMINT is placing heavy reliance on DNS and the emerging DNS-integrated ENUM directory infrastructure to support a ubiquitous VSP federation address and policy administration environment.
Under SPEERMINT’s specifications, a federation is defined as “a group of VSPs [that] agree to receive calls from each other via SIP, agree on a set of administrative rules for such calls [such as settlement and abuse handling], and agree on specific rules for the technical details of the interconnection.” A VSP declares its membership in a federation by publishing to DNS a “domain policy” regarding the conditions under which they are willing to accept incoming communications per the rules of the federation. The specifications define the structure of these domain policies and the general approach for publishing them to DNS, using Dynamic Delegation Discovery System (DDDS) DNS records.
Under SPEERMINT’s approach, each VSP federation would identify itself by a unique URI, set membership eligibility criteria, define its internal policies and rules, and determine how to communicate those rules to member VSPs. SPEERMINT recommends but does not require that VSP federations use URLs to point to documents describing federation policies and rules.
Some of the VSP-federation policies, rules, and membership conditions that might be described in these documents include:
• Federated VSPs agree to use federation-designated ENUM infrastructure to translate existing numeric phone numbers to SIP addresses using DNS to facilitate on-net VoIP call routing;
• Federated VSPs agree to accept SIP-based calls from each other via the public Internet, as long as each call uses Transport Layer Security (TLS) over Transmission Control Protocol and presents a X.509 cert that was signed by a federation-designated public key infrastructure certificate authority;
• Federated VSPs agree to accept only those SIP-based calls from each other that were transmitted over a federation-wide virtual private network;
• Federated VSPs agree to accept all SIP-based calls from each other that were originated from within the same country;
• Federated VSPs agree to accept only those SIP-based calls from each other that were routed through a central, federated-designated SIP proxy;
• Federated VSPs agree to have revenue settlements for calls from each other administered by a federation-designated clearinghouse; and
• Federated VSPs agree to use firewalls and other perimeter security devices to block SIP calls that violate federation-administered anti-SPIT rules.
The SPEERMINT working group also points out that the same DNS-enabled federation approach may be used for peering among providers of SIP, instant messaging (IM), and other IP application services.
Though the SPEERMINT group doesn’t directly acknowledge the IPsphere Forum’s work, it’s clear that the two industry initiatives are complementary. The SPEERMINT effort defines an IP environment under which providers of a particular service—VoIP calling—may federate the policies under which they connect their users. IPsphere, by contrast, defines a larger IMS-based technical environment within which VSPs can provision and coordinate end-to-end VoIP and other services that conform to federation policies.
Likewise, the SPEERMINT and IPsphere frameworks require that end users and their devices authenticate using federated IdM protocols, at both the application layer (in the context of SOA and Web services) and network layer (in the context of IMS’ HSS). So there’s an important and growing role for the Liberty Alliance, SAML, and other federated IdM protocols in IP, IMS, SIP, VoIP, and IPTV federations.
Federation in a complex IP internetwork is a many-layered thing. In fact, federation—on many levels—is the key to convergence of diverse, pan-provider, multimedia IP services. Every new carrier, hosted application provider, and content publisher in the IMS fabric is another domain that must federate with existing providers in order to do business online.
***************************************
Back in the days I was a federation analyst. And an SOA analyst. Still am, but I've moved on.
Jim
