CN100399739C - 基于协商通信实现信任认证的方法 - Google Patents

Abstract

本发明公开了一种基于协商通信实现信任认证的方法，信任协商服务端检验协商参数和服务提供端的协商策略匹配，则创建一个服务会话，否则结束；服务请求端判断协商继续，则提取满足访问控制策略的信任证集，否则结束；服务提供端判断信任证满足访问服务提供端的要求，则建立服务提供端和服务请求端之间的安全通信通道，协商完成；否则判断是否继续协商，是则重新执行协商过程，否则结束。通过本发明的方法，实现了跨越多个安全域动态的建立信任关系，避免了预先注册产生大规模用户数据信息及维护；分级别对服务提供端和服务请求端的信息进行了保护；有效保证了网格环境的隐私性和有效性。

Description

基于协商通信实现信任认证的方法

技术领域

本发明涉及一种基于协商通信实现信任认证的方法，特别是一种在跨越多个安全域的网格环境中，通过交互协商通信的方式实现信任关系动态认证的方法。

背景技术

在互联网领域，由于运用网格环境进行计算有效的解决了动态资源共享和协作的问题，因此，获得了越来越多的应用，比如，GGF的开放网格服务体系(Open Grid Service Architecture，简称OGSA)。

但是，出于网格环境安全角度的考虑，网格计算中应用了大量的基础安全技术。同时，在广域开放的网格协作环境中，由于构成网格计算系统的计算机资源通常属于不同的机构或组织，并且使用不同的安全机制，因此需要各个机构或组织共同参与解决多级安全域的问题。

所谓安全域即一个具有集中管理权威和安全策略的封闭域，域内每个活动实体都可映射为域内控制的一种或多种主体身份。也就是说，一个安全域内的服务终端采取同一类型的安全保护，比如防火墙，当其他安全域的服务终端进行访问时，必须获得所访问安全域的信任。由于在广域开放的网络环境中，网格服务往往需要跨越多个安全域，采用多种安全策略，以及解决主体动态变化的问题，因此，服务提供端和请求方之间必须进行访问控制权限的认证以确保资源共享过程中的安全性。

在网格环境中，实施访问控制权限认证的方法主要包括基于身份、基于能力和基于属性进行认证三种方法。

基于身份的权限认证主要应用于早期的网格安全解决方案中，也是网格安全解决方案中应用的较为广泛的一种技术，其代表设施包括GT3.x系统的网格安全基础设施(Grid Security Infrastructure，简称GSI)3以及GT4.x。Globus Toolkit(GT)系统是网格领域著名的开发源码组织Globus推出的网格服务系统，GSI是Globus项目中广泛应用的支持网格应用安全的中间件，GSI3基于Web服务技术进行权限认证，主要分为两个方面：一是遵照WS-Security、WS-SecureConversation和WS-Trust规范实现通信安全机制，包括双向鉴别、加密/解密，二是以简单对象访问协议(Simple Object AccessProtocol，简称SOAP)报文为载体实现委托授权和信任证交换；GT4.x从OGSA/开放网格安全基础设施(Open GSI，简称OGSI)架构过渡到了OGSA/网站服务源框架(Web Services Resource Framework，简称WSRF)架构，增加了新的技术标准如安全断言标记语言(Security Assertion Markup Language，简称SAML)和可扩展的访问控制标记语言(Extensible Access ControlMarkup Language，简称XACML)。但无论是GSI3还是GT4.x，都具有以下缺点：服务访问前必须进行静态配置安全域间的信任关系即进行用户预先注册，依赖于公钥基础设施(Public Key Infrastructure，简称PKI)或者Kerberos协议等实现身份的鉴别和访问授权，常常需要庞大的用户身份证书库；因此带来了对安全管理的负担，影响了网格安全基础设施的可扩展性和灵活性，从而无法满足分散式的网格环境中可扩展性的安全管理和认证机制。

