到底什么是MSDN？MD5？SHA-1？

让我们先来了解一些基本知识，了解hash。

Hash，一般翻译做“散列”，也有直接音译为"哈希"的，就是把任意长度的输入（又叫做预 映射， pre-image），通过散列算法，变换成固定长度的输出，该输出就是散列值。这种转换是一种压缩映射，也就是，散列值的空间通常远小于输入的空间，不 同的输入可能会散列成相同的输出，而不可能从散列值来唯一的确定输入值。

简单的说就是一种将任意长度的消息压缩到某一固定长度的消息摘要的函数。

HASH主要用于信息安全领域中加密算法，他把一些不同长度的信息转化成杂乱的128位的编码里,叫做HASH值. 也可以说，hash就是找到一种数据内容和数据存放地址之间的映射关系

了解了hash基本定义，就不能不提到一些著名的hash算法，MD5 和 SHA1 可以说是目前应用最广泛的Hash算法，而它们都是以 MD4 为基础设计的。那么他们都是什么意思呢？
这里简单说一下：

1) MD4
MD4(RFC 1320)是 MIT 的 Ronald L. Rivest 在 1990 年设计的，MD 是 Message Digest 的缩写。它适用在32位字长的处理器上用高速软件实现--它是基于 32 位操作数的位操作来实现的。

2) MD5
MD5(RFC 1321)是 Rivest 于1991年对MD4的改进版本。它对输入仍以512位分组，其输出是4个32位字的级联，与 MD4 相同。MD5比MD4来得复杂，并且速度较之要慢一点，但更安全，在抗分析和抗差分方面表现更好。
MD5是一种不可逆的加密算法，目前是最牢靠的加密算法之一，尚没有能够逆运算的程序被开发出来，它对应任何字符串都可以加密成一段唯一的固定长度的代码。
那么它有什么用呢？很简单，通过它可以判断原始值是否正确（是否被更改过）。一般用于密码的加密。而我们所提供的MD5校验码就是针对安装程序的唯一对应 的一段代码。你可以使用任何MD5运算器对下载的文件进行运算，运算出来的结果如果完全符合我们提供的MD5校验码，那么说明你下载的这个程序没有被中途 修改过。
　　这个特征码有如下特性，首先它不可逆，例如我有一段秘密的文字如："My Secret Words"，经算法变换后得到MD5码(b9944e9367d2e40dd1f0c4040d4daaf7)，把这个码告诉其他人，他们根据这个 MD5码是没有系统的方法可以知道你原来的文字是什么的。
　　其次，这个码具有高度的离散性，也就是说，原信息的一点点变化就会导致MD5的 巨大变化，例如"ABC" MD5(902fbdd2b1df0c4f70b4a5d23525e932)和"ABC "（多了一空格）MD5(12c774468f981a9487c30773d8093561)差别非常大，而且之间没有任何关系，也就是说产生的MD5 码是不可预测的。
　　最后由于这个码有128位那么长，所以任意信息之间具有相同MD5码的可能性非常之低，通常被认为是不可能的。
　　所以一般认为MD5码可以唯一地代表原信息的特征，通常用于密码的加密存储，数字签名，文件完整性验证等。


3) SHA1 及其他
SHA1是由NIST NSA设计为同DSA一起使用的，它对长度小于264的输入，产生长度为160bit的散列值，因此抗穷举(brute-force)性更好。SHA-1 设计时基于和MD4相同原理,并且模仿了该算法。SHA-1是由美国标准技术局（NIST）颁布的国家标准，是一种应用最为广泛的hash函数算法，也是 目前最先进的加密技术，被政府部门和私营业主用来处理敏感的信息。而SHA-1基于MD5，MD5又基于MD4。
论坛里提供的系统镜像文件的hash也就是微软官方提供的SHA-1值，下载后和此值对应，就说明你下载过程中文件没有被更改，属于原版。

什么是CRC
CRC的全称为Cyclic Redundancy Check，中文名称为循环冗余校验。它是一类重要的线性分组码，编码和解码方法简单，检错和纠错能力强，在通信领域广泛地用于实现差错控制。实际上，除 数据通信外，CRC在其它很多领域也是大有用武之地的。例如我们读软盘上的文件，以及解压一个ZIP文件时，偶尔会碰到“Bad CRC”错误，由此它在数据存储方面的应用可略见一斑。

那么这些Hash算法到底有什么用呢？
Hash算法在信息安全方面的应用主要体现在以下的3个方面：

1) 文件校验
我们比较熟悉的校验算法有奇偶校验和CRC校验，这2种校验并没有抗数据篡改的能力，它们一定程度上能检测并纠正数据传输中的信道误码，但却不能防止对数据的恶意破坏。
MD5 Hash算法的"数字指纹"特性，使它成为目前应用最广泛的一种文件完整性校验和(Checksum)算法，不少Unix系统有提供计算md5 checksum的命令。
2) 数字签名
Hash 算法也是现代密码体系中的一个重要组成部分。由于非对称算法的运算速度较慢，所以在数字签名协议中，单向散列函数扮演了一个重要的角色。 对 Hash 值，又称"数字摘要"进行数字签名，在统计上可以认为与对文件本身进行数字签名是等效的。而且这样的协议还有其他的优点。
3) 鉴权协议
如下的鉴权协议又被称作"挑战--认证模式：在传输信道是可被侦听，但不可被篡改的情况下，这是一种简单而安全的方法。

当然，hash函数并不是完全可靠，不同文件产生相同MD5和SHA1的几率还是有的，只是不高，在我们论坛里提供的系统光盘，你想对这么几个文件存在相同HASH的不同文件根本是不可能的。
论坛MSDN版块，提供的就是微软发布MSDN提供给程序员研究的Windows系统的镜像的HASH值——SHA-1，不提供MD5因为微软只提供了 SHA1。而论坛发布区发布的镜像是和这些值对应的镜像，你校验自己的镜像的HASH和MSDN信息区相应版本的SHA-1对应的上，说明你手中的光盘是 微软通过MSDN发布的原盘。对不上还存在属于零售或通过销售渠道发布的镜像的可能。毕竟MSDN只是微软发布系统光盘的一个途径，MSDN只是给程序开 发人员研究用的。
寻求原版的证实，对应SHA-1和MD5外，CRC的认证也是一个很重要的因素，CRC同样是校验文件的完整性，还有CDIMGE的封装版本。
微软出品的镜像都能通过CRC验证，当然也有人使用CRC自己进行制作可以得到通过CRC的镜像，那么这时候你需要对应镜像的SHA-1等了，所以，验证一个镜像的原盘可以通过对应多个数值来完成。

什么是MSDN
MSDN是Microsoft Software Developer Network的简称。这是微软的针对开发者的开发计划。你可以在http://msdn.microsoft.com看到有关软件开发的资料。在VC++ 6.0中包括MSDN Library的光盘，其中包括VC++的帮助文件和许多与开发相关的技术文献，学习VC++编程经常要搜索一下MSDN Library。MSDN Library每个季度更新一次，可以向微软订阅更新光盘。
所以MSDN资源不是匿名就可以访问并看的到的，需要订购的客户才能看到并下载。
MSDN订购可以标准、教育或批量价格，从你喜欢的软件分销商那里购买。

CPA CPS CPC CPM CPO PPC PPL PPS CPTM

