Compact encoding of static permissions for real-time access control

A physical access control system (PACS) for protecting a resource. The PACS includes a credential including information regarding a user stored thereon, the credential presented to request access to a resource protected by an access point. A reader is in operative communication with the credential and configured to read the user information from the credential. The user information includes at least one attribute. A controller executes a set of access control rules, the rules based on policies extracted from a database of static permissions for the user, the policies defining requirements for permitting access of the user to the resource based on the at least one attribute, the controller configured to permit access to the resource.

TECHNICAL FIELD

The subject matter disclosed herein relates generally to physical access control systems (PACS), and more particularly to how PACS decide to grant access to a credential holder when presenting the credential.

BACKGROUND

Physical access control systems (PACS) prevent unauthorized individuals access to protected areas. Individuals who have a credential (e.g., card, badge, RFID card, FOB, or mobile device) present it at an access point (e.g., swipe a card at a reader) and the PACS makes an almost immediate decision whether to grant them access (e.g., unlock the door). The decision is usually computed at a nearby controller by checking a permissions database to ascertain whether there is a static permission linked to requester's credential. If the permission(s) are correct, the PACS unlocks the door as requested providing the requestor access. Typically, with static permissions, such a request for access can be made at a given time of the day. In standard deployment of a PACS, a permission(s) database is maintained at a central server and relevant parts of the permissions database are downloaded to individual controllers that control the locks at the doors.

However, database of permissions can be large especially as the scale of an enterprise grows large. Such large databases can consume significant amounts of memory on a controller. Moreover, because of the size of the database, it can be very time consuming to update controllers by downloading databases from the central server to controllers every time there is a change in any permission(s), credential, controller, or users. Such deployments therefore require more costly installations, by either installing more powerful controllers or larger number of controllers.

BRIEF SUMMARY

According to an exemplary embodiment, described herein A physical access control system (PACS) for protecting a resource The PACS including a credential including information regarding a user stored thereon, the credential presented to request access to a resource protected by an access point, a reader in operative communication with the credential and configured to read the user information from the credential, wherein the user information includes at least one attribute, and a controller executing a set of access control rules, the rules based on policies extracted from a database of static permissions for the user, the policies defining requirements for permitting access of the user to the resource based on the at least one attribute, the controller configured to permit access to the resource.

In addition to one or more of the features described above or below, or as an alternative, further embodiments could include the controller receiving context based information from at least one of the reader, the a door controller, server, cloud, other controllers, or an administrator.

In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the executing is based on the context based information.

In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the context based information includes information regarding attributes specific to or associated with access to the resource.

In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that context based information includes at least one of occupancy of a resource, a maximum occupancy of a resource, a time based constraint, a user based constraint, user history, a PACS constraint, a building system parameters, a parameter of other building systems, and external criteria.

In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the credential is at least one of a badge, a magnetic card, an RFID card, a smart card, a FOB, and a mobile device.

In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the attribute is specific to the user.

In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that wherein the attribute is generic to a group of users.

In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the attribute is at least one of a user's role, a user's department, a user's export control status, a user's certification/training status, a badge type, and a credential ID.

In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the controller executes the policy on controller using standard Attribute-Based Access Control policy execution mechanisms.

In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the controller executes the policy based on an IF-CONDITION-THEN-ACTION rule, wherein each condition of the rule is a logical relationship over user and resource attribute values and action of the rule is to permit or deny access to the resource.

In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the controller executes the rules in a compiled knowledge representation format using graphical traversal algorithms.

In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the system computes a derived attribute for an attribute to enable formulation of compact rules with “compressed derived attribute value checking” in the format of IF-CONDITION-THEN-ACTION rules, wherein the logical condition involves checking whether the derived attribute value is available in a set of derived attribute values.

In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the derived attribute is a derived credential ID and the set of derived attribute values is a collection of intervals of derived credential IDs [min ID, max ID].

In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the controller executes the rules formulated based on derived attribute values.

In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the policies are extracted based on at least one of pattern mining, decision trees, and inductive logic programming.

In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the reader and controller are integrated.

In addition to one or more of the features described above or below, or as an alternative, further embodiments could include a door controller operatively coupled to the controller, the door controller disposed at the door and responsive to commands from the controller to control access to the resource.