基于能力的认证是将用户能够执行的操作通过信任证封装，这样对用户提交包含能力信息的信任证进行鉴权就可以确定该用户对资源的操作权限，其代表设施包括Akenti、PERMIS等，其显著缺陷是当资源拥有方进行策略修改时，所执行的变动将影响已有授权，不利于维护，也对资源扩展造成影响。

基于属性的认证是通过集成一些基于属性的鉴别和授权系统实现鉴权和信任关系的建立，其代表设施是2005年9月中旬GridShib项目组发布的beta版本，支持Shibboleth和GT的互操作，主要基于Web Service的GT运行环境和Shibboleth身份提供中心(Identity Provider，简称IdP)两个模块，为GT4.x提供通过查询Shibboleth IdP来获取用户的属性信息，并且基于得到的属性执行鉴权和授权决策。另外，OGSA授权工作组(OGSA AuthorizationWorking Group，简称OGSA-AUTHZ)进行规范定义后的Akenti、PERMIS、CAS、VOMS等。OGSA-AUTHZ定义在OGSA框架中实现授权组件的基本互操作性和可插拔性的规范，使上述代表设施能够基于属性应用到网格环境中。可以看出，基于属性的认证通过委托机制和基于属性的访问控制技术，能够跨安全域实现鉴权和建立信任关系，相对比较灵活，但同时也具有以下缺点：首先，委托机制在大规模动态协作应用时需要复杂的信任链，该信任链的建立需要一定的时间，因此，难以实现实时动态鉴权；第二，现阶段还不能提供对复杂信任链的有效系统支持；第三，未考虑对敏感信息的保护，不能维护服务请求端和服务方的隐私信息；第四，采用单独的服务请求端收集属性或者目标服务方收集属性的方法，进行一次性的信任决策，不能区分信任授权的认证级别。

综合来说，随着Grid应用的更加普及，网格环境中的动态性特征日益显著，很多情况下无法为在实体间预先建立信任关系，而是需要在独立的访问过程通过一种快速、有效的机制为数目庞大、动态分散的个体和组织进行鉴权认证并建立信任关系，达成协作或资源访问的目的，并能维护服务的自治性、隐私性等安全需要。而现有技术中，无论基于身份、基于能力还是基于属性的认证方法，都难以满足上述要求。因而，如何在动态无中心的开放网络中，采取有效的机制为数目庞大、动态分散的服务提供端和请求方进行安全认证，从而建立信任关系，就成为当前面临的一个挑战性问题。

发明内容

本发明的目的是为了克服上述缺陷，提出一种基于协商通信实现信任认证的方法，通过服务请求端与提供方之间的会话交互，自动进行安全认证，从而动态的建立信任关系。

本发明的另一目的是为了克服上述缺陷，提出一种基于协商通信实现信任认证的方法，通过保护各方的敏感信任证和访问控制策略，以及验证所签名的公钥来提高可靠性。

本发明的再一目的是为了克服上述缺陷，提出一种基于协商通信实现信任认证的方法，通过平衡鉴权操作和服务访问性能的要求，提高实用性。

为实现上述目的，本发明提供了一种基于协商通信实现信任认证的方法，包括以下步骤：

步骤1、服务请求端生成握手请求报文并发送给信任协商服务端，所述握手请求报文中包括服务请求端的访问对象信息、可验证公钥和协商参数；

步骤2、信任协商服务端接收到握手请求报文，根据所述握手请求报文确定所述服务请求端所请求的服务提供端，并装载所述服务提供端的信任证、协商策略和访问控制策略；

步骤3、所述信任协商服务端比较所述协商参数和服务提供端的协商策略是否匹配，是则在与服务提供端的共享安全上下文环境中创建一个服务会话，保存所述服务会话ID和所述服务请求端的可验证公钥，然后生成握手状态标识为通过的握手响应报文并发送给所述服务请求端，所述握手响应报文中包括服务提供端的访问控制策略；否则生成握手状态标识为未通过的握手响应报文发送给所述服务请求端；

