在联合身份认证中有两大标准: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.
分享到:
相关推荐
文件“WS-Federation-V1-1B.pdf”** 这个PDF文档详细介绍了WS-Federation的版本1.1,包括规范、用例和实现指南。通过阅读这份文档,开发者能够深入理解WS-Federation的工作原理,从而在实际项目中有效应用。 总之...
跟踪和解码所有SAML,WS联合身份验证和OAuth 2.0(OIDC)消息 rcFederation跟踪程序跟踪SAML,WS-Federation和OAuth(OIDC)消息。 在浏览时,跟踪程序将收集所有联盟消息,以供您调查。 消息按出现的顺序显示在概览...
其他配置文件可能包括WS-Federation、Browser/POST等,满足不同应用场景的需求。 4. **元数据(Metadata)** SAML2.0的元数据提供了关于参与SAML交互实体的信息,如身份提供者(Identity Provider, IdP)、服务提供...
开发者可能会使用PowerShell脚本来设置IIS(Internet Information Services)服务器,配置应用程序的Web.config文件,或者执行其他与WS-Federation和SAML2设置相关的任务。 在文件名"asp-net-mvc4-sso-master"中,...
POST绑定加密的断言SAML单一注销服务签名(SHA1或SHA256) HTTP-POST绑定响应请求的HTTP-POST或HTTP重定向绑定SAML元数据使用IdP元数据自动配置发布SP元数据支持以下WS-Federation功能: 安全令牌服务响应使用公钥...
因为:首先Azure Active Directory提供了OAuth2.0、OpenId Connect 1.0、SAML和WS-Federation 1.2标准协议接口;其次微软在ASP.NET 5中移植了集成OpenId Connect的OWIN中间件。所以,只要在ASP.NET 5项目中引用”...
欢迎使用Apache CXF Fediz! Fediz通过将安全实施委派给基础应用程序服务器来帮助您保护Web应用程序。 使用Fediz,身份验证从Web应用程序...SAML 1.1/2.0 Tokens Custom token support Publish WS-Federation Metada
- **WS-Federation**:定义了一组扩展Web服务规范,支持不同系统之间的身份联合。 这些标准的支持使得OpenSSO能够创建一个既易于使用又与现有企业系统兼容的身份联合框架和认证共享机制。 #### 三、Salesforce简介...
它支持各种身份验证协议,例如SAML 2.0 Web SSO,OpenID,OAuth 2.0 / 1.0a,OpenID Connect和WS-Federation Passive。 它通过XACML 2.0 / 3.0支持基于角色的授权和精细授权,而SCIM支持入站/出站置备。 这基于...