Also described herein in an embodiment is a method of encoding of static permissions for real time access control. The method includes extracting a policy from a set of static permissions, receiving a request for access to a resource from a user, the user having a credential including user information stored thereon, the user presenting the credential to request access to a resource protected by a door, and receiving a user information from the credential, wherein the user information includes at least one attribute. The method also includes executing a set of access control rules, the rules based on policies extracted from a database of static permissions for each user defining requirements for permitting access of the user to the resource based on the at least one attribute, and permitting access to the resource if the rules are satisfied, otherwise denying access.

In addition to one or more of the features described above or below, or as an alternative, further embodiments could include the controller receiving context based information from at least one of the reader, a door controller, a server, a cloud based server, another controller, or an administrator.

In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the executing is based further on the context based information.

In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the context based information includes information regarding constraints specific to or associated with access to the resource.

Other aspects, features, and techniques of embodiments will become more apparent from the following description taken in conjunction with the drawings.

DETAILED DESCRIPTION

In general, embodiments herein relate to migrating conventional access decision mechanisms based on database lookups to a mechanism that requires less memory and processing power without disrupting access administration based on static permissions. The migration is based on shifting the decision making process in a typical Physical Access Control System (PACS) to transform static permissions into equivalent representation based on attribute-based rules. The attribute based rules being compiled into a more efficient representation than the database of static permissions for rapid execution and less resource requirements. These attribute based rules may then be executed by and at a local control panel to make an access decision(s).

For the purposes of promoting an understanding of the principles of the present disclosure, reference will now be made to the embodiments illustrated in the drawings, and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of this disclosure is thereby intended. The following description is merely illustrative in nature and is not intended to limit the present disclosure, its application or uses. It should be understood that throughout the drawings, corresponding reference numerals indicate like or corresponding parts and features. As used herein, the term controller refers to processing circuitry that may include an application specific integrated circuit (ASIC), an electronic circuit, an electronic processor (shared, dedicated, or group) and memory that executes one or more software or firmware programs, a combinational logic circuit, and/or other suitable interfaces and components that provide the described functionality.

As shown and described herein, various features of the disclosure will be presented. Various embodiments may have the same or similar features and thus the same or similar features may be labeled with the same reference numeral, but preceded by a different first number indicating the figure to which the feature is shown. Thus, for example, element “a” that is shown in Figure X may be labeled “Xa” and a similar feature in Figure Z may be labeled “Za.” Although similar reference numbers may be used in a generic sense, various embodiments will be described and various features may include changes, alterations, modifications, etc. as will be appreciated by those of skill in the art, whether explicitly described or otherwise would be appreciated by those of skill in the art.

FIG. 1depicts a relatively standard deployment and operation of a conventional PACS10. In the figure, a user12with a credential14(e.g., cardholder) arrives at a reader22at a given access point with a lock21e.g., locked door20, gate etc. controlling access to a protected space or resource26. The user12presents the credential14(e.g., badge, FOB, or mobile device) which is read by the reader22and identification information stored on the credential14is accessed and transmitted to a local controller30. The controller30compares the identification information from the credential14with a permissions database25on the controller30to ascertain whether there is a static permission linked to user's credential14. If the permission(s) are correct, i.e., there is a match, and the particular credential14has authorization to access the protected space, the controller30then sends a command to the door controller or lock21to unlock the door20as requested providing the user or requestor12access. The controller30in this instance, makes an almost immediate decision whether to grant the access (e.g., unlock the door). Users12also expect a rapid response, waiting at the access point of access decisions would be very undesirable and wasteful. In a conventional deployment of a PACS, a set of static permission(s) database25is maintained at a central server50. To ensure rapid response when queried, relevant parts of the permissions database on the server50are downloaded to individual controllers30that control the locks21at the doors20.

