CN100433031C - 基于角色的访问控制系统和方法 - Google Patents

Abstract

本发明涉及一种基于角色的访问控制系统，包括：角色定义系统，用于将角色定义为个体资源上的许可集合，并因此分别形成角色实例；和超级角色定义系统，用于通过将一组角色实例合组为一个超级角色而定义至少一个超级角色，其中一个超级角色包含被合组的资源实例中所含的全部许可。进而，本发明涉及一种合适的方法、计算机程序和计算机程序产品。

Description

基于角色的访问控制系统和方法

技术领域

本发明涉及一种用于联网的计算机资源的安全授权的方法和系统，并特别涉及一种用于提供对系统资源的访问控制的技术。

本发明还涉及带有计算机可读介质的计算机程序产品和存储于具有程序代码的计算机可读介质上的计算机程序，当在计算机上运行计算机程序时，所述程序代码适宜于实现这一方法。

背景技术

服务系统功能通常包括所谓的资源管理，服务器通过它来同步和管理对诸如数据库或数据库服务器的一个或多个资源的访问。来自客户机的请求由服务器系统接收、处理，并进行对资源的适当的访问。接着，创建对客户机系统的响应，并将其发送至客户机系统。此通用模型适用于许多服务器范例，包括在线银行、订单输入和跟踪、电子商务乃至电子邮件处理。客户机程序一般处理用户交互，诸如表示下拉列表、菜单和信息页面。客户机程序一般还包括由服务器系统代表用户请求数据或起动某些数据修正的功能。在许多情况下，单个的服务器系统被众多客户机同时使用。例如，成打或成百的客户机可与控制数据库访问的少量服务交互。使用这种系统和功能的配备，客户机系统从不得不知道所有关于实际的资源管理器和资源的事情中解脱出来。它只需要具有与服务器系统通信和交互的能力，而不必拥有与资源直接通信的特定能力或软件。服务器系统内的资源管理器经常被分配以安全和访问控制的任务，从而从资源中请求安全数据的用户可被允许或拒绝对该数据的访问。

对于诸如服务器或存储空间的基于计算机的资源的访问控制不仅可帮助防止一个机构以外的人访问资源，还可被用来限制内部人员的访问。

经典的访问控制是通过使用访问控制列表(ACL)来提供的，从而用户与对各种资源的访问或交互的特定许可相关联。在这个意义上，ACL一般被视为许可的逐个人或逐个组的列举。

无论何时ACL内的许可发生改变，就必须以改变后的许可重建ACL。配置或改变ACL不是轻松的过程。在以下的情况中尤其是这样，即期望对许可层次的控制做细致的划分(grain)，诸如当资源被排列为节点的层级树时。经典的基于角色的访问控制模型缺乏将不同的访问控制约束强加到个体资源实例上的可能性。为了克服此问题，对将角色定义为对个体资源的许可集合(基于资源层次角色的访问控制(Resource-level role-based Access Control，RRBAC))的经典的模型做了扩展。此领域的两个最重要的例子是在美国专利US 2003/0229623 A1中说明的J2EE授权模型和所谓的WebSphere^TM系统管理角色。IBM公司的WebSphere^TM产品是可用于多种平台的应用服务器，包括从个人计算机到高端“大型机”、运行从Microsoft Windows NT^TM到IBM的AIX^TM再到开源Linux的操作系统的计算机。

J2EE授权模型或单纯的基于角色的访问控制(RBAC)模型不提供实例层次资源保护。

美国专利US 2003/0229623 A1说明了另外的基于角色的访问控制模型，其为随WebSphere 5.0^TM而引入的系统管理角色形成基础。此模型不很普遍也不很灵活。

J2EE授权模型与Java Authorization Contract for Containers(JACC，Java容器授权规范)定义了J2EE角色由个体许可构成，所述个体许可允许对特定的万维网内容或由个体Java Enterprise Bean(Java企业豆组件)暴露的商业逻辑的访问。个体资源实例的保护很有限。粒度大小由Java Enterprise Bean所暴露的接口和可直接面对Web URL的信息来定义。

希望有更灵活的系统，其具有减少系统管理错误的可能性和访问控制系统管理的简化。

发明内容

本发明提供了一种基于角色的访问控制系统以及基于角色的访问控制方法。

根据本发明一个方面，提供了一种基于角色的访问控制系统，包括：角色定义系统，用来将角色定义为个体资源上的许可集合，并因此分别形成角色实例；以及超级角色定义系统，用来通过将一组角色实例合组为一个超级角色而定义至少一个超级角色，其中一个超级角色包含被合组的角色实例中所含的全部许可。

在该系统的另一实施例中，系统进一步包括超级角色分配系统，用于将超级角色分配给个体用户或用户组。

通过提供将个体RRBAC角色累积到被称作超级角色的更高层次角色的装置，超级角色的概念扩展了RRBAC模型。

