一种用户权限分配方法和一种用户权限控制方法

摘要

本发明提供了一种用户权限控制方法，包括：从预置的用户角色映射关系表中获取相应用户的角色；提取所述角色的资源访问权限，所述资源访问权限采用正则表达式定义，并记录在权限定义文件中，所述资源由唯一的资源代码进行标识；拦截所述用户提交的资源访问请求，获得所述资源的资源代码；将所述资源代码与所述角色的资源访问权限进行匹配，若匹配成功，则向用户返回所述资源；若匹配失败，则拒绝所述用户的资源访问请求。本发明以可插入的方式应用于多种系统架构中，应用范围广、可以灵活定义并能显著降低系统开发和实施的成本。

说明书

技术领域

本发明涉及用户权限控制领域，特别是涉及一种用户权限分配的方法和装置，以及，一种用户权限控制的方法和装置。

背景技术

在应用系统开发中，为应用系统加入权限控制功能，使不同的用户有不同的资源访问权限，非常重要的一项功能。现有技术中，应用系统的权限控制功能往往与各个资源访问模块是紧密耦合的，即针对每个资源访问模块添加相应的权限检验代码，将程序功能和权限检验混淆在一起，显然在这种方式下，对权限控制功能的扩展、修改难度大，并且只能保护单一的资源类型。

在这种情况下，现有的Tomcat通过提供Realm支持以解决上述问题。Realm类似于Unix里面的group.在Unix中，一个group对应着系统的一定资源，某个group不能访问不属于它的资源。Tomcat用Realm来对不同的应用(类似系统资源)赋给不同的用户(类似group)。没有权限的用户则不能访问这个应用。具体而言，Tomcat提供三种Realm，1：JDBCRealm，这个Realm将用户信息存在数据库里，通过JDBC获得用户信息来进行验证。2：JNDIRealm，用户信息存在基于LDAP的服务器里，通过JNDI获取用户信息。3：MemoryRealm，用户信息存在一个xml文件里，当manager应用验证用户时即使用此种Realm.通过Realm对访问某个应用的客户进行验证。

然而，Tomcat Realm必须在Web服务器软件Tomcat的配置文件中定义，因此它只支持基于B/S架构的web应用程序，并且严重依赖与Web服务器软件Tomcat，只能应用与部署在Tomcat的web应用程序中，相应地，Tomcat Realm也只支持针对Web应用URL的权限控制。并且，它在定义某个角色可以访问哪些URL时，只有两种方式：URL列表和*号通配符，因此Tomcat Realm的权限定义比较单一。

总之，目前需要本领域技术人员迫切解决的一个技术问题就是：如何能够创新的提出一种可以适用于多种系统架构，应用范围广、可以灵活定义并且开发成本较低的权限分配与控制方法。

发明内容

本发明所要解决的技术问题是提供一种用户权限分配的方法和用户权限控制的方法，可以以可插入的方式应用于多种系统架构中，应用范围广、可以灵活定义并能显著降低系统开发和实施的成本。

本发明还提供了一种用户权限分配的装置和用户权限控制的装置，用以保证上述方法在实际中的实现及应用。

为了解决上述问题，本发明公开了一种用户权限分配的方法，包括：

定义用户的角色，生成用户角色映射关系表；

采用正则表达式定义所述角色的资源访问权限，并记录为权限定义文件，所述资源由唯一的资源代码进行标识。

优选的，所述用户角色映射关系表包括用户名字段、密码字段和角色字段。

优选的，所述权限定义文件为XML配置文件。

本发明实施例还公开了一种用户权限分配装置，包括：

用户角色定义模块，用于定义用户的角色，并生成用户角色映射关系表；

角色权限定义模块，用于以正则表达式定义所述角色的资源访问权限，并记录为XML文件，所述资源由唯一的资源代码进行标识。

优选的，所述用户角色映射关系表包括用户名字段、密码字段和角色字段。