In many PACS, such as the access control system10shown inFIG. 1, neither the card readers22nor the credentials14(e.g., access cards) have any appreciable processing, power, or memory themselves. Hence, such card readers22and access cards are usually referred to as passive devices. By contrast, the centralized controller30and server50of the access control system10is usually a well-designed and sophisticated device with fail-operational capabilities and advanced hardware and algorithms to perform fast decision making. Moreover, the decision making process of the centralized controller30is fundamentally based on performing a lookup of the static permissions25. The static permissions25contains static policy based rules (e.g., one rule might provide that user12is not allowed entry into a given room), which change only when the policy changes (e.g., the static permissions25might be changed to provide that user12can henceforth enjoy the privileges of a given room). Policies are implemented in a set of rules that governs authorization. The static policies as mentioned above can be viewed as context-independent policies and rules. In contrast, context-sensitive policies will require a dynamic evaluation of different states of the PACS10, building system parameters, other building systems, and external criteria, maybe even including the user's past history of activities. This evaluation is referred to as dynamic authorization.

With such an interconnect architecture as depicted inFIG. 1and with a reasonable number of users12of a protected facility, the PACS10using static permissions25makes decisions quickly, is reliable, and is considered to be reasonably robust. However, as buildings expand and enterprises expand, the use of the static permissions25database can grow and become unwieldy. Furthermore, it is expected that buildings and facilities of the future will require increasingly more intelligent physical access control solutions. For example, access control solutions are being provided with the capability to detect such conditions as intrusion and fire. In general, this increased capability implies that such access control solutions should be provided with the ability to specify conditions that are dynamically evaluated, e.g., disable entry to a particular room in case of a break-in, and/or disable entry to a particular room if its occupancy reaches its capacity limit, and/or allow entry to a normal user only if a supervisor is already present inside the room, etc. This increased capability leads to a significant emphasis on the need for dynamic authorization. That is, if context-sensitive policies form a significant part of the access control policies of a facility, then the facility will appear to adapt its access control enforcement in keeping with the changes in the system. Thus, the facility will appear to be more intelligent as compared to facilities having a lesser number of context dependent, access control policies.

Such dynamic authorization can be centrally implemented with the current architecture (FIG. 1) including modifications and reconfiguration. While this process can work for small facilities, such a centralized solution may not scale up well with an increase in the number of users, size of the facility, or complexity of the policies, especially context sensitive policies, since progressively more and more information will have to be pushed from various sources to the central controller. In particular, a large number of static permissions25may need to be defined to account for a variety of combinations of contextual conditions that cannot be represented directly with static permissions25. For example, this may include for example defining separate permissions for access to a room during emergency, without emergency, while supervisor is in the room, while supervisor is not in the room, while there is emergency and supervisor is in the room, while there is emergency and supervisor is not in the room, and the like. There can be a combinatorial explosion of a number of static permissions25that may need to be defined to account for dynamic circumstances.

Turning now toFIG. 2, depicting a deployment and operation of a PACS100in accordance with an embodiment.FIG. 2depicts an access control system100using a simpler interconnect architecture and may include readers122-122n(hereinafter just referred to as reader122) access agents120a-120n(e.g., portals such as doors) (herein after just referred to as doors120) that govern access to a resource126(e.g., protected areas such as rooms). The doors120are controlled by a door controller121a-121n(hereinafter just referred to as door controller121) that permits the door120to be opened and access permitted. The resources126, for example, may be enclosed spaces or other restricted areas. Access to the resources126is permitted by the doors120with each of the doors120being provided with a corresponding one of the door-controllers121to control access through a corresponding one of the doors120and into a corresponding one of the resources126.

The PACS100also includes a controller130operating as a rule engine processor. Controller130executes a rule engine that executes policies154or rules155which are a relevant subsets of policies154downloaded to a controller. It will be appreciated that as used herein rules155may be a subset of policies154, but in some instances the two could be the same. Policies154are typically more general for a user112or group of users112, facility, or resource126, while rules155are more specific and may be associated with a specific user112or resource126. For example, the subset of rules155taken from policies154may be limited only to resources126protected by controller130. Furthermore, the rules155may be transformed from their original formulation in154to make them more efficiently executed on controller130. One such transformation may include compilation into a more efficient format suitable for execution, such as a decision diagram or an automaton. As used herein, the terms policies154and rules155may unless otherwise noted, be used and considered interchange to describe the embodiments. The policies154may or may not be context sensitive and dynamic, the operation of which will be described below. In an embodiment the controller130is resource constrained. The readers,122, door controllers or locks121and controller130are connected to an interconnect or network140that is either a wired only network, or a wireless only network, or a mixed wired and wireless network. The PACS100may also include a form of a server150, which may be centrally located or cloud based.