角色定义系统可以基于J2EE授权模型。

在该系统的另一实施例中，由定义系统定义的角色与系统管理性的角色相应。那些系统管理性的角色可以是所谓的系统管理角色，特别是在美国专利US 2003/0229623 A1中公开和说明的所谓WebSphere^TM系统管理角色。那些角色是从IBM的WebSphere Portal 5.0^TM产品而引入的。

进而，该方法的另一实施例可基于所谓的基于继承角色的访问控制(IRBAC)模型，这在尚未公布的序号为10/889625的美国专利申请中有所说明，并且其全部内容通过引用而被清楚地包含于此。

为了更好地理解，下面将简短地说明此模型。IRBAC模型基于由许可构成的角色。反过来，许可可被展示(scope)给个体资源。IRBAC模型定义了继承模型，所述继承模型允许方便地基于角色类型定义这样的角色实例，为交互的不同途径建模，所述交互保护对受保护的资源层级的特定子层级的访问。IRBAC许可被展示给个体资源，并由一个动作和一个对域资源的引用构成。在IRBAC中，对例如编辑特定文档的敏感操作的访问被映射至一个或多个相应的许可。角色被分配给用户或用户组，以将相应角色所含的许可赋予(grant)那些用户或用户组。如果分配给此用户或用户组的全部角色实例中所含的全部许可的联合包含敏感操作所需的全部许可，则允许用户或用户组执行这样的敏感操作。IRBAC模型中的一个本质的点是创建和管理角色实例的方式，例如如何确定被认为是特定角色实例的一部分的许可集合。IRBAC模型定义了三个概念，以允许方便地管理这样的角色，即角色类型、角色块和域根资源。在IRBAC模型内，每个角色实例都具有关联的角色类型。角色类型首先是动作的集合，并依工作责任而为与资源交互的特定方式建模，例如，因为编辑通常负责修改资源和创建新资源，所以被称作“编辑”的角色类型可包含像“查看”、“编辑”、“添加子级(child)”的动作。

此外，每个角色实例具有关联的域根资源。这只是受保护资源的层级内的某些特定资源。特定IRBAC角色实例中所含的许可集合是通过这样定义的：即在相应的角色类型所含的动作集合和以角色的域根资源为根的子树所含的资源集合之间建立笛卡儿积，即所谓的角色域。可通过引入角色块来制约角色域。角色块可被捆绑在个体资源上，且角色块是角色类型所特定的。角色块防止以携带块的资源为根的子树被包括在同一角色类型的角色域和某些祖先域根资源中。

在所谓的WebSphere Protal 5.0^TM中实现的IRBAC提供了细致划分的代表模型。创建/删除角色分配和创建/删除角色块的操作是通过这样而保护的：即根据所涉及的角色类型给受影响的资源强加特定的一个或多个许可；以及给受影响的用户或用户组强加特定许可。

当IRBAC模型提供基于继承性角色的访问控制系统时，根据本发明的方法提供了甚至更为灵活的系统，所述系统具有更为简化的访问控制系统管理。

因此，在参照IRBAC模型的方法的又一实施例中，角色定义系统可以对应于这样的角色定义系统：即为至少一个角色类型定义至少一组许可动作，所述角色定义系统还包括角色绑定系统，用于将至少一个角色类型绑定至节点结构的至少一个节点，其中所述节点代表基于计算机的资源，于是形成至少一个角色实例。多个这样形成的角色实例构建了与角色实例的层级树相应的角色实例结构，且角色实例结构内的每个角色实例具有关联的域根实例，以至于角色类型的实例是由域根实例的层级式子级继承的。这意味着超级角色概念扩展了先前说明的IRBAC模型。

基于角色的访问控制系统可以进一步包括角色分块系统，用于为角色类型建立角色类型块，其中角色类型块限制了角色类型实例的继承。

在本系统的可能的实施例中，可通过从定义超级角色的合组的角色实例组中添加和/或移除角色实例来修改一个超级角色。

在本发明的又一实施例中，基于角色的访问控制系统内的一个超级角色在受保护的资源实例的结构内被注册，于是定义了受保护的超级角色实例。这意味着超级角色的特性同时受访问控制系统的保护，并为其他受保护资源提供许可。

在另一实施例中，超级角色是可嵌套地形成超级角色嵌套结构的。在此情况下，根据超级角色的嵌套结构，将其注册于受保护的资源层级内。嵌套的超级角色的语义是，超级角色包含所有许可，所述许可被包括在：被包含在超级角色中的所有RRBAC角色实例中，和被嵌套进超级角色中的所有超级角色中。

在本发明的又一实施例中，通过将分配条件与个体超级角色分配相关联而将超级角色动态地分配给至少一个用户或用户组。