步骤4、所述服务请求端查看所述握手响应报文中的握手状态，如果握手状态为通过，执行步骤5；否则在安全上下文中标识握手状态为失败并结束；

步骤5、服务请求端判断是否继续进行与信任协商服务端的协商，是则所述服务请求端提取满足服务提供端访问控制策略的信任证集，以及保护所述信任证集中敏感信任证的访问控制策略，并封装成协商请求报文发送给所述信任协商服务端，否则在安全上下文中标识协商状态为失败并结束；

步骤6、所述信任协商服务端接收到协商请求报文，获取所述协商请求报文中的访问控制策略和信任证，并判断服务请求端提供的信任证是否满足访问所述服务提供端的要求，是则，执行步骤8，否则执行步骤7；

步骤7、所述信任协商服务端判断是否继续进行与服务请求端的协商，是则向所述服务请求端发送协商状态为尚未建立的协商响应报文，该协商响应报文中包括要求所述服务请求端进一步提供信任证的信息，并重新执行步骤5，否则在共享安全上下文中标识协商状态为失败并结束；

步骤8、所述信任协商服务端向所述服务请求端发送协商状态为建立的协商响应报文，并在共享安全上下文中标识信任关系建立，在所述服务提供端和服务请求端之间建立安全通信通道，将服务会话ID号发送给所述服务请求端并结束。

由上述技术方案可知，本发明通过针对请求进行认证，采用反复协商的方法，具有以下有益效果：

1、跨安全域动态的建立信任关系，避免了预先注册产生大规模用户数据信息维护；

2、根据不同的访问控制策略，分级别的对服务提供端和服务请求端的信息进行了保护；

3、有效保证了网格环境的安全性和有效性。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

图1为本发明基于协商通信实现信任认证的系统的整体示意图；

图2为图1所示系统的具体示意图；

图3为图2所示客户端安全处理模块和服务端安全处理模块的示意图；

图4为本发明基于协商通信实现信任认证的方法实施例1的流程图；

图5为本发明基于协商通信实现信任认证的方法实施例2的流程图；

图6为图5中服务提供端B提供目标服务的流程图；

图7为本发明基于协商通信实现信任认证的方法实施例3的流程图。

具体实施方式

为实现本发明在网格环境中通过协商实现认证的方法，可以利用服务网格的安全支撑设施进行安全处理，参见图1，为本发明基于协商通信实现信任认证的系统的实施例，包括服务请求端A，服务提供端B以及信任协商服务端C；

该信任协商服务端C分别与服务请求端A和服务提供端B连接，用于完成服务请求端A和服务提供端B协商策略以及访问控制策略的信息交互和认证；

该信任协商服务端C与服务提供端B通过服务提供端B的共享安全上下文22连接，该共享安全上下文22用于标记协商状态，并记录协商信息。当信任协商服务端C将协商状态记入该共享安全上下文22中时，服务提供端B即可以从该共享安全上下文22中获取协商状态信息，以决定是否进一步协商。

参见图2，是图1所示实施例的具体组成结构图，其中服务请求端A具体包括：客户端安全处理模块11、安全上下文12、协商引擎13以及操作终端14；服务提供端B具体包括：服务端安全处理模块21、共享安全上下文22和操作终端23；信任协商服务端C具体包括：信任协商接入端31和协商引擎32。

该客户端安全处理模块11与服务提供端B和信任协商服务端C连接，对服务请求端A接收的信息进行解密，并对所述服务请求端A发出的信息进行签名和加密，使加密后的信息具有所述服务请求端A的可验证公钥；

该客户端安全处理模块11还与安全上下文12、协商引擎13及用户操作终端14分别连接，根据具体的信息情况调用安全上下文12及协商引擎13。比如，当该客户端安全处理模块11得到用户操作终端14指令，发起请求时，会根据安全配置中指定的服务请求端A的信任证、访问控制策略和服务访问点信息初始化协商引擎13，调用该协商引擎13生成握手请求报文，对该报文进行加密、签字后，发送出去至信任协商服务端C。再例如，当客户端安全处理模块11获取握手应答报文后，需要调用协商引擎13进行信任证和访问控制策略的采集，并调用安全上下文12进行记录。