经常有人问CPA CPS CPC 什么意思啊?
加广告似乎有这些方式的啊
CPA (Cost-per-Action) ：每次行动的费用，即根据每个访问者对网络广告所采取的行动收费的定价模式。对于用户行动有特别的定义，包括形成一次交易、获得一个注册用户、或者对网络广告的一次点击等。
　　CPC (Cost-per-click)： 每次点击的费用。根据广告被点击的次数收费。如关键词广告一般采用这种定价模式。
　　CPM（Cost per Thousand Impressions）：每千次印象费用。广告条每显示1000次（印象）的费用。CPM是最常用的网络广告定价模式之一。
　　CPO (Cost-per-Order) ：也称为Cost-per-Transaction，即根据每个订单/每次交易来收费的方式。
　　PPC（Pay-per-Click）：是根据点击广告或者电子邮件信息的用户数量来付费的一种网络广告定价模式。
　　PPL（Pay-per-Lead）：根据每次通过网络广告产生的引导付费的定价模式。例如，广告客户为访问者点击广告完成了在线表单而向广告服务商付费。这种模式常用于网络会员制营销模式中为联盟网站制定的佣金模式。
　　PPS（Pay-per-Sale）：根据网络广告所产生的直接销售数量而付费的一种定价模式 。
　　CPTM (Cost per Targeted Thousand Impressions) ：经过定位的用户（如根据人口统计信息定位）的千次印象费用。CPTM与CPM的区别在于，CPM是所有用户的印象数，而CPTM只是经过定位的用户的印象数。

另外收集一篇
什么是CPA、CPC、CPS、CPL、CPM、CPO、PPC、PPL、CPTM？

在有关网络广告的术语中，经常会遇到CPA、CPC、CPM、CPO、PPC、PPL、CPTM等缩写字母，这些都是有关网络广告定价方式的缩写短语，下面是《网络营销基础与实践》第二版第6章“网络广告基础”中对这些概念的解释。

关于网络广告定价模式的一组常用术语：

CPA (Cost-per-Action) ：每次行动的费用，即根
据每个访问者对网络广告所采取的行动收费的定价模式。对于用户行动有特别的定义，包括形成一次交易、获得一个注册用户、或者对网络广告的一次点击等。

CPC (Cost-per-click)： 每次点击的费用。根据广告被点击的次数收费。如关键词广告一般采用这种定价模式。

CPL(Cost for Per Lead)：按注册成功支付佣金。

CPM（Cost per Thousand Impressions）：每千次印象费用。广告条每显示1000次（印象）的费用。CPM是最常用的网络广告定价模式之一。

CPO (Cost-per-Order) ：也称为Cost-per-Transaction，即根据每个订单/每次交易来收费的方式。

CPS(Cost for Per Sale)：营销效果是指，销售额。

PPC（Pay-per-Click）：是根据点击广告或者电子邮件信息的用户数量来付费的一种网络广告定价模式。

PPL（Pay-per-Lead）：根据每次通过网络广告产生的引导付费的定价模式。例如，广告客户为访问者点击广告完成了在线表单而向广告服务商付费。这种模式常用于网络会员制营销模式中为联盟网站制定的佣金模式。

PPS（Pay-per-Sale）：根据网络广告所产生的直接销售数量而付费的一种定价模式 。

CPTM (Cost per Targeted Thousand Impressions) ：经过定位的用户（如根据人口统计信息定位）的千次印象费用。CPTM与CPM的区别在于，CPM是所有用户的印象数，而CPTM只是经过定位的用户的印象数。

Performance Improvement in a J2EE Application

http://dev2dev.bea.com.cn/techdoc/2004122805.html

Java is hot. Just nine years old, it has become one of the leading development environments in the world. Millions of programmers and thousands of companies use it, and half of all IT managers expect to deploy J2EE applications this year.

But Java's popularity hasn't necessarily made it easy for the growing population of Java code jockeys. Ever-shortening production cycles have kept the heat on programmers, who increasingly work in large teams to meet production milestones. And every day those teams come face-to-face with an immutable law of software development: the more code you write, the more bugs you'll get - bugs that cost time and sap quality and performance from applications.

This article looks at performance tuning and optimization of memory usage of a J2EE application. Our setup uses the BEA WebLogic Application Server. We will consider the following:

• The problem domain
• Tuning the Java Virtual Machine
• HTTP session management
• Tuning the application server
• Coding standards: laying ground rules for the future

The Problem Domain
We have a J2EE application with the following setup:

• BEA WebLogic 6.1 Service Pack 5 as application/Web server.
• Some popular RDBMS. This has no effect on our discussion.
• Model I Web Architecture.
• Eight stateless EJBs and six stateful EJBs.
• HTTP session holding references to stateful EJBs.
• Database Connection Pool with initial size 2 and maximum size 10.
• Around 120 servlets in the Web tier.
• XML/XSLT-based architecture.

The Problems
There was a memory issue with the application. When the server was started, the memory usage was around 7-8% of the total physical memory available. As the days went by and the application went into wider use, the memory usage grew to nearly 49-53% (over a 7-10 day period).

If the users logged off from their session by clicking the "Log off" button in the left-hand side menu, the application removed all the stateful beans from the server, but if a user just closed the browser window it didn't remove those beans and stayed in the container until the application server was restarted. As this continued, the number of EJB instances in memory shot up to 400 and above.

When BEA WebLogic Server loads more than ~400 EJBs, the Hotspot VM throws an OutOfMemory Exception. This occurs even though there appears to be more memory available.

Tuning the Java Virtual Machine
The Hotspot Virtual Machine was throwing an OutOfMemory Exception while trying to allocate PermGeneration space. The Hotspot VM uses different sections of memory. The permanent generation section is used for storing classes, methods, and symbols used by running Java objects. The initial size of the permanent generation section is 1 MB and the maximum size was 32 MB prior to 1.3.1 and 64 MB.

To get around this, we can set up the permGeneration space through a JVM switch with the following command line:

java -server -XX:MaxPermSize=128M.

Note that increasing the max perm size only delays a failure. It's up to your application to properly clean the unused objects. Also, the XX options are not supported across all JVMs.

HTTP Session Management
When the user closes the browser without logging off from the session, the EJBs in the user's session will not be garbage collected. This is the primary reason for having too many EJBs in memory. To get around this, the HTTP session management has to look into all possible combinations. We can set up a default session time-out period in web.xml (Web application deployment descriptor) as follows:

x

With this setting, the user's session will be automatically deactivated after x minutes of inactivity.

The other way is to code the session management using the following code when creating HTTP session

HttpSession session=new HttpSession ();
session.setmaxinactiveinternal(int timeoutSeconds);

This code will invalidate the user's session of timeoutSeconds of inactivity.

Note: If you do both of these steps, the value in the servlet code will override the value set up in the web.xml.

The only difference between these two methods is that the second one takes seconds as the parameter while the tag value takes minutes as the argument. Normally, when the session is invalidated the logoff servlet/JSP will have code to remove references to all objects/object graphs referenced by the particular session. But when the user just closes the browser button there is no way our logoff servlet/JSP will be called. In this scenario, even though the session is invalidated, the enclosed objects/object graphs will still be there. When the garbage collector tries to garbage collect this session, it will also have to garbage collect all of these enclosed objects. When we have large objects (objects with larger references/data), we can also use the HTTPSessionListener interface to perform some clean-up action.

javax.servlet.http.HTTPSessionListener Interface
This interface declares the following two call-back methods:

Public void sessionCreated(HttpSessionEvent event);
Public void sessionDestroyed(HttpSessionEven event);

These methods are called before a session is created/destroyed.

We can have a listener class that implements this interface and use these callback methods to control how sessions are created/destroyed. We need to register our listener class in the web.xml as follows:

MySessionListener

The advantage of using listener class along with the session timeout parameter in the web.xml file is that we will have more control of session management. If the session has large objects, then before the garbage collecter cleans up the objects, its time slice may disappear. In this case, it needs to wait for the next slice to clean up the objects.