因此，在前述模型中已定义的角色实例可被合组为多个超级角色，且多个超级角色可被嵌套。这使得可在语义(semantic)级别上管理角色分配。这降低了访问控制系统管理的复杂性，并因此减少了成本以及可能导致无意的访问控制配置的错误。这简化了用户和用户组的一致动态绑定，以通过动态超级角色分配而访问控制配置。一个超级角色分配可描绘较大数量的已知的角色分配。这减少了应维持的访问控制数据的量。这允许可更有效地实施相应的访问控制引擎。

根据其超级角色嵌套，超级角色实例被注册于例如受保护的资源层级上。由此，改进了访问控制代表的灵活性。对个体超级角色实例的访问，根据例如将特定的超级角色分配给特定用户的能力，可由RRBAC角色或甚至由保护个体超级角色实例的超级角色来控制。

此外，嵌套的超级角色实例可作为角色的层级而出口至外部授权提供者。这允许当在集中式(centralized)安全组件中管理角色分配时，可对其他授权系统所提供的访问控制继承模型进行掌握(leverage)。

超级角色概念允许克服全部现有的RRBAC模型的一个内在限制，所述内在限制制约了与特定角色实例关联的角色域，以精确地保护受保护的资源层级的资源的一个子层级。被分配给某域根资源的某IRBAC角色实例可决不包含在以此域根资源为根的子树以外的资源上的许可。超级角色概念允许将一组IRBAC角色实例添加至一个超级角色实例。结果，一个单个的超级角色实例可包含在受保护的资源层级内的各种子层级上的许可，其建立了更高级别的语义角色，所述语义角色包含满足系统内特定任务所必需的全部许可。

此外，本发明是指基于角色的访问控制方法。该基于角色的访问控制方法包括以下步骤：将角色定义为个体资源上的许可集合，因而分别形成角色实例；以及将一组角色实例合组为一个超级角色，以使得一个超级角色包含被合组的角色实例中所含的全部许可。

在本发明的方法的又一实施例中，一个超级角色被注册于受保护的资源实例的结构内，因而定义了受保护的超级角色实例。

在该方法的另一实施例中，根据本发明的基于角色的访问控制方法可以进一步包括以下步骤：为角色类型定义一组可许可的动作；提供节点结构，其中所述节点代表基于计算机的资源；将角色类型绑定至节点结构的节点上，于是形成角色实例，并将一组角色实例结构的角色实例合组成一个超级角色定义，以使得一个超级角色包含被合组为该超级角色组的所有角色实例中所含的全部可许可的动作。在这种情况下，该方法基于已说明的IRBAC模型。

基于IRBAC模型，如前所述，角色实例的结构因而可以对应于角色实例的层级树，并且角色实例的结构内的每个角色实例都具有关联的域根实例，以使得角色类型的实例是从域根实例的层级式子级继承来的。

该方法可进一步包括以下步骤：为角色类型建立角色类型块，其中角色类型块限制了角色类型实例的继承。

而且，超级角色可以是可嵌套地形成超级角色嵌套结构的。根据本发明的方法可进一步包括以下步骤：通过将分配条件与个体超级角色分配相关联而将超级角色动态地分配给至少一个用户或用户组。

通过说明和附图，本发明的更多特征和实施例将会变得一目了然。

应当明白：在不脱离本发明的范围的条件下，前述和后述特征不仅可用于指定的组合，还可用于其他组合或独自使用。

通过举例的方法在附图中示意性地解释了本发明，并且此后将参照附图而详细说明。应当明白：本说明书决非限制本发明的范围，而仅是本发明的优选实施例的说明。

附图说明

通过审阅详细的说明并参照附图，本发明的其他方面和优点将会变得一目了然，其中：

图1示出了根据IRBAC模型的基于角色的访问控制系统的实施例的示意图；

图2示出了根据本发明的基于角色的访问控制系统的实施例的示意图；

图3示出了根据本发明的基于角色的访问控制系统的又一实施例的系统组件；以及

图4示出了根据本发明的基于角色的访问控制系统的另一实施例的基于许可检查的权利(entitlement)的示意图。

具体实施方式

图1描述了根据IRBAC模型的可能的情况。IRBAC模型内的每个角色都具有关联的角色类型。角色类型首先是一组动作，并依工作责任而为与资源交互的特定方式建模。例如，因为编辑通常负责修改资源和创建新资源，所以“编辑”角色类型可包含“查看”、“编辑”、“添加子级”等。此外，每个角色实例具有关联的域根资源。关于IRBAC角色实例的命名惯例是“角色@域根资源”。图1描绘了例如被捆绑在资源“第1页”的类型为“管理员”的角色实例，称作“管理员@第1页”。特定IRBAC角色实例中所含的一组许可是通过这样定义的：即在对应的角色类型中所含的动作集合和以角色的域根资源为根的子树所含的资源集合之间建立笛卡儿积，即所谓的角色域。在图1中描绘了角色“用户@出纳员(teller)应用”。角色类型“用户”可被定义为例如仅包含一个单独的被称作“查看”的动作。结果，角色“用户@出纳员应用”包含许可(查看，出纳员应用)，(查看，吞吐口(portlet)1)和(查看，吞吐口2)。

