一种分布式资源统一网关转发方法与流程

1.本发明属于数据处理技术领域，特别是涉及一种分布式资源统一网关转发方法。


背景技术：

2.信息资源管理是70年代末80年代初在美国首先发展起来然后渐次在全球传播开来的一种应用理论，是现代信息技术特别是以计算机和现代通信技术为核心的信息技术的应用所催生的一种新型信息管理理论。信息资源管理有狭义和广义之分。狭义的信息资源管理是指对信息本身即信息内容实施管理的过程。广义的信息资源管理是指对信息内容及与信息内容相关的资源如设备、设施、技术、投资、信息人员等进行管理的过程。
3.企业信息资源是企业在信息活动中积累起来的以信息为核心的各类信息活动要素(信息技术、设备、信息生产者等)的集合。企业信息资源管理的任务是有效地搜集、获取和处理企业内外信息，最大限度地提高企业信息资源的质量、可用性和价值，并使企业各部分能够共享这些信息资源。
4.信息技术的爆炸式发展，政府、企业、社会信息化应用的过热式需求，使信息资源从技术应用变成了无处不在的重要经济资源。信息资源牵动着经济增长、体制改革、社会变迁和发展，信息资源管理技术也从单一走向综合，正在形成集各种软件构件于一体的大型平台。用于分布式信息资源管理的信息资源管理平台成为当前及未来信息化推进的关键。
5.api gateway(apigw/api网关)，顾名思义，是出现在系统边界上的一个面向api的、串行集中式的强管控服务，这里的边界是企业it系统的边界，可以理解为企业级应用防火墙，主要起到隔离外部访问与内部系统的作用。在微服务概念的流行之前，api网关就已经诞生了，例如银行、证券等领域常见的前置机系统，它也是解决访问认证、报文转换、访问统计等问题的。
6.api网关的流行，源于近几年来移动应用与企业间互联需求的兴起。移动应用、企业互联，使得后台服务支持的对象，从以前单一的web应用，扩展到多种使用场景，且每种使用场景对后台服务的要求都不尽相同。这不仅增加了后台服务的响应量，还增加了后台服务的复杂性。随着微服务架构概念的提出，api网关成为了微服务架构的一个标配组件。
7.目前常采用的网关转发方法多是基于zuul、spring cloud gateway、nginx实现的，但是zuul、spring cloud gateway无法提供统一的资源地址规则，地址规则只能处理到网关前缀和服务网关路由；多个资源提供方中js、css等静态资源同路径时将无法处理。nginx无法提供统一的资源地址规则，需要大量配置，修改配置需要重启。多个资源提供方中js、css等静态资源同路径时将无法处理；无法完成统一资源鉴权。


技术实现要素：