优选的，所述权限定义文件为XML配置文件。

本发明实施例还公开了一种用户权限控制方法，包括：

从预置的用户角色映射关系表中获取相应用户的角色；

提取所述角色的资源访问权限，所述资源访问权限采用正则表达式定义，并记录在权限定义文件中，所述资源由唯一的资源代码进行标识；

拦截所述用户提交的资源访问请求，获得所述资源的资源代码；

将所述资源代码与所述角色的资源访问权限进行匹配，若匹配成功，则向用户返回所述资源；若匹配失败，则拒绝所述用户的资源访问请求。

优选的，所述的方法，还包括：

将所述用户角色映射关系表读至内存中。

优选的，所述的方法，还包括：

将当前用户的角色和资源访问权限记录至全局变量中。

优选的，所述匹配步骤包括：

从所述全局变量中读取所述资源访问权限的正则表达式，与所述资源代码进行正则表达式匹配。

优选的，所述资源代码由字符串组成。

本发明实施例还公开了一种用户权限控制装置，包括：

角色获取模块，用于从预置的用户角色映射关系表中获取相应用户的角色；

权限获取模块，用于提取所述角色的资源访问权限，所述资源访问权限采用正则表达式定义，并记录在权限定义文件中，所述资源由唯一的资源代码进行标识；

访问资源确定模块，用于拦截所述用户提交的资源访问请求，获得所述资源的资源代码；

匹配模块，用于将所述资源代码与所述角色的资源访问权限进行匹配，若匹配成功，则向用户返回所述资源；若匹配失败，则拒绝所述用户的资源访问请求。

优选的，所述的装置，还包括：

内存写入模块，用于将所述用户角色映射关系表读至内存中。

优选的，所述的装置，还包括：

共享记录模块，用于将当前用户的角色和资源访问权限记录至全局变量中。

优选的，所述匹配模块包括：

读取子模块，用于从所述全局变量中读取所述资源访问权限的正则表达式；

表达式匹配子模块，用于将所述正则表达式与所述资源代码进行正则表达式匹配。

与现有技术相比，本发明具有以下优点：

首先，本发明通过采用正则表达式来定义用户角色的资源访问权限，对用户角色的权限定义描述性强，非常灵活，并能支持多种粒度的访问控制；

其次，本发明只需要对正则表达式进行修改即可对系统权限进行维护或修改，操作方便；

再者，本发明中的受保护的资源采用资源代码唯一标识，采用当前被请求资源的资源代码与当前用户角色的被授权访问资源的正则表达式，即可匹配校验用户是否具备访问权限，简而言之即通过字符串的匹配即可实现校验操作，操作效率高，并能有效节约系统资源；

此外，本发明适用于不同的系统架构中，应用范围十分广泛，不受系统架构模式的限制；

最后，应用本发明对应用系统的修改非常小，因而开发和实施成本是很低的。

附图说明

图1是本发明的一种用户权限分配方法实施例的流程图；

图2是本发明的一种用户权限分配装置实施例的结构框图；

图3是本发明的一种用户权限控制方法实施例的流程图；

图4是本发明的一种用户权限控制装置实施例的结构框图；

图5是应用图4所示的优选实施例进行用户权限控制的流程图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

本发明可用于众多通用或专用的计算装置环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器装置、包括以上任何装置或设备的分布式计算环境等等。

本发明可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本发明，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本发明实施例的核心构思之一在于，通过正则表单式来定义角色对受保护资源的访问许可规则，通过业务拦截来实施访问控制，实现对用户界面，界面子元素，系统接口三种粒度的系统资源进行访问控制的一种权限分配和访问控制方法，用以快速地实施于各种系统架构中，并能够显著的降低开发和实施的成本。

参照图1，示出了本发明的一种用户权限分配方法实施例的流程图，可以包括：

步骤101、定义用户的角色，生成用户角色映射关系表；