角色域可通过引入角色块来制约。角色块可被捆绑在个体资源上，而且角色块是角色类型特定的。角色块防止以携带块的资源为根的子树被包括在同一角色类型的角色域和某个祖先域根资源中。例如，图1示出了位于资源“第5页”的类型为“编辑”的角色块。结果“第5页”和“第6页”未被包含在角色“编辑@出纳员页面”的角色域中。

图2示出了图示的层级树10。通常，树10的每个小矩形节点代表一处资源。在层级树10的上方示出了4个超级角色：一个被称作“超级角色1”的超级角色、一个被称作“出纳员”的超级角色、一个被称作“超级角色4”的超级角色，和一个被称作“雇员”的超级角色。以层级方式排列这些超级角色。超级角色“超级角色1”包含超级角色“出纳员”和超级角色“超级角色4”，而超级角色“出纳员”包含超级角色“雇员”。这意味着与超级角色“出纳员”和“超级角色4”耦合(couple)的全部许可也被分配给超级角色“超级角色1”。被分配给超级角色“雇员”的全部许可也被分配给超级角色“出纳员”，并从而被分配给超级角色“超级角色1”。

层级树10在最高级别中示出了被称作“根”的资源。第二级别包括：被称作“超级角色”、“页面根”、“外部AZN”和“应用根”的资源。那些资源中的每一个分别都是进一步的子树的根。以下将首先考虑始于“页面根”的子树。为了提供本发明下的访问控制，首先经角色定义系统来定义角色类型。通常，基于一组动作集合定义角色类型，所述动作被允许由分配给该角色类型的角色实例的用户或用户组来执行。例如，“管理员”角色类型可包含这样的动作，即其暗示能够从对象空间中读取数据对象并将新对象写入对象空间；但不包含这样的动作，即暗示被许可编辑已存在的数据对象。

相反，“编辑”角色能够读、写和编辑数据对象。一旦定义了角色类型，他们就可被分配/绑定至树10的特定资源。如图中所示，“管理员”角色已绑定至资源“第1页”，其直接位于资源“页面根”下方。在所示例子中，当角色类型被绑定至树10中的资源时，除非已建立了角色类型块，那个角色类型的实例和可许可动作因此将被全部层级子级继承。于是，例如，绑定至资源“第1页”的“管理员”角色将被对应于前述IRBAC模型的资源“第5页”继承。如图2中进一步所示，将角色类型绑定至资源和角色继承的概念导致创建了所谓的角色域。角色域是由资源定义的，其上绑定或继承了角色类型。在图2所示始于资源“页面根”的绑定下，创建了三个分离的域，即域30、31和32。

域30是通过将“管理员”角色类型绑定至资源“第1页”而定义的。如图2进一步所示，“编辑”角色类型已被分配给资源“出纳员页面”，所述资源“出纳员页面”导致创建了两个域，其中域31被域30包融。域32从域31中分离，但被域30包融。如上述，所示实施例内的角色类型的实例被继承，除非已建立了角色类型块。例如，关于“编辑”角色类型的继承块已建立于资源“第5页”上。在这种情况下，绑定至资源“出纳员页面”上的“编辑”角色类型将不被资源“第5页”或“第6页”继承。然而，它仍被资源“第3页”和“第4页”继承。关于特殊角色类型的继承块不影响其他角色类型的实例。已建立在资源“第1页”上的“管理员”角色类型仍被资源“第5页”或“第6页”继承。

已提到的超级角色是通过对许多角色实例分组而创建的，其以虚线来描述。例如超级角色“出纳员”是通过将角色实例“编辑@出纳员页面”和“用户@出纳员应用”归为组而形成的。这意味着超级角色“出纳员”包含角色实例“编辑者@出纳员页面”和“用户@出纳员应用”的全部许可。结果，分配给“出纳员”超级角色的用户被允许作为资源“出纳员页面”上的“编辑”和作为资源“出纳员页面”上的“用户”而操作，并经作为资源“第3页”和“第4页”上的“编辑”和作为资源“吞吐口1”及“吞吐口2”上的“用户”的继承而操作。

如图2进一步所示，通过将超级角色看作受保护的资源自身而进一步使用超级角色的灵活性，即通过将超级角色实例自身注册于受保护的资源层级内而进一步利用。已提到的超级角色“超级角色1”、“出纳员”和“超级角色4”被注册于层级树10内。在树10的第二级别上，将“超级角色”示为虚拟资源。“超级角色1”就在此虚拟资源下作为受保护的资源而被示出。图2还示出了控制对受保护的超级角色实例“超级角色1”的访问的角色实例“管理员@超级角色1”。超级角色“出纳员”和“超级角色4”是“超级角色1”的子级。关于“管理员”角色类型的继承块已被建立在那些受保护的超级角色实例上，以使得被绑定在“超级角色1”上的“管理员”角色类型不会被受保护的超级角色实例“出纳员”和“超级角色4”继承。

