CN110337676B - 物理访问控制系统中用于访问设置的框架 - Google Patents

Abstract

一种在物理访问控制系统（PACS）中用于访问设置的框架。框架包含：许可请求接口，所述许可请求接口配置成准许用户或监管员请求对资源的访问/撤销访问的许可；许可建议模块，所述许可建议模块与许可请求接口进行通信以接收请求并且建议要被指派给用户或从用户移除的许可。框架还包含：许可验证模块，所述许可验证模块可操作以确保要被指派或要被移除的许可不违反现有访问控制策略，要被指派的许可准许对所有准许的资源的访问，或者要被从用户移除的许可拒绝对所有撤销的资源的访问；以及批准工作流识别模块，所述批准工作流识别模块识别指派或移除许可所要求的批准。

Description

物理访问控制系统中用于访问设置的框架

技术领域

本文中公开的主题一般地涉及物理访问控制系统（PACS），并且更特别地，涉及在PACS中用于访问设置（access provisioning）的框架。

背景技术

物理访问控制系统（PACS）防止未经授权个体访问受保护区域。具有信任凭证（例如，卡、证章、RFID卡、FOB或移动装置）的个体在访问点呈现它（例如，在读取器处刷卡），并且PACS作出是否准予他们访问的几乎即时决定（例如，将门开锁）。通常在控制器通过检查许可数据库以查明是否有链接到请求者的信任凭证的静态许可来计算决定。如果（一个或多个）许可是正确的，则PACS如所请求地将门开锁，向请求者提供访问。通常，在有静态许可的情况下，此类访问请求能够在当天的任何给定时间被作出，并且访问将被准予。在PACS的标准部署中，在中央服务器处保持（一个或多个）许可的数据库，并且将许可数据库的相关部分下载到控制在门处的锁的各个控制器。

当持卡者在读取器处刷卡时，新记录在访问事件记录数据库中被创建，指定当天的时间、持卡者的身份、读取器的标识符和拒绝或准予访问的系统的响应。在PACS系统中，静态许可包含对物理位置（读取器、门）和时间（在其期间准许对读取器的输入的时间段）的组合引用。当前，监管员（administrator）基于他们对设施和组织访问策略的实际知识，决定持卡者应接收的静态许可并且随后在系统中人工查找希望的许可以便将这些指派给用户。然而，此过程耗时且易出错，因为在系统中能够有数千个静态许可并且有数十万个持卡者。另外，在大的组织中，单个监管员可能不具有关于设施和本地场所策略的所有必需知识以正确地这样做。这经常能够导致策略违反或者持卡者在门处等待，因为他们不具有在系统中他们应当已经具有的许可。

发明内容

根据示范实施例，本文中描述的是在物理访问控制系统（PACS）中用于访问设置的框架。框架包含：许可请求接口，所述许可请求接口配置成允许用户或监管员请求对添加/撤销对资源的访问许可的授权；许可建议模块，所述许可建议模块与许可请求接口进行通信以接收请求并且建议要被指派给用户或从用户移除的适当许可。框架还包含：许可验证模块，所述许可验证模块可操作以确保要被指派或要被移除的许可不违反现有访问控制策略，要被指派的许可准许对所有准许的资源的访问，或者要被从用户移除的许可仅拒绝对所有撤销的资源的访问并且不拒绝对准许的资源的访问；以及批准工作流识别模块，所述批准工作流识别模块识别指派或移除许可所要求的批准过程，包含文件提供。

除上面或下面描述的特征中的一个或多个特征外，或者作为备选方案，进一步的实施例能够包含基于由用户呈现的属性、指派给其它用户的静态许可和其它用户的已使用许可中的至少一个，许可要被指派给用户或从用户移除。

除上面或下面描述的特征中的一个或多个特征外，或者作为备选方案，进一步的实施例能够包含建议许可基于用于带有选择的属性的用户的现有访问控制策略。

除上面或下面描述的特征中的一个或多个特征外，或者作为备选方案，进一步的实施例能够包含建议许可基于用于带有类似属性的用户的静态许可。

