Date: Thu, 28 Mar 2024 21:34:52 +0000 (UTC)
Message-ID: <1709941209.7044.1711661692454@ip-10-10-7-29.ec2.internal>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_7043_1052944231.1711661692452"
------=_Part_7043_1052944231.1711661692452
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
What's New in SAM=
L V2.0?
- Pseudonyms - SAML V2.0 defines how an opaque pseudo-random identifier w=
ith no discernible correspondence with meaningful identifiers (for example,=
emails or account names) can be used between providers to represent princi=
pals. Pseudonyms are a key privacy-enabling technology because they inhibit=
collusion between multiple providers (as would be possible with a global i=
dentifier such as an email address).
- Identifier management - SAML V2.0 defines how two providers can establi=
sh and subsequently manage the pseudonym(s) for the principals for whom the=
y are operating.
- Metadata - SAML's metadata specification defines how to express configu=
ration and trust related data to make deployment of SAML systems easier. In=
doing this, it identifies the actors involved in the various profiles, suc=
h as SSO Identity Provider and Service Provider, and Attribute Authority an=
d Requester. The data that must be agreed on between system entities includ=
es 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 n=
ames and values.
- UUID Attribute Profile: supports use of UUIDs as attribute names.
- XACML Attribute Profile: defines formats suitable for processing by XAC=
ML.
- 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 user, after auth=
enticating at an identity provider, achieved single sign-on to multiple ser=
vice providers, they could be automatically logged out of all of those serv=
ice providers at the request of the identity provider.
- Devices - SAML V2.0 introduces new support for the mobile world, addres=
sing 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 po=
ssible to obtain and express a principal's consent to some operation being =
performed.
- Identity provider discovery - In deployments having more than one ident=
ity provider, service providers need a means to discover which identity pro=
vider(s) a principal uses. The identity provider discovery profile relies o=
n a cookie written in a common domain between identity and service provider=
s.
The Benefits of SAML V2.=
0
Why is InCommon pushing for broad SAML V2.0 support across the Fede=
ration? Let=E2=80=99s imagine for the moment that 100% of InCommon IdPs and=
SPs supported SAML V2.0. Then all of the following would become possi=
ble:
- IdPs would encrypt all issued assertions, guaranteeing end-to-end confi=
dentiality and relying party authenticity.
- Because of the enhanced security characteristics associated with encryp=
ted assertions, IdPs would simply push attributes in all cases. No attribut=
e query or artifact resolution would be necessary. No SOAP or back-channel =
SSL/TLS exchanges would be required.
- With the need for back-channel exchanges all but eliminated, SAML Web B=
rowser SSO would become much easier to deploy. The promise of significantly=
reduced administrative overhead would induce smaller organizations with li=
mited resources to join the Federation, which would increase the penetratio=
n of InCommon throughout the education community.
- SPs could safely choose to deploy SAML V2.0 protocols only, which =
widens the range of SAML software options available to SP operators.
- A standard approach to SP-initiated Web Browser SSO, along with a rich =
authentication request protocol, would increase the communication bandwidth=
between SPs and IdPs, and enable use cases previously found to be ill-suit=
ed to federation.
- Support for non-browser SSO would increase the reach of SAML, giving us=
ers access to technologies and services previously unavailable via ordinary=
web browsers.
- A sophisticated framework for defining and transmitting authentication =
context from the IdP to the SP would enable a framework based on so-called =
levels of assurance. This capability is a prerequisite for the InC=
ommon Identity Assurance Program and the high-valued applications and servi=
ces it envisions.
The following is a more detailed, technical list of some of the more imp=
ortant advantages of SAML V2.0:
- SAML V2.0 standardizes SP-initiated Web Browser SSO
- SP-initiated SAML V1.1 Web Browser SSO is based on the proprietary=
Shibboleth 1.x
AuthnRequest
protocol
- SAML V2.0 provides a rich authentication request protocol (SAML&nb=
sp;V2.0
AuthnRequest
)
- SAML V1.1 doesn=E2=80=99t even have an authentication request prot=
ocol
- InCommon relies on the Shibboleth 1.x
AuthnRequest
pr=
otocol (which is functionally limited and nonstandard)
- SAML V2.0 leverages indexed
<md:AssertionConsumerService&=
gt;
endpoints in metadata
- these endpoints may be referenced in a
<samlp:AuthnRequest>=
message
- SAML V2.0 supports multiple
<md:ArtifactResolutionService=
>
endpoints in metadata
- these endpoints are not supported at all by SAML V1.1
- SAML V2.0 leverages multiple
<md:AttributeConsumingServic=
e>
elements in metadata
- these endpoints may be referenced in a
<samlp:AuthnRequest>=
message
- SAML V1.1 supports just one
<md:AttributeConsumingService=
>
element
- SAML V2.0 provides many choices with respect to SAML bind=
ing
- SAML V2.0 supports message-level encryption (i.e., XML Encryption)
- SAML V1.1 doesn=E2=80=99t support XML Encryption at all
- SAML V2.0 provides a standard transient name identifier
- SAML V1.1 doesn=E2=80=99t define a transient name identifier
- InCommon relies on the proprietary
urn:mace:shibboleth:1.0:nameId=
entifier
transient name identifier format
- SAML V2.0 introduces persistent name identifiers
- these identifiers are compatible with the
eduPersonTargetedID attribute
- SAML V2.0 provides message-level support for IdP Proxies
- SAML V2.0 provides extensive support for authentication context
- authentication context is required for participation in the InCommon Id=
entity Assurance Program
- SAML V2.0 defines a non-browser SSO profile (i.e., SAML V2.0 =
Enhanced Client or Proxy profile)
The OASIS SAML Technical Committee has published a comprehensive list of=
differences between SAML V2.0 and SAML V1.1 as well.
Taken from: SAML V2.0 Executive Overview (12 April 2005, published by OAS=
IS)
------=_Part_7043_1052944231.1711661692452--