超级角色可以具有嵌套结构。因此，一个超级角色有可能包含满足系统内特定任务所必需的全部可许可动作。现在可以将一组IRBAC角色实例添加至一个超级角色实例。结果，一个单个的超级角色实例可包含在受保护的资源层级10内的各种子层级上的许可，建立更高级别的语义角色，所述语义角色包含满足系统内特定任务所必需的全部许可。例如，银行端口(portal)应用例如可定义所谓的“出纳员”超级角色，所述“出纳员”超级角色同时包含在对应端口页面和吞吐口上的许可，尽管那些资源处于受保护的资源层级10的不同部分，如图2所示。于是，将此一个“出纳员”超级角色实例分配给特定用户就赋予了此用户使用资源集合所必需的全部实例级别的许可，所述资源以适宜银行出纳员的方式构成了银行端口应用。这允许可对如IRBAC模型或其他前述RRBAC模型内的更高级别进行访问控制系统管理。此外，这减少了系统管理开销。而且，此“出纳员”超级角色仍为特定页面和吞吐口实例提供了细致划分的实例级别资源保护。

超级角色在语义级别上给工作责任建模。因为这个原因，超级角色是用于引入动态访问控制系统管理概念的理想候选。这意味着，个体超级角色的分配可被捆绑附加条件，例如关联的工作流对象的状态。在前述的银行例中，这可被用来将“出纳员”超级角色实例分配给特定用户，条件是：此用户实际上有待做的工作项目，所述待做的工作项目需要此用户实际地充当出纳员。这种设置减少了在时间上的特定点处必需的授权人集合，并因此改进了全部的安全性和可跟踪性(auditability)。还存在其他许多可决定这样的动态超级角色分配设施的可能情况。诸如RRBAC角色或IRBAC角色的已知角色由于它们趋于太过细微(granular)，并且因为那里的IRBAC角色定义无法存在捆绑在同一域根资源上的相同角色类型的多个IRBAC角色实例，所以不太适宜以动态方式来分配。凭借超级角色，可定义多个超级角色实例，其包含捆绑在各种不同条件下的同一许可。

进而，如已述的，超级角色自身可以以层级方式来排列，所述层级方式提供一种方式以建立对在适合不同系统管理员和庄家(stakeholder)的相应的组的多级别粒度大的访问控制系统管理概念的访问。例如，如果某些系统管理员组需要不太细粒度的访问控制系统管理，则可以创建像前述“出纳员”超级角色那样含多种其他超级角色实例的超级角色。通过将超级角色实例当作受保护的资源自身对待而进一步利用此灵活性。将超级角色在受保护的资源层级10内注册为受保护的资源允许比由前述IRBAC授权(delegation)模型所提供的对访问控制授权的更细粒度的控制。例如，“将特定用户分配为特定的超级角色”这一敏感操作可通过强化在相应超级角色实例上的特定实例级别许可而受保护。于是，可以建立这样的角色：其允许被授权的系统管理员仅管理任何的给用户分配预定的超级角色并防止允许他们修改下面更低级别的IRBAC角色和/或修改相应的角色块。例如IRBAC角色“管理员@超级角色1”仅包含管理此特定超级角色的许可。在IRBAC授权模型中，不可以通过例如为相应的角色类型创建角色块而防止被允许为特定IRBAC角色创建角色分配的用户修改IRBAC角色自身。

为超级角色实例提供实例级别保护也有益于合作情形，其中当通过超级角色或仅通过角色分配而为合作社区建模时，经常需要对访问控制配置的显示的查看访问。于是，被分配为特定的超级角色并非像在IRBAC模型中那样自动地意味着允许查询“还有谁被分配给此角色”。随着超级角色在超级角色实例级别上受保护，有可能强化在超级角色自身上的实例级别的“查看”，提供额外的灵活性，其经证明对于合作环境是至关重要的。

此外，根据超级角色嵌套结构将超级角色实例注册于受保护的资源层级10上允许将此层级信息输出至外部授权提供者。这样的授权提供者通常被用来提供遍及整个企业的集中式访问控制系统管理。外部授权提供者于是可通过特定的继承模型来利用层级。

已提到并说明的IRBAC模型仅支持在应用运行期间对个体许可的检查。这意味着IRBAC角色仅是系统管理模型的一部分。他们在为性能优化的运行期模型中不可用。超级角色也被认为是授权运行期模型的一部分，所述授权运行期模型提供从J2EE授权模型中已知的“isUserInRole”方法的有效实现。这还支持弥合J2EE授权和实例级别授权概念之间的空隙。

实现超级角色概念需要支持某些超级角色系统管理设施和在访问控制决策期间识别超级角色配置。与特定超级角色实例关联的语义信息由下列性质构成：