除上面或下面描述的特征中的一个或多个特征外，或者作为备选方案，进一步的实施例能够包含建议许可基于用于带有类似属性的用户的已使用许可。

除上面或下面描述的特征中的一个或多个特征外，或者作为备选方案，进一步的实施例能够包含属性特定于用户。

除上面或下面描述的特征中的一个或多个特征外，或者作为备选方案，进一步的实施例能够包含属性对用户的群组是通用的。

除上面或下面描述的特征中的一个或多个特征外，或者作为备选方案，进一步的实施例能够包含属性是用户的职能、用户的部门、证章类型、证章/卡ID中的至少一个。

除上面或下面描述的特征中的一个或多个特征外，或者作为备选方案，进一步的实施例能够包含监管员进行以下中的至少一个：审查建议的许可、向建议的许可添加和从建议的许可移除以及向许可验证模块呈现接受的建议的许可。

除上面或下面描述的特征中的一个或多个特征外，或者作为备选方案，进一步的实施例能够包含许可验证模块确保要被指派给用户的许可足以到达所有准许的资源，或者要被从用户移除的许可拒绝对所有撤销的资源的访问。

除上面或下面描述的特征中的一个或多个特征外，或者作为备选方案，进一步的实施例能够包含许可验证模块生成报告，所述报告识别基于许可对准许的资源的访问的任何违反或基于撤销的许可对撤销的资源的任何访问。

除上面或下面描述的特征中的一个或多个特征外，或者作为备选方案，进一步的实施例能够包含不违反现有访问控制策略包含确保带有选择的属性的用户不具有对访问带有另一选择的属性的选择的资源的许可。

除上面或下面描述的特征中的一个或多个特征外，或者作为备选方案，进一步的实施例能够包含许可验证模块生成报告，所述报告识别任何访问控制策略违反。

除上面或下面描述的特征中的一个或多个特征外，或者作为备选方案，进一步的实施例能够包含许可验证模块由监管员调用。

除上面或下面描述的特征中的一个或多个特征外，或者作为备选方案，进一步的实施例能够包含批准工作流识别模块识别批准建议的许可的资源的管理者。

除上面或下面描述的特征中的一个或多个特征外，或者作为备选方案，进一步的实施例能够包含批准工作流识别模块识别完成批准所要求的用户信息。

除上面或下面描述的特征中的一个或多个特征外，或者作为备选方案，进一步的实施例能够包含批准工作流识别模块进行以下中的至少一个：识别用于核实识别的用户信息的经授权的批准者和调用外部工作流引擎并且将外部工作流引擎配置有识别的用户信息。

本文中在实施例中还描述的是一种带有用于访问设置的框架的物理访问控制系统（PACS）。物理访问控制系统包含：用户，所述用户具有包含在其上存储的用户信息的信任凭证，所述用户呈现信任凭证以请求对由门保护的资源的访问；读取器，所述读取器与信任凭证进行操作通信并且配置成从信任凭证读取用户信息；以及控制器，所述控制器执行一组访问控制许可以便准许用户对资源的访问，许可利用用于访问设置的框架被生成。框架包含：许可请求接口，所述许可请求接口配置成准许用户或监管员在PACS中提供对于对资源的访问/撤销访问的许可的请求；以及许可建议模块，所述许可建议模块与许可请求接口进行可操作通信以接收请求，所述许可建议模块基于由用户呈现的属性、指派给其它用户的静态许可和其它用户的已使用许可中的至少一个来建议要被指派给用户或从用户移除的许可。框架还包含：与许可建议模块进行可操作通信的许可验证模块，所述许可验证模块可操作以确保以下中的至少一个：要被指派给用户或从用户移除的许可不违反现有访问控制策略，要被指派给用户的许可足以到达所有准许的资源，以及要被从用户移除的许可拒绝对所有撤销的资源的访问；以及可操作地连接到许可验证模块的批准工作流识别模块，所述批准工作流识别模块识别指派或移除许可所要求的批准。系统还包含控制器被部署在门处以准许经由门对资源的访问。