In an embodiment to simplify the architecture of the PACS100, the framework as described with respect toFIG. 1is restructured revising the role of the central controller130making access control decisions as a result of static permissions downloaded form a server based database. In an embodiment, a more compact, functionally equivalent representation of the same access policies encoded in the static permissions125is extracted as depicted at152to formulate a functionally equivalent set of access policies154, from which a relevant subset of the policies154or rules155is downloaded to controller130for execution by the rules engine. This restructured representation links attributes124of cardholders112requesting access, identifiers of resources126to which access is requested (e.g. door IDs), and other contextual parameters (such as time of day) to formulate access control decision making (e.g., allow or deny access at a particular reader122and lock121). Attributes can be general in nature such as a user's112as role, badge type etc., but can also include specifics such as badge ID or cardholder ID. Attributes are a generic concept that should be applicable to resource constraints as well, i.e. resources have attributes just as users. Any aspect of a resource (location, voltage, weight, reliability etc.) may be seen as an attribute.

The attributes124can be both user specific and generic in nature for an entire group of users112. Attributes124can also be “resource attributes”, any attributes124specifically associated with a resource126and “user attributes,” i.e., any attributes specifically associated with a user112. Other attributes may include, but are not limited to cardholder's building, department, functional role within organization, validity of training that must be taken (e.g. to operate complex machinery controlled by the access mechanism), other certifications, citizenship and export control status which determines access to material subject to international trade and compliance laws etc. Some of the attributes124can be “derived” from original attributes124. For example, some rules155that refer to badge ID in order to determine access permissions would be more efficiently expressed if badge ID numbers with the same access rights would be in the same “range” of ID numbers. To accomplish this more efficient representation, we can therefore introduce a new “derived” badge ID attribute, denoted for example as MappedID, by introducing a unique mapping Badge ID→MappedID. For example, if there are 4 individual rules155for Badge IDs 123, 45, 65 and 234, the algorithm could map BadgeID→MappedID such as 123→1, 45→2, 65→3 234→4 and creates a rule “IF MappedID is in interval [1, 4] THEN allow access to R&D Lab”. If badge ID numbers are remapped, in to a mapped grouping, e.g., (BadgeID→MappedID) a new rules155based on the ranges of mapped ID numbers may be employed to define access permissions. Attributes could be derived not only from a single original attribute, but may be derived from multiple other existing attributes.

Furthermore, the rules155may be represented in a compact form, such as a finite state automata, including minimal deterministic finite state automata or a decision diagram, including reduced, ordered decision diagrams. The representation of rules155into more compact format such as automata or decision diagrams can be achieved using standard techniques for “knowledge compilation” in artificial intelligence domain. Each compiled knowledge representation format (such as automata, decision diagrams, disjunctive negation normal forms etc.) provides equivalent information as original rules155but in a more compact or explicit format that allows faster reasoning. For example, in one embodiment, rules155are in the form of compiled knowledge representation format using graph traversal algorithms that either reach “accept” node or “deny” node to determine “accept” or “deny” decision for access request. Finally, rules155may be combined with traditional database lookups in a hybrid representation, so that execution of rules155may be complemented or replaced by standard lookup of permissions based on credential ID.

According to an embodiment, users112carry a credential114, such as RFID cards, smart cards, mobile devices on which a plurality of programmed attributes124are stored. The user-carried devices or credentials114may have some built in computational capabilities and at least some memory for storing attributes124, as opposed to conventional passive cards14(FIG. 1) that are commonly used today For example, smart cards, mobile devices and the like. Users112are required to carry the carried device or credential114and present it for access to a secured space or resource126. While the credentials or user carried devices114are more simply referred to herein as smart cards, it should be understood that the embodiments herein my employ to credentials/user-carried devices114other than smart cards in particular a mobile device with an app that facilitates the credentialing function. Upon an access request by the user112, the access decision is made locally by virtue of the interaction between the smart card114, the reader122, and the door controller121, which supplies some context information associated with the particular resource126to be accessed. In one embodiment, controller130can use the policy, the presented user attributes124, and both the system context and the user's history in order to make a decision regarding the request for access by the user112through the door120.

