跨系统的权限管理方法、装置、电子设备和存储介质与流程

1.本技术涉及移动互联技术领域，尤其涉及一种跨系统的权限管理方法、装置、电子设备和存储介质。


背景技术：

2.现有的系统权限管理，通常是基于用户身份的访问管理来实现。用户通过身份认证后，在系统中就具备了相应身份关联的所有权限，用户难以对每个请求所允许访问资源的权限进行控制。因此，用户在跨系统交互时，特别是不同系统归属于不同组织的情况，如果被用户授权的系统拥有用户在其他系统所具有的所有权限，执行一些用户并不期望进行的操作，这将存在极大的安全隐患。
3.针对上述跨系统的权限管理中存在的问题，现有的oauth2.0协议提供了一套能够允许用户将部分系统资源访问权限授权给其他系统的机制。但是，这种方式是一次将一组权限赋予指定系统，相当于指定系统在一段时间内具备了用户在授权系统上的部分权限。因此，这种授权方式仍然难以控制到用户的每一个具体请求，安全隐患依然存在。


技术实现要素：

4.本技术提供一种跨系统的权限管理方法、装置、电子设备和存储介质，以解决现有技术中的跨系统授权方式仍然难以控制到用户的每一个具体请求的技术问题。
5.第一方面，本技术提供了一种跨系统的权限管理方法，该方法包括：
6.接收用户的业务请求，所述业务请求中包括所述用户构建的请求参数和能力信息，其中，所述能力信息用于记载所述用户分别对当前系统和外部系统授权执行的权限；
7.根据所述请求参数和能力信息处理所述业务请求；
8.响应于处理所述业务请求过程中对所述外部系统的调用需求，将生成的调用请求发送至所述外部系统，其中，所述调用请求中包括所述能力信息；
9.接收所述外部系统根据所述能力信息对所述调用请求进行处理的返回结果，并根据所述返回结果完成对所述业务请求的处理。
10.第二方面，本技术还提供了一种跨系统的权限管理装置，该装置包括：
11.业务请求接收模块，用于接收用户的业务请求，所述业务请求中包括所述用户构建的请求参数和能力信息，其中，所述能力信息用于记载所述用户分别对当前系统和外部系统授权执行的权限；
12.业务请求处理模块，用于根据所述请求参数和能力信息处理所述业务请求；
13.调用请求发送模块，用于响应于处理所述业务请求过程中对所述外部系统的调用需求，将生成的调用请求发送至所述外部系统，其中，所述调用请求中包括所述能力信息；
14.所述业务请求处理模块，还用于接收所述外部系统根据所述能力信息对所述调用请求进行处理的返回结果，并根据所述返回结果完成对所述业务请求的处理。
15.第三方面，本技术还提供了一种电子设备，包括：
16.一个或多个处理器；
17.存储装置，用于存储一个或多个程序，
18.当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如上所述的跨系统的权限管理方法。
19.第四方面，本技术还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上所述的跨系统的权限管理方法。
20.本技术的技术方案中，通过在请求中附加能力信息，并使其在服务调用链中能被跨系统传递，实现了为每个请求附加更细粒度的权限控制，确保用户在跨系统授权访问时，中间系统无法欺骗用户去做一些用户不期望做的操作。同时，用户也能够为每个请求附加不同的权限限制，提高了跨系统权限控制的灵活性和安全性。
附图说明
21.图1是本技术实施例一中的跨系统的权限管理方法的流程图；
22.图2是本技术实施例二中的跨系统的权限管理方法的流程图；
23.图3是本技术实施例三中的跨系统的权限管理方法的流程图；
24.图4是本技术实施例四中的跨系统的权限管理方法的流程图；
25.图5是本技术实施例五中的跨系统的权限管理方法的流程图；
26.图6是本技术实施例六中的跨系统的请求执行流程示意图；
27.图7是本技术实施例七中的跨系统的权限管理装置的结构示意图；
28.图8是本技术实施例八中的电子设备的结构示意图。
具体实施方式
29.下面结合附图和实施例对本技术作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本技术，而非对本技术的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本技术相关的部分而非全部结构。
30.当前的系统权限控制方法大部分是基于用户身份来实现的，即将用户(角色或组)关联访问权限，当用户通过系统的身份认证以后，就可以被授权访问相关的资源，执行相关的操作。这相当于是对系统资源设置一个访问控制列表(acl)，这种方式将“指示”和“权力”分离开了。用户通过认证后，用户与系统的每一次交互，系统内部逻辑都可以访问用户权力范围内的资源，尽管用户可能不希望如此。例如，用户具有一个系统的查询a资源和修改b资源的权限，用户发起查询a资源的请求，但系统内部有可能执行了修改b资源的操作，然而这并不是用户想要的。
31.上述的这种情况在访问单系统或者组织内部的多系统时可能可以接受，用户使用某系统就表示愿意信任该系统对系统内部资源的操作是合理的。但是当涉及跨组织的系统交互(跨系统)时，这样做就会存在很大的安全隐患。例如，有两个系统sa和sb，用户ua具有系统sb的读写资源rb1和rb2的权限，系统sa可以在用户的授权下和系统sb交互，当用户ua向系统sa发起一个请求，这个请求内部需要读写系统sb的资源rb1，但系统sa在获取用户授权的时候，可能会要求用户授权对系统sb的所有权限，然后执行一些用户意料之外的操作。
32.本技术在现有的基于身份的权限控制基础之上，通过引入能力模型，使得用户能
够对每一个请求都设置一个最小的资源访问权限，尽可能防止系统欺骗用户去做一些用户不期望做的事情。
33.实施例一
34.图1为本技术实施例一提供的跨系统的权限管理方法的流程图，本实施例可适用于在跨系统调用的场景中进行用户权限管理的情况，涉及移动互联技术领域。该方法可以由跨系统的权限管理装置来执行，该装置可以采用软件和/或硬件的方式实现，优选是配置于电子设备中，例如智能终端、计算机设备或服务器等。如图1所示，该方法由任意的当前系统，该当前系统可以运行在所述电子设备中。其中，所述方法具体包括：
35.s101、接收用户的业务请求，所述业务请求中包括用户构建的请求参数和能力信息，其中，所述能力信息用于记载用户分别对当前系统和外部系统授权执行的权限。
36.其中，业务请求可以是用户在当前系统发起的任意业务请求，请求参数中包含了当前系统处理该业务所需的必要参数，本技术对此不作任何限定。此外，在本技术实施例中，除需要用户构建请求参数之外，还需要构建能力信息，并将能力信息和请求参数封装在一起构成业务请求发送至当前系统。
37.能力信息用于记载用户分别对当前系统和外部系统授权执行的权限。也就是说，在实现当前业务过程中，存在当前系统调用外部系统的需求，属于跨系统的业务处理场景。那么，为了确保当前系统不会以用户的身份在外部系统进行一些具有用户权限但用户不期望进行的操作，就需要在发送业务请求时附带能力信息，对当前系统和外部系统分别授予哪些权限进行声明。通过能力信息的构建，将“指示”和“权力”两者结合在一起，用户“指示”系统执行某个操作的同时，将需要用到的“权力”附加其上，这样系统将没有“权力”执行用户“指示”之外的操作。
38.s102、根据请求参数和能力信息处理业务请求。
39.当前系统在获取到业务请求后，就可以从中提取能力信息，以及能力信息中与当前系统有关的用户授予执行的权限，然后在该权限范围内处理业务请求，实现访问控制。
40.s103、响应于处理业务请求过程中对所述外部系统的调用需求，将生成的调用请求发送至所述外部系统，其中，调用请求中包括所述能力信息。
41.当需要调用外部系统来完成该业务请求的处理时，当前系统会生成针对该外部系统的调用请求，同时附带s101步骤中获取到的能力信息。也就是说，该能力信息会在跨系统的调用链上的各级系统间层层转发，使得外部系统也能获取到用户构建的能力信息，以使外部系统根据该能力信息中用户授予的权限进行操作。
42.s104、接收所述外部系统根据所述能力信息对调用请求进行处理的返回结果，并根据返回结果完成对业务请求的处理。
43.当外部系统基于能力信息中的权限操作完毕，并返回结果，当前系统则可以根据该返回结果，继续完成业务请求的处理，并将最终的处理结果返回给用户。
44.由此，在上述跨系统的业务处理过程中，不管是当前系统还是外部系统，其在执行业务逻辑时，都需要额外检查外部请求中的能力信息里是否包含相应的授权信息，这样就确保了用户能够对每次系统请求都只赋予最小的权限，实现更细粒度的权限控制，防止系统欺骗用户去做一些用户不期望做的操作，提高跨系统权限控制的安全性。同时，通过能力信息的构建，还可以实现为每个请求附加不同的权限限制，提高了跨系统权限控制的灵活
性。
45.本技术实施例的技术方案中，通过在请求中附加能力信息，并使其在服务调用链中能被跨系统传递，实现了为每个请求附加更细粒度的权限控制，确保用户在跨系统授权访问时，中间系统无法欺骗用户去做一些用户不期望做的操作。同时，用户也能够为每个请求附加不同的权限限制，提高了跨系统权限控制的灵活性和安全性。
46.实施例二
47.图2为本技术实施例二提供的跨系统的权限管理方法的流程图，本实施例在上述实施例的基础上进行进一步地优化。如图2所示，所述方法包括：
48.s201、接收用户的业务请求，所述业务请求中包括所述用户构建的请求参数和能力信息，其中，所述能力信息用于记载所述用户分别对当前系统和外部系统授权执行的权限。
49.具体的，所述能力信息中包括用户标识、权限内容和用户对权限内容的签名；其中，权限内容中包括当前系统和外部系统各自对应的系统标识、权限编号列表、token以及根据所述系统标识、权限编号列表和token计算出的哈希值。
50.其中，用户标识即为用户的唯一标识。权限内容中包括跨系统的场景中所涉及到的各个系统的权限内容。本技术实施例中的跨系统场景涉及到当前系统和任意的外部系统，因此，权限内容中包括当前系统的系统标识、权限编号列表、token以及根据当前系统的这些内容计算出的哈希值，还包括外部系统的系统标识、权限编号列表、token以及根据外部系统的这些内容计算出的哈希值。哈希值的计算可以采用任意的非对称加密算法来进行，目的是为了后面对能力信息是否被篡改进行验证。需要说明的是，如果跨系统的业务处理场景中存在两个以上的系统，则依然按照本技术实施例中描述的方法实现，能力信息的权限内容中则包括每个所涉系统的系统标识、权限编号列表、token以及根据所述系统标识、权限编号列表和token计算出的哈希值。
51.每个系统都可以有属于自己的权限划分机制，基于各自的机制，预先为每个系统中的权限进行编号，当用户构建能力信息时，就可以根据需要生成权限内容个的权限编号列表。其中，权限编号列表中可以包括一个或一个以上的权限的编号。
52.此外，考虑到系统性能的原因，对所述权限内容的签名可以只是利用用户的私钥，对权限内容中当前系统和外部系统各自对应的哈希值的拼接字符串计算得到。例如，利用任意的非对称加密算法计算得到。
53.s202、获取用户标识对应的公钥，并利用公钥对签名进行验签。
54.通过签名验签可以验证能力信息是否被篡改，尤其是在跨系统的权限管理过程中，能力信息需要被跨系统传递，因此，验证能力信息是否被篡改，就更加具有必要性，其直接影响跨系统权限控制的安全性。
55.具体而言，可以结合非对称加密技术来实现，包括：
56.根据签名和公钥计算权限内容的第一哈希值；将权限内容中当前系统和外部系统各自对应的哈希值进行拼接，得到拼接字符串，并根据拼接字符串计算第二哈希值；比较第一哈希值和第二哈希值，如果比较结果为相等，则验签通过。
57.由此，利用非对称加密算法，先由用户利用私钥对权限内容进行签名，然后由当前系统利用公钥和签名反算出一个哈希值，如果该哈希值与根据能力信息中记载的信息计算
出的哈希值相同，则签名验签通过，表明能力信息在跨系统传递的过程中未被篡改，反之，则表明能力信息可能被篡改，此时可做报错处理等，本技术对此不作任何限定。
58.s203、如果签名验签通过，则根据请求参数和能力信息处理业务请求。
59.s204、响应于处理业务请求过程中对外部系统的调用需求，将生成的调用请求发送至外部系统，其中，所述调用请求中包括所述能力信息。
60.s205、接收外部系统根据能力信息对调用请求进行处理的返回结果，并根据返回结果完成对业务请求的处理。
61.需要说明的是，外部系统在处理调用请求之前，出于安全性的考虑，也需要验证一下接收到的能力信息是否被篡改，当验证未被篡改，则可以基于能力信息中的权限内容进行业务处理。其中，外部系统验证能力信息是否被篡改的方式与本实施例中描述的当前系统的上述验证方式相同，此处不再赘述。
62.本技术实施例的技术方案，通过在请求中附加能力信息，并使其在服务调用链中能被跨系统传递，实现了为每个请求附加更细粒度的权限控制，提高了跨系统权限控制的灵活性和安全性。同时，还利用非对称加密算法来验证能力信息是否被篡改，进一步确保了跨系统权限控制的安全性。
63.实施例三
64.图3为本技术实施例三提供的跨系统的权限管理方法的流程图，本实施例在上述实施例的基础上进行进一步地优化。如图3所示，所述方法包括：
65.s301、接收用户的业务请求，所述业务请求中包括用户构建的请求参数和能力信息，其中，所述能力信息用于记载用户分别对当前系统和外部系统授权执行的权限。
66.具体的，所述能力信息中包括用户标识、权限内容和用户对所述权限内容的签名；其中，所述权限内容中包括当前系统和外部系统各自对应的系统标识、权限编号列表、token以及根据所述系统标识、权限编号列表和token计算出的哈希值。
67.s302、根据能力信息的权限内容中当前系统的系统标识、权限编号列表和token计算出第三哈希值。
68.s303、比较第三哈希值和能力信息的权限内容中当前系统对应的哈希值是否相等，并根据比较结果确定所述能力信息是否被篡改。
69.能力信息中的权限内容中包括的哈希值，是在能力信息构建之初，根据各系统的系统标识、权限编号列表和token计算出来的。因此，如果能力信息中的权限内容在能力信息跨系统传递的过程中被篡改，则根据获取到的能力信息中的相应内容，并按照相同的算法再次计算出来的哈希值，就会与能力信息中原本的哈希值不同。因此，本技术实施例通过对哈希值进行比对，来验证能力信息是否被篡改。
70.具体的，当前系统可以遍历能力信息的权限内容，从中获取针对当前系统的权限编号列表，然后按照能力信息构建时生成哈希值的相同的算法，根据系统标识、权限编号列表和token重新计算出第三哈希值。其中，计算哈希值的算法可以预先约定，也可以采用标志位等方式进行传递，算法也可以是诸如sha256等算法，本技术实施例对此不作任何限定。然后，将第三哈希值与能力信息中当前系统的哈希值进行比较，以验证能力信息是否被篡改。如果验证不通过，则可做报错处理等，本技术对此不作任何限定。
71.s304、如果确定能力信息未被篡改，则根据请求参数和能力信息处理所述业务请
求。
72.s305、响应于处理业务请求过程中对外部系统的调用需求，将生成的调用请求发送至所述外部系统，其中，调用请求中包括所述能力信息。
73.s306、接收外部系统根据能力信息对调用请求进行处理的返回结果，并根据返回结果完成对所述业务请求的处理。
74.需要说明的是，外部系统在处理调用请求之前，出于安全性的考虑，也需要验证一下接收到的能力信息是否被篡改，当验证未被篡改，则可以基于能力信息中的权限内容进行业务处理。其中，外部系统验证能力信息是否被篡改的方式与本实施例中描述的当前系统的上述验证方式相同，此处不再赘述。
75.本技术实施例的技术方案，通过在请求中附加能力信息，并使其在服务调用链中能被跨系统传递，实现了为每个请求附加更细粒度的权限控制，提高了跨系统权限控制的灵活性和安全性。同时，还可以通过哈希值的比较来验证能力信息是否被篡改，进一步确保了跨系统权限控制的安全性。
76.实施例四
77.图4为本技术实施例四提供的跨系统的权限管理方法的流程图，本实施例在上述实施例的基础上进行进一步地优化。如图4所示，所述方法包括：
78.s401、接收用户的业务请求，所述业务请求中包括用户构建的请求参数和能力信息，其中，所述能力信息用于记载用户分别对当前系统和外部系统授权执行的权限。
79.具体的，所述能力信息中包括用户标识、权限内容和用户对权限内容的签名；其中，所述权限内容中包括当前系统和外部系统各自对应的系统标识、权限编号列表、token以及根据所述系统标识、权限编号列表和token计算出的哈希值。
80.s402、将能力信息的权限内容中当前系统对应的token，在当前系统的token管理信息中进行匹配。
81.s403、根据匹配的结果，确定权限内容中的token是否失效，以及与用户标识是否相对应。
82.首先需要说明的是，本技术实施例对token凭证的生成、传递及存储方式不做任何限定，每个系统各自的任意一种token管理方式在本技术中均适用。本技术实施例中对token进行校验的目的，一方面，在于校验当前能力信息中的token与用户标识是否对应，从而确定该token凭证确实属于当前用户；另一方面，则在于校验token是否失效，若token失效，则可以不对当前的业务请求进行处理，进行报错，从而确保当前权限控制的安全性。
83.s404、如果通过token校验，则根据请求参数和能力信息处理业务请求。
84.s405、响应于处理业务请求过程中对外部系统的调用需求，将生成的调用请求发送至所述外部系统，其中，调用请求中包括所述能力信息。
85.s406、接收外部系统根据能力信息对调用请求进行处理的返回结果，并根据所述返回结果完成对业务请求的处理。
86.需要说明的是，外部系统在处理调用请求之前，出于安全性的考虑，也需要进行外部系统的token凭证校验，当校验通过，则可以基于能力信息中的权限内容进行业务处理。其中，外部系统进行token凭证校验的方式与本实施例中描述的当前系统的上述校验方式相同，此处不再赘述。
87.本技术实施例的技术方案，通过在请求中附加能力信息，并使其在服务调用链中能被跨系统传递，实现了为每个请求附加更细粒度的权限控制，提高了跨系统权限控制的灵活性和安全性。同时，还可以对能力信息中的token凭证进行校验，进一步确保了跨系统权限控制的安全性。
88.实施例五
89.图5为本技术实施例五提供的跨系统的权限管理方法的流程示意图，本实施例在上述实施例的基础上进行进一步地优化。如图5所示，所述方法包括：
90.s501、接收用户的业务请求，所述业务请求中包括用户构建的请求参数和能力信息，其中，所述能力信息用于记载用户分别对当前系统和外部系统授权执行的权限。
91.具体的，所述能力信息中包括用户标识、权限内容和用户对所述权限内容的签名；其中，所述权限内容中包括当前系统和外部系统各自对应的系统标识、权限编号列表、token以及根据所述系统标识、权限编号列表和token计算出的哈希值。
92.s502、获取当前系统存储的所述用户标识对应的系统配置权限。
93.s503、将能力信息的权限内容中当前系统对应的权限编号列表，与系统配置权限进行比对。
94.具体的，能力信息中虽然记载了用户在本次业务请求中对当前系统授权执行的权限，但该权限也应该是从属于当前系统内部配置给用户的权限，因此需要对其进行校验，以保证安全性。
95.先根据用户标识，获取当前系统存储的与用户标识对应的系统配置权限，其中，每个权限都有相应的编号，然后将能力信息的权限内容中当前系统对应的权限编号列表，与系统配置权限进行比对，如果权限编号列表中出现系统配置权限中不存在的权限编号，表明当前能力信息中记载的权限已经超出当前系统内部原本配置给该用户的权限范畴，应该予以报错。
96.s504、如果权限编号列表中没有出现系统配置权限中不存在的权限编号，则根据请求参数和能力信息处理所述业务请求。
97.s505、响应于处理业务请求过程中对外部系统的调用需求，将生成的调用请求发送至外部系统，其中，所述调用请求中包括所述能力信息。
98.s506、接收外部系统根据所述能力信息对调用请求进行处理的返回结果，并根据返回结果完成对业务请求的处理。
99.需要说明的是，外部系统在处理调用请求之前，出于安全性的考虑，也需要验证一下接收到的能力信息中与外部系统对应的权限，是否从属于外部系统内部配置给该用户的权限，如果是，则可以继续处理调用请求，反之则报错。具体的验证方式与本实施例中描述的当前系统的上述验证方式相同，此处不再赘述。
100.本技术实施例的技术方案，通过在请求中附加能力信息，并使其在服务调用链中能被跨系统传递，实现了为每个请求附加更细粒度的权限控制，提高了跨系统权限控制的灵活性和安全性。同时，还通过对能力信息中的权限的验证，进一步确保了跨系统权限控制的安全性。
101.实施例六
102.图6是本技术实施例六中的跨系统的请求执行流程示意图。在本实施例中，当前系
统以系统a为例，外部系统以系统b为例，示出了从用户向系统a发起业务请求，系统a在处理的过程中又调用系统b的过程中，包含权限管理在内的完整交互策略。如图6所示，整个交互策略的执行流程包括：
103.1、用户构建请求参数及能力信息：用户构建请求参数，并且构建能力信息(包含系统a和系统b相关的能力)；
104.2、用户发起调用请求：用户将请求参数和能力信息封装起来，向系统a发送请求，请求方式不做限制；
105.3、系统a验证处理本系统相关能力信息；
106.4、系统a执行内部逻辑：系统a执行用户请求的系统内部业务逻辑；
107.5、系统a构建请求参数，附加能力信息：系统a在访问系统b时，需要将一开始用户传递过来的能力信息附加到发送给b的请求参数中；
108.6、系统b验证处理本系统相关能力信息；
109.7、系统b执行内部逻辑：系统b执行用户授权给系统a的系统内部业务逻辑；
110.8、结果返回：系统b将执行结果返回系统a，系统a处理完后续逻辑后，将最终结果返回给用户。
111.在上述过程中，系统a和系统b都会分别验证处理系统各自的相关能力信息，验证方式可以包括上述实施例中描述的验证签名、本系统能力信息验证、凭证校验以及能力校验中的至少一种，优选可以全部包括，以提高跨系统权限控制的安全性。
112.其中，示例性的，能力信息可以为json格式，例如下表所示：
[0113][0114][0115]
其中的content结构，例如下表所示：
[0116][0117]
需要说明的是，本技术聚焦权限授权验证的过程，不对系统中的公私钥管理以及token凭证的生成、传递及存储方式做任何限定，也不限定用户获取凭证和执行系统权限列
表的方式。
[0118]
本技术实施例的技术方案，在现有的基于身份(用户、角色、组)的权限访问管理机制之上，针对外部每个请求，都需要附加相关的能力信息，它由用户产生并签名，在服务调用链中能被跨系统传递。系统在处理每个外部请求时，系统内部在权限校验的同时会检查传入的能力信息中是否包含对应的权限信息，这样用户就能够为每个请求附加更细粒度的权限控制，确保用户在跨系统授权访问时，中间系统无法欺骗用户去做一些用户不期望做的操作，同时用户也能够为每个请求附加不同的权限限制，提高权限控制的灵活性和安全性。
[0119]
实施例七
[0120]
图7是本实施例中的跨系统的权限管理装置的结构示意图。本实施例可适用于在跨系统调用的场景中进行用户权限管理的情况，涉及移动互联技术领域。该装置可实现本技术任意实施例所述的跨系统的权限管理方法。如图7所示，该装置具体包括：
[0121]
业务请求接收模块701，用于接收用户的业务请求，所述业务请求中包括所述用户构建的请求参数和能力信息，其中，所述能力信息用于记载所述用户分别对当前系统和外部系统授权执行的权限；
[0122]
业务请求处理模块702，用于根据所述请求参数和能力信息处理所述业务请求；
[0123]
调用请求发送模块703，用于响应于处理所述业务请求过程中对所述外部系统的调用需求，将生成的调用请求发送至所述外部系统，其中，所述调用请求中包括所述能力信息；
[0124]
所述业务请求处理模块704，还用于接收所述外部系统根据所述能力信息对所述调用请求进行处理的返回结果，并根据所述返回结果完成对所述业务请求的处理。
[0125]
可选的，所述能力信息中包括用户标识、权限内容和用户对所述权限内容的签名；
[0126]
其中，所述权限内容中包括所述当前系统和外部系统各自对应的系统标识、权限编号列表、token以及根据所述系统标识、权限编号列表和token计算出的哈希值。
[0127]
可选的，所述对所述权限内容的签名是利用所述用户的私钥，对所述权限内容中所述当前系统和外部系统各自对应的哈希值的拼接字符串计算得到。
[0128]
可选的，所述装置还包括：
[0129]
签名验签模块，用于在所述业务请求处理模块处理所述业务请求之前，获取所述用户标识对应的公钥，并利用所述公钥对所述签名进行验签。
[0130]
可选的，所述签名验签模块具体用于：
[0131]
根据所述签名和公钥计算所述权限内容的第一哈希值；
[0132]
将所述权限内容中所述当前系统和外部系统各自对应的哈希值进行拼接，得到拼接字符串，并根据所述拼接字符串计算第二哈希值；
[0133]
比较所述第一哈希值和第二哈希值，如果比较结果为相等，则验签通过。
[0134]
可选的，所述装置还包括：
[0135]
能力信息验证模块，用于在所述业务请求处理模块处理所述业务请求之前，执行如下操作：
[0136]
根据所述能力信息的权限内容中所述当前系统的系统标识、权限编号列表和token计算出第三哈希值；
[0137]
比较所述第三哈希值和所述能力信息的权限内容中所述当前系统对应的哈希值是否相等，并根据比较结果确定所述能力信息是否被篡改。
[0138]
可选的，所述装置还包括：
[0139]
凭证校验模块，用于在所述业务请求处理模块处理所述业务请求之前，执行如下操作：
[0140]
将所述能力信息的权限内容中所述当前系统对应的token，在所述当前系统的token管理信息中进行匹配；
[0141]
根据所述匹配的结果，确定所述权限内容中的token是否失效，以及与所述用户标识是否相对应。
[0142]
可选的，所述装置还包括：
[0143]
能力校验模块，用于在所述业务请求处理模块处理所述业务请求之前，执行如下操作：
[0144]
获取当前系统存储的所述用户标识对应的系统配置权限；
[0145]
将所述能力信息的权限内容中所述当前系统对应的权限编号列表，与所述系统配置权限进行比对；
[0146]
如果所述权限编号列表中出现所述系统配置权限中不存在的权限编号，则报错。
[0147]
可选的，所述能力信息为json格式。
[0148]
本技术实施例所提供的跨系统的权限管理装置可执行本技术任意实施例所提供的跨系统的权限管理方法，具备执行方法相应的功能模块和有益效果。
[0149]
实施例八
[0150]
图8为本技术实施例八提供的一种电子设备的结构示意图。图8示出了适于用来实现本技术实施方式的示例性电子设备12的框图。图8显示的电子设备12仅仅是一个示例，不应对本技术实施例的功能和使用范围带来任何限制。
[0151]
如图8所示，电子设备12以通用计算设备的形式表现。电子设备12的组件可以包括但不限于：一个或者多个处理器或者处理单元16，系统存储器28，连接不同系统组件(包括系统存储器28和处理单元16)的总线18。
[0152]
总线18表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(isa)总线，微通道体系结构(mac)总线，增强型isa总线、视频电子标准协会(vesa)局域总线以及外围组件互连(pci)总线。
[0153]
电子设备12典型地包括多种计算机系统可读介质。这些介质可以是任何能够被电子设备12访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。
[0154]
系统存储器28可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(ram)30和/或高速缓存存储器32。电子设备12可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统34可以用于读写不可移动的、非易失性磁介质(图8未显示，通常称为“硬盘驱动器”)。尽管图8中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如cd-rom,dvd-rom或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线18相连。存储器28可以包括至少一个程序产
品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本技术各实施例的功能。
[0155]
具有一组(至少一个)程序模块42的程序/实用工具40，可以存储在例如存储器28中，这样的程序模块42包括但不限于操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块42通常执行本技术所描述的实施例中的功能和/或方法。
[0156]
电子设备12也可以与一个或多个外部设备14(例如键盘、指向设备、显示器24等)通信，还可与一个或者多个使得用户能与该电子设备12交互的设备通信，和/或与使得该电子设备12能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口22进行。并且，电子设备12还可以通过网络适配器20与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器20通过总线18与电子设备12的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备12使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。
[0157]
处理单元16通过运行存储在系统存储器28中的程序，从而执行各种功能应用以及数据处理，例如实现本技术实施例所提供的跨系统的权限管理方法。
[0158]
实施例九
[0159]
本技术实施例九还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本技术实施例所提供的跨系统的权限管理方法。
[0160]
本技术实施例的计算机存储介质，可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
[0161]
计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
[0162]
计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于无线、电线、光缆、rf等等，或者上述的任意合适的组合。
[0163]
可以以一种或多种程序设计语言或其组合来编写用于执行本技术操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、smalltalk、c ，还包括常规的过程式程序设计语言—诸如”c”语言或类似的程序设计语言。程序代码可以
完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(lan)或广域网(wan)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
[0164]
注意，上述仅为本技术的较佳实施例及所运用技术原理。本领域技术人员会理解，本技术不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本技术的保护范围。因此，虽然通过以上实施例对本技术进行了较为详细的说明，但是本技术不仅仅限于以上实施例，在不脱离本技术构思的情况下，还可以包括更多其他等效实施例，而本技术的范围由所附的权利要求范围决定。