Note: It is important that we design the application so that there is a single entry point. We need to start a new HTTP session in this class. All the remaining pages should check for the existence of HTTP session and for an error page when the session is null (Session Expired). This enables centralized control of HTTP sessions.

Tuning the Application Server
BEA WebLogic offers a number of parameters that we can set to optimize the bean pool size, including setting the initial size of the stateless bean pool. Some of the features include:

Use the to set it to minimum possible value for stateless session beans: By default, the value is 1000. As stateless session beans can be shared between concurrent users, it is better to set this value to a very minimum. The correct value for this tag depends upon the concurrent users and peak load situation of the application.

Use the tag to set the maximum bean pool size for the stateful session beans: The default value for this has no limit. The value set for this tag greatly affects the activation/passivation mechanism of BEA WebLogic Server. The appropriate value for this tag depends on the application's traffic. When the number of beans in this pool has reached the threshold and a request for a new bean instance has come, the WebLogic Server will pick one or more beans for this pool for passivation. The algorithm for picking up the bean instance for passivation is either LRU (Least Recently Used) or NRU (Not Recently Used).

If max-beans-in-cache is reached and EJBs in the cache are not being used, WebLogic Server passivates some of those beans. This occurs even if the unused beans have not reached their idle-timeout-seconds limit. If max-beans-in-cache is reached and all EJBs in the cache are being used by clients, WebLogic Server throws a CacheFullException.

Use the tag to set the time the WebLogic Server will wait before passivating an idle stateful session bean instance: The WebLogic Server will wait for the same amount of time before removing the bean from the swap space. Care should be taken in setting this value because once the passivated instance is removed from the swap space, there is no way to retrieve the state of the bean again.

For example, consider the following setting:

1200

The idle bean instances will be passivated after 20 minutes of inactivity. After another 20 minutes, the bean instance will be removed from the disk also. Now let's say at the 41st minute the user has called a method on the bean instance. The BEA WebLogic Server will throw the error shown in Listing 1.

WebLogic 6.1 Service Pack 5 provides a useful tag to get around this. The tag is described as follows:

If we set the value for this we can control the time the passivated beans will be removed from the disk. We can use this tag and set it to a very value so that we will always have our stateful EJBs (either in memory or on the disk). This will completely eliminate the bean deleted error.

Using WebLogic Managed Servers
BEA WebLogic allows you to create one or more servers within a single domain. One server will be the admin server; all other servers will be managed servers in the sense that they are managed by the admin server. An application, when put into production, should not be deployed in the admin server. The advantage of using managed servers is that we can start and stop them from the admin console. Thus even if the server holding the application stops responding (for any reason), we still have a chance to restart the server from the admin console.

Coding Standards: Laying Down the Rules for the Future
Managing a production system is even more difficult when the environment in which the system will run has not been taken into account in the design phase. System re-engineering is a simple task when careful consideration of the environment, boundaries, and context of the application is taken care of during the design phase. Design is an abstract definition of execution path. Solutions will be more scalable when the development is done by taking into account every minute detail of the design. There will be no hard and fast rules for system development as this depends on the particular problem domain in hand. But, there are some axioms that always help.

Have a clear idea about supplementary classes like String and StringBuffer: Use the appropriate class in appropriate situations. For example, using String class to build a long SQL query is inefficient and overloads the JVM string pool.

Clean up legacy objects like Hashtable as soon as you're done with them.

Call remove() method on EJB references explicitly: This will release the bean instance to the bean pool and reduce the number of bean instances created by the container.

Manage database connections carefully: Have a close() method called on them as soon as you're done with it. Don't open the connection as a first line in the class. Open the connection only when you need it.

Understand the business requirements and the context in which your code executes before you write a single line of code.

To sum up... "Create Objects as late as possible and remove them as early as possible".

用Axis开发Web Service

选择Axis的理由:
1. 开发速度快
2. 可移植性好，可在不同的application server, web container中运行
3. 成熟稳定，Axis是从Apache SOAP(IBM SOAP4J)发展过来的，Axis 1.0在2002年10月发布，Axis是许多商业app server的基础，如WebSphere。

开发WSDL
开发Web Service应该从设计WSDL入手。对于使用了复杂数据类型的web service，如果对手写xml schema不是很熟悉可以先编写web service的java接口定义和表示相关的参数、返回值类的类，然后再用Axis的Java2WSDL工具生成wsdl的草稿。
修改生成的 wsdl草稿要考虑合理选择binding的方式，WSDL规范定义了两种binding style：rpc和document，rpc意味着web service的客户端和服务端使用远程方法调用的约定进行通信，而使用document意味着客户端和服务端用xml文档进行通信。WSDL还规定了两种use：encoded和literal，literal意味着soap body中的xml是用相应的schema约束的；encoded意味着具体的soap message语义需要指定编码规则(通常是所谓的SOAP encoding，在SOAP规范的第五部分定义，又叫section 5 encoding)来解释。所以在wsdl中共有style/use的四种组合: rpc/encoded, rpc/literal, document/encoded, document/literal。第三种方式没有实际应用。另外，Microsoft提出了一种所谓的document/literal wrapped的方式，它用一个与operation同名的元素作为所有参数的"包装器"。document/literal wrapped方式解决了document/literal方式无法表达operation名称的缺点。
rpc/encoded(Axis默认的方式)可以表达的对象图、多态的数据，wsdl定义的抽象的SOAP数据模型依赖于具体的实现，这可能带来互操作性问题(如Axis的默认使用multi -ref表达soap响应)，所以rpc/encoded是WS-I BP1.0规范所禁用的方式。

关于如何合理地选择的style/use方式请参考developerworks上的
http://www-106.ibm.com/developerworks/webservices/library/ws-whichwsdl/

用Axis 的Java2WSDL工具生成wsdl可以使用Axis发布时自带的命令行工具或ant task。但两者配置繁琐，本文以maven-axis-plugin为例说明如何使用。maven-axis-plugin的java2wsdl可以根据java的interface或class生产相应的wsdl。
使用该插件前先要下载：
maven plugin:download -DartifactId=maven-axis-plugin -DgroupId=maven-plugins -Dversion=0.6-jus -Dmaven.repo.remote=http://ultra/maven/
然后，需要配置该插件，使用java2wsdl至少需要配置两种信息：一是namespace和package之间的映射关系，二是要暴露为web service的class或interface的名称(FQCN)，以及该class的对应的service的location(也就是通过什么url 可以访问到该web service)和namespace。
示例：
# axis java2wsdl plugin settings
maven.java2wsdl.namespaceMappings = http://www.ceservice.com.cn/ce/PAPS/exception=com.erry,
http://www.ceservice.com.cn/ce/PAPScom.erry.webservice,
http://www.ceservice.com.cn/ce/PAPS/datatype/baseinfo=com.erry.webservice.VO.baseinfo,
http://www.ceservice.com.cn/ce/PAPS/datatype/srvsht=com.erry.webservice.VO.srvsht
maven.axis.classnames = com.erry.webservice.ServiceSheetServiceSoapBindingImpl
com.erry.webservice.ServiceSheetServiceSoapBindingImpl = http://localhost/services/ServiceSheetService,http://www.ceservice.com.cn/ce/PAPS

namespace 和package之间的映射关系的用maven.java2wsdl.namespaceMappings属性表示，其值为逗号分隔的 namespace=package；maven.axis.classnames指定要暴露为web service的class或interface的名称，如果有多个用逗号分隔。每个class或interface还要指定location和 namespace(两者用逗号分隔)。
配置完，运行maven axis:java2wsdl即在target/axis/wsdl目录下产生与class同名(FQCN)，wsdl为后缀的文件。


