为什么 Web 服务安全需要单独的标准？
如果有 ssl 通信来实现此目的，为什么需要 WS 安全性来提供令牌、签名等？ WS 安全性如何提供 ssl 无法提供的完整性、保密性和真实性？简单说明为什么使用 WS 安全性（如果可能，您能提供任何示例）
如果 paypal 的业务合作伙伴在其网站中使用 paypal 的 Web 服务。如果该 Web 服务是询问其客户的用户名和密码，PayPal 如何保护客户的数据？业务合作伙伴？客户、PayPal 及其业务合作伙伴之间如何进行 SOAP 交易？请您解释一下 WS 安全概念（提供完整性、机密性、真实性） ） 在这种情况下？
Why WS security is needed to provide tokens,signatures etc if there are ssl communication to achieve this purpose? How can WS security used to provide integrity,confidentiality and authenticity that ssl can't provide?simply why ws secuirty(If possible can you provide any example)
If business partner of paypal using paypal's web service in its website.If that web service is asking for username and password of its customer,how paypal can protect customers data from there Business partners?How soap transaction can take place between customers,paypal and its business patners?plz can you explain how WS security concepts ( provide integrity, confidentiality,authenticity) in this case?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
主要区别在于 HTTP 相关的安全机制保护 Web 服务的传输层，而 WS 安全性则解决更高级别的抽象。
同样，您可能还拥有较高级别（例如：仅加密 Web 服务中的特定密码字段）或较低级别（例如 VPN）的安全解决方案。
不同的场景将需要不同层的不同安全措施
一些示例：
Web 服务不限于 HTTP 传输 - 您的环境可能包括其他传输（例如使用 JMS、MSMQ 等的消息传递）。在 Web 服务层（而不是传输层）设置安全性将允许您在整个环境中使用通用机制。
另一个问题是，当您在 Web 服务堆栈中走得更高时，http 级别的安全信息就会被“剥离”——例如，在许多地方您不会直接访问服务提供商，而是通过中央 ESB（企业服务总线）访问。 ESB 充当服务的中央枢纽，还可以执行日志记录、路由、发布到多个服务端点等任务。
使用 ESB 时，http 连接在 ESB 处断开，并且服务会获取源自 ESB 的新 http 连接 - 因此 http 安全机制无法提供端到端安全性。
然而，即使消息通过 ESB 路由，WS 安全信息也可以保留您
在上一条评论中描述的内容似乎与之前的答案无关
您的意思是他们有像 OpenID 或 kerberos 这样的机制，您可以在其中使用您的凭据从一个站点访问另一站点？
这并不是特定于 Web 服务的，并且有各种现有协议可以做到这一点（我的猜测是它们使用现有协议）。当然，可以使用 WS 安全标准开发类似的机制。
例如，kerberos 协议的工作原理如下：
1. 用户向安全服务器进行认证
2. 安全服务器回复一条签名消息（称为票证），表示“用户 123 已通过身份验证”
3. 用户使用此消息向第二站点证明他确实是用户123，而不需要第二站点实际获取他的用户名密码。
该协议基于加密和加密签名 - 两者均可使用 WS 安全性。
The main difference is that HTTP related security mechanisms secure the transport layer of the web service, and WS security addresses a higher level of abstraction.
similarly, you may have also security solutions in higher (for example: encrypt just a specific password field in a web service) or lower levels (like VPN)
Different scenarios will require different security measures in different layers
Some examples:
Web Services are not limited to HTTP transport - your environment may include other transports (like messaging using JMS, MSMQ, etc). setting up security at the Web Services layer (rather then the transport layer) will allow you to use a common mechanism for the whole environment.
Another issue is that http level security information is "pealed" as you go higher in the Web Services Stack - for example, in many places you wont be accessing the service provider directly, but through a central ESB (Enterprise Service Bus). the ESB acts as a central hub for services, and may also perform tasks such as logging, routing, publishing to multiple service endpoints, etc.
When using an ESB the http connection is broken at the ESB, and the service gets a new http connection originating from the ESB - thus http security mechanisms cannot offer end-to-end security.
WS Security information however can be preserved even if the messages are routed through an ESB
What you describe in you last comment appears to be not related to the previous answer
Do you mean they have a mechanism like OpenID or kerberos, where you can use your credentials from one site to access a different site?
This isn't specific to web services, and there are various existing protocols to do it (my guess is that they use an existing protocol). Of course a similar mechanism can be developed using WS Security standards.
The kerberos protocol for example works like this:
1. The user authenticates to the security server
2. the security server replies with a signed message (called ticket) saying "the user 123 has been authenticated"
3. The user uses this message to prove that he is indeed user 123 to the 2nd site, without the need for the 2nd site to actually get his username password.
This protocol is based on encryption and cryptographic signatures - both are available using WS security.
SSL (TLS) 安全性将保护用户免遭窃听。但它不会保护您（您的网站）免受恶意用户的侵害。您仍然容易受到缓冲区溢出、SQL 注入等问题的影响。
SSL (TLS) security will protect the user from eavesdropping. But it won't protect you (your site) from malicious users. You're still vulnerable to buffer overflows, SQL injection and so on.
有关一个很好的示例，请观看 Samy Kamkar 在 Defcon 上发表的“我如何遇见你的女朋友”演讲（较短）和Blackhat（较长）。 Samy 解释了如何利用 Web 应用程序漏洞侵入使用 SSL 的某人的帐户（在本例中为 Facebook）。
For a great example watch the "How I met your girlfriend" talks by Samy Kamkar at Defcon (shorter) and at Blackhat (longer). Samy explains using web application vulnerabilities to breaking into an account (in this case it's Facebook) of someone who uses SSL.
SSL 和 WS-Security 之间的主要区别在于，SSL 是传输级别，而 WS-Security 是消息级别...换句话说，当您使用 SSL 时 - 一旦消息离开传输通道 - 它就不安全。但通过 WS-Security，消息仍将受到保护，并且消息安全性独立于传输通道。
使用 WS-Security、
加密/WS-Security]
纯 SSL 提供身份验证/机密性和完整性 - 但不提供不可否认性。
2-legged OAuth 是支持 SSL 不可否认性的标准。
谢谢...
The main difference between SSL and WS-Security is, SSL is transport level but WS-Security is message level... In other words when you use SSL - as soon as the message left the transport channel - its not secured. But with WS-Security message will be still secured and message security is independent from the transport channel.
With WS-Security,
Encryption/WS-Security]
Pure SSL provides Authentication/Confidentiality and Integrity - but not Non-repudiation.
2-legged OAuth is a standard to support Non-repudiation over SSL.
Thanks...
WS 或 Web 服务安全性是 SOAP 的扩展，它将安全性应用于不同的 Web 服务。 Ws-Security 使用 XML 签名和加密来提供端到端安全性。该协议的主要重点是指定如何在 Web 上的用户和服务提供商（例如 Paypal）之间的消息交换中强制执行完整性和机密性。该服务还允许不同安全令牌格式的通信，如 SAML、X.509、Kerberos 等。与主要侧重于提供传输级别安全性的 HTTP 协议不同，WS 安全机制在应用层实现了更高级别的抽象并提供加密的安全解决方案。
由于每个平台的安全需求不同，这两个标准侧重于满足此类安全平台的不同需求。借助这种安全性，端到端安全性、不可否认性、反向代理、传输绑定等都得到了改善。
总的来说，您可以说该服务是为数据交换平台和用户隐私提供更好安全性的另一种方法。还有许多其他服务/软件可以执行相同的任务，例如 TOR（提供用户隐私的完整性）、ScrapeSentry（一项提供安全防范不良机器人流量和垃圾邮件的服务）、Distil Network（另一项用于阻止网络垃圾邮件上的垃圾邮件的服务）然而，每种安全机制的概念都不同，但它们的主要动机是为用户和企业提供持续可靠的安全性。
WS or Web Service Security is an extension of SOAP which applies security to different web services. Ws-Security uses XML signatures and encryption to provide end to end security. Main focus of this protocol is to specify how integrity and confidentiality can be enforced in messages exchanges between user and service provider on web such as Paypal. This service also allows communication of different security token formats like SAML, X.509, Kerberos etc. Unlike HTTP protocol which mainly focuses on providing security at transport level, WS security mechanism implements higher level of abstraction in application layer and provide encrypted security solution.
Since need of security is different on every platforms, these two standards focuses to meet distinguish need of such security platforms. With the help of this security, end to end security, non- repudiation, reverse proxy, transport bindings etc are improved.
In general terms you can say that this service is another method to provide better security to data exchange platforms and user’s privacy. There are many other services/software which does same task like TOR (provides integrity to user privacy), ScrapeSentry (a service which provide security from bad bot traffic and spam), Distil Network (another service to block spam on web spam) etc. However concept of every security mechanism is different but their main motive is to provide constant and reliable security to user as well as businesses.
大家好，
SSL/TLS 技术是一种安全技术技术。其目标是保护用户的信息（信用卡、地址、电话号码...）不被黑客窃取。 SSL 证书将保护网站，每个连接该网站的人都将确保拥有一个安全的环境。
安全质量取决于相关网站上安装的证书类型，无论是 DV（域验证）、OV（组织验证）、EV（扩展验证），以及是否存在 SGC 技术。
如果您有任何其他问题，可以在此处了解更多详细信息。
Good day people,
the SSL/TLS technology is a security technology. Its goal is to protect the user from having his/her information (credit card, address, tel number...) being stolen by a hacker. The SSL certificate will protect the website and each person who connects on the website will be sure to have a secured environment.
The quality of the security depends on the type of certificate installed on the website in question, whether it is DV (Domain Validation), OV (Organization Validation), EV (Extended Validation), if the SGC technology is present or not.
If you have any other questions, you can have more details here.