本步骤可以用于将用户和角色进行绑定，为用户分配角色，并记录用户与角色的映射关系。

例如，假设用户信息如下表所示：

 

用户信息张三李四王五

角色信息如下表所示：

 

角色信息超级管理员管理员一般用户

定义相应用户的角色，生成用户角色映射关系表为：

 

用户角色映射关系表张三-超级管理员张三-管理员李四-超级管理员李四-管理员王五-一般用户

可以理解的是，在本发明中，用户是权限的拥有者。角色是权限分配的单位与载体，角色还可以通过继承关系支持分级的权限实现。例如，科长角色同时具有科长角色、科内不同业务人员角色。

在实际中，用户的账号、密码等基本信息，以及用户被定义的角色都可以存放在一个用户角色映射关系表中，因而，优选的，所述用户角色映射关系表可以包括用户名字段、密码字段和角色字段，例如，参见下表：

 

帐号密码角色其他用户信息Mike***采购员......Tom***库管员......Jack***经理......Bob***装置管理员......

其中，经理可以设置比较高级的权限，例如，继承库管员和采购员的角色，即具备三种角色的权限。

步骤102、采用正则表达式定义所述角色的资源访问权限，并记录为权限定义文件；

其中，所述资源由唯一的资源代码进行标识。

本实施例所述权限可以理解为，对受保护的资源操作的访问许可(Access Permission)，是绑定在特定的资源实例上的。对应地，访问策略(Access Strategy)和资源类别相关，不同的资源类别可能采用不同的访问模式(Access Mode)。例如，页面具有能打开、不能打开的访问模式，按钮具有可用、不可用的访问模式，文本编辑框具有可编辑、不可编辑的访问模式。同一资源的访问策略可能存在排斥和包含关系。例如，某个数据集的可修改访问模式就包含了可查询访问模式。

公知的是，正则表达式是用于进行文本匹配的工具，通常由一些普通字符和一些元字符(metacharacters)组成。普通字符包括大小写的字母和数字，而元字符则具有特殊的含义。正则表达式的匹配可以理解为，在给定的字符串中，寻找与给定的正则表达式相匹配的部分。有可能字符串里有不止一个部分满足给定的正则表达式，这时每一个这样的部分被称为一个匹配。匹配在本文里可以包括三种含义：一种是形容词性的，比如说一个字符串匹配一个表达式；一种是动词性的，比如说在字符串里匹配正则表达式；还有一种是名词性的，就是刚刚说到的“字符串中满足给定的正则表达式的一部分”。

以下通过举例对正则表达式的生成规则进行说明。

假设要查找hi，则可以使用正则表达式hi。这个正则表达式可以精确匹配这样的字符串：由两个字符组成，前一个字符是h，后一个是i。在实际中，正则表达式是可以忽略大小写的。如果很多单词里都包含hi这两个连续的字符，比如him，history，high等等。用hi来查找的话，这此单词里面的hi也会被找出来。如果要精确地查找hi这个单词的话，则应该使用\bhi\b。

其中，\b是正则表达式的一个元字符，它代表着单词的开头或结尾，也就是单词的分界处。虽然通常英文的单词是由空格或标点符号或换行来分隔的，但是\b并不匹配这些单词分隔符中的任何一个，它只匹配一个位置。

假如要找的是hi后面不远处跟着一个Lucy，则应该用\bhi\b.*\bLucy\b。其中，.是另一个元字符，匹配除了换行符以外的任意字符。*同样是元字符，它代表的是数量——即指定*前边的内容可以连续重复出现任意次以使整个表达式得到匹配。现在\bhi\b.*\bLucy\b的意思就很明显了：先是一个单词hi，然后是任意个任意字符(但不能是换行)，最后是Lucy这个单词。

基于上述说明，下文将以在用户界面(UI MainFrame)、界面元素(UIElement)和系统应用接口(Application Interface)三类系统资源中进行角色权限定义为例具体说明。