用Axis开发Web Service客户端的步骤
编写完wsdl后，可以用Axis的wsdl2java生成web service的客户端，wsdl2java生成的客户端是stub方式的。它包括endpoint借口、实现该接口的stub、 serviceLocator、可选的单元测试代码。其中，serviceLocator中hard code了服务端地址。可以用spring的dependency injection将服务器地址放在spring bean配置文件中。

使用maven-axis-plugin生成client代码首先需要配置，主要涉及的信息有wsdl文档的位置(maven.axis.url)， namespace和package的映射(maven.wsdl2java.namespaceMappings)，是否生成单元测试 (maven.axis.testcase)。maven.wsdl2java.namespaceMappings的格式和 maven.java2wsdl.namespaceMappings一样。
示例：
maven.axis.url = ${maven.src.dir}/conf/srvshtservice.wsdl
maven.axis.testcase = true
maven.wsdl2java.namespaceMappings = http://www.ceservice.com.cn/ce/PAPS/exception=com.erry,
http://www.ceservice.com.cn/ce/PAPS=com.erry.webservice,
http://www.ceservice.com.cn/ce/PAPS/datatype/baseinfo=com.erry.webservice.VO.baseinfo,
http://www.ceservice.com.cn/ce/PAPS/datatype/srvsht=com.erry.webservice.VO.srvsht

配置完后运行maven axis:wsdl2java即在target/axis/src目录下产生endpoint interface，stub， serviceLocator和data type对应的Java Class。如果maven.axis.testcase为true，则还在target/axis/test目录下生成相应的单元测试代码。

用Axis开发Web Service服务器端的步骤
Axis 的wsdl2java工具除了客户端代码外还可以生成服务器端代码的框架和web service部署说明文件(wsdd)。Axis生成的默认wsdd基本上能够满足一般的要求了。其中需要修改的有：将multi-ref设成 false，这只要在globalConfiguration中增加；在service中加入元素指定wsdl文件，而不是让Axis在运行时刻生成。 元素中的文件路径是相对于web app的WEB-INF/classes目录的。

和生成客户端代码类似，使用 maven-axis-plugin生成server端框架带和部署说明文件首先需要配置。配置的内容除了wsdl文档的位置，namespace和 package的映射外还需要指定deploy scope，maven.axis.serverside设为true表示生成服务端代码。
示例：
maven.axis.url = ${maven.src.dir}/conf/srvshtservice.wsdl
maven.axis.deployscope = application
maven.axis.serverside = true
maven.axis.testcase = true
maven.wsdl2java.namespaceMappings = http://www.ceservice.com.cn/ce/PAPS/exception=com.erry,
http://www.ceservice.com.cn/ce/PAPS=com.erry.webservice,
http://www.ceservice.com.cn/ce/PAPS/datatype/baseinfo=com.erry.webservice.VO.baseinfo,
http://www.ceservice.com.cn/ce/PAPS/datatype/srvsht=com.erry.webservice.VO.srvsht

配置完后运行maven axis:wsdl2java即在target/axis/src目录下产生endpoint interface，data type对应的Java Class，JSE框架代码，部署说明文件等。


Axis开发调试工具
Axis自带了一个名为tcpmon的工具用于截获SOAP消息。使用该工具可以看到完整的HTTP请求和响应。本文以maven-axis-plugin为例说明如何启动该工具。
配置
# axis tcpmon plugin settings
maven.axis.tcpmon.listen.port=90
maven.axis.tcpmon.destination.host=localhost
maven.axis.tcpmon.destination.port=80
第一行是tcpmon监听端口，web service的客户端应该向该端口发出请求，第二、三行是web service服务端所在的主机和端口
配置完，运行maven axis:tcpmon即出现tcpmon swing界面。此时，可以运行web service的客户端了。

Java Web Service的客户端实现

Java Web Service的客户端实现有三种
1. 生成的stub
2. 动态代理
3. 动态调用接口
其中 生成stub是最常用的。stub是用JAX-RPC编译器根据WSDL文档生成的，其主要功能是将对endpoint接口的方法调用转化为SOAP 消息，并且负责将返回的SOAP响应转换为方法的返回值，把SOAP fault转化为方法的异常。JAX-RPC编译器产生的stub除了要实现endpoint接口外，还需要实现或继承 javax.xml.rpc.Stub接口或其实现的子类(Axis中是org.apache.axis.client.Stub)。 javax.xml.rpc.Stub接口主要定义了和网络通讯和认证相关的属性的设置和获取的机制。
Java Web Service的客户端实现有三种
1. 生成的stub
2. 动态代理
3. 动态调用接口
其 中生成stub是最常用的。stub是用JAX-RPC编译器根据WSDL文档生成的，其主要功能是将对endpoint接口的方法调用转化为SOAP 消息，并且负责将返回的SOAP响应转换为方法的返回值，把SOAP fault转化为方法的异常。JAX-RPC编译器产生的stub除了要实现endpoint接口外，还需要实现或继承 javax.xml.rpc.Stub接口或其实现的子类(Axis中是org.apache.axis.client.Stub)。 javax.xml.rpc.Stub接口主要定义了和网络通讯和认证相关的属性的设置和获取的机制。其代码如下：
package javax.xml.rpc;
import java.util.Iterator;

public interface Stub {

// Standard property: The Web service's Internet address.
public static String ENDPOINT_ADDRESS_PROPERTY;
// Standard property: Password for authentication.
public static String PASSWORD_PROPERTY;
// Standard property: User name for authentication.
public static String USERNAME_PROPERTY;
// Standard property: Boolean flag for maintaining an HTTP session.
public static String SESSION_MAINTAIN_PROPERTY;

// Given a property name, get its value.
public Object _getProperty(java.lang.String name);
// Get the names of all the properties the stub supports.
public Iterator _getPropertyNames();
// Configure a property on the stub.
public void _setProperty(java.lang.String name, java.lang.Object value);
}

JAX -RPC编译器产生还可以产生一个和WSDL中service元素对应的Service接口，该接口组合了多个port，也就是多个Stub。该接口继承 了javax.xml.rpc.Service。在J2EE环境中Service接口通常通过JNDI lookup得到。
在J2EE中使用生成的stub的典型用例如下:
代码：
package com.jwsbook.jaxrpc;
import javax.servlet.http.*;
import javax.servlet.*;
import javax.naming.InitialContext;