第一个性质是“名称”，用来在以特定超级角色实例为父代的一组超级角色兄弟中，唯一地标识特定超级角色实例。全系统的唯一识别是通过将个体超级角色名称与类路径结构串联而得到的。例如，图2中的超级角色“出纳员”由于是“超级角色1”的孩子角色，故以全名“超级角色1/出纳员”在系统内被唯一标识。

第二个性质是父亲角色，其标识特定超级角色的内含超级角色实例，例如关于“出纳员”角色的“超级角色1”。此信息可由对个体超级角色实例的单一参照而代表。这是保证个体超级角色的层级嵌套的真正的1对多的关系。在物理数据模型中，这一般是通过将父亲角色参照存储于专用(dedicate)表格栏中而得到的。

第三个性质是一组关联的RRBAC角色。此性质与父亲角色性质一起定义特定超级角色实例中所含的实际许可集合。此信息可由对个体RRBAC实例的一组参照来代表。在物理数据模型中，这一般是通过在存储RRBAC角色实例的表格和存储超级角色实例的表格间建立数据库关系而得到的。个体RRBAC角色实例可从多个超级角色实例中参照。

另一个性质是外部化(externalization)状态，其反映了对于特定超级角色的用户和用户组分配是否可由外部授权提供者来管理。

除此之外，决定超级角色概念的访问控制系统必须也能够管理个体超级角色实例到个体用户或用户组的映射，通常被称作“主干(principal)”，例如管理超级角色分配。与特定超级角色分配关联的语义信息应由下列信息构成。首先，应有识别已被分配了特定超级角色实例的主干的主要参照。这可以是例如个体用户、用户组或某些其他系统内的实体，所述实体可被授权执行敏感的操作。此信息可由对用户注册表内特定主干的参照来代表，例如经其可辨认名称来识别。在物理数据模型中，这通常是通过对某些存储主干信息的表格建立外密钥关系而得到的。

第二个性质应是识别超级角色实例的超级角色参照。在物理数据模型中，这通常是通过对某些存储超级角色实例的表格建立外密钥关系而得到的。

此外，还有被称作分配条件的可选性质，其标识可与特定超级角色分配关联的外部条件。这样的条件可经能以各种方式实现的某些特定服务编程接口(SPI)来定义，它决定存在于系统中的外部信息。这可以是例如工作流引擎。访问控制决策引擎在访问控制决策期间识别超级角色分配条件，并忽略那些角色分配，它们的关联条件如果被定义即被认定为假。

参照图3，示出了根据本发明的基于角色的访问控制系统的几个系统组件，其支持超级角色和超级角色分配性质的管理。那些系统组件被包括于或链接至为基于计算机的资源提供访问控制的控制计算机。所有组件可以处于单一物理位置上或以各种形式分布于多个物理系统中。如前所述，资源意在表示计算机基础设施内用户或用户组可能试图访问或要么与之交互的任何类型的计算机化的资源。例如，资源可包括动态对象空间、软件组件、硬件组件等。控制计算机意在表示能够实现本发明功能的任何类型的计算机化的系统。例如，控制计算机可以是服务器、工作站、台式计算机、笔记本式(laptop)计算机、手持设备等。在配置数据库1中存储了例如已存在的RRBAC角色、超级角色和超级角色分配。配置数据库1包含全部数据，所述数据对于全体系统接受用户标识和存储于用户注册表2中的用户组嵌套信息来说是必需的。数据库1可包括一个或多个存储设备，诸如磁盘驱动器或光盘驱动器。数据库1还可包括分布于例如局域网(LAN)、广域网(WAN)或存储域网(SAN)的数据。用户注册表2通常是某些LDAP(轻量级目录访问协议)实现。所有数据都是经由对配置数据库1和用户注册表2进行抽象的数据访问层3而访问的。配置数据库1和用户注册表2可位于与控制计算机连接的进一步的计算机上。图3内所示的其他组件通常全部位于控制计算机上。访问控制决策引擎4必须识别存储于配置数据库1上的现有的RRBAC角色、超级角色和超级角色分配。通常，如果被分配给该用户或用户所属的用户组的全部RRBAC角色实例中所含的全部许可与被分配给该用户或用户所属的用户组之一的任何超级角色实例中所含的全部RRBAC角色的联合包含了敏感操作所需的全部许可，则允许此特定用户执行敏感操作。当且仅当RRBAC角色被列于各超级角色实例或超级角色实例的任何嵌套的子级超级角色实例的

