服务调用者将Token再重组为Ticket

　　服务调用者获取到Token后，将自行组装Ticket。此Ticket将用于下一步骤的服务调用，并可被服务提供者验证并信任。

　　Ticket格式定义如下：

　　(InvokerPart，ProviderPart，ArgumentsSignature)

　　InvokerPart格式：SessionKey(Timestamp, InvokerId)

　　其中Timestamp为当前Invoker的系统时间。

　　ArgumentsSignature格式如下：

　　SessionKey(MD5(Timestamp, Arguments))

　　即首先把所有参数连接后，加入Timestamp作为扰乱信息。然后通过MD5取得信息摘要，最后用SessionKey加密。此参数签名用于防止网络传输过程中Web Service的参数被篡改。

　　服务提供者验证服务调用者的合法性

　　RequestToken 将是唯一一个不需要Ticket参数的服务。即凡是使用本研究所描述的模型的应用，在对外提供服务时，将要求服务调用者提供Ticket参数，并在每次服务调用时通过此参数(Ticket)验证来获得对Invoker的信任关系。

　　服务提供者收到Ticket以后，首先通过ProviderKey 来解密ProviderPar t 获得SessionKey，然后通过SessionKey 解密InvokerPart和ArgumentsSignature，之后服务提供者对Ticket做如下验证：

　　1. 验证ProviderPart和InvokerPart的InvokerId

　　2. 验证Expire Timeout(可设定)<=Timestamp <= Expire。此处考虑到网络延时、服务器时间的不同步等，在检查时将有少量的容错的偏移。

　　3. 验证InvokerIP是否一致，服务提供者可从Request中获取。此处考虑的网络拓扑等因素，要求InvokerIP对应于统一授权服务的IP和对应于服务提供者的IP必须是相同的。当此要求不被满足时，此检查将通过一定方式跳过。

　　4.验证参数摘要ArgumentsSignature。

　　如果验证通过，则此次服务调用将被认为可信，并有助于服务提供者获得调用者的更详尽信息。

　　本文通过提出应用间的信任模型，以解决高校内部各个应用系统之间在不安全的网络环境中的信任问题，并且已经在上海交通大学的多个应用系统中实施运行。但此模型依然存在一些问题，其中一个问题是单向信任的问题。出于效率考虑，本模型仅仅可供服务的提供者来信任服务的调用者，而没法保证服务的调用者调用到的服务是可信任的。

　　另外一个问题是服务的信任级别和信任粒度问题。OAuth可以有更细的、权限级别的应用间信任的粒度，而本模型只能提供应用级别的信任，服务级、接口级或者权限级别的粒度的信任，还是一个有待研究的问题。

　　(作者单位为上海交通大学网络信息中心)

　　扩展文献：

　　[1]http://web.mit.edu/kerberos/www/：Kerberos:The Network Authentication Protocol.

　　[2]The Kerberos Network Authentication Service (V5), RFC1510.

　　[3]http://zh.wikipedia.org/wiki/Kerberos, 2011/04/05有效.

　　[4] 茅维华，谢金宝，Web 应用单一登录的类Kerberos 实现，计算机应用与软件，2004年2月,pp.87-90.

　　[5]白雪松，茅维华，身份与权限体系关键技术的总体设计与实践，中山大学学报(自然科学版)，200948(z1)：260-263页.

　　[6] http://zh.wikipedia.org/wiki/OAuth2011/04/05有效.