一种权限控制方法及装置

1.一种权限控制方法，其特征在于，包括：
预设权限配置文件的步骤，包括：在权限配置文件中将业务功能映射为权限、服务和服务包；
加载所述权限配置文件的步骤，包括：将所述权限配置文件中设定的权限、服务和服务包映射为权限内存模型数据；其中，所述权限内存模型数据为将权限组与位序列进行关联而建立的一个二维权限位向量矩阵；
权限判定步骤，包括：接收用户请求，并利用所述权限内存模型数据判定是否授权所述用户请求；其中，所述利用所述权限内存模型数据判定是否授权所述用户请求包括：利用所述二维权限位向量矩阵进行位运算，并根据运算结果判定授权所述用户请求或禁止所述用户请求。
2.根据权利要求1所述的方法，其特征在于：
所述权限内存模型数据为0和1表示的二进制位向量矩阵。
3.根据权利要求2所述的方法，其特征在于，将所述权限配置文件中设定的权限、服务和服务包映射为权限内存模型数据，包括：
为每一组权限分配一组位序列，位序列中设为1的每一个位分别对应权限组中的一个权限，多个权限组对应一个二维的权限位向量矩阵；
在所述权限位向量矩阵中，将服务所拥有的权限对应的位设为1，否则设为0，得到服务向量矩阵；
对服务包所包含的服务对应的服务向量矩阵进行或运算，得到服务包向量矩阵。
4.根据权利要求3所述的方法，其特征在于，将所述权限配置文件中设定的权限、服务和服务包映射为权限内存模型数据，还包括：
向服务增加权限，则将该权限对应位的值与服务向量矩阵进行或运算；
和/或，
向服务删除权限，则将该权限对应位的值取反，再与服务向量矩阵进行与运算。
5.根据权利要求3所述的方法，其特征在于，
所述预设权限配置文件的步骤还包括：在权限配置文件中设定资源的访问控制权限；
所述加载权限配置文件的步骤还包括：将所述资源的访问控制权限映射到所述权限位向量矩阵的相应位置。
6.根据权利要求5所述的方法，其特征在于，所述接收用户请求并利用所述权限内存模型数据判定是否授权所述用户请求，包括：
接收用户请求，从用户请求中提取用户要访问的资源信息，并获得该资源的访问控制权限在权限位向量矩阵中相应位置处的值；
为该用户请求分配服务包，并将该服务包对应的服务包向量矩阵授权为用户权限；
将用户权限对应的向量矩阵与该资源的访问控制权限在权限位向量矩阵中相应位置处的值进行与运算，并根据运算结果进行判定：如果运算结果大于0，则授权所述用户请求；否则，禁止所述用户请求。
7.一种权限控制装置，其特征在于，包括：
权限配置模块，用于预设权限配置文件，在权限配置文件中将业务功能映射为权限、服务和服务包；
配置加载模块，用于加载所述权限配置文件，将所述权限配置文件中设定的权限、服务和服务包映射为权限内存模型数据；其中，所述权限内存模型数据为将权限组与位序列进行关联而建立的一个二维权限位向量矩阵；
权限判定模块，用于接收用户请求，并利用所述权限内存模型数据判定是否授权所述用户请求；其中，所述利用所述权限内存模型数据判定是否授权所述用户请求包括：利用所述二维权限位向量矩阵进行位运算，并根据运算结果判定授权所述用户请求或禁止所述用户请求。
8.根据权利要求7所述的装置，其特征在于：
所述权限内存模型数据为0和1表示的二进制位向量矩阵。
9.根据权利要求8所述的装置，其特征在于，所述配置加载模块包括：
权限加载子模块，用于为每一组权限分配一组位序列，位序列中设为1的每一个位分别对应权限组中的一个权限，多个权限组对应一个二维的权限位向量矩阵；
服务加载子模块，用于在所述权限位向量矩阵中，将服务所拥有的权限对应的位设为
1，否则设为0，得到服务向量矩阵；
服务包加载子模块，用于对服务包所包含的服务对应的服务向量矩阵进行或运算，得到服务包向量矩阵。
10.根据权利要求9所述的装置，其特征在于，所述服务加载子模块包括：
服务增加单元，用于向服务增加权限，则将该权限对应位的值与服务向量矩阵进行或运算；
和/或，
服务删除单元，用于向服务删除权限，则将该权限对应位的值取反，再与服务向量矩阵进行与运算。
11.根据权利要求9所述的装置，其特征在于：
所述权限配置模块还用于在权限配置文件中设定资源的访问控制权限；
所述配置加载模块还用于将所述资源的访问控制权限映射到所述权限位向量矩阵的相应位置。
12.根据权利要求11所述的装置，其特征在于，所述权限判定模块包括：
资源映射子模块，用于接收用户请求，从用户请求中提取用户要访问的资源信息，并获得该资源的访问控制权限在权限位向量矩阵中相应位置处的值；
用户授权子模块，用于为该用户请求分配服务包，并将该服务包对应的服务包向量矩阵授权为用户权限；
权限匹配子模块，用于将用户权限对应的向量矩阵与该资源的访问控制权限在权限位向量矩阵中相应位置处的值进行与运算，并根据运算结果进行判定：如果运算结果大于0，则授权所述用户请求；否则，禁止所述用户请求。