该安全上下文12用于标记协商状态，并记录协商信息；该协商引擎13，用于获取所述服务请求端的信任证和访问控制策略，并进行协商控制；该操作终端14可以采用通常的PC机或者移动PC或者其他可进行存储处理的网络设备，进行网格用户操作。

对于服务提供端B，其服务端安全处理模块21与服务请求端A连接，用于对服务提供端B接收的信息进行解密，对所述服务提供端B发出的信息进行签名和加密。

服务端安全处理模块21与共享安全上下文22、操作终端23连接，与所述协商信任服务端连接，根据具体的信息情况调用共享安全上下文22。例如，接收到服务请求端A的会话时，需要调用共享安全上下文22，识别该会话的协商状态，并基于此决定是否许可会话进行。

该共享安全上下文22是服务提供端B与协商信任服务端3共享的安全上下文，标记协商状态，并记录协商信息；服务提供端B与协商信任服务端3通过共享安全上下文22传递协商信息。

操作终端23可以采用通常的PC机或者移动PC或者其他可进行存储处理的网络设备，进行网格用户操作。

对于协商信任服务端3，其信任协商接入端31，与服务请求端A、共享安全上下文22、协商引擎32连接，用于与服务请求端A进行信息交互，根据接收信息调用对应的协商引擎32进行协商处理，并将协商记录和协商结果记录进入共享安全上下文22。该协商引擎32，用于获取所述服务提供端B的信任证、协商策略和访问控制策略，并进行协商控制。

信任协商服务端C以及服务提供端B可以布置在一个服务容器中。

该信任协商服务端C可能同时为多个服务提供端提供会话认证服务，也就是说，该信任协商服务端C可能同时共享多个服务提供端的共享安全上下文。

进一步的，服务请求端A和服务提供端B是随机动态产生的，当网格资源A’的网格用户A1发现网格资源B’的目标终端B1上具有其需要的资源时，进行服务关系的建立。此时，网格资源A’成为服务请求端，网格资源B’成为服务提供端。假设一个物理学家在一个国际合作组织团体中进行科学研究，他收到同事的一封关于新的实验数据讨论的邮件，然后登陆到自己所在的网格资源A’中的一台工作站A1并启动一个用户代理程序，该用户代理程序代表他运行一个物理分析程序，而这个物理分析程序需要访问存储在远程站点B’中的数据存储系统中的一些数据。在物理分析程序运行过程中，为了比较试验结果与预期的结果，它可能需要启动另一个用于物理模拟的程序。于是，站点A’中的用户代理与合作站点C’中的资源代理联系，以查找网格中能够用来进行物理模拟的闲散计算资源。通过查找分析，站点C’中的资源代理找到了站点D’和站点E’上的闲散计算资源，于是资源代理分别在两个站点(D’和E’)中的主机上同时启动了与物理模拟相关的计算，而这些计算都需要访问存放在另一个站点F’上的一些参数值。这样，该物理学家所在的网格资源A’就成为服务请求端，而站点B’、C’、D’、E’和F’成为了服务提供端。其中，站点B、C、D、E和F可以属于同一网格资源，也可属于不同的网格资源。属于同一网格资源的服务提供端具有同一信任协商服务端C’。

在上述实施例中客户端安全处理模块11和服务端安全处理模块21的结构相同，以客户端安全处理模块11为例，如图3所示，包括安全处理链1a、安全上下文管理器1b、信任证管理器1c、配置策略管理器1d、异常处理模块1e以及认证管理器1f。

