| TOC |
|
This document presents a brief comparison of OpenID and SAML. For the most part, the comparison is between OpenID 2.0 and SAML 2.0, although there are some mentions of prior versions of each. The comparison addresses technical features, breadth of addressed use cases, and attributes of the specification sets.
1.
Introduction
2.
Comparison Scope
3.
OpenID - SAML comparison
4.
Contributors
5.
Acknowledgments
6.
Open Issues
7.
Change Log
8.
References
§
Author's Address
| TOC |
| TOC |
The scope of this analysis is:
The following are outside the scope of this analysis:
| TOC |
OpenID, both 1.X and 2.0, and SAML 1.X and 2.0, offer functionality quite similar to each other. Obvious differentiators are the message encodings, security mechanisms, and overall profile flows -- OpenID specifies a flow that no present single SAML profile congruently matches.
However, we note that it is distinctly possible to relatively easily craft a new SAML profile that incorporates the deltas between OpenID and, say, the SAML Web Browser SSO profile.
In fact, we have begun to do just that: [draft‑hodges‑saml‑openid‑profile‑00] (Hodges, J., “OpenID SAMLv2 Lightweight SSO Profile,” January 2007.).
Below, Table 1 (Specification Set Contents and Scope)
provides a high-level comparison of the OpenID and
SAML specification sets.
| OpenID | SAML |
|---|---|
|
Overall Status: At the time of writing this document, OpenID 2.0 was a draft specification set. There are claimed to be multiple alpha/beta implementations. OpenID 1.x is discussed in a table below. |
Overall Status: SAML 2.0 was approved as an OASIS Standard in March 2005. There are multiple certified interoperable implementations including at least two open source ones [OpenSSO and LASSO]. SAML 1.x is discussed in a table below. |
| OpenID 2.0 specifies a concrete web SSO protocol, IDP discovery protocol, principal identifier format, an extensibility mechanism (e.g. for attribute exchange), security considerations, and backwards compatibility in a single draft specification [OpenID.openid‑authentication‑2_0‑11] (OpenID, “OpenID Authentication 2.0 - Draft 11,” January 2007.). |
SAML specifies an abstract extensible security assertion and an abstract extensible request-response protocol via XML schemas, in one specification, the SAML "core" [OASIS.saml‑core‑2.0‑os] (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.) (see also [OASIS.draft‑hodges‑HowToLearnSAML‑01] (Hodges, J., “How to Study and Learn SAML,” October 2006.)). SAML protocol bindings and concrete profiles are defined in further specifications in the spec set, as described below. |
| The OpenID specfication does not explicitly support profiling in the sense that the SAML specification set does. The OpenID specification set is concretely bound to HTTP and concretely defines a single web SSO profile. However, it does feature a simple extensibility mechanism, supporting definition of specific data query and response for name/value pairs. For example, three additional OpenID 2.0 draft specifications define attribute exchange [OpenID.openid‑attribute‑exchange‑1_0‑04] (Hardt, D. and J. Bufu, “OpenID Attribute Exchange 1.0 - Draft 04,” January 2007.), attribute types [OpenID.openid‑attribute‑types‑1_0‑02] (Hardt, D., “OpenID Attribute Types - Draft 02,” November 2006.), and attribute metadata (aka properties) [OpenID.identity‑attribute‑metadata‑1_0‑01] (Hardt, D., “Identity Attribute Metadata - Draft 01,” November 2006.) via this facility. |
Concrete SAML profiles -- one per each specific use-case, e.g. Vanilla web browser SSO, enhanced-client SSO, IDP discovery, Single Logout, name identifier management & mapping, assertion query/response, attribute query/response -- are specified in the "SAML profiles" specification [OASIS.saml‑profiles‑2.0‑os] (Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, “Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.). Note that SAML profiles are specified using, or "on top of" SAML bindings. A given profile may be designed to utilize more than one binding, e.g. the Web SSO profile, or may be designed to use just one particular binding, e.g. as the SAML Lightweight Web Browser SSO (lSSO) Profile [I‑D.hodges‑saml‑lsso] (Hodges, J. and S. Cantor, “SAMLv2 Lightweight Web Browser SSO Profile,” October 2006.) uses just the SAML "SimpleSign" binding [OASIS.draft‑hodges‑saml‑binding‑simplesign‑02] (Hodges, J. and S. Cantor, “SAMLv2: HTTP POST "SimpleSign" Binding,” September 2006.) (see also [OASIS.draft‑hodges‑HowToLearnSAML‑01] (Hodges, J., “How to Study and Learn SAML,” October 2006.)). Further note that SAML was explicitly designed such that any number of profiles and bindings may be defined, in whatever venue makes sense for the definers (note that the lSSO draft is presently ensconced in the IETF venue). |
|
OpenID, in [OpenID.openid‑authentication‑2_0‑11] (OpenID, “OpenID Authentication 2.0 - Draft 11,” January 2007.), specifies two bindings to HTTP POST and HTTP GET (and requisite responses) messages. The former is intended for so-called "direct" interactions between system entities (i.e. not redirected), and the latter are explicitly defined as being redirected through the user agent. The specification does not provide guidance with respect to the creation of any other bindings. |
Protocol bindings of abstract request-response protocol messages to concrete underlying protocols, e.g. HTTP and SOAP, are specified in the ""SAML Bindings" specification [OASIS.saml‑bindings‑2.0‑os] (Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. Maler, “Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.). All of HTTP POST, HTTP redirect, SOAP-over-HTTP, reverse SOAP-over-HTTP ("PAOS"), SAML Artifact, and SAML URI bindings are specified. |
|
OpenID relies on XRDS documents, which can be found by resolving [OASIS.xri‑resolution‑v2.0‑wd‑10] (Wachob, G., Ed., Reed, D., Ed., Chasen, L., Ed., Tan, W., Ed., Churchill, S., Ed., McAlpin, D., Sabnis, C., Davis, P., Grey, V., and M. Lindelsee, “Extensible Resource Identifier (XRI) Metadata V2.0,” May 2006.) an XRI [OASIS.xri‑syntax‑V2.0‑cs] (Reed, D., Ed., McAlpin, D., Ed., Davis, P., Sakimura, N., Lindelsee, M., and G. Wachob, “Extensible Resource Identifier (XRI) Syntax V2.0,” November 2005.), for what is essentially service metadata. |
SAML metadata, e.g. for identity providers and relying parties (aka service providers), are defined in the "SAML metadata" specification [OASIS.saml‑metadata‑2.0‑os] (Cantor, S., Moreh, J., Philpott, R., and E. Maler, “Metadata for the Security Assertion Markup Language (SAML) V2.0,” March 2005.). |
| The OpenID spec set does not explicitly define conformance criteria at this time. Rather it is implicit in the specification(s). |
Conformance criteria and the specification roadmap are given in the "SAML conformance" specification [OASIS.saml‑conformance‑2.0‑os] (Mishra, P., Philpott, R., and E. Maler, “Conformance Requirements for the Security Assertion Markup Language (SAML) V2.0,” March 2005.). |
|
Security considerations are nominally discussed in [OpenID.openid‑authentication‑2_0‑11] (OpenID, “OpenID Authentication 2.0 - Draft 11,” January 2007.). An incomplete security profiles draft spec, [OpenID.openid‑authentication‑security‑profiles‑01] (Granqvist, H., “OpenID Authentication Security Profiles - Draft 1,” September 2006.), by an individual contributor, remains at version -01, from Sep-2006. |
Security considerations are presented and examined in the "SAML sec considerations" specification [OASIS.saml‑sec‑consider‑2.0‑os] (Hirsch, F., Philpott, R., and E. Maler, “Security and Privacy Considerations for the OASIS Security Markup Language (SAML) V2.0,” March 2005.). |
| The draft OpenID Assertion Quality specification [OpenID.openid‑assertion‑quality‑extension‑1_0‑03] (Recordon, D., Glasser, A., and J. Madsen, “OpenID Assertion Quality Extension 1.0 - Draft 3,” December 2006.) is an OpenID extension which conveys simple name-value pair information with respect to an authentication event. |
Meta-information regarding the particulars of authentication events is specified in the "SAML authn context" specification [OASIS.saml‑authn‑context‑2.0‑os] (Kemp, J., Cantor, S., Mishra, P., Philpott, R., and E. Maler, “Authentication Context for the Security Assertion Markup Language (SAML) V2.0,” March 2005.). SAML Authn Context information is expressed in XML, based on an extensible XML schema, and thus can easily represent complex, hierarchical or mesh relationships. Potential deploying organizations, such as mobile phone network operators, and financial institutions, specifically contributed to crafting this specification. |
| OpenID specification drafts typcially include a terminology section defining key terms. |
SAML terminology is coalesced and documented in the "SAML Glossary" [OASIS.saml‑glossary‑2.0‑os] (Hodges, J., Philpott, R., and E. Maler, “Glossary for the Security Assertion Markup Language (SAML) V2.0,” March 2005.) (also available in HTML: SAML-Glossary-in-HTML) |
| Table 1: Specification Set Contents and Scope |
| OpenID | SAML |
|---|---|
| OpenID presumes and specifies principal identifiers that are dereferenceable in order to yield the principal's OP/IDP. |
SAML does not specify, in the OASIS-issued specification sets themselves, for any SAML version, the nature of principal identifiers. It is left as an exercise for profiliers and/or deployers. |
| Table 2: Comparison of Identifier Treatment |
| OpenID | SAML |
|---|---|
| accomodates either "destination-site" first or "source-site" first. | accomodates either "destination-site" first or "source-site" first. |
|
"messages" are name-value pairs mapped to URL parameters or FORM-POST element name-values. Thus nominally equivalent to SAML 1.1 form of "authn request". |
SAML 1.1 form of AuthnRequest similar to OpenID, although not as full-featured. |
| (simplistic) security. can turn security off. DH key exchange + subsequent HMAC message signing |
Robust security based on profile stipulations, and profile particulars -- e.g. whether Redirect binding or POST binding are used. Message signatures either xmldsig-based, or simpleSign [OASIS.draft‑hodges‑saml‑binding‑simplesign‑02] (Hodges, J. and S. Cantor, “SAMLv2: HTTP POST "SimpleSign" Binding,” September 2006.) (withwhich security can be "turned off"). |
| security reviewed? By VeriSign at least, HansG sent messages to OpenID list cataloging findings |
security reviewed both in academia and in corporate. findings rolled into subsequent versions, culminating in SAML 2.0. |
| Table 3: Technical Details |
+----+ +----+ +--------+ | UA | | RP | | OP/IDP | +-+--+ +-+--+ +---+----+ | | | | 1. Authentication Req | | | and assoc_handle!=null| | +<- - - - - - - - - - - - | | . | (indirected via UA) | | . | | | +-------------------------+--------------------->| | | | | | | | | |<-+ | 2. OP/IDP authenticates Principal | | (2) is absent | (methods vary, realization is out of scope) | | if mode is |<============================================>| | check_immediate | | | | | | |<-+ | | | | 3. Authentication Resp| | +<- - - - - - - - - - - - - - - - - - - - - - - -| . | (indirected via UA) | | . | | | +------------------------>| | | | | | | | | | | | 4. Princ is signed-on | | | or some form of | | | error msg is displayed| | |<----------------------| | | | |
| Figure 1: test figure |
| TOC |
@@ TODO.
| TOC |
@@ TODO.
| TOC |
None at this time.
| TOC |
| TOC |
| TOC |
| Jeff Hodges | |
| NeuStar | |
| 2000 Broadway Street | |
| Redwood City, CA 94063 | |
| US | |
| Email: | Jeff.Hodges@neustar.biz |