Microservices Expo Authors: Liz McMillan, Pat Romanski, Carmen Gonzalez, Elizabeth White, Jason Bloomberg

Related Topics: Microservices Expo

Microservices Expo: Article

Federated Identity Standards

Confused? You bet you are

Business is becoming increasingly virtual and decentralized, while real-time management of relationships with employees, contractors, partners, suppliers, and customers is becoming ever more crucial. Even within a single company, applications may reside on different platforms, in separate departmental security domains, in legacy databases derived from prior acquisitions, or (thanks to outsourcing) in separate companies. As gaining access to distributed resources becomes increasingly vital, the ability to manage identity effectively becomes a paramount concern.

Federated Identity
"Federated Identity" is a set of mechanisms through which companies can share identity information between security domains. As a result of federation, companies are now able to create identity-based applications (such as federated single sign-on) that enable increased access to cross-boundary information.

Federated identity delivers several compelling benefits to organizations. Federation means that local identities and their associated data stay in place, but they are linked together through higher-level mechanisms. In addition, federated identity organizes controlled linkages among the distributed identities of a user. This allows for efficient management, control, and movement in a radically distributed world. As organizations integrate more tightly with trading partners and outsourcers, federated identity provides a flexible mechanism that authenticates users from partner organizations and provides them with seamless access to protected online resources.

But federated identity and the standards surrounding it can be very confusing. From Liberty to WS-* to SAML and sea to shining sea, federation has become a bit of a tangle. This article will sort through some of the acronym jungle.

The Beginning of Federated Identity Standards
The move for federated identity standards began because customers of enterprise identity management companies started to ask how they could obtain single sign-on to and from their partner organizations. The fact that vendors could not ensure their own systems would achieve ubiquity of deployment led vendors to quickly realize that the ultimate solution to this problem was not one-off integration, but rather a standard mechanism for single sign-on.

The quest for developing one standard began with a company named Securant. (Securant and their identity management platform, "ClearTrust," was later sold to RSA Security). Securant worked for several months - with a few dozen of its customers, partners, and other vendors - to create a standard called "AuthXML." A few days after AuthXML was publicly announced, Netegrity and VeriSign announced their own standardization effort for the same problem - "S2ML." Through the encouragement of customers and analysts, it was decided that it was best for all involved if the efforts were combined.

During this time, a couple of meetings were held with representatives of all of the leading Web access control vendors. Ultimately, it was decided to merge the two standards efforts at the OASIS standards organization. All of the members of that group joined OASIS to work on the new standard, which took its name from the two standards it was based on, and was named SAML (the "Security Assertion Markup Language"). Their work resulted in the SAML specification, released on January 9, 2001.

From SAML to Liberty to WS Federation
The Liberty Alliance, a consortium of technology vendors and end-user companies, was formed to provide an open standard for federated identity. Liberty's work sought to build upon SAML to provide, in essence, an extension that more tightly defined the broad-based work that SAML had started. In so doing, Liberty also incorporated the WS-Security specification that Microsoft, IBM (and others) had submitted to the OASIS body. And, of course, the story doesn't end there.

Microsoft, IBM, VeriSign, and others united to write a broad set of specifications under the "WS" label. This body of work is intended to be a more modular architecture than other federated identity specifications - primarily because the WS work is meant to include other Web services needs. Accordingly, one can find WS-Security, Policy, Trust, Secure Conversation, and WS-Federation - where federation is one member of a larger family.

This tangle of standards and dependencies leads us to a brief explanation of the federated identity standards universe.

The Universe of Federated Identity
The universe of federated identity has come to encompass much more than simply single sign-on. Groups like the Liberty Alliance and the vendors focused on the WS-Federation specifications have begun to work on attribute exchange and associated services.

Figure 1 outlines the standards and dependencies that exist today. A brief explanation of each follows.

SAML 1.0, 1.1, and 2.0
SAML pronounced "Sam -el" is an extensible language for securely exchanging user information between security domains. SAML 1.0 defines a security token format (called an assertion), as well as "profiles" that define methods of using these assertions to provide Web single sign-on. SAML 1.1 incorporates feedback and errata from the 1.0 specification. SAML 2.0 is currently in the solution proposal phase - a state meant to address the requirements outlined in the market requirements document. SAML 2.0's primary objective is an incorporation of Liberty ID-FF 1.2, which I will discuss later.

Liberty Phase 1 (ID-FF 1.0)
Liberty Phase 1 extends SAML 1.0 by adding its own profiles for how to wield SAML assertions. These additional profiles add support for account linking, identity provider introduction, and global logout. The Liberty Alliance model defines roles within a federation - an Identity Provider (IdP) and a Service Provider (SP). Liberty ID-FF1.1 incorporates feedback and errata from the 1.0 specification.

Liberty Phase 2 (ID-FF 1.2)
This set of standards extends ID-FF with new functionality, such as one-time assertions of identity (for anonymity), metadata exchange, and affiliate relationships. Liberty Phase 2 (ID-WSF 1.0) is a set of standards that extend the existing Liberty framework with functionality for discovering and offering identity-related services. Profile access mechanisms are specified as an initial service, allowing for access to user attributes. Liberty Phase 2 defines many of its messages and protocol bindings in terms of SAML 1.1, and uses WS-Security for securing SOAP messages.

Liberty Phase 3
This set of standards still in the elaboration stage, but it is expected that ID-WSF will be extended with new services built on top of attribute exchange, such as a digital wallet and calendaring/address book services.

This specification defines mechanisms for providing security token-based integrity and confidentiality on Web Service (SOAP) messages. Several security tokens are defined, as well as a mechanism for associating them with messages.