例如，当服务请求端A中的网格用户14需要调用服务提供端B目标终端23上的资源时，其安全处理链1a启动，初始化协商引擎13，通过安全上下文管理器1b确定会话的安全上下文环境，并将该会话的信息记录在安全上下文12中，最后由认证管理器1f生成握手请求报文，由安全处理链1a加密、签字发送给信任协商服务端C。

服务提供端B的服务端安全处理链21通过安全处理链1a对接收到的会话进行解密，并通过安全上下文管理器1b获取协商状态消息，通过认证管理器1f进行会话有效性鉴权。

参见图4，为本发明基于协商通信实现信任认证的方法的实施例1的流程图，包括以下步骤：

步骤101、服务请求端A生成握手请求报文并发送给信任协商服务端C，该握手请求报文中包括服务请求端的访问对象信息、可验证公钥和协商参数，该协商参数包括服务请求端A所支持的协商策略类型信息和访问控制策略的描述规范语言等信息；

步骤102、信任协商服务端C接收到握手请求报文，根据握手请求报文确定所述服务请求端A所请求的服务提供端为B，并装载服务提供端B的信任证、协商策略和访问控制策略，其中，信任协商服务端C可以通过初始化协商引擎来装载服务提供端B的信任证、协商策略和访问控制策略；

步骤103、信任协商服务端C比较所述协商参数和服务提供端B的协商策略是否匹配，即比较协商策略类型和访问控制策略的描述规范语言是否匹配，匹配则执行步骤104，否则生成握手状态标识为未通过的握手响应报文发送给所述服务请求端A并执行步骤106；

步骤104、信任协商服务端C在与服务提供端B的共享安全上下文环境中创建一个服务会话，生成并保存所述服务会话ID，保存服务请求端A的可验证公钥；

步骤105、信任协商服务端C生成握手状态标识为通过的握手响应报文并发送给服务请求端A，所述握手响应报文中包括服务提供端B的访问控制策略；

步骤106、服务请求端A查看所述握手响应报文中的握手状态，如果握手状态通过，执行步骤107；否则证明双方无法进行沟通，比如双方的访问控制策略的描述规范语言不相同时，就不可能进行进一步协商，则在安全上下文中标识握手状态为失败并结束；

步骤107、服务请求端A判断是否继续进行与信任协商服务端的协商，是则执行步骤108，否则在安全上下文中标识协商状态为失败并结束；

步骤108、所述服务请求端A提取启动协商引擎，调取满足服务提供端访问控制策略的信任证集，以及保护所述信任证集中敏感信任证的访问控制策略，并封装成协商请求报文发送给所述信任协商服务端C；

步骤109、信任协商服务端C接收到协商请求报文，获取所述协商请求报文中的访问控制策略和信任证，并判断服务请求端A提供的信任证是否满足访问所述服务提供端B的要求，是则，执行步骤112，否则执行步骤110；

步骤110、信任协商服务端C判断是否继续进行与服务请求端的协商，是则执行步骤111，否则在共享安全上下文中标识协商状态为失败并结束；

步骤111、信任协商服务端C向服务请求端A发送协商状态为尚未建立的协商响应报文，该协商响应报文中包括要求所述服务请求端进一步提供信任证的信息，并重新执行步骤107；

步骤112、信任协商服务端C向所述服务请求端A发送协商状态为建立的协商响应报文，并在共享安全上下文中标识信任关系建立，在所述服务提供端A和服务请求端B之间建立安全通信通道，将服务会话ID号发送给所述服务请求端A并结束。

在本实施例中，通过交互为服务提供端提供认证并建立保护，避免了由于用户预先授权而产生的大规模用户数据信息维护，也避免了预先注册的步骤，因此，无须同时进行大批量的鉴权，平衡了鉴权操作和服务访问性能的要求，提高系统的实用性。

同时，本实施例所提供的方法中经过了反复的协商通信，可以为不同安全级别的服务提供端提供信任关系的认证保护。

进一步的，在步骤109中，同时可以验证服务提供端的信任证是否满足服务请求端敏感信任证的访问控制策略的要求，作为信任协商服务端判断是否继续协商的标准之一，实现对服务请求端建立信任关系的认证保护。