本文中在实施例中还描述的是一种物理访问控制系统（PACS）中的访问设置的方法。方法包含：接收来自用户和监管员中的至少一个的在PACS中提供对资源的访问的许可或者撤销对资源的许可访问的请求；基于由用户呈现的属性、指派给其它用户的静态许可和其它用户的已使用许可中的至少一个来建议要被指派给用户或从用户移除的许可；验证以下中的至少一个：要被指派给用户或从用户移除的许可不违反现有访问控制策略，要被指派给用户的许可足以到达所有准许的资源，以及要被从用户移除的许可拒绝对所有撤销的资源的访问；以及识别指派或移除许可所要求的批准。

从结合附图进行的以下描述，实施例的其它方面、特征和技术将变得更显而易见。

附图说明

在说明书的结束处的权利要求中特别指出并清楚地要求保护被认为是本发明的主题。从结合附图进行的下面的详细描述中，本发明的上述和其它特征以及优点是显而易见的，其中

图1描绘常规PACS的标准部署和操作；

图2描绘根据实施例的在PACS中用于访问设置的智能框架；以及

图3是描绘根据实施例的PACS中的访问设置的方法的流程图。

具体实施方式

一般地，本文中的实施例涉及用于在PACS中管理访问许可的智能框架。框架从PACS软件内的信息学习以简化指派和撤销对单个或一组持卡者的许可的所有方面。框架能够被使用于简化用于指派许可给新持卡者、为现有持卡者添加新许可或撤销许可的过程。

为了促进本公开的原理的理解的目的，现在将参照附图中图示的实施例，并且将使用特定语言来描述相同的实施例。不过，将理解的是，不意图由此限制本公开的范围。下面的描述在本质上仅是说明性的，并且不意图限制本公开、本公开的应用或使用。应理解的是，贯穿附图，对应参考标号指示相似或对应部分和特征。如本文中所使用的，术语控制器指可包含执行一个或多个软件或固件程序的专用集成电路（ASIC）、电子电路、电子处理器（共享、专用或群组）和存储器的处理电路系统（circuitry）、组合逻辑电路和/或提供描述的功能性的其它适合接口和组件。

另外，用语“示范”在本文中被用来意味着“充当示例、实例或说明”。本文中描述为“示范”的任何实施例或设计不一定被解释为是优选的或优于其它实施例或设计。用语“至少一个”和“一个或多个”被理解成包含大于或等于一的任何整数，即一、二、三、四等。用语“多个”被理解成包含大于或等于二的任何整数，即二、三、四、五等。用语“连接”能够包含间接“连接”和直接“连接”。

如本文中所示出和描述的，本公开的各种特征将被呈现。各种实施例可具有相同或类似特征并且因此相同或类似特征可被标记有相同参考标号，但前面带有指示特征被示出的图的不同首数字。因此，例如，在图X中示出的元件“a”可被标记有“Xa”，并且在图Z中的类似特征可被标记为“Za”。虽然类似参考标号可在一般意义上被使用，但各种实施例将被描述，并且各种特征可包含如本领域技术人员将领会的更改、变更、修改等，无论是被明确描述还是本领域技术人员将另外领会的。

图1描绘常规PACS 10的相对标准部署和操作。在图中，例如持卡者的带有信任凭证14的用户12到达控制对也称为资源26的受保护空间的访问的、例如锁着的门20、大门等带有锁21的给定访问点处的读取器22。用户12呈现由读取器22读取的信任凭证14（例如，智能卡、证章、FOB或移动装置），并且在信任凭证14上存储的识别信息被访问并且传送到本地控制器30。控制器30比较来自信任凭证14的识别信息与在控制器30上的许可数据库25以查明是否有链接到用户的信任凭证14的静态许可25a。如果（一个或多个）许可25是正确的，即存在匹配，并且特定信任凭证14具有访问受保护空间26的授权，则控制器30随后发送命令到门控制器或锁21以如所请求地将门20开锁，为用户或请求者12提供访问。在此实例中，控制器30作出是否准予访问（例如，将门开锁）的几乎即时决定。用户12也预期快速响应，在访问点处等待访问决定将是非常不希望的和浪费的。在PACS 10的常规部署中，在中央服务器50处保持一组（一个或多个）静态许可25a数据库。为确保在被查询时的迅速响应，许可数据库的相关部分被下载到控制在门20处的锁21的各个控制器30。

