签名属性文件outsecurity_sig.properties指定了密钥存储的位置、口令、和签名者的别名：

org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=keystorePass
org.apache.ws.security.crypto.merlin.alias.password=client344Password
org.apache.ws.security.crypto.merlin.keystore.alias=client-344-839
org.apache.ws.security.crypto.merlin.file=com/dev/ws/client/driver/clientStore.jks

通过可用的签名运行计算器的例子会产生如下的SOAP消息：

＜soap:Envelope ...＞
＜soap:Header＞
＜wsse:Security ...＞
＜ds:Signature ...＞
...
＜ds:SignatureValue ...＞
Jx/wbsqjTsNZha+JDTCeCtNzUlaXAzWUOjyRCTQE6OQhiwQOpCt0gOd4mxsb5mI9Hrtr+0lSIZOJ
dOHBKTqcCQNmQneM8CI/oeo0RwLSaMXh2fIA+/mZt+EBcS9+WB9Vdv4AnCWYr4/feAxJkioZwzXt
9NquZMnC1nhRTMOoFpM=
＜/ds:SignatureValue＞
...
＜/ds:Signature＞
＜/wsse:Security＞
＜/soap:Header＞
＜soap:Body ...＞
...
＜/soap:Body＞
＜soap:Envelope＞

注意SOAP的头部现在包括了一个SignatureValue成分，该成分包含着签名。服务器使用这个签名来验证SOAP消息的真实性。

基于签名的身份验证是一种用于保障服务安全性的有效方法，这些服务的客户是其它服务器和设备。签名还满足了应用程序对安全性的需要，这些应用程序需要每一项服务处理身份验证的合法证据。管理客户端和服务器证书的需要增加了总体的可维护性，而且必须在规划阶段就加以考虑。你应该清楚，这种方案并没有涉及到J2EE验证模式，因此它仅限于处理身份验证的需要。

影响你选择安全方案的主要因素

本文讨论了一些最流行的Web服务安全解决方案，并提供了一些例子用以具体展示其使用方法。本文根据影响你应用程序安全问题的因素评估了每一种方案。下面我们给出在你需要做出决策时应该考虑的主要因素：

保密性和完整性：你需要决定到底你的消息的哪些部分需要保密和完整。消息级的安全（MLS）支持精细的安全性，而SSL以增加性能上的负担为代价可以保障整个消息的安全。

会话状态：如果服务客户不需要保持状态，那么一种简单的身份验证方案，如UsernameToken也就足够了。如果需要保持状态的话，就应该考虑其它的方案，如Kerberos。

拓扑：服务通信可以是点到点的，也可以是涉及到网关等仲裁者的端到端的拓扑。SSL仅支持点到点的结构，而MLS两种都支持。

基础结构：应用程序服务器提供了对WS-*安全性不同程度的支持。因此，你的应用程序服务器支持会影响你对安全方案的选择。

身份验证：应用程序需要各种各样的身份验证，其中包括基于用户的验证、基于签名的验证和联合验证。你需要决定哪一种身份验证模式最适合你的安全性需要。

客户端类型：互联网（Internet）客户端与Intranet(企业内部网)客户端相比，一般都有不同的安全限制。在考虑一个安全方案时，你应该考虑它对你的客户端部署的影响。

性能：安全性往往对应用程序的性能都有负面的影响。SSL比起基于MLS（消息级别的安全）的方案要容易实施，但它会导致更高的性能的损失。

复杂性：在选择一个方案时，复杂性是一个容易被忽略的、可能会对项目有害的因素。MLS可比SSL提供更好的性能，不过，它要以增加开发的复杂性为代价。