It should be appreciated that users112would be expected to re-program, reflash, or otherwise alter the attributes124stored on their smart cards/credential114as needed for updates, or on a predetermined granularity to ensure that they can reflect any changes needed to facilitate correct access within the PACS100. In specific instances, it may be possible for some components of the PACS100to make updates. For example, some door controllers121and/or readers122may be instructed to reflash/reprogram the attributes124of certain users or a group of users112by using the readers122attached to the door controllers121to reflash/reprogram the smart cards114. In other instance it may be that updates based on a mobile credential114are pushed to a user's112mobile device. Furthermore, some updates may be made via synchronization to cloud infrastructure or remote servers via standard communication channels based on IP networks.

Continuing withFIG. 2, the readers122at the doors120or other portals are able to read from and write to the user-carried devices or smart cards114. The access agents120are access control enabled, and are more simply referred to herein as doors120. However, it should be understood that the present invention relates to access agents other than doors such a gates, turnstiles, elevator access, vehicle access and the like. Each of the doors120, for example, may be arranged to have one or more readers122. For example, each of the doors120may be arranged to have two readers122with one of the readers122on each side of the corresponding door120. Also, each of the doors120, for example, may be arranged to have a corresponding one of the door controllers121. The door controller121is connected to the reader122and has an actuator for locking and unlocking the corresponding door120. The door controller121will usually have a wireless/locally wired communication component and some processing capabilities. Each reader122may have its own controller130too. Also, the functionality of the door controller121and the reader122can be folded into one integrated unit as well, and a door120may have two such units on either side. In an embodiment as described herein, a resources constrained controller130executing a set of policy based rules155communicates with a reader122and a door controller or lock121to permit/deny access to a resource126. Thus, instead of a central controller130storing all permissions as is done in traditional access control systems, the pertinent portions thereof are broken down into policies154that are stored on a resource constrained controller130in connection with the access control system100. The readers122, and door controller121communicate with the resource constrained controller130in order to choose the rules155as a function of a user's presented attributes124and hence control access to the resource or room126.

The interconnect/network140interconnects the door controllers121, readers,122, and controller130and the like and is typically a mix of wired and wireless components, and can leverage the facility IP network. It should be understood that the interconnect140may instead comprise only wired components or only wireless components, that the wired components may include regular network cables, optical fibers, electrical wires, or any other type of physical structure over which the door controllers121, readers122, controller130of the PACS100can communicate, and that the wireless components may include RF links, optical links, magnetic links, sonic links, or any other type of wireless link over which the door controllers121, readers122, and controller130of the PACS100can communicate.

The interconnect140may be used to transfer system-level information to and program the door-controllers121and readers122. One example of system level information may be administrative actions from an administrator156, like raising the security level of a facility to high, which need to be communicated to all or to at least some of the door controllers121and readers122. Another example can be local information as collected from different door controllers121of a particular room126in order to locally compute the room occupancy using the interconnect140to talk amongst themselves. Moreover, a log of the various door controllers121and readers122may also be periodically pushed to a central controller130or server150using the interconnect140.

Continuing now withFIG. 2and turning also toFIGS. 3 & 4, for additional details regarding the generation of the policies154from the static permissions125.FIG. 3depicts a graphical representation of policies155being applied to replace static permissions125in accordance with an embodiment.FIG. 4depicts a flowchart of the methodology200of compact encoding of static permissions for real time access control as described herein in an embodiment. The policy extraction152may be accomplished on a central server150or any other location. It should be noted that the server150that includes the static permissions database125could be cloud based. The policies154may include authorization policies154that depend on a system context, e.g., specific information associated with or constraining the physical resource126, (e.g., refuse entry if the number of people in a room126is more than a threshold) and that can be altered dynamically. For example, one policy might provide that a requesting user112is allowed access only if the occupancy of the resource126is less than or equal to a predetermined capacity limit, such as 20 occupants In such a case, an allow access or deny access decision is dictated by the system context involving the occupancy of the specific room126. In an embodiment, to implement and enforce context-sensitive policies154, the controller130executes the policy rule-engine instead of a set of static permissions125. The readers122and/or door-controllers121, by virtue of the interconnect140, provides a system context. The system context, in conjunction with the rule-engine, is employed by the controller130to dynamically makes the access decisions.

