SOA目前普遍采用Web Services作为其实现技术，因为Web Service具有松耦合的特性，而这点对于SOA试图解决的问题显得尤为重要。服务的可发现性，平台无关性，接口的自描述性等特点赋予了Web Service这一特性。正是因为这一特性，Web Service被广泛的用于企业信息集成，其中既包括了企业内部的信息集成(不同部门的信息集成，遗留系统与新系统的信息集成)，也包括了企业与企业之间的信息集成。同样也是因为它，使得通过服务与服务的组合而构成新的应用变得更加简单，也更加可行，这也是SOA中广泛使用Web Service的原因。
在考虑企业应用的时候，一个不得不关注的问题就是安全。而Web Service的诸多优点反而使得安全问题变得比以往任何时候都更具挑战性。由于Web Service被广泛的运用于企业间的交互，使得安全边界由Intranet扩大到了Internet，安全的风险也自然大大增加；SOA中服务组合的思想，使得Web Service应用更具动态性，服务的创建者往往无法预料到服务将在何种环境下(比如使用何种安全认证方式)被使用，在这种情况下要想实现服务的安全访问变的更加复杂；同时由于Web Service使用的是基于XML的，具有自描述能力的消息(在面向消息的方式中，消息甚至就是业务实体)进行通讯，那么如何保证消息的安全性也成为了Web Service安全中需要重视的问题。
在我们考虑安全问题的时候，有三个概念是最为基础的： 机密性（Confidentiality）、 完整性（Integrity）、 身份鉴别（Authentication）。
机密性：除了指定的接受者，其他人无法查看消息的内容。通常会使用密钥（对称或非对称）对消息加密，从而保证消息的机密性。
完整性：确保消息在传输的过程中没有被修改。即保证消息的接收者接收到的消息与消息发送者最初发送的消息完全一致。通常会对消息做摘要(Digest)，再使用密钥（对称，非对称）加密摘要，从而保证消息的完整性。
身份鉴别：确保消息发送者的身份与消息中所声称的用户身份一致。最简单的做法就是让用户同时发送用户名和密码，服务方确认密码的有效性从而判断该用户身份是否与用户名所代表的一致。然而在实际的应用中的做法通常不会如此简单，此时往往会使用密钥对一段信息加密，服务方通过解密此信息确认用户的身份。例如在Kerberos协议中，会使用对称密钥加密用户身份信息，加密后的信息称为Authenticator，服务方通过解密此消息获得发送者的身份声明，再将其与票据（Kerberos Ticket）中的身份声明相比较，从而确认消息发送者身份。同理，经过私钥加密的消息摘要(即数字签名)也可以用于消息发送方的身份鉴别。
Web Service已经被广泛的采用，那么现在Web Service的安全问题是如何处理?在没有运用WS-Security之前，主要是通过Https提供的运输层的安全来确保的运行在此之上Web Service的安全的。
从之前对安全技术的介绍可以看出，要想实现Web Service的安全，最重要的就是让服务请求方和服务提供方能够共享一个秘密(对称密钥). 有了对称密钥就可以用它加密，从而保证消息的机密性(Confidentiality), 也可以利用它来加密摘要从而保证消息的Integrity，并用于身份鉴别，这点从Kerberos和SSL协议中都可以看出。在Kerberos协议中，我们通过引入一个第三方(KDC)来实现密钥的发布。初始时Service Requestor(R)和KDC(K)之间享有一个密钥，KDC(K)和Service Provider(P)之间享有一个密钥。而后K产生R和P之间的session key, 分别通过它和R和P的密钥加密后传给它们，这样R和P各自解密后之间就安全的拥有了他们共同的密钥(K产生的session key)。而SSL则是利用PKI的公钥技术来实现密钥的传递，R先向P打声招呼，然后P把自己的证书(Certificate: 包含用户名和该用户的公钥，并由CA签名)发送给R。R产生他们之间的密钥，然后用证书中P的公钥将密钥加密后传递给P，这样R和P之间就安全的拥有了一个密钥。Https对Web Service安全的保障就是通过这个密钥来实现了(最常被用于加密的就是我们的密码)。看上去SSL似乎显得比较简单，不过这是基于PKI才得以实现的，而PKI却是一个很复杂的安全基础设施。而Kerberos由于初始时的前提条件，使得它的应用往往局限于某个组织内部的网络。
在当前大多数的应用中，Web Services技术通常采用Https传输协议保障安全，但是该方法存在很多缺点，已无法满足现在越来越复杂的Web Services安全需求。
1. Https提供的是点对点安全保护，而Web Services应用的一个特点就是消息往往就要经过多个中介才能到达最终的服务提供方，每个中介都有可能对消息做出些处理，也就是说它需要的是端到端的保护。这显然是Https所不能提供的。
2. Https是在传输层提供安全保障的，而不是在消息层面，也就是说消息只有在传输过程中才是安全的(加密的)，而一旦到达了终点后就不再安全了。例如恶意攻击者可以从消息队列中将重要的信息窃取出来。
3. Https分配好共享密钥后，传递消息的时候并没有使用数字签名技术，此时传递的消息也就无法获得抗否认性的能力。而这一项功能恰恰是在电子商务中不可豁缺的。
4. 由于Https提供的是传输层的安全，当然也就不可能达到消息安全所需要的灵活性的要求。例如加密消息中的部分元素；使用不同的密钥加密消息的不同部分，从而让不同的消息接收者查看与之对应的信息。
因此，为了适应当前Web Services环境下对安全的特殊需求，IBM和Microsoft等公司共同制定了WS-Security规范。为了解决之前所提到的三个方面的安全问题：机密性、完整性、身份鉴别，在Web Services使用SOAP（XML 格式）作为消息封装协议的背景下，标准化组织分别制定了XML Encryption、XML Digital Signature、与SAML(XML格式的Security Token)三套规范，WS-Security则是规定了如何将以上规范组合起来以满足Web Services安全需求的一套规范。
参考资料:
<<Securing Web Services with WS-Security>>
<<Web Service Security Scenarios, Patterns, and Implementation Guidance
for Web Services Enhancements (WSE) 3.0>>
推荐资料:
性能比较：安全性设计选择
系列文章