public class BookQuoteServlet_1 extends javax.servlet.http.HttpServlet {
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException,java.io.IOException {
try{
String isbn = req.getParameter("isbn");

InitialContext jndiContext = new InitialContext();

BookQuoteService service = (BookQuoteService)
jndiContext.lookup("java:comp/env/service/BookQuoteService");

BookQuote bookQuote = service.getBookQuotePort();

float price = bookQuote.getBookPrice( isbn );

java.io.Writer outStream = resp.getWriter();
outStream.write("The wholesale price for ISBN:"+isbn+
" = "+price+"");
}catch(javax.naming.NamingException ne){
throw new ServletException(ne);
}catch(javax.xml.rpc.ServiceException se){
throw new ServletException(se);
}
}
部署说明文件：

service/BookQuoteService
com.jwsbook.jaxrpc.BookQuoteService
BookQuote.wsdl
mh:BookQuoteService

一 般都是通过JNDI查询到相应的Service接口，然后从Service接口中得到stub，最后调用web service的方法。部署文件中申明了名为"service/BookQuoteService"的Service接口，在代码里获取该接口的代码是 jndiContext.lookup("java:comp/env/service/BookQuoteService")，前缀"java: comp/env/"是所有J2EE资源在JNDI树种的parent Context。

在非J2EE环境中实现web service客户端
在 非J2EE环境中也可以实现web service客户端，这时需要用到javax.xml.rpc.ServiceFactory(或其子类，在axis中是 org.apache.axis.client.ServiceFactory)的静态方法loadService得到service接口。接下来的调用 代码和J2EE中的类似。

动态代理调用
动态代理调用是Java web service的另一种方式。对于使用该方式的客户端代码，和生成stub的方式相比较，其变化不是很大。它和生成stub的方式主要区别在于前者在编译时刻产生service接口和stub，后者则将这部分工作延迟到运行时刻。
动态代理调用的典型代码和部署说明文件：
package com.jwsbook.jaxrpc;
import javax.naming.InitialContext;

public class JaxRpcExample_2 {
public static void main(String [] args) throws Exception{
String isbn = args[0];

InitialContext jndiContext = new InitialContext();

javax.xml.rpc.Service service = (javax.xml.rpc.Service)
jndiContext.lookup("java:comp/env/service/Service");

BookQuote BookQuote_proxy = (BookQuote)
service.getPort(BookQuote.class);

float price = BookQuote_proxy.getBookPrice( isbn );

System.out.println("The price is = "+price);
}
}


service/Service
javax.xml.rpc.Service
BookQuote.wsdl
mh:BookQuoteService


由 于不需要在编译时刻产生service接口和stub，用JNDI lookup和部署说明时只使用了javax.xml.rpc.Service。得到service接口后通过getPort方法可以取得动态代理的 stub。getPort有两种版本，getPort(java.lang.Class endpointInterface)和getPort(javax.xml.namespace.QName portName,java.lang.Class endpointInterface)，通常当WSDL中一个PortType有一种以上的绑定时，如果需要得到某个绑定的port接口就使用后者，否者 使用前者。QName是该绑定的完全限定名称，有命名空间加上局部名构成。对应的QName对象的构造方法有构造函数法和静态valueOf法，实例如 下：
// Use constructor method
QName portName =
new QName("http://www.Monson-Haefel/jwsbook/BookQuote",
"BookQuoteLiteralPort");

// Use static valueOf() method
String s = "{http://www.Monson-Haefel/jwsbook/BookQuote}BookQuoteLiteralPort";
QName qname2 = QName.valueOf(s);
valueOf方法接受的String参数以"{namespace}localName"的模式构成。
PortType有一种以上的绑定时还需要在JAX-RPC Mapping 文件中说明不指定QName版本的getPort方法对应的port绑定。示例：

xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:mh="http://www.Monson-Haefel.com/jwsbook/BookQuote"...>
...

com.jwsbook.jaxrpc.BookQuote

mh:BookQuote
mh:BookQuote_LiteralBinding
...



使用QName的动态代理调用实例：
package com.jwsbook.jaxrpc;
import javax.naming.InitialContext;
import javax.xml.namespace.QName;

public class JaxRpcExample_3 {
public static void main(String [] args) throws Exception{
String isbn = args[0];

InitialContext jndiContext = new InitialContext();

javax.xml.rpc.Service service = (javax.xml.rpc.Service)
jndiContext.lookup("java:comp/env/service/Service");

QName portName =
new QName("http://www.Monson-Haefel/jwsbook/BookQuote",
"BookQuoteLiteralPort");

BookQuote BookQuote_proxy = (BookQuote)
service.getPort(portName, BookQuote.class);

float price = BookQuote_proxy.getBookPrice( isbn );

System.out.println("The price is = "+price);
}
}
动态代理的底层实现是用java的反射机制和java.lang.reflect.Proxy完成的。

动态调用接口(DII)

动态调用接口的通常使用顺序：
1. 获得一个通用的service接口，比如通过JNDI lookup
2. 构造代表WSDL中port和operation的QName对象，作为service接口的createCall方法的参数，得到Call对象。
3. 准备operation所需的参数，如果是原子类型则需要将其包装成相应的对象类型。视operation是否有返回值调用invoke或invokeOneWay方法。
4. 如果operation定义了INOUT,OUT参数，则在invoke后调用getOutputValues，比如：java.util.List outputParams = call.getOutputValues();
完整的代码示例：
package com.jwsbook.jaxrpc;
import javax.naming.InitialContext;
import javax.xml.rpc.Service;
import javax.xml.rpc.Call;
import javax.xml.namespace.QName;

public class JaxRpcExample_4 {
public static void main(String [] args) throws Exception{
String isbn = args[0];

InitialContext jndiContext = new InitialContext();

javax.xml.rpc.Service service = (javax.xml.rpc.Service)
jndiContext.lookup("java:comp/env/service/Service");

QName portName =
new QName("http://www.Monson-Haefel.com/jwsbook/BookQuote",
"BookQuotePort");
QName operationName =
new QName("http://www.Monson-Haefel.com/jwsbook/BookQuote",
"getBookPrice");

Call call = service.createCall(portName,operationName);

Object [] inputParams = new Object[]{isbn};

Float price = (Float)call.invoke(inputParams);

System.out.println("The price is = "+price.floatValue());
}
}

WS-Federation：活动请求方概要

发布日期： 4/26/2004 | 更新日期： 4/26/2004

版本 1.0

2003 年 7 月 8 日

作者

Siddharth Bajaj，VeriSign

Giovanni Della-Libera，Microsoft

Brendan Dixon，Microsoft

Maryann Hondo，IBM

Matt Hur，Microsoft

Chris Kaler (Editor)，Microsoft

Hal Lockhart，BEA

Hiroshi Maruyama，IBM

Anthony Nadalin (Editor)，IBM

Nataraj Nagaratnam，IBM

Andrew Nash，RSA Security

Hemma Prafullchandra，VeriSign

John Shewchuk，Microsoft

本页内容