According to one embodiment of the present invention, at least a portion of the system context results from the evaluating context. For example, a context may simply be a counter that counts the number of users112permitted in the room/resource126controlled by the door120and door controller121. In addition the reader122or door controller121may detect additional or other system contexts to be stored internally and/or transmitted to the controller130.

Attribute-based policies154can be extracted automatically from the database of static-permissions125. Well known algorithms in the area of pattern mining such as association rule mining, decision trees or inductive logic programming, in which concepts are learned from examples and expressed as logic programs, can be used to extract policies154by finding combinations of cardholders' attributes124that determine if a cardholder112should have or should not have a permission based on the examples from the database of static permissions125. For example if all the cardholders112who have access to R&D Lab are from Department Engineering and have Title Research Scientist, then the algorithm will extract the following rule: “IF Department=Engineering and Title=Research Scientist, THEN allow access to R&D Lab”. Note that the policy154(set of rules) has to be 100% accurate and cover 100% of the cardholders112. The accuracy of the rule is computed as percentage of the cardholders112that satisfying the condition of the rules (e.g., have Department Engineering and Title Research Scientist), also satisfy the effect of the rule (e.g. have access to R&D Lab). The coverage of a rule155or a policy154is the percentage of cardholders112whose permissions are explained through the rule154(e.g., if there are 10 cardholders112who have access to R&D Lab and 9 of them have Department Engineering and Title Research Scientist, then, the rule “IF Department=Engineering and Title=Research Scientist THEN allow access to R&D Lab” has 90% of coverage). To ensure the coverage of a policy154is 100%, individual rules that cover only one or a few cardholders112can be added into the policy154. Individual rules155may contain the cardholders'112Badge ID attribute124(e.g., IF cardholder ID is 234 THEN allow access to R&D Lab). During the extraction of policies154, the algorithm aims to extract the minimum number of rules155that explain completely the database of static permissions125. The algorithm also can redefine Badge ID (Badge ID→MappedID) to decrease the number of rules155by grouping individual rules155in only one. For example, if there are 4 individual rules155for Badge IDs 123, 45, 65 and 234, the algorithm could map BadgeID→MappedID such as 123→1, 45→2, 65→3 234→4 and creates a rule “IF MappedID is in interval [1, 4] THEN allow access to R&D Lab”.

Continuing withFIGS. 2, 3, and 4, it will be appreciated that the representation format can be in form of standard Attribute-Based Access Control (ABAC) rules, but also in form of decision diagrams, finite state automata and other compiled logical representations. For example, in an embodiment, the rules155may be compiled into a graphical finite state diagram. Such a structure is advantageous because it facilitates very fast computation speeds. In implementation, at process step205the policies154may be established in two ways. First, generating a new representation based on a previously established set of static permissions125. Second, updates to existing representations, for example, as may be triggered by updates to the permission database (e.g. after performing administration tasks). Further details on the implementation of policies154will be presented below.FIG. 3depicts a graphical representation of rules155being applied to replace static permissions125in accordance with an embodiment.