“关联RRBAC角色集合”属性中时，特定RRBAC角色实例被认为被包含在特定超级角色中。在检索已分配的超级角色实例期间，可能附着于相应超级角色分配的全部条件都必须被评估，且那些被评估为假的分配在进一步的评估期间必须被忽略。图3进一步示出了可来回通信的超级角色管理单元5和RRBAC角色管理单元6。超级角色系统管理设施7必须支持超级角色5和RRBAC角色6的管理单元。超级角色系统管理设施7支持管理单元5和6，例如通过提供操作，以创建新的根超级角色实例；以在特定角色实例下创建新的子级超级角色实例；以通过添加和/或移去特定的RRBAC角色实例来更新特定的超级角色实例；以通过查询关于特定的超级角色实例的已存在超级角色分配集合或通过查询特定超级角色中所含的RRBAC角色实例集合来读取特定的超级角色实例；以删除特定的超级角色实例，隐含地删除全部子级超级角色；以创建或删除个体超级角色分配；以及以对个体超级角色实例添加或移去个体条件。用户可在访问控制客户机8上直接与访问控制决策引擎4通信。

参照图4，示出了说明根据本发明的服务器系统功能的序列图，系统通过它而同步并管理对诸如数据库或数据库服务器的一个或多个资源的访问。客户机的请求被系统接收、处理，并创建对客户机的响应并发送至客户机。对所说明的逻辑的一种简单实现可基于：首先，如果以前没有做过也没有被存储于相应缓存中，则对个体用户组和用户计算许可联合，即所谓的权利(entitlement)，再检查由敏感操作所请求的全部许可是否由此许可联合暗示。换句话说，这也可以在每种资源类型基础上进行，这减少了缓存粒度和缓存无效惩罚。这也已提供了基于权利的资源类型的功能，如一般在所谓WebPortal方案、例如所谓WebSphere Portal^TM中所需的。此模型适用于许多服务器范例，包括例如在线银行、订单输入和跟踪、电子商务和电子邮件处理。

类似查询的超级角色分配检查可这样实施：即通过在特定的超级角色实例和全部超级角色实例联合之间构建交汇点，其中所述全部超级角色实例要么被直接分配到给定主干，要么被分配给用户组内它们的主干之一。如果存在涉及携带附加条件的超级角色分配，则必须首先评估这些。

为了在系统内执行一致的访问控制策略(policy)，对其组件资源要求访问控制的全部系统组件调用访问控制决策引擎4以检验执行用户是否具有访问系统组件的足够许可。这可由例如下述方式而做到。

用户想要在使特定的资源集合“R”有效的组件上执行特定操作“O”。该组件根据由系统组件要求的安全策略而确定基于操作“O”的一组所需许可“P”和受影响的资源“R”的集合。通过经由访问控制API(应用编程接口)9调用访问控制决策引擎4，系统组件变成访问控制客户机8。访问控制决策引擎4位于访问控制客户机8和数据访问层3之间。访问控制客户机8向访问控制决策引擎4询问该执行用户“U”是否具有全部所需许可“P”。在第一步，访问控制决策引擎4通过经由数据访问层3调用用户管理或注册表2而标识执行用户“U”。该执行用户“U”的标识是在登录(log-in)时将用户授权与用户注册表2比照期间确定的。访问控制决策引擎4经数据访问层3得到关于对应于执行用户“U”的主干的组。这意味着：访问控制决策引擎4检索该执行用户“U”所属的全部组。在下一步，访问控制决策引擎4通过调用相应的缓存10而检索分配给用户“U”的权利。在被分配给用户或用户所属的用户组之一的权利已被计算的情况下，则把直接分配给用户或用户所属的用户组之一的所有那些权利存储于缓存10内。此后，访问控制决策引擎4标识要被检查的许可“P”的集合。访问控制决策引擎4检查经由RRBAC角色或超级角色分配给执行用户“U”的全部许可11的超级集合是否暗示被请求的许可“P”集合中所含的全部许可，并将布尔计算结果返回访问控制客户机8。根据访问控制决策引擎4的结果，客户机8允许或防止操作“O”的执行。

在执行用户“U”的权利尚未存储于如虚线所示的相应缓存10中的情况下，则把访问控制决策引擎4首先载入被分配给执行用户“U”或用户所属的用户组之一的角色和资源。这些信息全部是经由对配置数据库1进行抽象的数据访问层3而访问的。于是，访问控制决策引擎4识别存储于配置数据库1中的已存在RRBAC角色、超级角色和超级角色分配，并借助此信息的帮助而计算由弯箭头所示的关于用户“U”的权利。在计算了权利以后，该权利被放入合适的相应缓存10中。此后，访问控制决策引擎4检查经由RRBAC角色或超级角色分配给执行用户的全部许可的集合是否暗示基于操作的全部许可，并向允许或防止操作“O”的执行的访问控制客户机8返回。