在诸如图1中示出的访问控制系统10的许多PACS中，卡读取器22和信任凭证14（例如，访问卡）本身均不具有任何可感知的处理、功率或存储器。因此，此类卡读取器22和访问卡通常被称为无源装置。相比之下，访问控制系统10的集中式控制器30和服务器50通常是设计良好和复杂的装置，其带有故障可操作（fail-operational）能力以及先进的硬件和算法以执行快速决定作出。另外，集中式控制器30的决定作出过程基本上是基于执行静态许可25中的查找。静态许可25含有基于静态策略的规则（例如，一个规则可能规定不允许用户12进入到给定房间中），所述基于静态策略的规则仅在策略135（图2）更改时才更改（例如，静态许可25可能被更改以规定用户12能从此以后享有给定房间的特权）。策略135在管控授权的一组规则中被实现。如上所提及的策略135能够被视为不依赖上下文的策略135和规则。与此相反，上下文敏感策略135将要求以下各项的动态评估：PACS 10的不同状态、建筑系统参数、其它建筑系统及外部准则甚至可能包含用户的活动的过去历史。此评估被称为动态授权。

通过图1中描绘的此类互连架构并且通过受保护设施的合理数量的用户12，使用静态许可25的PACS 10迅速作出决定，是可靠的，并且被认为是相当鲁棒的。然而，随着建筑扩张和企业扩张，服务器50上静态许可25a数据库的使用能够增长并且变得使用不便。使下载到控制器30或实现改正变得困难。此外，预期将来的建筑和设施将越来越多地要求更智能的物理访问控制解决方案。例如，访问控制解决方案正在被提供有检测如侵入和火灾的此类状况的能力。一般地，此增加的能力意味着应为此类访问控制解决方案提供有指定被动态评估的状况的能力，例如使得在非法进入的情况下不能进入特定房间，和/或如果特定房间的占用达到其容量限制，则使得不能进入该房间，和/或仅在监督员已经在房间内时才向普通用户允许进入等。此增加的能力导致对于对动态框架的需要的显著强调，所述动态框架用于为新用户指派许可以及为现有用户添加新许可或者修改许可。此类动态框架能够利用学习PACS 10内的信息以促进包含许可和工作流的修改和重新配置的将来任务或使包含许可和工作流的修改和重新配置的将来任务自动化的框架和架构集中地被实现。

现在也转到图2，图2描绘根据实施例的在PACS 10中用于访问设置的智能框架100。框架100由以下不同的模块组成：许可建议模块（PRM）120 – 当新持卡者12被添加到系统10时，PRM 120使用PACS 10中的多种输入来自动建议应被指派给新持卡者12的访问级别和许可25；许可验证模块（PVM）130 - PVM 130确保一旦所请求的许可25被添加或撤销，持卡者12将不违反组织的任何访问策略135和/或能访问所有准许的资源26（房间、区域等）；批准工作流识别模块 - （AWIM）140，AWIM 140分析正在被添加的许可25以识别在PACS 10中能够批准所提出的许可25的指派的用户12。此类用户12将被提供有此类授权，因为他们是委派的资源/区域26所有者或者在过去已批准过许可25的类似指派。AWIM 140也识别批准者中的每个批准者将要求的持卡者信息14（比如说护照的副本、培训证书等）。模块140随后调用工作流引擎以生成和执行识别的工作流来完成要求的批准。