WS-Security Extensions (WS-Trust, WS-Policy, WS-Federation)
This collection of specifications is an evolving set of Web service-oriented mechanisms for layering authentication, authorization, and policy across both a single and multiple security domains. WS-Federation defines a framework for federation. Profiles will be developed subsequently to specify the details for implementation.

An Oasis technical committee focused on the finishing stages of standardizing WS-Security and several security token types.

Practically Speaking
Confused? Of course you are - that's why this article exists. To sort this out, let's deal with the universe of federation standards as they exist today. That leaves us with SAML 1.1 (which is not backward compatible with SAML 1.0), Liberty 1.1, and Liberty Phase 2.

Given all of the above, the distinguishing factor is simple:

If you are an enterprise that is seeking to link two pre-existing accounts, and you must do so before the end of Q1 2005, then your easiest path is to use the Liberty Alliance specifications.

The reason for this is simple. While SAML 1.1 will allow you to perform the same operations, it will require you to extend the profiles to do so. The Liberty Alliance - in its current form - is built to accomplish this operation. That said, all of this will change as SAML 2.0 is released (realistically it should ship in products in the Q2 2005 timeframe), as SAML 2.0 will incorporate Liberty 1.2.

The Future of Federated Identity Standards
The one question that surfaces time and time again is around convergence - will there be a convergence of the federated identity standards? Hopefully, this article has shone some light on that conundrum. SAML and Liberty are becoming increasingly intertwined. WS-Federation (and the supporting specifications) stand apart. Broadly speaking, then, federated identity sits in two camps: the SAML/Liberty camp and the WS-Federation camp. Of course, some vendors are planning to incorporate all standards.

In the meantime, the practical implementation of federated identity becomes a question of business drivers. If there is a business imperative to more tightly integrate and manage distributed systems of identity, and that business imperative demands some near-term action, then the enterprise needs to make some hard choices. The safe bet is a vendor that has stated support for all three standards (nearly all do). The implementation choices will most likely come down to the use case - and if that use case is about linking two pre-existing accounts, then the Liberty Alliance presents the easiest path.

More Stories By Eric Norlin

Eric Norlin is SVP of Strategic Marketing for Ping Identity Corporation (www.pingidentity.com) and contributing editor for Digital ID World (www.digitalworld.com).

More Stories By Darren Platt

Darren Platt is CTO of Symplified and a recognized expert on identity management. He co-authored the AuthXML specification, which was the precursor to the SAML identity federation standard. He has served as Senior Director of Technology for Ping Identity where he managed the company's conformance services and PingTrust SOA security product. Previously he was vice president of engineering at Web access management pioneer Securant Technologies, where he managed development of the ClearTrust product until its acquisition by RSA Security in 1991.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Microservices Articles
Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is foundational - something customers routinely cite as a top pain point. In his session at @DevOpsSummit at 21st Cloud Expo, Bill Borsari, Head of Systems Engineering at Datera, explored how organizations can reap the bene...
"NetApp's vision is how we help organizations manage data - delivering the right data in the right place, in the right time, to the people who need it, and doing it agnostic to what the platform is," explained Josh Atwell, Developer Advocate for NetApp, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examin...
In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, discussed how to use Kubernetes to set up a SaaS infrastructure for your business. Mike Johnston is an infrastructure engineer at Supergiant.io with over 12 years of experience designing, deploying, and maintaining server and workstation infrastructure at all scales. He has experience with brick and mortar data centers as well as cloud providers like Digital Ocean, Amazon Web Services, and Rackspace. H...
Skeuomorphism usually means retaining existing design cues in something new that doesn’t actually need them. However, the concept of skeuomorphism can be thought of as relating more broadly to applying existing patterns to new technologies that, in fact, cry out for new approaches. In his session at DevOps Summit, Gordon Haff, Senior Cloud Strategy Marketing and Evangelism Manager at Red Hat, will discuss why containers should be paired with new architectural practices such as microservices ra...
In his session at 20th Cloud Expo, Scott Davis, CTO of Embotics, discussed how automation can provide the dynamic management required to cost-effectively deliver microservices and container solutions at scale. He also discussed how flexible automation is the key to effectively bridging and seamlessly coordinating both IT and developer needs for component orchestration across disparate clouds – an increasingly important requirement at today’s multi-cloud enterprise.
The Software Defined Data Center (SDDC), which enables organizations to seamlessly run in a hybrid cloud model (public + private cloud), is here to stay. IDC estimates that the software-defined networking market will be valued at $3.7 billion by 2016. Security is a key component and benefit of the SDDC, and offers an opportunity to build security 'from the ground up' and weave it into the environment from day one. In his session at 16th Cloud Expo, Reuven Harrison, CTO and Co-Founder of Tufin, ...
DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm. In their Day 3 Keynote at 20th Cloud Expo, Chris Brown, a Solutions Marketing Manager at Nutanix, and Mark Lav...
Many organizations are now looking to DevOps maturity models to gauge their DevOps adoption and compare their maturity to their peers. However, as enterprise organizations rush to adopt DevOps, moving past experimentation to embrace it at scale, they are in danger of falling into the trap that they have fallen into time and time again. Unfortunately, we've seen this movie before, and we know how it ends: badly.
TCP (Transmission Control Protocol) is a common and reliable transmission protocol on the Internet. TCP was introduced in the 70s by Stanford University for US Defense to establish connectivity between distributed systems to maintain a backup of defense information. At the time, TCP was introduced to communicate amongst a selected set of devices for a smaller dataset over shorter distances. As the Internet evolved, however, the number of applications and users, and the types of data accessed and...