8.为了解决上述问题，本发明提出了一种分布式资源统一网关转发方法，提供统一资源访问地址且只能通过该地址访问资源，网关中进行统一资源鉴权。
9.为达到上述目的，本发明采用的技术方案是：一种分布式资源统一网关转发方法，
包括步骤：
10.s10,资源提供方携带服务信息和路由信息通知注册中心，注册中心将信息通知资源管理中心构建网关路由；
11.s20,资源使用方通过网关路由访问资源，资源使用方通过资源网关访问api或资源使用方通过资源网关访问html；
12.s30,资源提供方鉴定请求是否经过网关转发。
13.进一步的是，在所述步骤s10中，资源提供方携带服务信息和路由信息通知注册中心，注册中心将信息通知资源管理中心构建网关路由，包括步骤：
14.s11,资源提供方配置服务元数据，说明当前服务为资源提供方；
15.s12,资源提供方启动，发现注册中心，并将自身服务信息发送给注册中心；
16.s13,注册中心收到服务上线消息，将自身服务信息通知资源管理中心；
17.s14,资源管理中心接收到服务变更通知后更新在线服务信息集合，并通知资源管理中心服务内的可刷新路由定位器进行网关路由更新；
18.s15,可刷新路由定位器接收到在线服务变更事件后获取注册中心中所有资源提供方信息并缓存；
19.s16,可刷新路由定位器根据缓存对象提供方生成新的资源提供方路由规则集合提供给网关使用；
20.s17,注册中心监听到服务下线消息，将消息通知资源管理中心；之后资源管理中心执行步骤s14-s16刷新缓存对象提供方和网关路由。
21.进一步的是，所述资源使用方通过资源网关访问api，包括步骤：
22.s211,资源使用方获取资源认证；
23.s212,资源使用方使用统一资源访问地址访问资源管理中心网关，携带资源认证；
24.s213,资源管理中心网关接收请求，获取资源认证和请求路径；
25.s214,资源管理中心网关验证请求路径是否合规，路径规则是否满足网关提供统一资源访问地址规则，不满足则结束请求返回错误信息；
26.s215,资源管理中心网关根据请求路径获取资源提供方服务网关路由、资源类别编码、业务id，根据网关提供统一资源访问地址规则解析拆分；
27.s216,资源管理中心网关根据资源提供方服务网关路由获取资源提供方服务名和是否使用临时资源认证。
28.s217,资源管理中心网关校验资源认证是否有效，无效则结束请求返回错误信息；
29.s218,根据资源认证和资源提供方服务名、资源类别编码、业务id查询资源权限，权限不存在则结束请求返回错误信息；权限存在则根据资源提供方服务名、资源类别编码、业务id获取资源信息；
30.s219,判断资源信息是否存在，不存在则结束请求返回错误信息；资源信息存在，判断资源信息中接口地址是否存在，不存在则结束请求返回错误信息；
31.s2110,资源信息中接口地址存在，网关设置反向代理接口地址；
32.s2111,资源管理中心网关根据资源提供方服务名、资源类别编码、业务id加密生成资源标识信息；
33.s2112,资源管理中心网关将资源标识信息添加到反向代理请求头；
34.s2113,资源管理中心网关反向代理请求到资源提供方，并接收资源提供方返回结果，将结果返回给资源使用方。
35.进一步的是，在步骤s211中资源使用方获取资源认证，包括：
36.资源使用方访问资源管理中心客户端凭证接口，获得资源认证，资源认证信息包含资源使用方服务名和资源使用方服务中文名，不包含用户信息；资源认证权限只能控制到资源使用方服务级，无法控制到用户；
37.资源使用方访问资源管理中心密码式接口，获得资源认证，资源认证信息包含资源使用方服务名、资源使用方服务中文名、用户信息；资源认证权限控制到用户，但资源使用方需要接入资源管理中心单点登录。
38.进一步的是，所述资源使用方通过资源网关访问html，包括步骤：
39.s221,资源使用方获取资源认证；
40.s222,资源使用方使用统一资源访问地址访问资源管理中心网关，携带资源认证；
41.s223,资源管理中心网关接收请求，获取资源认证和请求路径；
42.s224,资源管理中心网关验证请求路径是否合规，路径规则是否满足网关提供统一资源访问地址规则，不满足则结束请求返回错误信息；
43.s225,资源管理中心网关根据请求路径获取资源提供方服务网关路由、资源类别编码、业务id，根据网关提供统一资源访问地址规则解析拆分；
44.s226,资源管理中心网关根据资源提供方服务网关路由获取资源提供方服务名和是否使用临时资源认证。
45.s227,资源管理中心网关校验资源认证是否有效，无效则结束请求返回错误信息；
46.s228,根据资源认证和资源提供方服务名、资源类别编码、业务id查询资源权限，权限不存在则结束请求返回错误信息；权限存在则根据资源提供方服务名、资源类别编码、业务id获取资源信息；
47.s229,判断资源信息是否存在，不存在则结束请求返回错误信息；资源信息存在，判断资源信息中html地址是否存在，不存在则结束请求返回错误信息；资源信息中html地址存在，根据资源提供方服务名获取资源提供方服务地址并与html地址一起构建重定向地址；
48.s2210,资源管理中心网关判断是否使用临时资源认证，如果不使用临时资源认证，则根据资源提供方服务名、资源类别编码、业务id加密生成资源标识信息，将资源认证和资源标识信息作为参数追加到重定向地址；如果使用临时资源认证，根据资源认证、资源提供方服务名、资源类别编码、业务id、临时认证标记生成临时资源认证，将临时资源认证替换原资源认证作为参数追加到重定向地址；
49.s2211,资源管理中心网关终止反向代理逻辑，返回重定向地址到浏览器；浏览器进行重定向，访问资源地址。
50.进一步的是，资源信息中html地址存在，根据资源提供方服务名获取资源提供方服务地址并与html地址一起构建重定向地址，包括步骤：
51.根据资源提供方服务名先从资源管理中心数据库中查询是否设置了资源提供方服务地址，如果设置了则执行下一步；如果没设置则通过微服务注册中心获取资源提供方的ip和端口，生成资源提供方服务地址；
52.构建重定向地址：资源提供方服务地址+资源信息中html地址。
53.进一步的是，在步骤s30中，资源提供方鉴定请求是否经过网关转发，包括步骤：
54.s31，资源提供方接收到主资源请求，获取请求中资源认证；
55.s32，资源提供方校验资源认证是否有效；无效则结束请求返回错误信息；
56.s33，根据资源认证获取其中包含的认证信息；
57.s34，资源提供方根据请求获取资源信息；
58.s35，判断认证信息是否为临时资源认证，是临时资源认证则使用认证信息和资源信息校验请求是否合法，不合法则结束请求返回错误信息；认证信息是临时资源认证且资源信息校验合法，则继续访问资源；认证信息非临时资源认证，则获取请求中资源标识信息；
59.s36，使用资源标识信息和资源信息校验请求是否合法，不合法则结束请求返回错误信息；请求合法，则继续访问资源。
60.采用本技术方案的有益效果：
61.在本发明中资源提供方携带服务信息和路由信息通知注册中心，注册中心将信息通知资源管理中心构建网关路由；资源使用方通过网关路由访问资源，资源使用方通过资源网关访问api或资源使用方通过资源网关访问html；资源提供方鉴定请求是否经过网关转发。本发明使用统一资源访问地址开放多个资源提供方中的资源。本发明限制资源使用方直接访问资源提供方。本发明网关无需配置路由映射关系，自动识别资源提供方网关路由。本发明能适应资源表现形式为api(一个资源为单个请求)场景，也能适应资源表现形式为html场景(一个资源需要多个请求)。本发明能适应资源提供方服务为前后端分离的场景(使用js变量、sessionstorage缓存资源认证)，也能适应资源提供方服务为前后端不分离的场景(使用cookie、localstorage缓存资源认证)。
附图说明
62.图1为本发明的一种分布式资源统一网关转发方法流程示意图；
63.图2为本发明实施例中资源使用方通过资源网关访问api流程示意图；
64.图3为本发明实施例中资源使用方通过资源网关访问html流程示意图；
65.图4为本发明实施例中资源提供方鉴权过程的流程示意图。
具体实施方式
66.为了使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明作进一步阐述。
67.在本实施例中，参见图1所示，本发明提出了一种分布式资源统一网关转发方法，包括步骤：
68.s10,资源提供方携带服务信息和路由信息通知注册中心，注册中心将信息通知资源管理中心构建网关路由；
69.s20,资源使用方通过网关路由访问资源，资源使用方通过资源网关访问api或资源使用方通过资源网关访问html；
70.s30,资源提供方鉴定请求是否经过网关转发。
71.作为上述实施例的优化方案，在所述步骤s10中，资源提供方携带服务信息和路由信息通知注册中心，注册中心将信息通知资源管理中心构建网关路由，包括步骤：
72.s11,资源提供方配置服务元数据，说明当前服务为资源提供方；
73.服务元数据具体包含服务名(一般为英文)、服务中文名、服务类型(值为resource-provider表示当前服务为资源提供方)、服务网关路由(为空则使用服务名)、是否使用临时资源认证。
74.使用临时资源认证适用于html资源提供方前后端分离，临时资源认证缓存(使用js变量、sessionstorag缓存，额外包含资源信息)只对当前浏览器窗口有效。临时资源认证只对当前资源有效，使用临时资源认证访问其他资源无效。
75.不使用临时资源认证适用于html资源提供方前后端不分离或api资源，资源认证缓存(cookie、localstorage缓存，不包含资源信息)作用于所有资源请求。此时请求需要额外参数资源标识信息resource。
76.网关转发请求时必须携带资源信息，资源提供方不光验证资源认证还要验证当前请求的资源与携带的资源信息是否配置。防止了资源使用方直接访问资源提供方(资源使用方是不知道如何在请求上附带资源信息的)。
77.s12,资源提供方启动，发现注册中心，并将自身服务信息(包含资源提供方ip、端口、服务元数据等)发送给注册中心；
78.s13,注册中心收到服务上线消息，将自身服务信息通知资源管理中心；
79.s14,资源管理中心接收到服务变更通知后更新在线服务信息集合(包含资源提供方ip、端口、服务元数据等)，并通知资源管理中心服务内的可刷新路由定位器进行网关路由更新；
80.s15,可刷新路由定位器接收到在线服务变更事件后获取注册中心中所有资源提供方信息并缓存；
81.先获得在线服务信息集合。
82.遍历在线服务信息集合，查找服务类型值为resource-provider的服务。并为满足条件的服务生成资源提供方信息(服务名、服务中文名、服务网关路由、是否使用临时资源认证)
83.将资源提供方信息存入缓存对象providers(键值对类型，键为服务网关路由，值为资源提供方信息)。
84.s16,可刷新路由定位器根据缓存对象提供方providers生成新的资源提供方路由规则集合提供给网关使用；
85.遍历缓存对象providers所有值，获取单个资源提供方信息。
86.根据资源提供方信息生成路由对象。
87.表1主要的资源提供方信息与路由对象映射规则
88.路由对象资源提供方信息路由id服务名服务id服务名路径规则/服务网关路由/**
89.将路由对象加入资源提供方路由规则集合。
90.s17,注册中心监听到服务下线消息，将消息通知资源管理中心；之后资源管理中心执行步骤s14-s16刷新缓存对象提供方providers和网关路由。
91.网关提供统一资源访问地址：资源管理中心地址/网关前缀/资源提供方服务网关路由/资源类别编码/业务id/资源表现形式。
92.作为上述实施例的优化方案，如图2所示，所述资源使用方通过资源网关访问api，包括步骤：
93.s211,资源使用方获取资源认证resourcetoken；
94.方式一，资源使用方访问资源管理中心oauth 2.0客户端凭证接口，获得资源认证resourcetoken，此资源认证信息包含资源使用方服务名(oauth 2.0客户端id)和资源使用方服务中文名(oauth 2.0客户端名称)，不包含用户信息。该资源认证权限只能控制到资源使用方服务级，无法控制到用户。
95.方式二，资源使用方访问资源管理中心oauth 2.0密码式接口。获得资源认证resourcetoken，此资源认证信息包含资源使用方服务名(oauth 2.0客户端id)、资源使用方服务中文名(oauth 2.0客户端名称)、用户信息。该类资源认证权限可控制到用户，但资源使用方需要接入资源管理中心单点登录。
96.s212,资源使用方使用统一资源访问地址访问资源管理中心网关，携带资源认证resourcetoken；
97.s213,资源管理中心网关接收请求，获取资源认证resourcetoken和请求路径uri；
98.s214,资源管理中心网关验证请求路径uri是否合规，路径规则是否满足网关提供统一资源访问地址规则，不满足则结束请求返回错误信息；
99.s215,资源管理中心网关根据请求路径uri获取资源提供方服务网关路由、资源类别编码、业务id，根据网关提供统一资源访问地址规则解析拆分；
100.s216,资源管理中心网关根据资源提供方服务网关路由获取资源提供方服务名和是否使用临时资源认证。
101.使用源提供方服务网关路由作为键从缓存对象providers中获取资源提供方信息，然后从资源提供方信息中获取资源提供方服务名和是否使用临时资源认证。
102.s217,资源管理中心网关校验资源认证resourcetoken是否有效，无效则结束请求返回错误信息；
103.resourcetoken有效性包括，resourcetoken是否存在、是否能正确解密，是否过了有效期。
104.s218,根据资源认证resourcetoken和资源提供方服务名、资源类别编码、业务id查询资源权限，权限不存在则结束请求返回错误信息；
105.根据资源使用方获取资源认证的两种方式：
106.对于方式一，resourcetoken包含资源使用方服务名和资源使用方服务中文名，查询资源使用方服务名是否有该资源的权限。
107.对于方式二，resourcetoken包含资源使用方服务名、资源使用方服务中文名、用户信息(包含用户id)，查询用户是否有该资源的权限。
108.权限存在则根据资源提供方服务名、资源类别编码、业务id获取资源信息；具体包括步骤：
109.(1)网关根据资源提供方服务名获取接口调用工具(本案例以spring cloud下feignclient)，使用接口调用工具访问资源提供方开放查询单个资源信息接口，携带资源类别编码、业务id、携带authorization(资源管理中心认证)。
110.(2)资源提供方接收到访问查询单个资源信息接口，校验authorization是否有效，有效则继续执行返回单个资源信息，未查询到资源信息返回空。
111.(3)单个资源信息结构(json为例)
[0112][0113][0114]
s219,判断资源信息是否存在(判断资源信息是否为空)，不存在则结束请求返回错误信息；资源信息存在，判断资源信息中接口地址是否存在，不存在则结束请求返回错误信息(判断资源信息中resourceapi是否为空或空字符串)；
[0115]
s2110,资源信息中接口地址存在，网关设置反向代理接口地址；
[0116]
s2111,资源管理中心网关根据资源提供方服务名、资源类别编码、业务id加密生成资源标识信息resource；
[0117]
资源管理中心网关给反向代理请求附带资源信息。资源使用方不知道加密方式和秘钥。
[0118]
s2112,资源管理中心网关将资源标识信息resource添加到反向代理请求头(header参数方式)；
[0119]
s2113,资源管理中心网关反向代理请求到资源提供方，并接收资源提供方返回结果，将结果返回给资源使用方。
[0120]
作为上述实施例的优化方案，如图3所示，所述资源使用方通过资源网关访问html，包括步骤：
[0121]
s221,资源使用方获取资源认证resourcetoken；
[0122]
方式一，资源使用方访问资源管理中心oauth 2.0客户端凭证接口，获得资源认证resourcetoken，此资源认证信息包含资源使用方服务名(oauth 2.0客户端id)和资源使用方服务中文名(oauth 2.0客户端名称)，不包含用户信息。该资源认证权限只能控制到资源使用方服务级，无法控制到用户。
[0123]
方式二，资源使用方访问资源管理中心oauth 2.0密码式接口。获得资源认证resourcetoken，此资源认证信息包含资源使用方服务名(oauth 2.0客户端id)、资源使用方服务中文名(oauth 2.0客户端名称)、用户信息。该类资源认证权限可控制到用户，但资源使用方需要接入资源管理中心单点登录。
[0124]
s222,资源使用方使用统一资源访问地址访问资源管理中心网关，携带资源认证resourcetoken；
[0125]
s223,资源管理中心网关接收请求，获取资源认证resourcetoken和请求路径uri；
[0126]
s224,资源管理中心网关验证请求路径uri是否合规，路径规则是否满足网关提供统一资源访问地址规则，不满足则结束请求返回错误信息；
[0127]
s225,资源管理中心网关根据请求路径uri获取资源提供方服务网关路由、资源类别编码、业务id，根据网关提供统一资源访问地址规则解析拆分；
[0128]
s226,资源管理中心网关根据资源提供方服务网关路由获取资源提供方服务名和是否使用临时资源认证。
[0129]
使用源提供方服务网关路由作为键从缓存对象providers中获取资源提供方信息，然后从资源提供方信息中获取资源提供方服务名和是否使用临时资源认证。
[0130]
s227,资源管理中心网关校验资源认证resourcetoken是否有效，无效则结束请求返回错误信息；
[0131]
resourcetoken有效性包括，resourcetoken是否存在、是否能正确解密，是否过了有效期。
[0132]
s228,根据资源认证resourcetoken和资源提供方服务名、资源类别编码、业务id查询资源权限，权限不存在则结束请求返回错误信息；
[0133]
根据资源使用方获取资源认证的两种方式：
[0134]
对于方式一，resourcetoken包含资源使用方服务名和资源使用方服务中文名，查
询资源使用方服务名是否有该资源的权限。
[0135]
对于方式二，resourcetoken包含资源使用方服务名、资源使用方服务中文名、用户信息(包含用户id)，查询用户是否有该资源的权限。
[0136]
权限存在则根据资源提供方服务名、资源类别编码、业务id获取资源信息；具体包括步骤：
[0137]
(1)网关根据资源提供方服务名获取接口调用工具(本案例以spring cloud下feignclient)，使用接口调用工具访问资源提供方开放查询单个资源信息接口，携带资源类别编码、业务id、携带authorization(资源管理中心认证)。
[0138]
(2)资源提供方接收到访问查询单个资源信息接口，校验authorization是否有效，有效则继续执行返回单个资源信息，未查询到资源信息返回空。
[0139]
(3)单个资源信息结构(json为例)
[0140][0141][0142]
s229,判断资源信息是否存在，不存在则结束请求返回错误信息；资源信息存在，判断资源信息中html地址是否存在，不存在则结束请求返回错误信息；
[0143]
判断资源信息中resourceaddress是否为空或空字符串。html地址中只有url路径和参数，不包含服务ip和端口。
[0144]
资源信息中html地址存在，根据资源提供方服务名获取资源提供方服务地址并与html地址一起构建重定向地址；具体包括步骤：
[0145]
根据资源提供方服务名先从资源管理中心数据库中查询是否设置了资源提供方服务地址；如果设置了则构建重定向地址；如果没设置则通过微服务注册中心获取资源提供方的ip和端口，生成资源提供方服务地址：http://ip:端口。
[0146]
构建重定向地址：资源提供方服务地址+资源信息中html地址。
[0147]
s2210,网关判断是否使用临时资源认证，如果不使用临时资源认证，则根据资源提供方服务名、资源类别编码、业务id加密生成资源标识信息resource，将资源认证和资源标识信息作为参数追加到重定向地址；
[0148]
如果使用临时资源认证，根据资源认证、资源提供方服务名、资源类别编码、业务id、临时认证标记生成临时资源认证，将临时资源认证替换原资源认证作为参数追加到重定向地址；
[0149]
临时资源认证包含原resourcetoken所有信息，在并增加资源提供方服务名、资源类别编码、业务id作为资源标识和临时认证标记。oauth 2.0jwt方式加密生成。
[0150]
s2211,网关终止反向代理逻辑，返回重定向地址到浏览器；浏览器进行重定向，访问资源地址。
[0151]
作为上述实施例的优化方案，在步骤s30中，如图4所示，资源提供方鉴定请求是否经过网关转发，包括步骤：
[0152]
s31，资源提供方接收到主资源请求，获取请求中资源认证resourcetoken；
[0153]
对于反向代理api的，请求地址对应步骤s2110。
[0154]
对于重定向html，请求地址对应步骤s2211之后的浏览器发起的主资源请求。
[0155]
s32，资源提供方校验资源认证resourcetoken是否有效；无效则结束请求返回错误信息。
[0156]
resourcetoken有效性包括，resourcetoken是否存在、是否能正确解密，是否过了有效期。
[0157]
s33，根据资源认证resourcetoken获取其中包含的认证信息jwtinfo(解密后的可识别认证信息)；
[0158]
根据资源使用方获取资源认证的两种方式：
[0159]
对于方式一，jwtinfo包含资源使用方服务名和资源使用方服务中文名。
[0160]
对于方式二，jwtinfo包含资源使用方服务名、资源使用方服务中文名、用户信息(包含用户id)。
[0161]
对于执行了步骤s2210使用临时资源认证的，jwtinfo还包含资源提供方服务名、资源类别编码、业务id、临时认证标记。
[0162]
s34，资源提供方根据请求获取资源信息(包含资源类别编码、业务id)；
[0163]
资源提供方根据主资源请求uri路径识别，资源提供方不同资源类别不同识别方式也不同，资源提供方自行处理。
[0164]
主资源请求地址是资源提供方定义提供的，所以资源提供方完全可以解析。
[0165]
s35，判断认证信息jwtinfo是否为临时资源认证(是否包含临时认证标记)，是临时资源认证则使用认证信息jwtinfo和资源信息校验请求是否合法，不合法则结束请求返回错误信息；
[0166]
用jwtinfo中资源提供方服务名，比对当前资源提供方服务名。
[0167]
用jwtinfo中资源类别编码、业务id，比对资源信息中资源类别编码、业务id都对则认为合法。
[0168]
认证信息jwtinfo是临时资源认证且资源信息校验合法，则继续访问资源；认证信
息jwtinfo是非临时资源认证，则获取请求中资源标识信息resource；
[0169]
s36，使用资源标识信息resource和资源信息校验请求是否合法，不合法则结束请求返回错误信息；解密resource获取资源提供方服务名、资源类别编码、业务id(加密对应步骤s2111或s2210)。
[0170]
用resource中资源提供方服务名，比对当前资源提供方服务名；
[0171]
用resource中资源类别编码、业务id，比对资源信息中资源类别编码、业务id；
[0172]
都对则认为合法。
[0173]
请求合法，则继续访问资源。
[0174]
以上显示和描述了本发明的基本原理和主要特征和本发明的优点。本行业的技术人员应该了解，本发明不受上述实施例的限制，上述实施例和说明书中描述的只是说明本发明的原理，在不脱离本发明精神和范围的前提下，本发明还会有各种变化和改进，这些变化和改进都落入要求保护的本发明范围内。本发明要求保护范围由所附的权利要求书及其等效物界定。