	1. 引言
	1.1. 目标和需求
	1.1.1 需求
	1.1.2. 非目标
	1.2. 标记约定
	1.3. 命名空间
	1.4. 术语
	2. 模型
	3.1. 单一登录
	3.2. 注销
	3.3. 属性
	3.4. 假名 (Pseudonym)
	4. 语法
	4.1. 请求安全性令牌
	4.2. 返回安全性令牌
	4.3. 注销语法
	4.4. 属性请求
	4.5. 假名请求
	5. 详解示例
	6. 其他示例
	6.1. 无资源 STS
	6.2. 第三方 STS
	6.3. 委派的资源访问
	7. 安全性令牌
	7.1. X.509v3
	7.2. Kerberos
	7.3. XrML
	7.4. SAML
	9. 安全考虑事项
	10. 致谢
	11. 参考资料

版权声明

_ 2001-2003 International Business Machines Corporation, Microsoft Corporation, BEA Systems, Inc., RSA Security, Inc., VeriSign, Inc.保留所有权利。

如 果您在 WS-Federation：活动请求方规范的完整副本或您制作的部分副本中包含了以下内容，IBM、Microsoft、BEA Systems, Inc.、RSA Security, Inc. 和 VeriSign, Inc.（统称为“作者”）将据此授予您以任何媒介形式复制和公开 WS-Federation：活动请求方规范的权限，且不需要任何费用或特许权使用费：

•	指向此处规范的链接或 URL
•	WS-Federation：活动请求方规范中所注明的版权声明。

除了以上授予的版权许可证以外，作者没有明示或暗示地授予任何知识产权（包括他们拥有或控制的专利）的许可证。

WS -Federation：活动请求方规范是“按原件”提供的，作者不作以下任何明示或暗示的陈述或担保：包括（但不限于）对适销性、特殊用途的适用性、无 侵权或所有权的担保；及担保 WS-Federation：活动请求方规范内容适用于任何用途，且这些内容的实施将不会侵犯任何第三方的专利、版权、商标或其他权利。

作者将不对由于任何使用或分发 WS-Federation：活动请求方规范产生的（或与之相关的）任何直接、间接、特殊、偶然或必然的损失负责。

WS-Federation：活动请求方规范在最终发布以前可能会发生变化，因此用户在使用此规范的内容时必须注意。

在获得明确的书面授权以前，不得以任何方式使用作者的名称和商标，包括与该规范或其内容相关的广告或宣传。WS-Federation：活动请求方规范的版权所有权任何时候都由作者保留。

没有以暗示、禁止反言或其他方式授予其他权利。

摘要

此规范定义了活动请求方（如支持 SOAP 的应用程序）如何使用 WS-Federation 中定义的交叉信任领域身份、身份验证和授权联合机制。

模块结构

通 过使用 XML、SOAP 和 WSDL 可扩展模型，各种 WS* 规范旨在通过互相组合来提供丰富的 Web 服务环境。WS-Federation：活动请求方自身不为 Web 服务提供完整的安全解决方案。WS-Federation：活动请求方是一个用于与其他 Web 服务和应用程序特定的协议结合使用的构造块，以适应各种各样的安全模型。

状态

此 WS-Federation 活动请求方规范是最初公开的草拟版，仅作为查看和评估用。BEA、IBM、Microsoft、RSA Security 和 VeriSign 希望在不远的将来能征求您的稿件和建议。BEA、IBM、Microsoft、RSA Security 和 VeriSign 不以任何方式做出关于此规范的担保或陈述。

目录

1. 引言

WS-Federation 规范定义了一种联合不同信任领域间的身份、身份验证和授权的集成模型。该规范定义了如何将联合模型应用于活动请求方（如 SOAP 应用程序）。

返回页首

1.1. 目标和需求

此规范的主要目标是定义对那些应用于活动请求方的身份、身份验证和授权信息进行联合的机制。

返回页首

1.1.1 需求

以下列表指出了此规范的关键实施要求：

•	在活动请求方之间支持身份、身份验证和授权数据的共享
•	代理活动请求方环境中的信任和安全性令牌交换
•	活动请求方环境中身份信息和其他属性的可选隐藏或保护

返回页首

1.1.2. 非目标

以下主题则不属本文档讨论的范围：

•	消息安全性或信任建立/验证协议的定义
•	新安全性令牌格式的规范

返回页首

1.2. 标记约定

本 文档中的关键字“必须 (MUST)”、“绝不可以 (MUST NOT)”、“必需的 (REQUIRED)”、“将 (SHALL)”、“将不 (SHALL NOT)”、“应该 (SHOULD)”、“不应该 (SHOULD NOT)”、“推荐的 (RECOMMENDED)”、“可以 (MAY)”和“可选的 (OPTIONAL)”将按 RFC 2119 中说明的进行解释。

当描述抽象数据模型时，此规范使用 XML 信息集中使用的标记约定。具体来说，抽象属性名称始终出现在方括号中（如 [some property]）。

当 描述具体的 XML 架构时，此规范使用 WS-Security 的标记约定。具体来说，元素的 [children] 或 [attributes] 属性的每个成员都是使用类似于 XPath 的标记（如 /x:MyHeader/x:SomeProperty/@value1）描述的。使用 {any} 说明存在元素通配符 ()。使用 @{any} 说明存在属性通配符 ()。

返回页首

1.3. 命名空间

本文档使用到以下命名空间：

前缀	命名空间
S	http://www.w3.org/2002/06/soap-envelope
wsse	http://schemas.xmlsoap.org/ws/2003/07/secext
wsu	http://schemas.xmlsoap.org/ws/2002/07/utility
wp	http://schemas.xmlsoap.org/ws/2002/12/policy

返回页首

1.4. 术语

以下定义概述了本规范中的术语及用法。

活动请求方 － 联合中的活动请求方是一个能发出（并接收）如 WS-Security 和 WS-Trust 中描述的 SOAP 消息的应用程序（可能是一个 Web 浏览器）。

声明 (Claim) － 声明 是实体所作的声明（如名称、标识、关键字、组、权限、功能、属性等）。

安全性令牌 (Security Token) － 安全性令牌 表示声明的集合。

已签名安全性令牌 (Signed Security Token) – 已签名安全性令牌 是由特定的权威机构断言并加密签名的安全性令牌（如 X.509 证书或 Kerberos 票证）。

所有权证明令牌 (Proof-of-Possession Token) － 所有权证明令牌 是一种包含发送方用来证明所有权证明数据的安全性令牌。一般情况下（但不是专有的），所有权证明信息是经过使用只有发送方和接收方才知道的密钥加密过的。

摘要 (Digest) – 摘要 是八进制流的加密校验和。

签名 (Signature) － 签名 是一个以某种方式使用加密算法计算并绑定到数据的值，且该数据的预期接收者可以使用此签名来验证数据在签名者签署它以后没有被修改。

安全性令牌服务 (STS) － 安全性令牌服务 是一种颁发安全性令牌的 Web 服务（请参看 WS-Security 和 WS-Trust）。也即 STS 基于证据对信任该 STS 的实体做出声明。若要传递信任，服务就需要证据，如某个安全性令牌或安全性令牌组，并且使用它自己的信任声明颁发一个安全性令牌（需要注意的是，对于某些 安全性令牌格式，这可能只需对原始令牌进行重颁发或共同签名）。这也形成了信任代理的基础。

信任 (Trust) － 信任 是一个实体希望依赖于第二方实体以预期的方式执行一组操作和/或对一组主题和/或范围做出一组断言的特性。

信任域/领域 (Trust Domain/Realm) － 信任域/领域 是一个安全性空间，其中的请求目标能够判断来自某个源的特定凭据集是否满足该目标的相关安全性策略。目标可以遵从对第三方的信任，这样，就可以将受信任的第三方包括到信任领域 (Trust Realm) 中。

直接信任 (Direct Trust) － 直接信任 是当依赖方将由请求方发送的令牌中的所有声明（或一些声明子集）作为 true 接受时的信任方式。

直接代理信任 (Direct Brokered Trust) － 直接代理信任 是当一方在信任第二方，第二方依次信任或担保第三方时的信任方式。

间接代理信任 (Indirect Brokered Trust) － 间接代理信任 是直接代理信任的变体，第二方与第三方（或其他方）在其中进行协商，用于评估对第三方的信任的信任方式。

签名验证 (Signature validation) － 签名验证 是验证接收的消息与发送的消息是否相同的过程。

发送方身份验证 (Sender Authentication) － 发送方身份验证 是 Web 服务主角/角色之间的加强的身份验证，以指示 Web 服务消息（及其相关数据）的发送方。需要注意的是，如果存在身份验证的中介体，消息可能会有多个发送方。还要注意的是，如何判断谁是消息的第一创建人是依 应用程序而定的（且不属本文范围），因为消息发信方可能独立于或隐藏在身份验证发送方的后面。

领域或域 (Realm or Domain) － 领域 或域 表示安全性管理或信任的单个单元。

联合 (Federation) － 联合 是由领域集合（至少两个）建立的受信任关系。信任的级别可能会变化，但通常包括身份验证，并可能包括授权。

标识提供商 (Identity Provider) － 标识提供商 是一个担当针对终端请求方的对等实体身份验证服务，以及针对服务提供商的数据源身份验证服务（一般是安全性令牌服务的扩展）的实体。

单一登录 (SSO) － 单一登录 是身份验证序列的优化，用以去除终端请求方面临的重复操作的负担。为了方便 SSO，被称作标识提供商 (Identity Provider) 的元素可以代表请求方担当一个代理，以向请求关于此请求方信息的第三方提供身份验证活动的证据。这些标识提供商是受信任的第三方，并且需要得到请求方（以 维护请求方身份信息，因为这些信息丢失可能会导致请求方身份的泄露）和 Web 服务双方的信任，Web 服务可能基于 IP 提供的身份信息的完整性授予对宝贵资源和信息的访问权限。

标识映射 (Identity Mapping) － 标识映射 是一种创建身份属性之间关系的方法。一些标识提供商可能会利用 id 映像。

注销 － 注销 是主体表明它们将不再使用其令牌且领域中的服务可能破坏此主体令牌缓存的过程。

返回页首

2. 模型

WS-Federation 规范定义了一个模型和消息集合，用于在不同信任领域间代理信任并联合身份和身份验证信息。本章描述了如何将该模型应用于活动请求方（如 Web 服务请求方）。

WS-Federation 中描述的联合模型构建于 WS-Security 和 WS-Trust 建立的基础之上。因此，此概要定义了在活动请求方上下文内请求、交换及颁发安全性令牌的机制。

此规范中定义的模型允许支持不同（但兼容）的消息交换。例如，资源可以担当它自己的安全性令牌服务 (STS)，而并不使用一个单独的服务（或甚至 URI），从而减少一些步骤。后续的概要有望定义成具有特定交换模式的特性。

返回页首

3.1. 单一登录

因为活动请求方 能够发出它们自己的消息，所以它们可以利用 WS-Security、WS-Trust 和 WS-Federation 内定义的机制。

在 高层次上，策略可以用来表明通信需求。请求方可以提前或通过错误响应从服务中获取策略。一般来说，在请求方对自身进行身份验证时，系统要求它们从其标识提 供商（或 STS）处获得安全性令牌（或令牌）。IP/STS 通过联合方生成一个供使用的安全性令牌。该过程是通过使用 WS-Trust 中定义的机制来完成的。有些情况下，目标服务担当它自己的 IP/STS，这使得无需与其他服务进行通信。否则，请求方可能需要从服务特定的或服务所需的标识提供商或安全性令牌服务处获得其他的安全性令牌。下图说 明了一种可能的流程。

然而，以上示例并没有说明这点，即用于安全性令牌的 WS-Trust 消息可能包括对请求方的质询。有关其他信息，请参考 WS-Trust。

返回页首

3.2. 注销

就像针对某个活动请求方登录不具代表性一样，它对注销 也不具代表性。然而，对于那些需要注销的情况而言，则“可以”使用 WS-Federation 中定义的注销消息。

在 需要联合注销消息的情况中，请求方的 IP/STS“应该”保持对其颁发令牌领域 — 特别是这些领域的 IP/STS（或资源，如果不同）的跟踪。当在请求方的 IP/STS 上接收注销时，此请求方的 IP/STS 就负责向有关方和授权方发出联合注销消息。发生此操作采用的确切机制取决于 IP/STS，但强烈“建议”使用 WS-Federation 中定义的注销消息。

当在某个领域中接收到联合的注销消息时，该领域“应该”清除所有的缓冲信息，并删除下图中说明的所有相关状态：

返回页首

3.3. 属性

对于活动请求方，属性服务是通过 WS-Federation 中描述的 WS-Policy 进行标识的。Web 服务和其他授权方可以使用由特定属性服务定义的消息获得或者甚至更新属性。

下 图说明了一个由请求方向 Web 服务发出请求的情况。请求可能包括请求方的策略，或者可能已被缓存在服务中，或者请求方可能使用 WS-PolicyExchange。Web 服务向请求方的属性服务发出请求，以获得一些属性的值，WS-Policy 可以用来描述属性服务的位置。该服务被授权，属性即被返回。请求得到处理，并向请求方返回响应。

返回页首

3.4. 假名 (Pseudonym)

对于活动请求方而言，假名服务是通过 WS-Federation 中描述的 WS-Policy 来标识的。服务和其他授权方可以使用 WS-Federation 中定义的消息来获取或管理假名。

下 图说明了请求方向某个 Web 服务发出请求的情况。该请求可能包括请求方的策略和请求方假名服务的位置，或它可能已被缓存在 Web 服务中。Web 服务向请求方的假名服务发出请求，以获取由安全性令牌授权的假名。授权此 Web 服务，假名即被返回。请求得到处理，并向请求方返回响应。

如 WS-Federation 中所描述的，假名和 IP/STS 可以作为令牌颁发过程的一部分进行交互。下图说明了一种情况，其中，请求方先前已针对特定的领域关联了一个假名和安全性令牌。当请求方请求一个该域/领域 的安全性令牌时，系统就获得其假名和令牌，并返回给请求方。请求方就使用这些安全性令牌来访问 Web 服务。

返回页首

4. 语法

此部分定义了以上模型中描述的联合机制的语法。

返回页首

4.1. 请求安全性令牌

安全性令牌是使用 WS-Trust 规范中定义的 消息进行请求的。

返回页首

4.2. 返回安全性令牌

安全性令牌是使用 WS-Trust 规范中定义的 消息进行返回的。

返回页首

4.3. 注销语法

显式的注销通知是使用 WS-Federation 规范中定义的 消息执行的。

同样地，联合的注销消息使用相同的消息元素。

返回页首

4.4. 属性请求

属性是使用 WS-Federation 规范所描述的属性服务所特有的消息来进行请求和更新的。此规范并不强制使用特定的属性存储技术。

返回页首

4.5. 假名请求

假名是使用 WS-Federation 规范中描述的消息和机制来进行请求和更新的。

返回页首

5. 详解示例

此部分提供了一个本规范中定义的协议的详解示例。确切流程可能会有很大不同；但是，以下图表和说明描述了一个通用 的事件序列。

在此情况中，活动请求方试图访问一个要求安全性身份验证要经过资源的安全性令牌服务进行验证的服务。

步骤 1：获取策略

如果请求方还没有服务策略，就可使用 WS-MetadataExchange 中定义的机制获取该策略。

步骤 2：返回策略

请求的策略是使用 WS-MetadataExchange 中定义的机制返回的。

步骤 3：请求安全性令牌

请求方使用 WS-Trust () 中定义的机制从它的 IP/STS 请求一个安全性令牌（假定是短期的安全性令牌）。

步骤 4：颁发安全性令牌

IP/STS 使用 WS-Trust（ 和 ）中定义的机制返回一个安全性令牌（以及可选的所有权证明信息）。

步骤 5：请求安全性令牌

请求方使用 WS-Trust () 中定义的机制从用于目标 Web 服务的 Web 服务 IP/STS 请求安全性令牌。需要注意的是，这是通过策略或某个带外机制决定的。

步骤 6：颁发安全性令牌

Web 服务的 IP/STS 使用 WS-Trust () 中定义的机制返回一个令牌（以及可选的所有权证明信息）。

步骤 7：发送安全的请求

请求方使用 WS-Security 中描述的颁发令牌向附加并保护此消息的服务发送请求。

步骤 8：返回结果

服务使用它的安全性令牌发出一个安全回复。

返回页首

6. 其他示例

本部分描述了其他活动请求方情况的交互式图表。

返回页首

6.1. 无资源 STS

下图说明了以上的资源访问情况，但没有资源 STS。也即 Web 服务担当它自己的 STS：

返回页首

6.2. 第三方 STS

下图说明了以上的资源访问情况，但信任是通过第三方 STS 代理的：

需要注意的是，第三方 IP/STS 是通过策略或某个带外机制决定的。

返回页首

6.3. 委派的资源访问

下图说明了某个资源代表第一方资源访问来自另一方资源的数据：

本示例中，请求方使用 WS-Trust 中定义的 颁发步骤 1 中的委派令牌。这就向 Web 服务 1 提供了必要的信息，使 Web 服务 1 在与 Web 服务 2 联系时能够代表请求方。

返回页首

7. 安全性令牌

当接受到安全性令牌时，接收者“应该”：

•	验证令牌是否经正确格式化
•	验证 STS 签名
•	验证令牌有效性时间间隔
•	验证策略请求的属性，如所需的身份验证类型、从身份验证时刻起的最大时间（如密码必须在 1 个小时以内提交），以及身份属性等。

本章描述了特定于令牌格式的需求，但并不强制特定令牌类型的用法。

返回页首

7.1. X.509v3

此规范对 X.509 令牌设置了以下要求：

•	除使用安全通道来传递令牌之外，令牌“必须”在整个令牌期间包含颁发机构的名称和颁发机构的签名。也即通过各断言的签名元素。需要注意的是，“建议”使用签名，即使是使用安全通道也是如此。
•	令牌“必须”包含主题标识符，以唯一地标识出被授予此令牌的主题。X.509 并不指定 Principal 字段的规则。遵守此规范的 X.509 令牌“应该”确保颁发的主体在各领域中是唯一的，并且该领域“应该”从主体名称中派生出来。
•	令牌“可以”包含初始身份验证的时间、有效性时间间隔以及执行的身份验证类型。
•	令牌“可以”包含证书吊销信息 (Certificate Revocation Information)，如 CRL 分发点
•	X.509 证书“必须”携带在 wsse:BinarySecurityToken 元素（它的 ValueType 是 wsse:X509v3）内。

返回页首

7.2. Kerberos

此规范对 Kerberos 令牌设置了以下要求

•	Kerberos 票证授权的票证“必须”携带在 wsse:BinarySecurityToken 元素（它的 ValueType 是 wsse:Kerberosv5TGT）内。
•	Kerberos 服务票证“必须”携带在 wsse:BinarySecurityToken 元素（它的 ValueType 是 wsse:Kerberosv5ST）内。
•	使用的对称密钥“应该”从所需领域中派生出来。

返回页首

7.3. XrML

此规范对 XrML 令牌设置了以下要求：

•	处理器“必须”支持带或不带包含的签名的 xrml:issuer 元素。除非 xrml:license 传送密钥（直接或间接），否则处理器“不应”包含所含的签名。
•	包含一个或多个 xrml:issuer 元素中签名的令牌“必须”声明 xrml:license 元素上的所有 XML 命名空间。
•	处理器“必须”包括一个用于标识 xrml:details 下颁发者的 xrml:issuer 元素。
•	当 xrml:license 令牌传送密钥（直接或间接）时，处理器“必须”在 xrml:issuer 元素内包含一个 xrml:validityInterval。xrml:validityInterval“必须”同时包含 xrml:notBefore 和 xrml:notAfter 元素。
•	令牌“应该”包含指示使用范围（如资源或领域）的接收者标识符 — 这是通过 grant resource 表示的，并且默认假定使用了此领域。

返回页首

7.4. SAML

此规范对 SAML 令牌设置了以下要求：

•	除非是使用安全通道传递该令牌，否则令牌“必须”包含颁发机构在整个令牌期间的签名。也即通过 SAML 断言的签名元素。需要注意的是，“建议”使用签名，即使是使用安全通道也是如此。
•	令牌“必须”包含主题标识符，以唯一地标识出被授予此令牌的主题。SAML 并不指定 NameIdentifier 元素的规则。遵守此规范的 SAML 断言“应该”确保颁发的标识符在各领域中是唯一的，并且该领域“应该”从主题标识符中派生出来。
•	令牌“应该”包含指示使用范围（如资源或领域）的接收者标识符 — SAML 断言中的 AudienceRestriction 或 Recipient 元素。
•	令牌“必须”包含初始身份验证的时间、有效性时间间隔以及执行的身份验证类型。SAML 断言中的有效性时间间隔是通过 Conditions 元素的 NotBefore 和 NotOnOrAfter 属性来满足的。初始身份验证类型和时间是通过 AuthenticationStatement 元素的属性来包含的。
•	令牌“可以”包含其他的标识信息。如果包含了其他信息，则描述这些其他信息的架构“必须”能被接收者所理解，否则，该令牌“必须”被拒绝。

返回页首

9. 安全考虑事项

本部分概述了未在 WS-Federation 和其他 Web 服务安全性规范中指出的安全考虑事项。

如果安全性令牌不是自我保护的，它就“应该”被包括在某种形式的消息完整性机制（如 WS-Security 中说明的机制）中。

如果涉及到隐私，则“可以”使用 WS-Security 中描述的机制，为授权的接收者加密安全性令牌。

返回页首

10. 致谢

此规范的制订是许多个人和团体共同努力的结果，包括：

Tim Hahn，IBM

Heather Hinton，IBM

Bronislav Kavsan，RSA Security

Anthony Moran，IBM

Robert Philpott，RSA Security

Yordan Rouskov，Microsoft

Shane Weeden，IBM

Jeff Spelman，Microsoft

返回页首

11. 参考资料

[关键字]

S. Bradner，Key Words for Use in RFCs to Indicate Requirement Levels， RFC 2119，Harvard University，1997 年 3 月。

[SOAP]

W3C 纪要， SOAP:Simple Object Access Protocol 1.1，2000 年 5 月 8 日。

SOAP 1.2，草案 http://www.w3.org/TR/soap12-part0/

SOAP 1.2，草案 http://www.w3.org/TR/soap12-part1/

SOAP 1.2，草案 http://www.w3.org/TR/soap12-part2/

[URI]

T. Berners-Lee、R. Fielding 和 L. Masinter，Uniform Resource Identifiers (URI):Generic Syntax， RFC 2396，MIT/LCS、U.C. Irvine、Xerox Corporation，1998 年 8 月。

[WS-Federation]

"Web Services Federation Language，BEA、IBM、Microsoft、RSA Security 和 VeriSign，2003 年 7 月。

[WS-Security]

"Web Services Security Language，IBM、Microsoft 和 VeriSign，2002 年 4 月。

"WS-Security Addendum，IBM、Microsoft 和 VeriSign，2002 年 8 月。

"WS-Security XML Tokens，IBM、Microsoft 和 VeriSign，2002 年 8 月。

[WS-Policy]

"Web Services Policy Framework，BEA、IBM、Microsoft 和 SAP，2002 年 12 月。

[WS-PolicyAttachment]

"Web Services Policy Attachment Language，BEA、IBM、Microsoft 和 SAP，2002 年 12 月。

[WS-PolicyAssertions]

"Web Services Policy Assertions Language，BEA、IBM、Microsoft 和 SAP，2002 年 12 月。

[WS-Trust]

"Web Services Trust Language，IBM、Microsoft、RSA 和 VeriSign，2002 年 12 月。

[WS-SecureConversation]

"Web Services Secure Conversation Language，IBM、Microsoft、RSA 和 VeriSign，2002 年 12 月。

[WS-SecurityPolicy]

"Web Services Security Policy Language，IBM、Microsoft、RSA 和 VeriSign，2002 年 12 月。

[XML-ns]

W3C 推荐，Namespaces in XML，1999 年 1 月 14 日。