参见图5，为本发明基于协商通信实现信任认证的方法实施例2的流程图，包括以下步骤：

步骤201至步骤212与实施例1中的步骤101至步骤112相同；

步骤213、服务请求端A将所述服务会话ID插入会话文件头，将会话信息通过所述安全通信通道发送给所述服务提供端B进行访问；

步骤214、服务提供端B提供目标服务。

其中，上述步骤214是获得了认证并且认证时效之内进行服务交互的处理方法，也就是无须判断直接提供服务的处理步骤。

但可能存在下述情况：

1、服务请求端A获得的服务ID不是与服务提供端B交互获得的服务ID，即不存在与该服务提供端B的认证会话记录；

2、服务请求端A未获得服务提供端B的服务会话ID；

3、服务请求端A获得的会话ID已经失效；

因此，步骤214往往经过一系列的判断，因此比较好的提供服务方法如图6所示，包括以下步骤：

步骤2141、服务提供端B接收到服务请求端A发送的会话消息，服务提供端B提取文件头中的服务会话ID；

步骤2142、服务提供端B查询与所述信任协商服务端C共享的安全上下文，检索是否存在该服务会话ID的认证会话记录，是则执行步骤2143，否则执行步骤2146；

步骤2143、服务提供端B在所述共享安全上下文中查询对所述服务会话ID的认证是否通过，通过则执行步骤2144，否则执行步骤2146；

步骤2144、服务提供端B查询所述会话消息携带的可验证公钥和在所述共享安全上下文中保存的可验证公钥是否匹配，是则所述服务请求端A为通过认证的服务请求端，执行步骤2145，否则执行步骤2146；

步骤2145、服务提供端B为服务请求端A提供目标服务，结束；

步骤2146、服务提供端B向服务请求端A返回无效信息并结束。

参见图7，是本发明基于协商通信实现信任认证的方法实施例3的流程图，通过申请临时信任证，提供一种避免短时间内重复协商的方法，即服务请求端发送握手请求报文时，附带请求生成临时信任证，从而在下次访问相同目标服务时直接传送临时信任证而不再经过认证过程，有效提高认证的效率，包括以下步骤：

步骤301、服务请求端A生成握手请求报文并发送给信任协商服务端C，该握手请求报文中包括服务请求端的访问对象信息、可验证公钥和协商参数，同时请求临时信任证；

步骤302至步骤312与实施例1中的步骤102至步骤112相同；

步骤313、信任协商服务端C使用私钥签发一份临时信任证，通过安全通信通道发送给服务请求端A，并结束。

其中，步骤301中，服务请求端可以在生成握手请求报文时，同时将报文中的临时信任证请求标识设置为True，实现对临时信任证的生成请求。

在步骤313之后，还可以包括：

步骤314、服务请求端A将会话信息和临时信任证通过所述安全通信通道发送给服务提供端B进行访问；以及

步骤315、服务提供端B获取临时信任证；

步骤316、服务提供端B检查临时信任证是否有效，有效则执行步骤317，否则向服务请求端A返回无效信息并结束；

步骤317、服务提供端B向所述服务请求端A提供目标服务。

通过实施例1、2和3，可以看出，基于信任证和访问控制策略，有效地提供了目标服务保护敏感信息的需求。

最后所应说明的是，以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或者等同替换，而不脱离本发明技术方案的精神和范围。

Claims (6)

1.一种基于协商通信实现信任认证的方法，其特征在于包括以下步骤：

步骤1、服务请求端生成握手请求报文并发送给信任协商服务端，所述握手请求报文中包括服务请求端的访问对象信息、可验证公钥和协商参数；

步骤2、信任协商服务端接收到握手请求报文，根据所述握手请求报文确定所述服务请求端所请求的服务提供端，并装载所述服务提供端的信任证、协商策略和访问控制策略；