所述用户界面可以为用户操作的主界面，例如，Web应用程序中的某个网页；或者，应用程序中点击某个菜单项出现的主界面等。因而对于用户界面访问的权限控制，可以理解为窗口级别的访问控制。所述界面元素可以为用户界面的子节点，例如，网页上的按钮、文本框，或者，应用程序的菜单项等。因而对于用户界面访问的权限控制，又可以理解成是按钮级别的访问控制。所述系统应用接口可以为系统的功能接口。

需要说明的是，本发明对于每个资源(受保护的资源)都应当指定唯一的资源代码或资源代码规则，所述资源代码优选由字符串组成，即由字母、数字和/或其它字符(如下划线)组成，用以在进行权限校验的时候，可以采用当前被访问资源的资源代码与权限定义文件中指定当前用户所处角色的资源访问权限的正则表达式进行匹配。

例如，假设Web网站应用程序的受保护资源是某个网页，则可以利用这个网页的url来作为资源代码；假设桌面端信息系统的受保护资源是某个按钮或某个菜单项，则可以利用这个按钮的应用程序资源ID来作为资源代码。

优选的，所述权限定义文件可以为XML配置文件。

在这种情况下，为每个角色指定一个正则表达式，来定义该角色的资源访问权限的格式可以如下所示：

<role name＝’角色名’type＝”资源类型”patttern＝’正则表达式’>

一、采用正则表达式对用户界面(UI MainFrame)的访问策略定义实例：

假设应用情境为一个网站(www.alibaba.com)系统对其url进行保护，用户管理的网页都放在网站的user_manage目录下，

1、对用户管理员(userAdmin)的权限定义如下：

<！—用户管理员具有所有数据管理权限-->

<rolename＝’userAdmin’type＝”url”patttern＝’http://www.alibaba.com/user_manage/^*.htm’>

2、对数据录入员(userInputer)的权限定义如下：

<！—数据录入员具有新增、修改和删除数据的权限，不具有查看用户列表的权限-->

<role name＝’userInputer’type＝”url”patttern＝’http://www.alibaba.com/user_manage/[add|edit|del]*.htm’>

可以看出，该xml文件片断中pattern属性部分的内容，就是定义该系统角色的访问网站URL的正则表达式。

在这种情况下，当包含相应角色的用户访问该网站时，只有匹配相应正则表达式的url访问，才允许访问。

二、采用正则表达式对界面元素(UI Element)的访问策略定义实例：

假设一个企业进销存系统采购模块的用户界面中所有菜单项名称都以BUY_MEMU作为前缀，所有按钮名称都以BUY_BUTTON作为前缀，所有文本框都以BUY_TEXT作为前缀；销售模块的用户界面中所有菜单项名称都以SALE_MENU作为前缀，所有按钮名称都以SALE_BUTTON作为前缀，所有文本框都以SALE_TEXT作为前缀，

1、对采购单据录入员(buyerInputer)的权限定义如下：

<！—采购单据录入员，具有录入采购单据的权限，不具有修改、删除、查看采购单据的权限-->

<role name＝’buyerInputer’type＝”ui_element”patttern＝’BUY_*_ADD’>

2、对采购员(buyer)的权限定义如下：

<！--采购员，具有访问采购管理界面、点击或输入采购管理界面的按钮、菜单、文本框的权限-->

<role name＝’buyer’type＝”ui_element”patttern＝’BUY_*’>

3、对销售员(seller)的权限定义如下：

<！--销售员，具有访问销售管理界面，点击或输入采购管理界面的按钮、菜单、文本框的权限-->

<role name＝’seller’type＝”ui_element”patttern＝’SELL_*’>

三、采用正则表达式对系统应用接口(Application Interface)的访问策略定义实例：

对管理员(admin)的权限定义如下：

<！—admin具有调用com.test.website.admin.ManageUser这个接口的所有开头字符串为add，或edit，或del方法的权限-->

