WS-Security在已建立的用于加密和XML加密和签名的行业标准的基础上，为Web服务应用程序提供了一套全面的安全功能。 您可以使用WS-Policy和WS-SecurityPolicy指定要用于特定应用程序的功能，从而允许服务的客户端自动配置自己以访问服务。 跨多个平台和Web服务框架对这些标准的广泛支持，互操作性很好（并且随着时间的推移越来越好）。
尽管有这些好处，WS-Security也有一些缺点。 在本系列的最后两篇文章中，您已经看到WS-Security的配置可能很复杂，并且有时会给正在交换的消息增加很多内容。 那么，什么时候WS-Security的收益才值得呢？ 在本文中，您将更好地了解WS-Security和相关的WS-SecureConversation的运行时成本（就处理开销和增加的批量而言），从而引发了有关如何应用WS-Security的讨论。以对您的应用程序有意义的方式。
看表现
为了衡量不同配置下的应用程序性能，本文采用了在客户端和服务器都在单个系统上运行时对特定请求序列执行时间进行计时的方法。 这种方法有一些缺点-最明显的是，它结合了客户端和服务器的处理开销，因此无法分别评估它们-但具有的优势是，与通过网络运行测试相比，通常产生更一致的结果。 在您自己的硬件和JVM上进行测试也很容易，您可以使用提供的代码来进行测试（请参阅下载 ）。
性能测试应用
用于测试的应用程序是地震数据检索服务。 它基于实际数据库，该数据库在过去几年中发生了全球93,000多次地震。 对服务的请求指定了纬度，经度，日期或震级的查询范围，并且该服务返回按区域和日期顺序分组的所有匹配地震。 整个数据库都保存在内存中，并为快速处理请求编制了索引，因此每个请求的几乎所有处理时间都花在了实际的Web服务处理代码（包括与XML相互转换的数据绑定代码）中。
清单1显示了对服务的示例请求，后跟响应（经过重新格式化以适合页面宽度）：
清单1.示例请求和响应
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:matchQuakes xmlns:ns1="http://ws.sosnoski.com/seismic/types">
<ns1:min-date>2001-08-08T16:31:05.752+00:00</ns1:min-date>
<ns1:max-date>2001-08-14T23:51:31.499+00:00</ns1:max-date>
<ns1:min-long>160.4685</ns1:min-long>
<ns1:max-long>178.19693</ns1:max-long>
<ns1:min-lat>-42.423557</ns1:min-lat>
<ns1:max-lat>-30.44976</ns1:max-lat>
</ns1:matchQuakes>
</soapenv:Body>
</soapenv:Envelope>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:results xmlns:ns1="http://ws.sosnoski.com/seismic/types" count="9">
<ns1:result-set>
<ns1:area-name>New Zealand Region</ns1:area-name>
<ns1:regions count="0">
<ns1:region ident="rgn159" index="159">NORTH ISLAND,
NEW ZEALAND</ns1:region>
<ns1:region ident="rgn160" index="160">OFF E. COAST OF N. ISLAND,
N.Z.</ns1:region>
</ns1:regions>
<ns1:quakes count="9">
<ns1:quake time="2001-08-11T09:52:54.000+00:00" millis="1000"
latitude="-37.6499" longitude="177.74" depth="83.0" magnitude="4.4"
method="ML" region="rgn160"/>
<ns1:quake time="2001-08-11T09:52:55.000+00:00" millis="0"
latitude="-37.71" longitude="177.77" depth="70.0" magnitude="4.5"
method="ML" region="rgn160"/>
<ns1:quake time="2001-08-11T15:02:47.000+00:00" millis="5600"
latitude="-38.0429" longitude="175.632" depth="299.8" magnitude="4.6"
method="ML" region="rgn159"/>
<ns1:quake time="2001-08-12T07:42:41.000+00:00" millis="7000"
latitude="-37.97" longitude="175.97" depth="289.0" magnitude="4.3"
method="MB" region="rgn159"/>
<ns1:quake time="2001-08-12T22:37:58.000+00:00" millis="5600"
latitude="-38.3839" longitude="176.121" depth="163.2" magnitude="4.0"
method="ML" region="rgn159"/>
<ns1:quake time="2001-08-12T23:25:09.000+00:00" millis="6700"
latitude="-39.9559" longitude="176.115" depth="76.0" magnitude="4.0"
method="ML" region="rgn159"/>
<ns1:quake time="2001-08-13T05:10:07.000+00:00" millis="4300"
latitude="-37.5859" longitude="176.651" depth="189.0" magnitude="4.3"
method="ML" region="rgn159"/>
<ns1:quake time="2001-08-14T02:43:18.000+00:00" millis="2900"
latitude="-38.3699" longitude="175.902" depth="193.4" magnitude="4.5"
method="ML" region="rgn159"/>
<ns1:quake time="2001-08-14T18:02:35.000+00:00" millis="5400"
latitude="-37.8159" longitude="176.375" depth="193.3" magnitude="4.5"
method="ML" region="rgn159"/>
</ns1:quakes>
</ns1:result-set>
</ns1:results>
</soapenv:Body>
</soapenv:Envelope>在测试中，客户端生成伪随机的一系列请求，并调整查询范围以覆盖全部地震的一部分。 每次使用相同的输入参数运行客户端时，都会生成相同的请求序列，从而可以测试不同的Web服务配置。 通过更改客户端的输入参数（从而更改用于请求的查询范围），可以轻松测试不同结果消息的大小。
WS-安全性能
本文显示的测试结果基于两个请求序列。 第一个序列使用1,000个请求，并调整了查询参数，因此每个查询仅匹配整个地震数据库的一小部分（对于1,000个请求，仅返回816个匹配的地震）。 第二组使用100个请求，将其调整为与数据库的较大部分匹配（对于100个请求，返回176,745个匹配地震）。 每个请求序列在不同的安全配置中运行了多次，结果中仅保留了每种配置的最佳时间。
该测试在使用Sun Java 1.6.0_13 32位JVM的Mandriva 2009.1 64位Linux®系统上运行，该系统具有Athlon X2 5400+处理器和4GB RAM。 服务器代码在Tomcat 6.0.20上运行，配置为使用1,024MB的堆，而客户端代码使用512MB的堆。 使用了Axis2版本1.5，以及当前的Rampart代码版本。 （截至测试时，尚无与Axis2 1.5代码匹配的Rampart实际版本可用。）令人惊讶的是，Tomcat上1,024MB的堆对于运行完整的测试集是必要的（每个测试都使用单独的Web服务应用程序）安全配置）； 当最初使用256MB的堆进行测试时，WS-Security测试有时会失败，或者出现没有道理的奇怪错误（例如，当不存在DTD时，“ SOAP消息不得包含文档类型声明（DTD）”）或java.lang.OutOfMemoryError 。
使用以下每个安全配置来运行测试：
- 普通 ：没有安全性
- ssl ：用于连接服务器的HTTPS
- username ：请求中的WS-Security纯文本
UsernameToken - sign ：带有时间戳的正文和标题的WS-Security签名
- encr ：主体的WS-Security加密
- signencr ：正文和标头的WS-Security签名，带有时间戳和正文加密
实际测试时间从普通配置的4秒到signencr配置的55秒不等。 图1显示了相对测试时间，将其标准化为普通配置时间的倍数，以便于比较：
图1.测试时间比较
从图1中可以看到，安全套接字层（SSL）（现在从技术上讲是传输层安全性（TLS），但在本文中使用了较旧的缩写词是为了表示熟悉程度），加密提供的性能几乎与不安全的情况相同（尽管大消息的情况比小消息的情况要好，小消息的情况要长80％，大消息的情况要长20％）。 另一方面，使用WS-Security会导致性能大幅下降。 仅在请求消息上添加简单的UsernameToken标头会导致性能下降到与小消息情况下的SSL大约相同的水平，并且比大消息情况下的SSL 慢几倍。 在结合签名和加密的情况下，测试时间比不安全的情况长2100％。
WS-Security造成此性能下降的部分原因是Rampart处理程序实现中的一个缺陷，该缺陷导致它在使用Rampart的任何时间都将每个请求和响应消息转换为文档对象模型（DOM）（即使没有进行任何安全处理）为消息完成）。 应该及时解决此特定问题，以使Rampart 1.5版本与Axis2 1.5一起发布。 根据修补程序的实现方式，它可能会大大缩短UsernameToken测试的时间。 但是，即使对此问题进行修复，也可能不会影响其他WS-Security时间。
其余WS-Security性能下降的原因是XML签名和XML加密的操作方式结合在一起，以及用于WS-Security和这些XML标准的实现的库。 您可能还记得“ Axis2 WS-Security签名和加密 ”中提到的，对XML消息进行签名需要一个名为canonicalization的步骤，该步骤在计算签名值之前将XML转换为特定的规范形式。 该标准要求执行此步骤，因为即使在XML被解析器分离并重新生成后，仍决定保留签名。 尽管这无疑是XML签名的有用特性，但它增加了处理的大量开销。 部分原因是使用DOM模型最容易实现规范化，因此所有XML安全性库都可以与XML的DOM表示一起使用。 （这就是为什么Rampart处理程序当前甚至在服务或客户机上使用时都会生成DOM的原因，并假设仍然需要DOM。）仅将数据转换为DOM表示的步骤会导致大量WS -安全性开销，如您从UsernameToken时间看到的那样。 对于较大的响应消息，此开销似乎与实际的签名或加密处理相当（在图1中，通过比较用户名情况下的红条看到— 图1中，DOM的创建是唯一主要的开销-用于签名和加密的情况（在创建DOM之后进行实际的加密处理）。
除DOM问题外，许多WS-Security开销是生成摘要和加密数据的计算密集型工作。 无论使用哪种实现方法，这部分工作都是必需的，因此可以对WS-Security处理时间进行多少改进是有限制的。 本系列的后续文章将比较其他使用Axis2 / Rampart的WS-Security实现的性能-但是大多数此类都使用相同的底层库，因此不要期望会有任何大的差异。
WS-SecureConversation
WS-SecureConversation是一个基于WS-Security和WS-Trust标准的标准，以支持涉及多个消息的安全交换。 因为它使用上下文进行正在进行的消息交换，所以WS-SecureConversation可能比WS-Security更有效。 Rampart发行版包含一个名为rahas的单独模块，该模块可发行WS-SecureConversation所需的安全令牌。 它还包括使用WS-SecureConversation的策略配置的示例（samples / policy / sample04），这是与性能测试应用程序一起使用的策略的基础。
WS-SecureConversation策略（未在此处显示，但在下载中显示为secureconversation-policy-client.xml）包括一个<sp:SecureConversationToken>元素，该元素详细说明将哪种类型的安全令牌用于消息交换并提供安全选项应用于令牌交换消息。 这些令牌交换消息使用rahas模块实现的操作在客户端和服务之间的常规消息交换上进行搭载-因此，当使用WS-SecureConversation时，您会看到客户端和客户端之间偶尔会出现请求-响应消息对。服务器，如清单2所示。 通过使用策略配置的不同安全选项以及使用特殊的http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT ，可以将这些添加的令牌交换消息与应用程序消息区分开来http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT请求和http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT响应操作代码，两者均由WS-SecureConversation定义。
清单2.示例请求和响应
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<soapenv:Header xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsse:Security xmlns:wsse="http://...-wss-wssecurity-secext-1.0.xsd"
soapenv:mustUnderstand="1">
...
</wsse:Security>
<wsa:To
>http://localhost:8800/axis2/services/seismic-secureconversation</wsa:To>
<wsa:ReplyTo>
<wsa:Address
>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:MessageID>urn:uuid:5EA8E8F04EBA73255B1246409570148</wsa:MessageID>
<wsa:Action>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT</wsa:Action>
</soapenv:Header>
<soapenv:Body xmlns:wsu="http://...-wss-wssecurity-utility-1.0.xsd"
wsu:Id="Id-30222347">
<xenc:EncryptedData ...>
...
</xenc:EncryptedData>
</soapenv:Body>
</soapenv:Envelope>
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsse:Security xmlns:wsse="http://...-wss-wssecurity-secext-1.0.xsd"
soapenv:mustUnderstand="1">
...
</wsse:Security>
<wsa:To
>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To>
<wsa:MessageID>urn:uuid:1BCDE6BE423F5FDE791246409571325</wsa:MessageID>
<wsa:Action
>http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT</wsa:Action>
<wsa:RelatesTo>urn:uuid:5EA8E8F04EBA73255B1246409570148</wsa:RelatesTo>
</soapenv:Header>
<soapenv:Body xmlns:wsu="http://...-wss-wssecurity-utility-1.0.xsd"
wsu:Id="Id-5148380">
<xenc:EncryptedData ...>
...
</xenc:EncryptedData>
</soapenv:Body>
</soapenv:Envelope>为了将性能与使用证书的常规WS-Security进行比较，将WS-SecureConversation配置设置为仅将会话令牌用于加密消息正文。 图2显示了所得测试时间与普通和encr测试配置的比较方式，并再次将其标准化为普通配置时间的倍数，以便于比较：
图2. WS-SecureConversation时间比较
正如您在图2中看到的那样，与WS-Security相比，WS-SecureConversation加密确实提供了显着的性能改进。 对于较小的消息尤其如此，因为对于这些消息，WS-SecureConversation配置几乎是使用证书的WS-Security加密速度的两倍。 对于较大的消息，性能优势并不明显，但是在这种情况下，WS-SecureConversation的速度仍然要快18％。
邮件大小比较
正如您在本系列以前的文章中已经看到的那样，WS-Security可以为SOAP消息头添加大量内容。 当数据通过网络在客户端和服务器之间发送时，这种增加的批量可能会对性能产生重大影响（与本文运行的性能测试不同，客户端和服务器在同一系统上运行）。 客户端和服务器之间网络连接的质量决定了此增加的大小对性能有多大影响，但是显然，消息越大，它们交换的速度就越慢。
图3显示了不同测试用例中代表消息的实际大小，并再次将其标准化为普通配置结果的倍数，以便于比较：
图3.消息大小比较
如您所料，用户名配置只会增加请求消息的大小，因为UsernameToken仅出现在请求消息中。 其他所有安全配置都增加了请求和响应消息的大小。 再次如您所愿，WS-Security添加的大量内容对于较小的请求和响应消息而言更为重要。 对于每种配置，WS-Security标头的大小基本上是一个常数，因此，当原始消息大小较小时，常数大小的增加将具有更为显着的效果。 使用加密时，会从用于加密数据的base64编码中产生单独的填充效果。
何时使用WS-Security
既然您已经看到了WS-Security对处理时间和消息大小的影响，您可能想知道何时值得花这笔钱。 简短的答案是：SSL更简单的替代方法不起作用时。 在本节的其余部分，您将获得一些指导原则，以帮助您确定您的需求是可以由SSL满足还是需要WS-Security的全功能解决方案，并且您还将获得一些建议，以最大程度地减少所涉及的开销当你使用WS-Security。
保守秘密
保持机密性是安全性的最重要方面之一。 WS-Security通常使用基于数字证书包装的公钥来使用XML加密来使消息内容对除预期的接收者以外的所有对象保密。 加密可以应用于整个消息或选定的部分，甚至可以使用多层加密来控制涉及多个系统的消息交换中的每个参与者可以访问哪些信息。
WS-Security的一个示例用例是一个在线购买系统，在该系统中，客户端连接到商家系统以下订单，但是在下单之前，需要由银行系统确认付款（例如，通过信用卡）处理。 如果商人系统能够以未加密的形式访问信用卡信息，则将产生一种基于浏览器的购物网站所特有的安全风险：信用卡号码通常最终存储在安全性低下的数据库中，容易受到黑客的攻击。 使用WS-Security，可以以加密形式发送信用卡信息，该信息只能由发出付款确认的银行系统解密。
但是对于许多应用程序而言，WS-Security和XML Encryption在保护机密性方面是过大的。 如果客户直接与您的服务联系（而不是通过其他服务器间接与您联系）并直接执行所有必要的处理，则只需使用SSL（HTTPS）连接进行访问即可提供出色的机密性保证，而性能成本要比WS-安全。 但是，此方法仅适用于直接客户端连接。 否则，如果该服务需要将信息传递给其他服务，那么您将回到与易受攻击的在线购物网站一样的情况，在这些网站上，您使用安全连接将信用卡信息传递到购物网站，但无法保证信息将由站点服务器保持安全。
维护数据完整性
数据完整性与机密性相似。 WS-Security使用XML签名来确保数据在传输过程中未被篡改，因为任何篡改都会使签名无效。 与XML加密一样，可以将签名应用于整个消息或选定的部分，并且可以使用多层签名来保证参与者在涉及多个系统的消息交换中处理的数据的完整性。
假设的在线购买系统也为数据完整性提供了一个很好的例子。 使用WS-Security，客户可以签署要发送到银行系统的付款指令，从而防止商人系统中间商对预期的付款金额进行任何修改。 由于付款金额是由客户签名的，因此无需进行加密，从而使商家系统在将付款金额提交给银行系统之前确认付款金额正确。
同样，如果客户端直接联系您的服务并在内部执行所有必要的处理，则WS-Security和XML Signature可能会过高。 SSL连接不仅可以保护数据机密性，还可以防止传输中的数据被修改，而且只能在单个客户端和服务器之间进行。 如果服务器将数据传递到其他系统，则这些系统不能保证服务器未修改数据。
保证真实性
真实性是WS-Security提供SSL所无法比拟的功能的一个领域，即使对于客户端和服务器之间的直接连接也是如此。 使用WS-Security和XML签名对消息进行签名可以为您提供一个文档，该文档不仅可以在接收和处理时被验证为真实，而且还可以存储以用于审核目的，同时保证真实性。
在这方面，最好的SSL措施是在建立客户端与服务器之间的连接时要求客户端证书作为身份证明。 但是，这提供了比消息的数字签名弱得多的真实性保证。 您无法轻易地将客户端和服务器之间交换的整个数据流作为SSL连接的一部分进行存储，因此，即使您在建立该连接时验证了客户端证书，也无法稍后再返回以证明此步骤正确无误。处理。
再次回到在线购买系统的例子，在支付指令上的客户签名将允许银行系统保留该指令，并在以后对交易有任何争议时提供。 这将使银行系统能够证明付款已被客户授权，从而使自己免受任何责任。
超越基础
除了机密性，完整性和真实性的基础知识之外，WS-Security还提供了许多其他功能来满足特殊的安全性要求。 例如， UsernameToken是一个简单的功能，它提供了将基本用户身份验证传达给服务的标准化方法。 其他WS-Security功能允许将安全断言标记语言（SAML）授权令牌和其他形式的与安全相关的信息添加到SOAP消息交换中。 如果您需要在Web服务中使用这种类型的安全性信息，则可能需要使用WS-Security支持来传输信息，因为它定义了标准格式和过程，这些标准格式和过程可能比您可以实现的标准格式和过程更健壮。你自己。
降低WS-Security的成本
如果要使用WS-Security，则从本文的测试结果中可以看到性能可能是一个问题。 但是，在出现恐慌之前，请停止考虑服务的数据量。 在同时使用WS-Security进行加密和签名时，将服务的性能降低22倍是一个令人恐惧的前景-但是，如果您的服务每小时仅交换几条消息，那么就硬件需求而言，差异将是微不足道的。
如果性能是一个值得关注的问题，则可以通过明智地使用安全性选项来帮助最大程度地降低WS-Security对性能的影响。 某些Web服务框架倾向于生成“上述所有”安全配置，其中消息使用WS-Security进行了完全签名和加密， 并通过SSL连接发送。 如果您确实想要最大程度的保护并且不关心性能，那很好，但是在大多数情况下，使用SSL（如果您只考虑保护客户端和单个服务器之间传输的信息）更有意义。 WS-Security加密（如果您需要跨多个服务器传送数据，同时在通过中介机构时保持机密性）。
与使用证书的WS-Security相比，您还可以使用WS-SecureConversation在客户端和服务器（甚至是通过中介访问的服务器）之间进行长时间的消息交换，从而获得相对适度但可观的性能提升。 WS-SecureConversation在交换相对较小的消息时效果特别好，与消息正文的实际（对称）加密相比，证书和非对称加密的额外开销可能很大。
降低WS-Security性能成本的另一种方法是将安全性处理工作转移到专用硬件上。 一些XML网关设备提供了WS-Security加密和签名的加速处理。 您可以在应用程序中使用纯SOAP时使用这些设备来处理繁重的WS-Security处理。 您显然需要确保在将设备添加到服务器中时不会出现任何潜在的安全漏洞。 购买前，您应该测试设备的性能提升。 但是至少从理论上讲，这种类型的布置可以带来一些实际的性能提升。
Wrapping up
WS-Security的性能成本可能很高，有时简单的SSL点对点加密可能是更好的解决方案。 但是对于许多类型的应用程序来说，SSL是不够的。 在这些情况下，需要WS-Security（或其后代，WS-SecureConversation），而性能成本只是必要的支出。 在本文中，您已经了解了WS-Security的成本，并了解了一些指导原则以帮助您确定WS-Security是否适合您的应用程序。
在本系列的下一篇文章中，您将进一步了解WS-Security，这次演示了如何使用WS-SecurityPolicy对Web服务应用程序中的各个操作所使用的WS-Security功能进行精细控制。 在操作级别控制WS-Security是另一种可以（至少潜在地）减少WS-Security开销的技术，因此，在该系列转向其他主题之前，它是本文的重要后续文章。
翻译自: https://www.ibm.com/developerworks/java/library/j-jws6/index.html
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