步骤3、所述信任协商服务端检验所述协商参数和服务提供端的协商策略是否匹配，是则在与服务提供端的共享安全上下文环境中创建一个服务会话，保存所述服务会话ID和所述服务请求端的可验证公钥，然后生成握手状态标识为通过的握手响应报文并发送给所述服务请求端，所述握手响应报文中包括服务提供端的访问控制策略；否则生成握手状态标识为未通过的握手响应报文发送给所述服务请求端；

步骤4、所述服务请求端查看所述握手响应报文中的握手状态，如果握手状态为通过，执行步骤5；否则在安全上下文中标识握手状态为失败并结束；

步骤5、服务请求端判断是否继续进行与信任协商服务端的协商，是则所述服务请求端提取满足服务提供端访问控制策略的信任证集，以及保护所述信任证集中敏感信任证的访问控制策略，并封装成协商请求报文发送给所述信任协商服务端，否则在安全上下文中标识协商状态为失败并结束；

步骤6、所述信任协商服务端接收到协商请求报文，获取所述协商请求报文中的访问控制策略和信任证，并判断服务请求端提供的信任证是否满足访问所述服务提供端的要求，是则，执行步骤8，否则执行步骤7；

步骤7、所述信任协商服务端判断是否继续进行与服务请求端的协商，是则向所述服务请求端发送协商状态为尚未建立的协商响应报文，该协商响应报文中包括要求所述服务请求端进一步提供信任证的信息，并重新执行步骤5，否则在所述共享安全上下文中标识协商状态为失败并结束；

步骤8、所述信任协商服务端向所述服务请求端发送协商状态为建立的协商响应报文，并在所述共享安全上下文中标识信任关系建立，在所述服务提供端和服务请求端之间建立安全通信通道，将服务会话ID号发送给所述服务请求端并结束。

2.根据权利要求1所述的方法，其特征在于所述步骤8之后还包括：

步骤9、所述服务请求端将所述服务会话ID插入会话文件头，将会话信息通过所述安全通信通道发送给所述服务提供端进行访问的步骤。

3.根据权利要求2所述的方法，其特征在于所述步骤9之后还包括：

步骤10、所述服务提供端提供目标服务，具体为：

步骤10a、所述服务提供端接收到所述服务请求端发送的会话消息，所述服务提供端提取文件头中的服务会话ID；

步骤10b、所述服务提供端查询共享安全上下文，检索是否存在该服务会话ID的认证会话记录，是则执行步骤10c，否则向所述服务请求端返回无效信息并结束；

步骤10c、所述服务提供端在所述共享安全上下文中查询对所述服务会话ID的认证是否通过，通过则执行步骤10d，否则向所述服务请求端返回无效信息并结束；

步骤10d、所述服务提供端查询所述会话消息携带的可验证公钥和在所述共享安全上下文中保存的可验证公钥是否匹配，是则服务提供端为所述服务请求端提供目标服务，否则向所述服务请求端返回无效信息并结束。

4.根据权利要求1所述的方法，其特征在于当步骤1中的服务请求端在握手请求报文中设置临时信任证请求标识时，在所述步骤8中，将服务会话ID号发送给所述服务请求端之后，还设有：所述信任协商服务端根据已接收的握手请求报文中临时信任证请求标识，使用私钥签发一份临时信任证，发送给所述服务请求端的步骤。

5.根据权利要求4所述的方法，其特征在于所述步骤8之后还包括：

步骤9’、所述服务请求端将会话信息和所述临时信任证通过所述安全通信通道发送给所述服务提供端进行访问的步骤。

6.根据权利要求5所述的方法，其特征在于所述步骤9’之后还包括：

步骤10a’、所述服务提供端获取临时信任证；

步骤10b’、所述服务提供端检查所述临时信任证是否有效，有效则执行步骤10c’，否则向所述服务请求端返回无效信息并结束；

步骤10c’、所述服务提供端向所述服务请求端提供目标服务。

Images