The SAML XML.org web site is not longer accepting new posts. Information on this page is preserved for legacy purposes only. For current information on SAML, please see the OASIS Security Services Technical Committee Wiki.

Diff for SAML 2.0 enhancements

Wed, 2007-12-12 22:55 by carolgeyerMon, 2008-01-07 16:12 by carolgeyer
Changes to Body
Line 1Line 1
 
<p>
 
<p>
-
SAML version 2.0 introduces a number of new features, including:
+
SAML 2.0 introduced a number of features not available in previous versions of the specification, including:
 
</p>
 
</p>
 
<p>
 
<p>
-
<strong>Pseudonyms</strong> – SAML V2.0 defines how an opaque pseudo-random identifier with no discenible correspondence with meaningful identifiers (for example, emails or account names) can be used between providers to represent principals. Pseudonyms are a key privacy-enabling technology because they inhibit collusion between multiple providers (as would be possible with a global identifier such as an email address).
+
<strong>Pseudonyms</strong> – SAML 2.0 defines how an opaque pseudo-random identifier with no discenible correspondence with meaningful identifiers (for example, emails or account names) can be used between providers to represent principals. Pseudonyms are a key privacy-enabling technology because they inhibit collusion between multiple providers (as would be possible with a global identifier such as an email address).
 
</p>
 
</p>
 
<p>
 
<p>
Revision of Mon, 2008-01-07 16:12:

What's different about SAML 2.0

SAML 2.0 introduced a number of features not available in previous versions of the specification, including:

Pseudonyms – SAML 2.0 defines how an opaque pseudo-random identifier with no discenible correspondence with meaningful identifiers (for example, emails or account names) can be used between providers to represent principals. Pseudonyms are a key privacy-enabling technology because they inhibit collusion between multiple providers (as would be possible with a global identifier such as an email address).

Identifier management – SAML V2.0 defines how two providers can establish and subsequently manage the pseudonym(s) for the principals for whom they are operating.

Metadata – The metadata specification defines how to express configuration and trust-related data to make deployment of SAML systems easier. In doing this, it identifies the actors involved in the various profiles, such as SSO Identity Provider and Service Provider, and

Attribute Authority and Requester – The data that must be agreed on between system entities includes supported roles, identifiers, supported profiles, URLs, certificates and keys.

Encryption – SAML V2.0 permits attribute statements, name identifiers, or entire assertions to be encrypted. This feature ensures that end-to-end confidentiality of these elements may be supported as needed.

Attribute Profiles – Attribute profiles simplify the configuration and deployment of systems that exchange attribute data. The attribute profiles include: Basic attribute profile: supports string attribute names and attribute values drawn from XML schema primitive type definitions. X.500/LDAP attribute profile: supports canonical X.500/LDAP attribute names and values. UUID Attribute Profile: Use of UUIDs as attribute names. XACML Attribute Profile: formats suitable for processing by XACML.

Session management – The single logout protocol in SAML V2.0 provides a protocol by which all sessions provided by a particular session authority can be near-simultaneously terminated. As an example, if a principal, after authenticating at an identity provider, achieved single sign-on to multiple service providers, they could be automatically logged out of all of those service providers at the request of the identity provider.

Devices – SAML V2.0 introduces new support for the mobile world – addressing both the challenges introduced by device and bandwidth constraints and the opportunities made possible by emerging smart or active devices.

Privacy Mechanisms – SAML V2.0 includes mechanisms that allow providers to communicate privacy policy and settings. For instance, SAML makes it possible to obtain and express a principal's consent to some operation being performed.

Identity provider discovery – In deployments having more than one identity provider, service providers need a means to discover which identity provider(s) a principal uses. The identity provider discovery profile relies on a cookie written in a common domain between identity and service providers.


See also:

- SAML Executive Overview
- SAML Technical Overview

XML.org Focus Areas: BPEL | DITA | ebXML | IDtrust | OpenDocument | SAML | UBL | UDDI
OASIS sites: OASIS | Cover Pages | XML.org | AMQP | CGM Open | eGov | Emergency | IDtrust | LegalXML | Open CSA | OSLC | WS-I