<rolename＝“admin”type＝“interface”patttern＝“com.test.website.admin.ManageUser.[add|edit|del]*”>

参考图2，示出了本发明的一种用户权限分配装置实施例的结构框图，用户权限分配装置20可以包括：

用户角色定义模块201，用于定义用户的角色，并生成用户角色映射关系表；

角色权限定义模块202，用于以正则表达式定义所述角色的资源访问权限，并记录为XML文件，所述资源由唯一的资源代码进行标识。

优选的，所述用户角色映射关系表包括用户名字段、密码字段和角色字段。

优选的，所述权限定义文件为XML配置文件。

对于本实施例而言，由于其基本相应于图1所示的方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

参考图3，示出了本发明的一种用户权限控制方法实施例的流程图，可以包括以下步骤：

步骤301、从预置的用户角色映射关系表中获取相应用户的角色；

步骤302、提取所述角色的资源访问权限，所述资源访问权限采用正则表达式定义，并记录在权限定义文件中，所述资源由唯一的资源代码进行标识；

步骤303、拦截所述用户提交的资源访问请求，获得所述资源的资源代码；

步骤304、将所述资源代码与所述角色的资源访问权限进行匹配，若匹配成功，则执行步骤305；若匹配失败，则执行步骤306；

步骤305、向用户返回所述资源；

步骤306、拒绝所述用户的资源访问请求。

所述用户角色映射关系表可以用于记录用户与角色的映射关系。

例如，假设用户信息如下表所示：

 

用户信息张三李四王五

角色信息如下表所示：

 

角色信息超级管理员管理员一般用户

定义相应用户的角色，生成用户角色映射关系表为：

 

用户角色映射关系表张三-超级管理员张三-管理员李四-超级管理员李四-管理员王五-一般用户

可以理解的是，在本发明中，用户是权限的拥有者。角色是权限分配的单位与载体，角色还可以通过继承关系支持分级的权限实现。例如，科长角色同时具有科长角色、科内不同业务人员角色。

在实际中，用户的账号、密码等基本信息，以及用户被定义的角色都可以存放在一个用户角色映射关系表中，因而，优选的，所述用户角色映射关系表可以包括用户名字段、密码字段和角色字段。

为提高用户角色映射关系的读取速度，本实施例还可以包括步骤：

将所述用户角色映射关系表读至内存中。

例如，可以在满足触发条件时(如应用本实施例的系统启动时)，将用户角色映射关系表读到内存中的特定区域(如用户池中)，以加快用户-角色的映射速度。

需要说明的是，本发明对于每个资源(受保护的资源)都应当指定唯一的资源代码或资源代码规则，所述资源代码优选由字符串组成，即由字母、数字和/或其它字符(如下划线)组成，用以在进行权限校验的时候，可以采用当前被访问资源的资源代码与权限定义文件中指定当前用户所处角色的资源访问权限的正则表达式进行匹配。

优选的，本实施例还可以包括步骤：

将当前用户的角色和资源访问权限记录至全局变量中

具体而言，可以在获取到相应用户的角色后，将该角色记录在该用户会话(session)的全局变量中，以便在用户访问资源时进行权限检验；在提取所述角色的资源访问权限后，将表示该权限的正则表达式也记录在所述全局变量中。

当用户提交资源访问请求时，如访问某个URL，或点击某个按钮，菜单时，可以通过拦截用户的访问请求，获得用户所请求访问资源的资源代码。然后从全局变量中读取该用户权限的正则表达式，与用户请求的资源代码进行正则表达式匹配，若匹配成功，则返回被请求的资源，若匹配失败，则拒绝用户的访问请求。

在实际中，为实现多种粒度的资源保护，使本发明不仅适用于与B/S架构的网站系统，还适用于C/S架构的桌面应用系统，还可以采用多种不同的拦截方法来对应不同的粒度、不同类型的资源访问请求。例如，在用户界面、界面元素和系统应用接口三类系统资源中采用的拦截方法如下表所示：

 

