Dueling Federation Standards

The nice thing about standards is that there are so many from which to choose. That may be a cliché, but it certainly applies to federated authentication protocols. There are several widely adopted protocols in use including SAML, WS-Federation, OAuth and OpenID. The first two are based on SOAP (Simple Object Access Protocol) messages carried over HTTP and are OASIS proposed or ratified standards. The latter two are non-SOAP REST HTTP protocols and are standards-track but not yet standardized.

SAML stands for Security Assertion Markup Language. The OASIS standard is composed of a set of specifications for assertions, protocols, bindings, profiles, metadata, etc. There is a community developed, open source implementation from the Shibboleth Consortium that is in wide use in higher education and elsewhere. SAML version 1.0 was ratified as a standard in 2002. The current version 2.0 of the standard was ratified in 2005.

WS-Federation is part of the Web Services Security (WSS) set of proposed and accepted standards which includes WS-Trust and WS-Security. Microsoft and IBM both contributed to the design of the standards and employ them in their federation software. The Microsoft implementations use either SAML versions 1.1 or 2.0 security tokens. To the best of my knowledge there is no open source reference implementation.

Although both of these standards share the same token format, the wire protocols are not compatible so that interoperation is not possible.

OpenID is a newer identity federation protocol specification. It is rapidly evolving due to early versions having significant security weaknesses. Several major web vendors, including Google and Yahoo!, implement OpenID authentication systems.

OAuth is technically not a federated authentication protocol. Rather, it is an authorization framework. It is typically employed in situations where one user is granting limited access to his or her protected resources to another user.

OpenID Connect is a protocol framework that incorporates the features of OpenID 2.0 and OAuth 2.0 in an API-friendly fashion. It employs elements that are compatible with REST including JSON Web Tokens (JWT) for the transmission of user attributes (a.k.a. claims or assertions).

Each federation standard defines several roles or components and they all function in a similar fashion. First there is an identity provider (IdP) that stores and verifies user identities. Technically the IdP is the protocol layer that lies in front of an authentication system such as Open LDAP or Active Directory. An IdP is also known as a security token service (STS). Then there is the web application that requires user authentication. Such an application is known as a service provider (SP) or relying party (RP). The standards define the function and format of the IdP and SP components.

So, which of these is the best? Well, it depends. The SAML standard has a non-proprietary and proven implementation in Shibboleth and it meets the needs of most web applications. The WSS protocols are widely used in business software. There are some advantages to designing a web API using REST-ful conventions rather than SOAP. A REST-ful API precludes the use of a SOAP-based authentication mechanism. However, the OpenID technologies are immature such that implementations vary in their interpretation of the protocols and many have suffered from significant security vulnerabilities. Time will tell if OpenID authentication evolves into a trusted and widely used technology. Note: when a large business like Microsoft or Google or Facebook adopts a technology, that technology can become a de facto standard. In the case of OpenID, their versions are slightly different, so hopefully a real standard will emerge through the standards development process.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.