In an embodiment the policies may be based on a new or updated representation downloaded to controllers130. For example, the controllers130use an algorithm to compute access decisions either locally based on new representation or inquire server150as needed for additional information. In operation, at process step210a user112presents credential114which sends the credential ID, as well as additional user attributes124, such as Department, Citizenship, etc. Controller130receives request for access with cardholder information, such as credential ID and other attributes124as depicted at process step215. Controller130first checks if the credential ID (one of the user's attributes124) is indicated locally as not suitable for local decision making, for example, if the extracted policies are not always able to make the correct decision for the credential holder112and cardholder's static permissions125are not available locally on controller130to make decision via traditional database lookup. The check can be performed, for example, by using a special database for this purpose which we refer to as an exception database. If credential ID is found in the exceptions database, then controller130contacts the static permissions server150to make the access decision. The controller130then also buffers the static permission125for this user112for updating policies154and making the decision locally in future for the same user112. Thereby reducing the decision time for frequent users in the exceptions database. This could happen either by updating the policies155to correctly account for static permissions125of the cardholder112or by explicitly storing cardholders permissions into a local database. It should be noted that this provides a hybrid approach in which attribute-based policies in combination with traditional database lookups may be employed. Moreover, it should be appreciated that for the purposes of the disclosed embodiments, distinction is not always explicitly made, referring to attribute-based rules and policies since database lookups can be thought of as rules based on single attribute124—e.g., credential IDs. If credential ID 124 is not included in the exceptions database, the controller130checks to see if all required attributes124are available from the cardholder to make the decision locally, if not, then controller can either defer the decision making to the static permissions server150or contact the server150to retrieve additional attributes124for the credential ID 124 to make the decision locally. Optionally, as depicted at process step220the controller130may request any context based information from the reader122and door controller121to aid in the access decision. Optionally, controller130may decide to verify attributes124provided by credential114by comparing their values with the values stored on the server150or some other authoritative source of information as determined by the organization. These checks help ensure integrity of the attribute124values stored on the credentials114that might have become outdated. The frequency of these verifications can be determined by access administrators156.

Once the controller130has obtained all required attributes124, and any optional context based information, the controller130executes the policy154based rules155and computes an access decision using attributes, optional context information, and access policy representation stored in the panel as depicted at process step225. Finally as depicted at process step230, the decision made by rule engine in controller130is used to allow or deny access to the requested resource126.

In another embodiment, the policies154are analyzed in conjunction with a facility topology (not shown), are converted into user-specific rules155. Moreover, the readers122and/or door controllers121are also programmed/configured in order for them to evaluate the system context in a distributed manner. The policies154are combined with the system context imposed by the door-controllers121in order to make access control decisions.

As an example, one of the rules155that is produced from the policies154might specify that entry into a particular one of the rooms126(identified by the facility topology) is allowed only if occupancy in this particular room is less than twenty occupants (e.g., the capacity limit of this room). The context of this policy154is the current occupancy of this room126. The door controller121, which is charged with imposing the system context, maintains a count of the occupants/users112of the room126. When a user112requests access to the room126, the policy is evaluated by the controller130after applying the system context which it receives from the door controller121and makes the access decision to grant or deny access. The system context may be received from centralized system as well (from a server, or cloud environment), especially if the context requires aggregating information coming from multiple doors controllers121or readers122connected to multiple controllers130.

The policy extraction algorithm152may also use the topology of the facility in which the PACS100is to be used. In that way, the executable automata may be tailored for this topology. Further, the readers122and door controllers121may also be programmed/configured in order for them to evaluate the system context in a distributed manner. Accordingly, when a user112requests access to a room126, the corresponding reader122transmits the attributes to the controller130and the controller130initiates execution of those of the policies154based on the user's attributes124stored in the user's smart card114which results in an access decision (allow/deny) that is unique to that user and to that room126.

In an embodiment, policies154may be specified in a formal language and stored as an executable on the resource constrained controller130. Examples of dynamic policy types that can be specified using the formal logical language may include the following: assisted access, whereby one user112can enter the resource126only when another designated user112is available to provide access; anti-pass back, whereby re-entry is denied if a user is found to have made an unrecorded exit after a valid entry; system state based policies, whereby access is limited, for example, by the number or category of users112inside a room126; and, temporal policies154, whereby a user112has access to a facility only during specific interval of time. Different or other policies may be implemented.

In another embodiment the extraction algorithm152analyzes and converts the policies154into their equivalent finite state automata. These automata act as rule engines155executing the policies154. They are constructed to allow precisely those behaviors that satisfy the policies154. All of the policies154corresponding to a particular user112are collected together and converted into executable automata (rules155) which are then stored. When the user112requests access to a room126, the corresponding reader transmits the attributes124to the controller130and it initiates execution of those of the rules155based on the policies154, which results in a an access decision (allow/deny) that is unique to that user112. Furthermore, automata may be constructed so not to be unique to the user112but rather depend on general attributes124, such as functional role, department, building, export control status etc. These automata may be applicable to more than one user112and would be evaluated for each such user112.

Accordingly, and particularly with context-sensitive policies, the access control in the PACS100is partially de-centralized. Thus, there is no need for a controller130to centrally maintain information about per-user permissions and system context or to refer to the static permissions database125for each access control decision. Instead, access control decisions are made locally, with the resource constrained controllers130dynamically maintaining pertinent environmental system context. This de-centralization alleviates the problem of scalability as the number of users112, enterprises, and the complexity of the policies154grow.

Moreover, the access control system100is easy to configure and re-configure. At a high level, the readers122and/or the door controllers121are equipped with the knowledge of what they are protecting, but not how they are protecting and how should they interact and compose the system context, but not with details about an user's attributes124or history of activities. The readers122and/or door controllers121are stateless in this regard, making reconfiguration of the facility easier.

While secure authorization is not the primary focus of the present invention, existing mechanisms can be used for a basic secure solution. For example, using symmetric key encryption, where all the access agents and the administrator156share a secret key k, with which they will be configured at the time of installation (or on a subsequent facility-wide reset operation, if the key is compromised), the per-user policy engine and states can be encrypted with k on the user-carried devices, and the readers122and/or the door controllers121can decrypt them using k and further write back encrypted states using k on the smartcard114. This symmetric key encryption ensures security as long as k is not compromised. The policy on the smart card can be certified by a digital certificate and its validity can be verified by using conventional verification services.

The system context may be detected by individual door controllers121through sensors either built into the door controllers121or otherwise connected to components of the PACS100. An example of this can be the presence of a certain chemical in a room126. The system context may also require the collaboration of different door controllers121e.g., to decide if the occupancy of a room126is below a certain threshold. Such contexts, along with each of the individual grants/denials to users112are all represented as discrete events happening at the respective controller130or door controllers121. The policy specification language can also define hierarchical events which are formed out of individual events at different controllers130or121. For example, if event e1 represents the context of “high threshold of a chemical in room A” and event e2 represents the context of “occupancy in room A>=1”, then the event e3 defined as “e1 AND e2” represents the system context “personnel hazard in room A”. Such events may be specified as part of the policies154. The extraction algorithm152can then translate the event definitions to specific actions on the part of the door controllers121by which they will detect system context either individually or in collaboration, as required by the policies154.

Moreover, as discussed above, the interconnect140may include the administrator156. The system administrator156may be used to supply special system contexts that are in addition to any system contexts. Such special system contexts, for example, may be used to take care of emergency situations including but not limited to revoking the access rights of a rogue user. Also, the system administrator156may be arranged to formally specify policy roles as the policies relate to each user112and to assign the users to appropriate ones of these roles.

Usually the policies will not differ across every individual user112, but are likely to be different across groups of users112. In this sense, a role refers to a special attribute124that is of key importance for a certain policy or groups of policies154that is applicable to a certain class of user112. For example, a “supervisor” is a role that can is applicable to the policy154of free access to all rooms126, whereas a “regular employee” can be a role that includes policies154which allow an entry to certain protected rooms126only if a “supervisor” is present. For example, the access control system100may also include user-specific authorization policies154. An example of this can be a special user112who is not a regular employee at a site but needs better structured access control policies154as compared to a user112that is identified as a visitor.

Physical Access Control Systems100need less expensive installations to enforce policies using compact representations. This leads to cheaper installations of PACS100for new users112or reduced frequency and costs of upgrades for existing customers, who would need to install less additional intelligent controllers130due to better usage of available resources. The described embodiments permit reducing the number of cardholder IDs stored on the local controller130by using cardholder attributes124for making decisions for majority of users112. Similarly, it also reduces the number of access levels stored locally at the controller130.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. While the description has been presented for purposes of illustration and description, it is not intended to be exhaustive or limited to the form disclosed. Many modifications, variations, alterations, substitutions, or equivalent arrangement not hereto described will be apparent to those of ordinary skill in the art without departing from the scope of the disclosure. Additionally, while the various embodiments have been described, it is to be understood that aspects may include only some of the described embodiments. Accordingly, embodiments are not to be seen as being limited by the foregoing description, but is only limited by the scope of the appended claims.