一种权限控制方法及装置\n技术领域\n[0001] 本申请涉及网络安全技术，特别是涉及一种权限控制方法及装置。\n背景技术\n[0002] 在网络环境中，对于网站而言每个URL(Universal Resource Locator，统一资源定位符)都是网站的一个资源，用户每发起一个资源访问请求，网站都需要对这个请求进行安全校验，以确认用户是否可以在网站上执行操作或查看内容。这种网站对用户行为的授权称为权限，权限控制就是用户到其可访问资源的映射关系的控制。\n[0003] 传统使用最为广泛的权限控制方法是基于角色的RBAC(Role-Based Access Control)权限控制模型。RBAC模型包含用户(USERS)、角色(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，权限赋予角色，角色指定给一个用户，此用户就拥有了该角色所包含的权限。而对于大多数请求(URL)的访问权限，是将该URL映射到角色，然后依据角色的定义来判断用户是否有权限。\n[0004] 起初多数网站都使用RBAC模型来管理和维护网站资源，但是随着网站业务的发展，网站中拥有的资源越来越多，并且网站资源也在不断变化中，这时RBAC模型显示出不足。这种不足是由于用户的身份具有多样性，网站的资源也是多种多样的，并且随着网站资源的变化，用户身份也在变化，这些都导致用户可访问的资源也需要灵活多变，而RBAC模型为了满足这种灵活性，其用户类型和许可权的耦合度非常高，给管理和维护工作带来很多不便。\n发明内容\n[0005] 本申请提供了一种权限控制方法及装置，以解决RBAC模型无法满足资源的权限控制对灵活性要求的问题。\n[0006] 为了解决上述问题，本申请公开了一种权限控制方法，包括：\n[0007] 预设权限配置文件的步骤，包括：在权限配置文件中将业务功能映射为权限、服务和服务包；\n[0008] 加载所述权限配置文件的步骤，包括：将所述权限配置文件中设定的权限、服务和服务包映射为权限内存模型数据；\n[0009] 权限判定步骤，包括：接收用户请求，并利用所述权限内存模型数据判定是否授权所述用户请求。\n[0010] 优选的，所述权限内存模型数据为0和1表示的二进制位向量矩阵。\n[0011] 优选的，利用所述权限内存模型数据判定是否授权所述用户请求，包括：利用所述二进制位向量矩阵进行位运算，并根据运算结果判定授权所述用户请求或禁止所述用户请求。\n[0012] 优选的，将所述权限配置文件中设定的权限、服务和服务包映射为权限内存模型数据，包括：为每一组权限分配一组位序列，位序列中设为1的每一个位分别对应权限组中的一个权限，多个权限组对应一个二维的权限位向量矩阵；在所述权限位向量矩阵中，将服务所拥有的权限对应的位设为1，否则设为0，得到服务向量矩阵；对服务包所包含的服务对应的服务向量矩阵进行或运算，得到服务包向量矩阵。\n[0013] 优选的，将所述权限配置文件中设定的权限、服务和服务包映射为权限内存模型数据，还包括：向服务增加权限，则将该权限对应位的值与服务向量矩阵进行或运算；和/或，向服务删除权限，则将该权限对应位的值取反，再与服务向量矩阵进行与运算。\n[0014] 优选的，所述预设权限配置文件的步骤还包括：在权限配置文件中设定资源的访问控制权限；所述加载权限配置文件的步骤还包括：将所述资源的访问控制权限映射到所述权限位向量矩阵的相应位置。\n[0015] 优选的，所述接收用户请求并利用所述权限内存模型数据判定是否授权所述用户请求，包括：接收用户请求，从用户请求中提取用户要访问的资源信息，并获得该资源的访问控制权限在权限位向量矩阵中相应位置处的值；为该用户请求分配服务包，并将该服务包对应的服务包向量矩阵授权为该用户权限；将用户权限对应的向量矩阵与该资源的访问控制权限在权限位向量矩阵中相应位置处的值进行与运算，并根据运算结果进行判定：如果运算结果大于0，则授权所述用户请求；否则，禁止所述用户请求。\n[0016] 本申请还提供了一种权限控制装置，包括：\n[0017] 权限配置模块，用于预设权限配置文件，在权限配置文件中将业务功能映射为权限、服务和服务包；\n[0018] 配置加载模块，用于加载所述权限配置文件，将所述权限配置文件中设定的权限、服务和服务包映射为权限内存模型数据；\n[0019] 权限判定模块，用于接收用户请求，并利用所述权限内存模型数据判定是否授权所述用户请求。\n[0020] 优选的，所述权限内存模型数据为0和1表示的二进制位向量矩阵。\n[0021] 优选的，所述权限判定模块利用所述二进制位向量矩阵进行位运算，并根据运算结果判定授权所述用户请求或禁止所述用户请求。\n[0022] 优选的，所述配置加载模块包括：\n[0023] 权限加载子模块，用于为每一组权限分配一组位序列，位序列中设为1的每一个位分别对应权限组中的一个权限，多个权限组对应一个二维的权限位向量矩阵；\n[0024] 服务加载子模块，用于在所述权限位向量矩阵中，将服务所拥有的权限对应的位设为1，否则设为0，得到服务向量矩阵；\n[0025] 服务包加载子模块，用于对服务包所包含的服务对应的服务向量矩阵进行或运算，得到服务包向量矩阵。\n[0026] 优选的，所述服务加载子模块包括：\n[0027] 服务增加单元，用于向服务增加权限，则将该权限对应位的值与服务向量矩阵进行或运算；\n[0028] 和/或，\n[0029] 服务删除单元，用于向服务删除权限，则将该权限对应位的值取反，再与服务向量矩阵进行与运算。\n[0030] 优选的，所述权限配置模块还用于在权限配置文件中设定资源的访问控制权限；\n所述配置加载模块还用于将所述资源的访问控制权限映射到所述权限位向量矩阵的相应位置。\n[0031] 优选的，所述权限判定模块包括：\n[0032] 资源映射子模块，用于接收用户请求，从用户请求中提取用户要访问的资源信息，并获得该资源的访问控制权限在权限位向量矩阵中相应位置处的值；\n[0033] 用户授权子模块，用于为该用户请求分配服务包，并将该服务包对应的服务包向量矩阵授权为该用户权限；\n[0034] 权限匹配子模块，用于将用户权限对应的向量矩阵与该资源的访问控制权限在权限位向量矩阵中相应位置处的值进行与运算，并根据运算结果进行判定：如果运算结果大于0，则授权所述用户请求；否则，禁止所述用户请求。\n[0035] 与现有技术相比，本申请包括以下优点：\n[0036] 首先，本申请提出的权限控制方法，其思路完全不同于现有的RBAC模型，没有采用角色的概念，而是直接依据业务定义，将业务功能划分为权限、服务和服务包，并可根据用户的需求进行权限、服务的任意组合。这种方法可以灵活地定义网站资源，并对资源进行打包(即服务包)授权给网站的用户，当用户每发起一次请求的时候，都能高效地确定该用户是否可以访问请求所对应的资源。而且，所述方法更贴近业务需求，能够有效减少网站授权管理的复杂性，降低管理开销，并对未来业务发展提供很大的伸缩性。\n[0037] 其次，本申请在进行权限判断时，采用内存向量来快速存储和计算，将权限、服务和服务包声明的内容映射为二进制位向量矩阵存储，并通过二进制位运算来判定是否授权。\n[0038] 当然，实施本申请的任一产品不一定需要同时达到以上所述的所有优点。\n附图说明\n[0039] 图1是本申请实施例所述一种权限控制模型的示意图；\n[0040] 图2是本申请实施例所述一种权限控制方法的流程图；\n[0041] 图3是本申请实施例中“权限声明”被加载在内存中的位向量矩阵示意图；\n[0042] 图4是本申请实施例中“服务声明”被加载在内存中的位向量矩阵示意图；\n[0043] 图5是本申请实施例中“服务包声明”被加载在内存中的位向量矩阵示意图；\n[0044] 图6是本申请实施例中“资源的访问控制权限声明”被加载在内存中的位向量矩阵示意图；\n[0045] 图7是本申请实施例中用户授权的示意图；\n[0046] 图8是本申请实施例所述一种权限控制装置的结构图。\n具体实施方式\n[0047] 为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。\n[0048] 随着网站业务的发展，网站推出以服务或服务包的形式提供服务功能，而且服务和服务包的应用越来越广泛。基于此，本申请提出一种高效灵活的权限控制方法，可直接依据业务定义，将业务功能划分为权限、服务和服务包，并依据这种划分进行网站资源的访问控制。当然，本申请所述方法不限于网站资源的权限控制，即独立于网站业务功能，还可适用于其他的业务功能。\n[0049] 其中，所述权限是指网站对用户行为的授权，从而确定用户可以在网站上执行的操作和查看的内容。所述服务是指业务上的一组完整的功能体系，所述服务包是指一个操作主体所拥有的服务集合。\n[0050] 下面通过实施例对本申请所述方法的实现流程进行详细说明。\n[0051] 参照图1，是本申请实施例所述一种权限控制模型的示意图。\n[0052] 本申请所述的权限控制基于图1所示的模型，该模型直接依据业务定义，将业务功能划分成服务包(ServiceBundle)、服务(Service)和权限(Permission)，模型数据可采用XML(Extensible Markup Language，可扩展标记语言)方式定义。\n[0053] 具体的，一个服务包可以定义多种服务，每种服务又可以定义多种权限，用户通过一定的映射逻辑可以映射到一个服务包，从而拥有该服务包中各种服务所定义的各个权限。\n[0054] 如图1所示，通过XML文件定义两个权限组(PermissionGroup)，每组分别定义了三种权限(Permission)。定义一个服务包(ServiceBundle)，该服务包中定义了两种服务(Service)，每种服务中分别定义了上述两个权限组中的三种权限。通过为用户分配所定义的服务包，该用户就分配到了这个服务包所定义的六种权限。\n[0055] 基于所述权限控制模型，本申请实施例还以jar包方式提供API(Application Programming Interface，应用程序编程接口)，以供相关应用调用所述模型进行权限判定。\n[0056] 举例说明，假设网站对于Buyer(买家)提供产品服务，该产品服务包含发布产品(post)到展示厅、编辑(edit)产品信息、删除(delete)产品、产品评价四个功能。依据上述权限控制模型对该产品服务定义如下的服务包、服务、权限：\n[0057] 服务包：\n[0058] \n[0059] 服务：\n[0060] \n[0061] 权限：\n[0062] \n[0063] 访问资源：\n[0064] \n[0065] 上述访问资源的定义中，target＝″/scrmPostProduct.htm为发布产品的功能页面(URL)，action＝″ProductAction″为该页面操作所执行的action(动作)，event＝″eventSubmitDoSave″为执行该操作所使用的方法。\n[0066] 访问控制场景：\n[0067] 当用户请求访问资源scrmPostProduct.htm时，首先拦截到该请求中的URL、action、event，然后调用本申请实施例所提供的API接口，通过该API接口调用当前用户所定制的buyer服务包对要访问的URL进行访问权限的判断，并返回是否许可操作的判断结果，从而完成访问资源的权限控制。\n[0068] 为了使本领域技术人员进一步了解本申请的内容，下面通过另一个例子详细说明权限控制的完整处理过程。\n[0069] 参照图2，是本申请实施例所述一种权限控制方法的流程图。\n[0070] 如图所示，本实施例所述的权限控制方法主要包括三个部分：\n[0071] 1.编写权限配置文件，在权限配置文件中将业务功能映射为权限、服务和服务包；\n[0072] 即在权限配置文件中进行网站资源数据定义，包括权限定义、服务定义、服务包定义，以及资源(URL)的访问控制权限定义；\n[0073] 2.加载所述权限配置文件，将所述权限配置文件中设定的权限、服务、服务以及资源的访问控制权限包映射为权限内存模型数据；\n[0074] 3.利用所述权限内存模型数据对请求URL进行授权处理。\n[0075] 下面通过以下步骤进行说明。\n[0076] 步骤201，配置权限；\n[0077] 步骤202，配置服务；\n[0078] 步骤203，配置服务包；\n[0079] 步骤204，配置资源的访问控制权限；\n[0080] 举例说明，如下：\n[0081] ■权限声明：\n[0082] \n[0083] 上述权限声明中定义了两个权限组，一个权限组是“Product”，其中定义了四个权限分别是“post”、“edit、“delete”和“read”；另一个权限组是“Order”，其中定义了五个权限分别是“create”、“pay”、“edit、“read”和“close”。\n[0084] ■服务声明：\n[0085] \n[0086] 上述服务声明中定义了两个服务，一个服务是“BuyService”，该服务中增加了权限组“Product”的所有权限和权限组“Order”的“create”权限，并删除了权限组“Product”的“delete”权限；另一个服务是“OrderService”，该服务中增加了了权限组“Order”的所有权限。\n[0087] ■服务包声明：\n[0088] \n[0089] 上述服务包声明中定义了一个服务包“Buyer”，该服务包中定义了“BuyService”服务和“OrderService”服务。\n[0090] ■资源的访问控制权限声明：\n[0091] \n[0092] 上述URL的访问控制权限声明指定了当用户访问taget所指向的资源页面“/postostProduct.htm”时，具有权限组“Product”的“post”权限，并可以提交productFrom表单。\n[0093] 步骤205，加载权限配置文件，并对权限配置文件中的声明内容进行解析，通过解析映射为权限内存模型数据；\n[0094] 为了方便用户的阅读和数据的维护管理，本实施例中上述声明内容将使用XML或者数据库表来管理配置。并且，本实施例通过构造权限内存模型，采用内存向量来快速存储和计算，系统在加载声明内容到内存时，将会把它理解为一个由0和1表示的二进制位向量矩阵。\n[0095] 总的来说，构造权限内存模型的基本思想是：为每一组权限分配一组位序列，位序列中设为1的每一个位分别对应权限组中的一个权限，位序列的其余位设为0。多个权限组的声明，则使得权限内存模型成为一个二维的位向量矩阵，矩阵中的每一个坐标表示一个权限位。\n[0096] “服务”则是一系列的权限的组合，当某服务拥有某权限时，对应的位向量矩阵对应位置为1，否则为0。因此，“服务”就是一个0和1的稀疏矩阵，同时也是所有权限矩阵的一个子集。\n[0097] 向“服务”增加权限，则是利用该权限对应的坐标值和服务向量矩阵进行或运算。\n删除“服务”中的某权限，则是该权限对应的坐标值取反再和服务向量矩阵进行与运算。\n[0098] “服务”和“服务”组合成“服务包”，“服务包”则是几个服务的向量矩阵进行或运算的结果矩阵。\n[0099] 例如，权限内存模型可表示为图3至图6所示的向量矩阵。\n[0100] 参照图3，是本申请实施例中“权限声明”被加载在内存中的位向量矩阵示意图。\n[0101] 由图3可以看出，权限组“Product”中的每个权限都被加载到8位二进制向量矩阵的一个位置上，并设置为1，该向量矩阵的值转换为十进制的值则表示为15。\n[0102] 同样，权限组“Order”中的每个权限都被加载到另一个8位二进制向量矩阵的一个位置上，并设置为1，矩阵的其余位置被设置为0，该向量矩阵的值转换为十进制的值则表示为31。\n[0103] 将表示“Product”的向量矩阵和表示“Order”的向量矩阵合并，即形成一个如图\n3所示的权限位向量矩阵[15，31]。\n[0104] 当“权限声明”被表示为位向量矩阵之后，“服务声明”则可以表示为该向量矩阵的一个子矩阵。\n[0105] 参照图4，是本申请实施例中“服务声明”被加载在内存中的位向量矩阵示意图。\n[0106] 在“服务声明”中，“allow”表示增加权限，“deny”表示删除权限。\n[0107] 对于服务“BuyService”，“Product.*”对应表示“Product”的向量矩阵，“Order.create”表示为一个在create位置为1其余位置为0的向量矩阵。\n“Product.delete”先取反操作，对“Product.delete”取反的结果如图所示。最后，将“BuyService”服务声明中“allow”和“deny”各自表示的矩阵取与操作，并转换为十进制值表示为[11，1]。\n[0108] 同样，对于服务“OrderService”，最终映射为一个如图4所示的向量矩阵，其值转换为十进制值表示为[0，31]。\n[0109] 在这样的原理下，“服务包”的向量矩阵的计算，则演变成为两个“服务”对应的向量稀疏矩阵之间的位与或运算的结果。\n[0110] 参照图5，是本申请实施例中“服务包声明”被加载在内存中的位向量矩阵示意图。\n[0111] 首先，将服务“BuyService”表示的向量矩阵和服务“OrderService”表示的向量矩阵取或操作，得到用[11，31]表示的二进制矩阵。然后，“Order.edit”在权限位向量矩阵中的向量坐标为(1，2)，向量值为1，取反后为0。最后，将[11，31]表示的矩阵与坐标(1，2)的向量值0取与操作，得到服务包“Buyer”表示的向量矩阵，其十进制值表示为[11，27]。\n[0112] 此外，对于“资源的访问控制权限声明”，在加载过程中也会将所述资源的访问控制权限映射到所述权限位向量矩阵的相应位置，如图6所示。\n[0113] 参照图6，是本申请实施例中“资源的访问控制权限声明”被加载在内存中的位向量矩阵示意图。\n[0114] 所述“资源的访问控制权限声明”表示当访问资源的URL是“/postostProduct.htm”时，允许的权限是“Product.post”，并可以返回Product.post表单。对应图中的权限位向量矩阵[15，31]，“Product.post”在[15，31]中对应的坐标是(0，0)，向量值为1。\n[0115] 基于上述权限内存模型，声明内容的加载过程如下：\n[0116] 1.加载所有permissionGroup和permission的声明。为每个permissionGroup从0开始分配编号，permissionGroup里面的permission分别也从0开始分配编号。\n[0117] \n (0，x)Product (0，0)post (0，1)edit (0，2)delete (0，3)read\n (1，x)Order (1，0)create (1，1)pay (1，2)edit (1，3)read (1，4)close[0118] 表1\n[0119] 每一个permission都有自己的坐标，建立起点阵图。\n[0120] 2.加载service的声明。当这个service中增加(allow)一个权限(permisison)时，在这个permission的坐标处用1进行或运算。当service中删除(deny)一个权限(permission)时，在相应坐标处用0进行与运算。Service加载结果就是一个0/1的二维矩阵，也就是int(整型)数组。例如：\n[0121] \n[0122] \n[0123] 上面得到结果是(二进制，首位1是符号位)：{11100000，10100000}＝int[]{3，\n2}。\n[0124] 3.加载serviceBundle的声明。同理service，如果allow，则对应坐标处用1取或；如果deny，则对应坐标处用0取或。最终serviceBundle将是一个int数组，表示了一系列的权限。\n[0125] 4.加载资源的访问控制权限声明。即将target定义的资源(URL)所允许的权限也映射到权限内存模型中的相应位置。\n[0126] 权限配置文件中的权限声明、服务声明、服务包声明和资源的访问控制权限声明一一加载完成后，得到这些serviceBundle(服务包)，等待使用。\n[0127] 步骤206，接收用户访问某资源URL的请求；\n[0128] 收到用户请求后，从用户请求中可以提取出用户要访问的资源信息(如URL)，并获得该资源的访问控制权限在权限位向量矩阵中相应位置处的值。例如，如果用户请求访问的资源URL为“/postostProduct.htm”，则根据上述的加载结果，该URL具有的权限“Product.post”在权限位向量矩阵[15，31]中对应的位置坐标是(0，0)，向量值为1。\n[0129] 此外，根据用户请求还可以提取出该用户所定制的服务包信息，然后依据该服务包信息通过API接口为该用户分配相适应的服务包，并将该服务包对应的服务包向量矩阵授权为该用户权限。例如，为该请求分配服务包“Buyer”。这种为用户分配服务包的过程即是用户授权的过程，当用户拥有某一个服务包时，在权限内存模型中则表示为该用户所拥有的特定的一个向量矩阵。\n[0130] 参照图7所示，是本申请实施例中用户授权的示意图。当用户拥有服务包“Buyer”后，则该用户拥有如图所示的向量矩阵，因此该用户的权限可表示为[11，27]。\n[0131] 步骤207，进行权限的匹配计算，并返回计算结果。\n[0132] 通过权限的匹配计算，可以返回授权访问和禁止访问两种结果。进行权限匹配的过程就是将要访问的资源映射值与用户权限进行与运算，更具体的说，是将用户权限对应的向量矩阵与该资源的访问控制权限在权限位向量矩阵中相应位置处的值进行与运算。如果运算结果大于0，则表示具有访问该资源的权限，许可用户访问该资源；否则，即如果等于0，表示没有权限访问该资源。\n[0133] 如前所述，在资源的访问控制权限声明中，如果target＝″/postostProduct.htm″，则具有权限组“Product”的“post”权限，并可以提交productFrom表单。参见图6，该资源映射到权限内存模型时，“Product.post”对应的坐标是(0，0)，向量值为1。权限匹配时，将该资源映射值1与用户权限[11，27]中“Product”对应的值11进行与运算，运算结果为1，大于0，因此该用户有权访问该URL。\n[0134] 综上所述，上述权限控制方法先在权限配置文件中定义了权限、服务和服务包，并指定了当用户访问target所指向的某页面时，需要哪一种permission(权限)。然后，当加载权限配置文件后会把访问target需要的权限对应到这个permission在权限坐标系中的坐标。进而，当用户提交请求的时候，如果用户的请求命中这个场景，则通过按位进行与运算的计算，判断用户所拥有的ServiceBundle(服务包)中对应的坐标是否大于0，如果大于\n0则给该用户授权。\n[0135] 由上述计算过程可以看出：\n[0136] 1.权限被虚拟化为二进制位向量矩阵，数据的体积非常小；\n[0137] 2.权限之间的叠加和权限的删除被演化为二进制的位运算；\n[0138] 3.匹配用户当前的访问是否被授权的计算过程也被演化为二进制位运算，授权计算简单快捷，对于并发大、安全要求高、对每次登录都需要严格的进行授权检查的系统而言非常实用；\n[0139] 4.能控制网站的每一个资源，并能灵活地组织网站的资源分配给各种不同的网站用户。\n[0140] 总之，本申请实施例所述的权限控制方法，其思路完全不同于现有的RBAC模型，没有采用角色的概念，而是直接依据业务定义，将业务功能划分为权限、服务和服务包，并可根据用户的需求进行权限、服务的任意组合。这种方法可以灵活地定义网站资源，并对资源进行打包(即服务包)授权给网站的用户，当用户每发起一次请求的时候，都能高效地确定该用户是否可以访问请求所对应的资源。而且，所述方法更贴近业务需求，能够有效减少网站授权管理的复杂性，降低管理开销，并对未来业务发展提供很大的伸缩性。\n[0141] 上述实施例是以网站资源为例进行说明，但具体应用中也可以应用到其他业务功能中，其实施原理与上述实施例相似，故不再赘述。\n[0142] 需要说明的是，对于前述的方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请所必须的。\n[0143] 基于上述方法实施例的说明，本申请还提供了相应的权限控制装置实施例，来实现上述方法实施例所述的内容。\n[0144] 参照图8，是本申请实施例所述一种权限控制装置的结构图。\n[0145] 所述权限控制装置可以包括权限配置模块81、配置加载模块82和权限判定模块\n83，其中，\n[0146] 权限配置模块81，用于预设权限配置文件，在权限配置文件中将业务功能映射为权限、服务和服务包；\n[0147] 配置加载模块82，用于加载所述权限配置文件，将所述权限配置文件中设定的权限、服务和服务包映射为权限内存模型数据；\n[0148] 权限判定模块83，用于接收用户请求，并利用所述权限内存模型数据判定是否授权所述用户请求。\n[0149] 优选的，为了快速存储和计算，本申请实施例中，所述权限内存模型数据为0和1表示的二进制位向量矩阵。因此，所述权限判定模块83是利用所述二进制位向量矩阵进行位运算，并根据运算结果判定授权所述用户请求或禁止所述用户请求。\n[0150] 进一步，基于所述权限内存模型，所述配置加载模块82具体可以包括：\n[0151] 权限加载子模块821，用于为每一组权限分配一组位序列，位序列中设为1的每一个位分别对应权限组中的一个权限，多个权限组对应一个二维的权限位向量矩阵；\n[0152] 服务加载子模块822，用于在所述权限位向量矩阵中，将服务所拥有的权限对应的位设为1，否则设为0，得到服务向量矩阵；\n[0153] 服务包加载子模块823，用于对服务包所包含的服务对应的服务向量矩阵进行或运算，得到服务包向量矩阵。\n[0154] 此外，所述服务加载子模块822具体可以包括：\n[0155] 服务增加单元，用于向服务增加权限，则将该权限对应位的值与服务向量矩阵进行或运算；\n[0156] 和/或，\n[0157] 服务删除单元，用于向服务删除权限，则将该权限对应位的值取反，再与服务向量矩阵进行与运算。\n[0158] 进一步，基于所述权限内存模型，所述权限配置模块81还用于在权限配置文件中设定资源的访问控制权限；相应的，所述配置加载模块82还用于将所述资源的访问控制权限映射到所述权限位向量矩阵的相应位置。\n[0159] 基于以上内容，所述权限判定模块83具体可以包括：\n[0160] 资源映射子模块831，用于接收用户请求，从用户请求中提取用户要访问的资源信息，并获得该资源的访问控制权限在权限位向量矩阵中相应位置处的值；\n[0161] 用户授权子模块832，用于为该用户请求分配服务包，并将该服务包对应的服务包向量矩阵授权为该用户权限；\n[0162] 权限匹配子模块833，用于将用户权限对应的向量矩阵与该资源的访问控制权限在权限位向量矩阵中相应位置处的值进行与运算，并根据运算结果进行判定：如果运算结果大于0，则授权所述用户请求；否则，禁止所述用户请求。\n[0163] 上述权限控制装置没有采用角色的概念，而是直接依据业务定义，将业务功能划分为权限、服务和服务包，并可根据用户的需求进行权限、服务的任意组合。所述装置可以灵活地定义网站资源，并且更贴近业务需求，能够有效减少网站授权管理的复杂性，降低管理开销，并对未来业务发展提供很大的伸缩性。\n[0164] 对于上述权限控制装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见上述方法实施例的部分说明即可。\n[0165] 本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。\n[0166] 本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。\n[0167] 而且，上文中的“和/或”表示本文既包含了“和”的关系，也包含了“或”的关系，其中：如果方案A与方案B是“和”的关系，则表示某实施例中可以同时包括方案A和方案B；如果方案A与方案B是“或”的关系，则表示某实施例中可以单独包括方案A，或者单独包括方案B。\n[0168] 以上对本申请所提供的一种权限控制方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。