现在以图2继续以便进行与PRM 120有关的详细描述。在实施例中，为在添加新用户12到PACS 10时制定所提出的许可25的建议，监管员27将信息输入到许可请求接口28（也称为访问请求管理器28）中。许可请求管理器提供用于添加用户、为现有用户添加和撤销许可等的用户接口。PRM 120使用指定带有某些属性24（图1）的持卡者12应具有对带有某些属性24的资源/区域26的许可25或者对特定资源/区域26的许可25的现有访问控制策略135。也就是说，带有某些属性24的用户12可与带有该属性24的所有其它用户12具有相同许可25。属性24能够在性质上是一般性的，诸如用户12的职能、证章类型等，但也能够包含诸如证章ID或持卡者ID的特性。属性24能够既是用户特定的，又是对于用户112的整个群组在性质上是通用的。属性是应也可适用于资源的通用概念，即，资源正如用户一样具有属性。在访问控制中，资源经常是建筑内的保护区域、办公室、会议室等。然而，它能够是要求受控访问的任何事物，例如膝上型计算机、服务器、设备等。资源的任何方面（位置、目的、值、电压、重量、可靠性等）可被视为属性。属性24能够既是用户特定的，又是对于用户12的整个群组在性质上是通用的。属性24也能够是“资源属性”、与资源26特定关联的任何属性24和“用户属性”，即，与用户12特定关联的任何属性。其它属性可包含但不限于持卡者的建筑、位置、楼层、部门、在组织内的功能职能、必须参加的培训的有效性（例如，操作由访问机制控制的复杂机械）、其它认证、公民身份和确定对受国际贸易和合规法律影响的材料的访问的出口控制状态等。

在另一实施例中，为制定建议，PRM 120可为带有类似属性24的持卡者12采用静态许可25a。这些是指派给带有与新持卡者12类似的属性24的现有持卡者12的许可25。在又一实施例中，PRM 120可为带有类似属性24的持卡者12采用实际已使用许可25b。这些是在历史上由带有类似属性24的现有持卡者12实际使用过的许可25b。

在为现有持卡者12添加新许可25时，除使用上面列出的信息外，PRM 120还分析用于已经具有所请求的许可25的其它持卡者12的静态许可25a，以建议请求持卡者12可能需要的另外许可25。例如，对可要求访问中间门20的许可25的请求将也导致准予对于该门20的许可25的提议。此外，在撤销对于现有持卡者12的给定许可时，通过分析带有这些许可25的其它持卡者12以及对于其许可25正在被撤销的资源或区域26的属性24，PRM 120也识别和建议应被移除的其它许可25。

以图2继续，在PRM 120生成对于许可25的建议时，例如通过显示带有建议的许可25的类似持卡者12的百分比、使用建议的许可25的持卡12的百分比等，PRM 120也指示建议该许可的根本原因。这允许监管员27（图1）在接受或否决建议时作出明智的决定。一旦监管员27已接受或否决许可25和添加任何新许可25，许可便如在125所示出地被更新和保存，并且许可验证模块（PVM）130被调用。

注意，由PRM 120生成的建议能够被用来填充（populate）用于在整个许可管理工作流中牵涉到的不同实体的不同用户接口。例如，在一个实例中，持卡者12能够使用许可请求接口自行请求对某些资源26的许可25。特别地，在一个实施例中，持卡者12可采用持卡者访问请求用户接口29。在此类情况下，由PRM 120为监管员27生成的许可25建议的子集能够被显示给持卡者12以便帮助他们请求正确的许可25。在另一示例中，在区域或资源26的管理者接收访问请求以进行批准时，落在资源26内的许可25建议的子集可被识别并且显示给管理者，以便它们能主动地批准或添加请求用户12可需要的许可25。

以图2继续，以便进行与许可验证模块（PVM）130有关的详细描述。在实施例中，PVM130确保一旦所请求的许可25被添加或撤销，持卡者12将a）不违反组织的任何访问策略，以及b）能访问所有准许的资源/区域26。在实施例中，为完成验证，PVM 130使用指定带有某些属性24的持卡者12不应具有对访问带有某些属性24的资源/区域26的许可25或者对特定资源/区域26的许可25的访问策略135。换而言之，PVM 130确保基于属性24的选择集合，鉴于那些属性24，持卡者12不具有他们不应具有的对某些资源26的访问。在另一实施例中，无论是单独还是与上面的验证组合，PVM 130也采用指定在到达对于持卡者12的准许的区域/资源26中的每个区域/资源26前需要被访问的区域/资源26的访问通路137。换而言之，如果有对于其要求许可25的中间门，则PVM 130确保基于用户12将需要以行进来从一个资源26到达下一资源的预期通路137，对于中间门的许可25也已被准予。

