UsernameToken 介绍(转)

很好的一篇文章，转过来收藏一下

?

转自：http://blog.csdn.net/cocojiji5/archive/2008/12/08/3478507.aspx

?

使用用户名和密码来验证用户的身份是最普通也最常见的方法，虽然在安全性方面也比较弱，由于其运用的广泛性还是成为了WS-Security目前所支持的Security Token之一。其原理非常简单，用户在发送请求的时候，在Soap head中加入自己的用户名以及密码，接受请求的Service通过之前与Client建立的共享密码来验证密码的合法性从而实现鉴别用户的功能。

不过实际运用起来就不能考虑的那么简单了，该方法主要存在两个问题：
1.?在SOAP包中传输密码怎么保证密码的安全性？
2.?怎么从用户名密码中获得签名和加密所需要的密钥？

针对第一个问题有三种解决方案：
1．?使用运输层的安全协议(如SSL)来保证明文密码的安全性。
2．?对明文密码做摘要后再传送给Service。
3．?利用从密码派生出来的密钥来代替直接使用密码来实现身份鉴别。

?

第一种方法采用了WS-Security结合运输层的安全协议(SSL)来保证密码的安全，在本系列一开始的文章已经描述过运输层安全协议的缺点，所以在此不对该方法做详细介绍。

?

第二种方法类似于HTTP Digest Authentication，先来看一段使用该方法的示例：

?

?
从中可以看到SOAP Head中的wsse:UsernameToken已经被加密，被xenc:EncryptedData所替代，查看其Token Reference发现加密使用的Key来自xenc:EncryptedKey。如果你完整阅读了本系列的文章，你将不会对它太陌生，在XML Encryption中曾经对它的来由做了详细介绍。
?????? Note由于使用对称密钥加密效率高，所以通常会使用对称密钥来加密数据，但是如何让消息的接受也获得对称密钥则成了一个问题。消息发送方不可能将对称密钥也随消息传递给消息接收方，此时利用非对称密钥来实现加密所用的对称密钥的传递成为了一个比较好的选择。EncrptedKey就是实现此种功能的扩展元素。

Client随机产生了一个对称密钥并用它来加密和签名SOAP Envelop中的其他元素(如UsernameToken)，然后通过使用Service(消息接受方）的公钥(由于是公钥可以方便获取)来加密该对称密钥，以保证只有Service能够获得Client随机产生的对称密钥，从而达到验证消息完整性，解密数据以及鉴别用户身份的目的。以下是采用这种方式保证安全的SOAP Envelop的示例：
?Note以上介绍的方法UsernameForCertificate仅被WS-Security1.1支持。因为在1.1中才支持使用对称密钥签名。
 

如此，之前所提到的问题都可以解决了，让我们回顾一下：
Q: 在SOAP包中传输密码怎么保证密码的安全性？
A: 使用密钥加密，只有接受方能解密密码。

Q: 怎么从用户名密码中获得签名和加密所需要的密钥？
A:? 随机产生密钥，并通过接受方的公钥加密，保证密钥不被别人所知。
Q: 如何避免重放攻击？
A: 由于其他人无法获得密钥，所以即便截获消息也无法冒充。
Q: 直接使用密码派生密钥被破解了怎么办？ 
A: 密钥不再从密码派生，而是每次随机产生，即便被破解也不会影响其他的消息和其他的服务。
Q: 用户密码必须以明文形式保存在Service端？ 
A: 由于密码被加密而不是做摘要所以不需要Service拥有明文密码。

应用场景：
B2C网上购物，每个用户都有各自的用户名密码，而且可以方便的获得Server端的Certification。(比如Amazon)


参考资料:
OASIS Kerberos Token Profile 1.1
Protect Your Web Services Through The Extensible Policy Framework In WSE 3.0
?
?
?