名称类型采用的拦截方法B/S架构的网站系统的URL用户界面Filter，ListenerC/S架构的桌面端应用软件的用户界面用户界面AOP技术B/S架构的网站的页面上元素(如按界面元素JAVA SCRIPT技术

 

钮、文本框)C/S架构的应用系统的用户界面子元素(如菜单等)界面元素AOP技术底层应用接口系统应用接口AOP技术

这种情况下，用户在配置文件中为角色指定访问资源的权限时，需要同时指定保护粒度和资源类型，以提示采用哪种拦截方法来监听并拦截用户的资源访问请求。在进行正则表达式匹配时，可以默认采用JAVA语言的正则表达式匹配包来进行正则表达式的匹配校验。

优选的，在用户的访问请求被拒绝后，可以向用户返回出错界面或出错信息，以提示用户访问被拒绝。

可以理解的是，对于本方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行，例如，步骤301和302，以及步骤303可以同时进行；也可以先执行步骤303，再执行步骤301和302；其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

参考图4，示出了本发明的一种用户权限控制装置实施例的结构框图，可以包括：

角色获取模块401，用于从预置的用户角色映射关系表中获取相应用户的角色；

权限获取模块402，用于提取所述角色的资源访问权限，所述资源访问权限采用正则表达式定义，并记录在权限定义文件中，所述资源由唯一的资源代码进行标识；

访问资源确定模块403，用于拦截所述用户提交的资源访问请求，获得所述资源的资源代码；

匹配模块404，用于将所述资源代码与所述角色的资源访问权限进行匹配，若匹配成功，则向用户返回所述资源；若匹配失败，则拒绝所述用户的资源访问请求。

优选的，本实施例还可以包括内存写入模块，用于将所述用户角色映射关系表读至内存中。

优选的，本实施例还可以包括共享记录模块，用于将当前用户的角色和资源访问权限记录至全局变量中。在这种情况下，所述匹配模块404可以包括以下子模块：

读取子模块，用于从所述全局变量中读取所述资源访问权限的正则表达式；

表达式匹配子模块，用于将所述正则表达式与所述资源代码进行正则表达式匹配。

参考图5，示出了应用图4所示的优选实施例进行用户权限控制的流程图，可以包括以下步骤：

步骤501、内存写入模块将所述用户角色映射关系表读至内存中；

步骤502、角色获取模块从所述用户角色映射关系表中获取相应用户的角色；

如在应用系统中，用户登录应用系统后，即把用户信息传递给角色获取模块，角色获取模块根据该用户信息从用户角色映射关系表中查找到相应用户的角色。

步骤503、共享记录模块将当前用户的角色记录至全局变量中；

步骤504、权限获取模块提取所述角色的资源访问权限；

其中，所述资源访问权限采用正则表达式定义，并记录在权限定义文件中，所述资源由唯一的资源代码进行标识；

步骤505、共享记录模块将当前用户角色的资源访问权限记录至全局变量中；

步骤506、访问资源确定模块拦截所述用户提交的资源访问请求，获得所述资源的资源代码；

步骤507、匹配模块将所述资源代码与所述角色的资源访问权限进行匹配，具体可以通过以下子步骤完成：

子步骤S1、读取子模块从所述全局变量中读取所述资源访问权限的正则表达式；

子步骤S2、表达式匹配子模块将所述正则表达式与所述资源代码进行正则表达式匹配。

步骤508、若匹配成功，则向用户返回所述资源；若匹配失败，则拒绝所述用户的资源访问请求。

为使本领域技术人员更好地理解本发明，以下将本发明实施例与最接近的现有技术Tomcat Realm进行对比说明：

(1)依赖关系的区别：

