Web Service Security --- Introduction

Web service目前被SOA所广泛采用。从目前Web Service的应用来看，Web Service技术确实具有某些显著的优点，已成为当前分布式技术的重要代表。

Web Service的一个显著特点就是Loose Coupling。服务的可发现性，平台无关性，接口的自描述性构成了Web Service的这一重要特点。而正是由于这个特点，Web Service被广泛的用于企业信息集成，其中既包括了企业内部的信息集成(不同部门的信息集成，遗留系统与新系统的信息集成)，也包括了企业与企业之间的信息集成。同样也是由于这个特点，使得通过服务与服务的组合而构成新的应用变得更加简单，也更加可行，这也是SOA中广泛使用Web Service的原因。

在考虑企业应用的时候，一个不得不关注的问题就是安全。而Web Service的诸多优点反而使得安全问题变得比以往任何时候都更具挑战性。由于Web Service被广泛的运用于企业间的交互，使得安全边界由Intranet扩大到了Internet，安全的风险也自然大大增加；SOA中服务组合的思想，使得Web Service应用更具动态性，服务的创建者往往无法预料到服务将在何种环境下(比如使用何种安全认证方式)被使用，在这种情况下要想实现服务的安全访问变的更加复杂；同时由于Web Service使用的是基于XML的，具有自描述能力的消息(在面向消息的方式中，消息甚至就是业务实体)进行通讯，那么如何保证消息的安全性也成为了Web Service安全中需要重视的问题。

在我们考虑安全问题的时候，有三个概念是最为基础的：Confidentiality(机密性), Integrity(完整性), Authentication(身份鉴别)。

Confidentiality: 机密性。 除了特定的接受者，别人无法查看消息的内容。使用Key（对称，非对称）来加密消息，从而保证消息的confidentiality。

Integrity: 完整性。 保证消息在传输的过程中没有被修改。即消息的接受者所持有的消息与消息的发送者完全一致。对消息做摘要(Digest)后，再使用Key（对称，非对称）来加密摘要，从而保证消息的Integrity。

Authentication: 身份鉴别。确定消息的发送者的身份与消息中所声称的用户身份一致。最简单的做法就是让用户同时发送用户名和密码，接受方确认密码的有效性从而判断该用户身份是否与用户名所代表的一致。然而在实际的应用中通常没有这么简单，往往使用Key对一段信息加密，接受方解密此信息，从而确认身份。比如在 Kerberos协议中，使用对称密钥加密用户身份信息，加密后的信息称为(Authenticator)，服务方通过解密此消息将身份与Ticket中的身份相比较以确认发送方身份。同样经过私钥(非对称密钥)加密的消息摘要(数字签名)也可以用于消息发送方的身份鉴别。

Note从上面的描述我们可以看到对称，非对称密钥往往同时出现。比如在Confidentiality中，我们可以使用任何一个来加密消息。而在Integrity中，他们也都可以用于加密摘要。那么一个有趣的问题，我们怎么确定使用那个呢？

由于对称密钥的加密解密速度比非对称密钥快很多(大约有1000倍)， 所以在加密消息的时候一般都是使用的对称密钥。但是有一个问题就是对称密钥又如何发布呢？网络上两个没有联系的用户如何建立起一个共享的密钥？这时就需要PKI来帮助我们将这个共享的密钥建立起来---即利用非对称密钥中的公钥来加密那个共享密钥，传递到私钥的拥有方。由此我们得到结论---对称密钥加密普通信息，非对称密钥加密对称密钥。

在Integrity中，使用非对称密钥的私钥加密摘要，得到的东西是一个广为人知的东西—Digital Signature(数字签名). 而使用对称密钥加密摘要得到的是HMAC( Hash message authentication codes)。他们在保证消息完整性的同时，都具有身份鉴别的功能，不过前者还有一个功能---抗否认性，而这点在电子商务中往往是不可豁缺的，所以大家对前者更加熟悉。

最后提醒大家注意，在Confidentiality中，使用非对称密钥方法是用公钥加密，私钥解密，而在Integrity中使用非对称密钥的方法恰恰相反。

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 Service广泛采用Https来保障安全，但是该方法也有很多的缺点，尤其是应用于现在越来越复杂的Web Service安全需求。

1. Https提供的是点对点安全保护，而Web Service的特点就是消息往往就要经过多个中介才能到达最终的服务提供方，每个中介还有可能对消息做出些处理，也就是说它需要的是端到端的保护。这显然是Https所不能提供的。

2. Https是在传输层提供的安全，而不是在消息层面，也就是只有在传输的过程中才有消息才是安全的(加密的)，而一旦到达了终点就是明文的了。比如可以从消息队列中将重要的信息窃取出来。

3. 在Https的建立完共享密钥后，传递消息的时候并没有使用数字签名技术，所以也就无法得到抗否认性的能力。而这又是在电子商务中不可豁缺的。

4. 由于Https提供的是传输层的安全，当然也就不可能达到消息安全所需要的灵活性的要求。比如加密消息中的部分元素；用不同的密钥加密消息的不同部分，从而让不同的消息接受者查看与之对应的信息。

因此，为了适应Web Service对安全的特殊要求，IBM和MS等公司共同制定了WS-Security规范。重新回顾安全问题的三个概念：Confidentiality(机密性), Integrity(完整性), Authentication(身份鉴别)，在Web Service使用SOAP（XML 格式）作为消息传输协议的背景下，分别产生了XML Digital Signature，XML Encryption和SAML(XML格式的Security Token), 而WS-Security则是如何将他们组合起来以满足Web Service安全需求的一套规范。

相关内容留待以后介绍。

参考资料:
<<Securing Web Services with WS-Security>>

<<Web Service Security Scenarios, Patterns, and Implementation Guidance
for Web Services Enhancements (WSE) 3.0>>

推荐资料:
性能比较：安全性设计选择

系列文章