另一具体例可参照IBM的产品即所谓的WebSphere^TM Portal来说明。例如在Web Sphere^TM Portal中，对给定用户、比方说“Bob”，是否被允许查看给定入口网页，比方说“出纳员页面”，的授权检查以如下被执行：此情形中的访问控制客户机8可能是入口网页累积组件。在此组件将“出纳员页面”包括于将被呈示给用户“Bob”的标记之前，先要对照访问控制API 9而做所谓的“hasPermission()调用”，以检查“Bob”是否被赋予了许可(查看，出纳员页面)。访问控制决策引擎4将接受此方法调用并从用户管理组件2中检索“Bob”所属的用户组列表。然后访问控制决策引擎4将借助此列表而检查用户组之一或“Bob”自己是否被赋予了许可(查看，出纳员页面)。在简单的实现中，这可通过分别检索被赋予“Bob”或被赋予“Bob”所属的用户组之一的全部许可来执行。许可的结果集合称作权利。这些权利被存储于缓存10。如果那些权利之一暗示了所请求的许可，则访问控制决策引擎4将赋予访问，否则会拒绝访问。关于特定用户或用户组的权利是这样计算的(以虚线示出)：即通过构建被包含在直接分配给用户“Bob”或分配给“Bob”所属的用户组之一的，或经内含的超级角色分配而被分配给用户“Bob”或分配给“Bob”所属的用户组之一的全部角色内的所有许可的超级集合。

可以理解，本发明的公开内容可作为商业方法在订购或付费基础上提供。例如，根据本发明的系统可被为顾客提供功能的服务提供者创建、支持、维护和/或配置(deploy)。即，服务提供者可提供如上所述的关于基于计算机的资源的控制访问。

应当注意本发明可实现于硬件、软件或其任何组合中。适宜实现这里所述的方法的任何种类的计算机/服务系统或多个系统或其他装置都是合适的。典型的硬件和软件的组合可以是带有计算机程序的通用计算机系统，所述计算机程序当被加载和被执行时，实现这里所描述的各方法。换句话说，也可利用这样的特定用途的计算机：其包含用于实现本发明的一个或多个功能任务的专用硬件。

Claims (14)

1.一种基于角色的访问控制系统，包括：

角色定义系统，用于将角色定义为个体资源上的许可集合，以分别形成角色实例；以及

超级角色定义系统，用于通过将一组角色实例的集合合组为一个超级角色而定义至少一个超级角色，其中一个超级角色包含被合组的角色实例中所含的全部许可；

其中，所述角色定义系统被配置为通过分别将一个许可动作集合分配给一个角色类型而定义角色类型，还包括角色绑定系统，用于将角色类型分别绑定至资源结构的资源，因而形成角色实例的结构，其中角色实例的结构对应于角色实例的层级树，且角色实例结构内的每个角色实例都具有关联的域根实例，以使得角色类型的实例是由域根实例的层级式子级继承的。

2.根据权利要求1所述的系统，进一步包括超级角色分配系统，用于将超级角色分配给个体用户或用户组。

3.根据权利要求1或2所述的系统，其中所述角色定义系统基于J2EE授权模型。

4.根据权利要求1或2所述的系统，其中由所述角色定义系统定义的角色对应于系统管理性的角色。

5.根据权利要求1所述的系统，还包括角色分块系统，用于为角色类型建立角色类型块，其中角色类型块限制了角色类型实例的继承。

6.根据权利要求1所述的系统，其中通过从被合组的角色实例的集合中添加和/或删除角色实例来修改一个超级角色。

7.根据权利要求1所述的系统，其中一个超级角色被注册于受保护的资源实例的结构内，从而定义了受保护的超级角色实例。

8.根据权利要求1所述的系统，其中超级角色是嵌套地形成超级角色嵌套结构的。

9.根据权利要求1所述的系统，其中通过将分配条件与个体超级角色分配相关联而将超级角色动态地分配给至少一个用户或用户组。

10.一种基于角色的访问控制方法，包括：

将角色定义为个体资源上的许可集合，从而分别形成角色实例；

将一组角色实例合组为一个超级角色，以使得一个超级角色包含被合组的角色实例中所含的全部许可；

其中，定义角色的步骤包括

a.通过分别将一个许可动作集合分配给一个角色类型而定义角色类型；

b.提供资源的结构；

c.分别将角色类型绑定至资源结构的资源，从而形成角色实例的结构，其中角色实例的结构对应于角色实例的层级树，且角色实例的结构内的每个角色实例都具有关联的域根实例，以使得角色类型的实例是由域根实例的层级式子级继承的。

11.根据权利要求10所述的方法，其中一个超级角色被注册于受保护的资源实例的结构内，作为受保护的资源实例，从而定义了受保护的超级角色实例。

12.根据权利要求10和11中的一个所述的方法，包括为角色类型建立角色类型块的进一步的步骤，其中角色类型块限制了角色类型实例的继承。

13.根据权利要求10所述的方法，其中超级角色是嵌套地形成超级角色嵌套结构的。

14.根据权利要求10所述的方法，进一步包括通过将分配条件与个体超级角色分配相关联而将超级角色动态地分配给至少一个用户或用户组。

Images