Tomcat Realm必须在Web服务器软件Tomcat的配置文件中定义，因此它只支持基于B/S架构的web应用程序，并且严重依赖与Web服务器软件Tomcat，只能应用与部署在Tomcat的web应用程序中。其他的Web服务器软件如Weblogic，Websphere等，也有类似Tomcat的Realm组件，也有与Tomcat Realm相同的问题，即只支持部署在自己web服务器软件中的Web应用程序。

而本发明实施例与Web应用服务器无关，有自己独立的配置文件，不依赖Web应用服务器，因此，不仅支持基于B/S架构的软件，业务支持C/S架构的软件。

(2)权限粒度的区别：

Tomcat Realm只支持针对Web应用URL的权限控制。

而本发明实施例支持用户界面(如URL，c/s客户端程序主界面)，界面元素，底层接口三种粒度的权限控制，应用范围比较广。

(3)定义方式的区别：

Tomcat Realm的权限定义不支持正则表达式，它在定义某个角色可以访问哪些URL时，只有两种方式URL列表和星号通配符，例如，

<web-resource-collection>

   <web-resource-name>

     BOPS editorl Protected Area

   </web-resource-name>

   <url-pattern>/admin/viewcatelist</url-pattern>

   <url-pattern>/admin/categoryinfo</url-pattern>

   <url-pattern>/admin/modifycategory</url-pattern>

   <url-pattern>/admin/modifycatestatus</url-pattern>

   <url-pattern>/admin/deletecategory</url-pattern>

   <url-pattern>/admin/movecategory</url-pattern>

   <url-pattern>/admin/addcategory</url-pattern>

</web-resource-collection>

或者，用*号标明某个目录下的所有ur

<web-resource-collection>

   <web-resource-name>

      BOPS admin Protected Area

   </web-resource-name>

   <url-pattern>/admin/*</url-pattern>

</web-resource-collection>

可以看出，Tomcat Realm的权限定义是比较单一的。

而本发明实施例支持复杂的正则表达式，因此具备更强的灵活性，可以定义及其复杂的访问逻辑，例如，要定义管理员(admin)角色的权限为，可以访问admin目录下的所有以add，edit，del开头的url，但不能访问以preview开头的url，相应的XML片段示意为：

<rolename＝’userInputer’type＝”url”patttern＝’http://www.alibaba.com/user_manage/[add|edit|del|^preview]*.htm’>

综上所述，可以概括得出本发明的优点为：

本发明通过采用正则表达式来定义用户角色的资源访问权限，对用户角色的权限定义描述性强，非常灵活，并能支持多种粒度的访问控制。如粗粒度(表示类别级，即仅考虑对象的类别(the type of object)，不考虑对象的某个特定实例。比如，用户管理中，创建、删除，对所有的用户都一视同仁，并不区分操作的具体对象实例)的窗口级别用户界面的访问控制、细粒度(表示实例级，即需要考虑具体对象的实例(the instance ofobject)，当然，细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，合同管理中，列表、删除，需要区分该合同实例是否为当前用户所创建)的按钮级别界面元素的访问控制，以及系统级别的底层功能模块的访问控制等。此外，只需要对正则表达式进行修改即可对系统权限进行维护或修改，操作方便；再者，本发明中的受保护的资源采用资源代码唯一标识，采用当前被请求资源的资源代码与当前用户角色的被授权访问资源的正则表达式，即可匹配校验用户是否具备访问权限，简而言之即通过字符串的匹配即可实现校验操作，操作效率高，并能有效节约系统资源；此外，本发明适用于不同的系统架构中，例如，不仅可以用于保护网站的URL，B/S、C/S应用软件的用户界面，还可以用于保护用户界面中的页面元素，如菜单项，按钮，文本框等界面元素等，应用范围十分广泛，不受系统架构模式的限制；并且，在实际中将本发明与应用系统集成时，对应用系统的修改非常小，因而应用成本是很低的。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上对本发明所提供的一种用户权限分配的方法和装置，以及，一种用户权限控制的方法和装置进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。