SAML2.0与WS-Federation比较

在联合身份认证中有两大标准：OASIS组织的SAML和微软支持的WS-Federation。二者主要的区别在于SAML直接使用XML加密和XML签名，这意味着它可以和REST协同工作，而WS-Federation则需要SOAP。下面是对两种标准的比较，列出了它们之间的区别。

 

Below is a table where I compare both specs on various features and technical details. Note that each blue highlight identifies what I think is a plus for the specification (when compared to the other).

 

Topic	WS-Federation	SAML 2.0
Target	- Browser Redirect (messages in URL) - Browser POST (messages in HTML form) - SOAP (over HTTP) - Artifact	- Browser Redirect (messages in URL) - Browser POST (messages in HTML form) - Artifact (reference to assertion + SOAP call) - SOAP (over HTTP) - Reverse SOAP (over HTTP)
Security tokens supported	- Those supported by WS-Trust (SAML assertions, X509 certificates, kerberos...)	- SAML assertions - Any other token types (embedded in a SAML assertions via the SubjectConfirmation element)
Dependencies	- WS-Trust [1], WS-Policy, WS-SecurityPolicy. - WS-Eventing to subscribe to Single Sign Out messages. - WS-Transfer & WS-ResourceTransfer.	- None!
Identity federation	- Performed by the Pseudonym service (optional...) which provides identity mapping and its management.   - A Pseudonym service may be independent of an IP/STS and could store tokens associated to a pseudonym.	- Identity mapping is part of the IdP. Although less (?) flexible it avoids the need for yet another protocol between the pseudonym service and the assertion generator (IP/STS in WS-*).
	- Mapping can be created either by the requestor (principal...) or the owner of the resource (SP).
		- Mapping is created by the IdP but can be changed by either the IdP or an SP.
	- All operations on pseudonyms (get, set, create or delete) are done via WS-Transfer (and its extension WS-ResourceTransfer to filter the scope of these operations).
	- Client-based pseudonyms: a requestor can specify (in an RST) ad-hoc data for a pseudonym it wants to be used by the STS (e.g. PPID, DisplayName, email...)
		- SAML does not provide a similar concept to the ClientPseudonym in its AuthNRequest . Is this one of the active requestor “benefit”? The Name ID management protocol (and SPProviderID) is not meant for transient ID mapping.
Metadata	- Description of the federation metadata format. - Description of a secure transfer of this metadata. - Can hold info about several federations.	- Description of metadata for SSO and more. - Organized by roles (IdP, SP, Attribute requester, PDP...)
Single Logout	- Can be initiated by either an SP or the (primary) STS which will send sign-out messages to all RP.	- Similar
Artifact	- Based on the use of a reference token (i.e. an EPR to which a WS-Transfer GET can be made to retrieve the actual token).	- Artifact profile (complete SAML response) - URI binding (to only obtain SAML assertion) - SAML also defines mechanisms to request or query existing assertions (by subject or statement type).
Authorization service	- Again a specialized STS. - Concept of authorization context (name-scope-value) to condition the issuance of a token.	- The context seems to be a kind of pendant to the SAML2 XACML profile...
Authentication freshness	- A requestor can specify its freshness requirements (allow caching of security tokens etc.)	- Similar with Conditions and ForceAuthN
Authentication level	- WS-Trust defines the parameter (AuthenticationType ). WS-Fed specifies predefined values (e.g. Ssl, SslSndKey, smartcard).	- SAML 2.0 offers a much broader & extensible set of authentication contexts .
Privacy	- A requestor can express its protection requirements for security tokens it requests (protectData w/h claims & confirmation from STS). - Privacy statements can be retrieved via WS-Transfer.	- SAML offers a range of options to constraint the use & scope of an assertion (audience, advice, proxyRestriction, oneTimeUse, condition) [2] - Those constraints can originate from both the SP or the IdP.

 
[1] WS-Federation basically extends WS-Trust to allow the issuance of tokens that can carry attributes or pseudonyms.

[2] One would argue that this could be achieved with WS-Policy but SAML has the advantage of offering built-in ones.