使用上面的信息，PVM 130可生成报告136，所述报告136指示策略135的任何违反，即根据访问策略135不被允许的许可；任何缺失的许可25，即持卡者12在没有该许可的情况下基于指派的许可25可能不能访问现有资源26之一的许可25；或任何异常许可25，即通常不被指派给带有给定配置文件（profile）、属性24等的持卡者12的许可。例如，在企业中，对“所有周界门”的访问仅被提供给带有属性24“部门”=“安全”的持卡者12。因此，指派“所有周界门”给带有“部门”=“工程”的持卡者12的任何尝试将被标记为异常许可指派。这样的报告通过识别统计异常许可25来被导出。

为促进验证，在实施例中，监管员27可随后使用由PVM 130提供的交互式报告以通过移除违规许可25来调查和修正所识别的违反，或者作出判定以宣布违反为例外并且保持违规许可25作为例外。类似地，在需要的情况下，监管员27能够添加缺失的许可25，或者选择省去缺失的许可25并且宣布缺失的许可25为例外，指示陪同（escort）将使得访问没有对其准予许可25的资源26能实现。

有利地，来自PVM 130的分析的结果还能够在整个工作流内的不同阶段被使用。例如，在持卡者12使用上面提及的持卡者访问请求用户接口29来请求特定访问许可25时，他们能在PVM 130中被立即验证，并且如果他们不符合给定策略135并且没有由监管员27识别的对于该策略135的建立的例外，则来自PVM 130的输出能够被用来自动否决某些许可25请求。类似地，同时反馈能够被提供给持卡者12以指示他们正在请求的对特定资源26的访问通常不由带有他们的配置文件的人持有。备选地，在监管员27或资源26的所有者/管理者在审查来自持卡者12的访问请求时，PVM 130能够由访问许可请求接口或管理器28自动调用。访问许可请求接口28将帮助监管员27作出用于批准/拒绝请求的各种决定。另外，它能够准许监管员27容易地轻松引证用于准予/拒绝许可的理由。

最后，一旦监管员27已解决了任何识别的策略135违反和缺失的许可25，批准工作流识别模块140便被调用以建立用于许可25请求和/或例外的授权和批准的任何要求的工作流。

现在以图2继续，以便进行与批准工作流识别模块（AWIM）140有关的详细描述。工作流在这里指在企业中对于准予或撤销许可所要求的审查和批准的序列。每个企业将定义他们自己的用户属性的集合、那些属性的可采纳证据、对于审查属性和批准许可指派的决策者。在实施例中，AWIM 140分析正在被添加的许可25以在PACS 10中识别因为他们是委派的资源26所有者或者在过去已批准过类似许可25所以能够批准许可25的指派的用户12。AWIM 140也识别批准者中的每个批准者将要求的持卡者12信息（比如说护照的副本、培训证书等）。AWIM 140随后调用工作流引擎，所述工作流引擎通过指派定义的序列中的任务到不同审查者/批准者、请求者，跟踪工作流的进度以及在参与者之间传递数据来管理定义的工作流的执行。它能够是用于执行识别的工作流的第三方软件，像YAWL（又一工作流语言）。例如，如果企业具有对受过心肺复苏术（CPR）培训的员工给予“全部公用区域”访问的策略，则AWIM 140将使用工作流引擎发送电子邮件到培训部门以便核实（发送电子邮件或上载）CPR培训，将待定核实通过电子邮件发送给所识别的安全管理者。一旦培训部门已核实认证，工作流引擎便将通知安全管理者审查和处理许可请求。

现在转到图3，图3描绘图示在PACS 100中访问设置的方法200的流程图。在实施例中，在过程步骤205开始方法200，其中用户12或监管员27请求对访问给定资源26的许可25。如上所述，如在过程步骤210所描绘的，PRM 120基于用户的属性24、类似用户等来提供对于用户12的许可25的建议。可选地，如在过程步骤215所描绘的和如本文中前面所描述的，监管员27可接受或否决所选择的建议的许可25。方法200在过程步骤220继续，其中PVM 130验证建议的许可25和由监管员27选择或添加的任何许可不违反在PACS 10中的任何访问控制策略135。可选地，如在过程步骤225所描绘的，PVM 130也可基于验证来生成报告136。最后，在过程步骤230，如本文中所述的，OVIM建立工作流以获得如对于要向用户12准予的许可25所需要的资源26的管理者的必需批准。

