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”? | ||
| 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.