有利地，本文中描述的访问管理框架100展示优于常规PACS的许多益处。框架100显著减少对于执行与PACS 10的监管关联的最常见任务（例如，添加新持卡者12，添加许可25到现有持卡者12，为现有持卡者12移除许可25）中的一些任务所要求的时间，同时防止组织/规章访问策略135的违反。另外，框架100显著减少监管员27对于管理访问许可25所要求的设施和组织实际知识。这对于可能不熟悉组织的受管理访问控制提供者是显著的益处。框架100也使部分的监管过程自动化，并且减少与组织内缺失的许可25有关的召修或服务请求。

另外，如上所讨论的，框架100和系统10可包含监管员27。系统监管员27可被用来供应除任何系统上下文外还有的特殊系统上下文或许可25。此类特殊系统上下文例如可被用来处理困难的情况，包含但不限于撤销恶意用户12的访问权。此外，系统监管员27可布置成由于策略135与每个用户12有关而正式指定策略职能，并且将用户12指派到这些职能中的适当职能。

通常，策略135将不会跨每个个体12而不同，但有可能跨个体12的群组是不同的。从这个意义上来说，职能指可适用于某类用户12的某个策略135或策略135的群组。例如，“监督员”是能够包含对所有房间/资源26的自由访问的策略135的职能，而“正式员工”能够是包含仅在“监督员”存在时才允许对某些受保护房间/资源26的进入的策略135的职能。例如，访问控制系统10也可包含用户特定的授权策略135。此情况的示例能够是特殊用户12，所述特殊用户12在场所不是正式员工，但与被识别为来访者的用户12相比较，需要结构更好的访问控制策略135。

在本文中使用的术语只用于描述特定实施例的目的，并且无意于是限制性的。尽管描述已为了说明和描述的目的而被呈现，但它无意于是详尽的或者被限于所公开的形式。在未脱离本公开的范围的情况下，到此为止未描述的许多修改、变化、变更、替代或等效布置将对本领域技术人员是显而易见的。另外，尽管各种实施例已被描述，但要理解的是，方面可只包含描述的实施例中的一些实施例。相应地，实施例不应被视为受前面的描述限制，而仅由随附权利要求的范围限制。

Claims (20)

1.一种在物理访问控制系统PACS中用于访问设置的框架，所述框架包括：

许可请求接口，所述许可请求接口配置成准许用户或监管员在所述PACS中提供对于对资源的访问/撤销访问的许可的请求；

许可建议模块，所述许可建议模块与所述许可请求接口进行可操作通信以接收所述请求，所述许可建议模块基于由所述用户呈现的属性、指派给其它用户的静态许可和其它用户的已使用许可中的至少一个来建议要被指派给所述用户或从所述用户移除的许可；

许可验证模块，所述许可验证模块与所述许可建议模块进行可操作通信，所述许可验证模块可操作以确保以下中的至少一个：要被指派给所述用户或从所述用户移除的所述许可不违反现有访问控制策略，要被指派给所述用户的所述许可足以到达所有准许的资源，以及要被从所述用户移除的所述许可拒绝对所有撤销的资源的访问；以及

批准工作流识别模块，所述批准工作流识别模块可操作地连接到所述许可验证模块，所述批准工作流识别模块识别指派或移除所述许可所要求的批准过程。

2.如权利要求1所述的框架，其中基于由所述用户呈现的属性、指派给其它用户的静态许可和其它用户的已使用许可中的至少一个，所述许可要被指派给所述用户或从所述用户移除。

3.如权利要求2所述的框架，其中所述建议许可基于用于带有选择的属性的用户的现有访问控制策略。

4.如权利要求2所述的框架，其中所述建议许可基于用于带有类似属性的用户的静态许可。

5.如权利要求2所述的框架，其中所述建议许可基于用于带有类似属性的用户的已使用许可。

6.如权利要求2所述的框架，其中所述属性特定于所述用户。

7.如权利要求2所述的框架，其中所述属性对用户的群组是通用的。

8.如权利要求1所述的框架，其中所述属性是用户的职能、用户的部门、证章类型、证章/卡ID中的至少一个。

9.如权利要求1所述的框架，进一步包含监管员进行以下中的至少一个：审查所述建议的许可、向所述建议的许可添加和从所述建议的许可移除以及向所述许可验证模块呈现接受的建议的许可。

10.如权利要求1所述的框架，进一步包含所述许可验证模块确保要被指派给所述用户的所述许可足以到达所有准许的资源，或者要被从所述用户移除的所述许可拒绝对所有撤销的资源的访问。

11.如权利要求10所述的框架，进一步包含所述许可验证模块生成报告，所述报告识别基于所述许可对准许的资源的访问的任何违反或基于撤销的许可对撤销的资源的任何访问。

12.如权利要求1所述的框架，其中不违反现有访问控制策略包含确保带有选择的属性的用户不具有对访问带有另一选择的属性的选择的资源的所述许可。

13.如权利要求11所述的框架，进一步包含所述许可验证模块生成报告，所述报告识别任何访问控制策略违反。

14.如权利要求11所述的框架，其中所述许可验证模块由监管员调用。

15.如权利要求1所述的框架，其中所述批准工作流识别模块识别批准建议的许可的资源的管理者。

16.如权利要求15所述的框架，其中所述批准工作流识别模块识别完成所述批准所要求的用户信息。

17.如权利要求15所述的框架，其中所述批准工作流识别模块进行以下中的至少一个：识别用于核实所述识别的用户信息的经授权的批准者和调用外部工作流引擎并且将所述外部工作流引擎配置有所述识别的用户信息。

18.一种带有用于访问设置的框架的物理访问控制系统PACS，所述物理访问控制系统包括：

用户，所述用户具有包含在其上存储的用户信息的信任凭证，所述用户呈现所述信任凭证以请求对由门保护的资源的访问；

读取器，所述读取器与所述信任凭证进行操作通信并且配置成从所述信任凭证读取用户信息；

控制器，所述控制器执行一组访问控制许可以便准许所述用户对所述资源的访问，所述许可利用用于访问设置的框架被生成，所述框架包括：

许可请求接口，所述许可请求接口配置成准许用户或监管员在所述PACS中提供对于对资源的访问/撤销访问的许可的请求；

许可建议模块，所述许可建议模块与所述许可请求接口进行可操作通信以接收所述请求，所述许可建议模块基于由所述用户呈现的属性、指派给其它用户的静态许可和其它用户的已使用许可中的至少一个来建议要被指派给所述用户或从所述用户移除的许可；

许可验证模块，所述许可验证模块与所述许可建议模块进行可操作通信，所述许可验证模块可操作以确保以下中的至少一个：要被指派给所述用户或从所述用户移除的所述许可不违反现有访问控制策略，要被指派给所述用户的所述许可足以到达所有准许的资源，以及要被从所述用户移除的所述许可拒绝对所有撤销的资源的访问；以及

批准工作流识别模块，所述批准工作流识别模块可操作地连接到所述许可验证模块，所述批准工作流识别模块识别指派或移除所述许可所要求的批准，

其中所述控制器被部署在所述门处以准许经由所述门对所述资源的访问。

19.如权利要求18所述的物理访问控制系统，其中所述信任凭证是证章、磁卡、RFID卡、智能卡、FOB和移动装置中的至少一个。

20.一种物理访问控制系统PACS中的访问设置的方法，所述方法包括：

接收来自用户和监管员中的至少一个的在所述PACS中提供对资源的访问的许可或者撤销对资源的许可访问的请求；

基于由所述用户呈现的属性、指派给其它用户的静态许可和其它用户的已使用许可中的至少一个来建议要被指派给所述用户或从所述用户移除的许可；

验证以下中的至少一个：要被指派给所述用户或从所述用户移除的所述许可不违反现有访问控制策略，要被指派给所述用户的所述许可足以到达所有准许的资源，以及要被从所述用户移除的所述许可拒绝对所有撤销的资源的访问；以及

识别指派或移除所述许可所要求的批准。

Images