Controlling access to a resource using an attribute based access control list

Methods, apparatuses, and computer program products are provided for controlling access to a resource. A method may include determining one or more request attributes associated with a request for access to the resource. The method may further include accessing an access control list associated with the resource. The access control list may include one or more access control attributes associated with the resource. The method may additionally include determining a permission defining one or more access abilities for the resource at least in part by comparing the request attributes to the access control attributes and, for any access control attribute corresponding to a request attribute, including an ability associated with the corresponding access control attribute in the permission. The method may also include determining whether to grant the request based at least in part on the determined permission. Corresponding apparatuses and computer program products are also provided.

TECHNOLOGICAL FIELD

Embodiments of the present invention relate generally to resource security and, more particularly, relate to methods, apparatuses, and computer program products for controlling access to a resource.

BACKGROUND

In the modern computing age, computers are often networked. In this regard, resources stored on a networked computer may be accessible to and/or vulnerable to attack from any computer or user of a computer on the network. Accordingly, securing networked computers may be important to prevent unauthorized users from accessing a resource of a networked computer. In this regard, computing resources are often intended to be accessed only by certain users. For example, a system administrator may define access permissions for system resources so as to restrict access to certain users or groups of users. Further, even a user having a right to access a resource may only be intended to have a certain subset of access abilities for the resource. For example, a system administrator may intend for a user to have the ability to execute a resource, but not to have the ability to write to the resource.

However, existing security models may be inefficient and may not provide sufficient scalability to allow implementation on a system with a large number of resources that may be accessed by a large number of users. For example, existing security models may be particularly unsuited for implementation on networked computers, which may, for example, function as data warehouses having a large number of resources, such as documents, applications, and/or the like. In this regard, providing resource level security on such a system using existing security models may be burdensome to a system administrator and may be inefficient from the standpoint of the processing and hardware resources required for implementation.

BRIEF SUMMARY OF SOME EXAMPLES OF THE INVENTION

Methods, apparatuses, and computer program products are herein provided for controlling access to a resource. These methods, apparatuses, and computer program products may provide several advantages to system administrators, computing system users, and computing systems implementing various example embodiments. In this regard, some example embodiments provide an access control model providing resource level security in a manner that may be less burdensome on system administrators and may be less processing intensive, thereby enhancing scalability on systems having a large number of resources and/or that are accessible by a large number of users. For example, some example embodiments enable resources to be organized within a hierarchy of one or more collections such that a resource may inherit access abilities associated with a containing collection(s). Accordingly, a system administrator may at least partially define access abilities for a resource by organizing the resource within a collection already having defined access abilities.

Further, some example embodiments may provide for determination of a permission for a request for access to a resource by iteratively comparing a request attribute to access control attributes of a hierarchy of access control lists until an access control attribute corresponding to the request attribute is found or the access control list associated with a root collection in a hierarchy of one or more collections in which the resource is contained is reached. In this regard, the iterative attribute comparison process provided by some example embodiments may facilitate inheritance of access abilities. Additionally, some example embodiments may provide for determination of whether to grant a request to access a resource based on a plurality of request attributes. Accordingly, a determination as to whether to grant access to a resource may be made based on the interaction of a plurality of request attributes, thus enabling more complex resource level security definitions to be set forth by system administrators. In this regard, such example embodiments may, for example, determine a permission for a request by performing an iterative attribute comparison process for each request attribute associated with the request.

Additionally, some example embodiments may reduce the burden on processing resources when compared to existing security models. In this regard, some example embodiments may leverage a cached access control model when determining whether to grant a request for access to a resource. Accordingly, such example embodiments may avoid repeated calls to a security database when determining whether a request should be granted.

In a first example embodiment, a method for controlling access to a resource is provided. The method of this embodiment comprises determining one or more request attributes associated with a request for access to the resource. The method of this embodiment further comprises accessing an access control list associated with the resource. The access control list of this embodiment comprises one or more access control attributes associated with the resource. The method of this embodiment additionally comprises determining a permission defining one or more access abilities for the resource at least in part by comparing the request attributes to the access control attributes and, for any access control attribute corresponding to a request attribute, including an ability associated with the corresponding access control attribute in the permission. The method of this embodiment also comprises determining whether to grant the request based at least in part on the determined permission.

In another example embodiment, an apparatus for controlling access to a resource is provided. The apparatus of this embodiment comprises at least one processor. The at least one processor is configured to cause the apparatus of this embodiment to determine one or more request attributes associated with a request for access to the resource. The at least one processor is further configured to cause the apparatus of this embodiment to access an access control list associated with the resource. The access control list of this embodiment comprises one or more access control attributes associated with the resource. The at least one processor is additionally configured to cause the apparatus of this embodiment to determine a permission defining one or more access abilities for the resource at least in part by comparing the request attributes to the access control attributes and, for any access control attribute corresponding to a request attribute, including an ability associated with the corresponding access control attribute in the permission. The at least one processor is also configured to cause the apparatus of this embodiment to determine whether to grant the request based at least in part on the determined permission.

In another example embodiment, a computer program product for controlling access to a resource is provided. The computer program product of this embodiment includes at least one tangible computer-readable storage medium having computer-readable program instructions stored therein. The program instructions of this embodiment comprise program instructions configured to determine one or more request attributes associated with a request for access to the resource. The program instructions of this embodiment further comprise program instructions configured to access an access control list associated with the resource. The access control list of this embodiment comprises one or more access control attributes associated with the resource. The program instructions of this embodiment additionally comprise program instructions configured to determine a permission defining one or more access abilities for the resource at least in part by comparing the request attributes to the access control attributes and, for any access control attribute corresponding to a request attribute, including an ability associated with the corresponding access control attribute in the permission. The program instructions of this embodiment also comprise program instructions configured to determine whether to grant the request based at least in part on the determined permission.

In another example embodiment, an apparatus for controlling access to a resource is provided. The apparatus of this embodiment comprises means for determining one or more request attributes associated with a request for access to the resource. The apparatus of this embodiment further comprises means for accessing an access control list associated with the resource. The access control list of this embodiment comprises one or more access control attributes associated with the resource. The apparatus of this embodiment additionally comprises means for determining a permission defining one or more access abilities for the resource at least in part by comparing the request attributes to the access control attributes and, for any access control attribute corresponding to a request attribute, including an ability associated with the corresponding access control attribute in the permission. The apparatus of this embodiment also comprises means for determining whether to grant the request based at least in part on the determined permission.

In another example embodiment, a method for controlling access to a resource contained within a hierarchy of one or more collections is provided. The method of this embodiment comprises determining a request attribute associated with a request for access to the resource. The method of this embodiment further comprises accessing an access control model comprising a hierarchy of linked access control lists. The hierarchy of linked access control lists of this embodiment comprises an access control list associated with the resource and one or more additional access control lists. Each additional access control list of this embodiment is associated with a respective one of the one or more collections and comprises one or more access control attributes. The method of this embodiment additionally comprises iteratively accessing the access control lists in the hierarchy of linked access control lists beginning with the access control list associated with the resource and proceeding to an access control list associated with a root collection in the hierarchy of collections and comparing the request attribute to the access control attributes in each accessed access control list until an access control attribute associated with the request attribute is found or until the access control list associated with the root collection is reached. The method of this embodiment also comprises, in an instance in which an access control attribute corresponding to the request attribute is found, accumulating an ability associated with the corresponding access control attribute in a permission used to determine whether to grant the request.

In another example embodiment, an apparatus for controlling access to a resource contained within a hierarchy of one or more collections is provided. The apparatus of this embodiment comprises at least one processor. The at least one processor is configured to cause the apparatus of this embodiment to determine a request attribute associated with a request for access to the resource. The at least one processor is further configured to cause the apparatus of this embodiment to access an access control model comprising a hierarchy of linked access control lists. The hierarchy of linked access control lists of this embodiment comprises an access control list associated with the resource and one or more additional access control lists. Each additional access control list of this embodiment is associated with a respective one of the one or more collections and comprises one or more access control attributes. The at least one processor is additionally configured to cause the apparatus of this embodiment to iteratively access the access control lists in the hierarchy of linked access control lists beginning with the access control list associated with the resource and proceeding to an access control list associated with a root collection in the hierarchy of collections and compare the request attribute to the access control attributes in each accessed access control list until an access control attribute associated with the request attribute is found or until the access control list associated with the root collection is reached. The at least one processor is also configured to cause the apparatus of this embodiment, in an instance in which an access control attribute corresponding to the request attribute is found, to accumulate an ability associated with the corresponding access control attribute in a permission used to determine whether to grant the request.

In another example embodiment, a computer program product for controlling access to a resource contained within a hierarchy of one or more collections is provided. The computer program product of this embodiment includes at least one tangible computer-readable storage medium having computer-readable program instructions stored therein. The program instructions of this embodiment comprise program instructions configured to determine a request attribute associated with a request for access to the resource. The program instructions of this embodiment further comprise program instructions configured to access an access control model comprising a hierarchy of linked access control lists. The hierarchy of linked access control lists of this embodiment comprises an access control list associated with the resource and one or more additional access control lists. Each additional access control list of this embodiment is associated with a respective one of the one or more collections and comprises one or more access control attributes. The program instructions of this embodiment additionally comprise program instructions configured to iteratively access the access control lists in the hierarchy of linked access control lists beginning with the access control list associated with the resource and proceeding to an access control list associated with a root collection in the hierarchy of collections and compare the request attribute to the access control attributes in each accessed access control list until an access control attribute associated with the request attribute is found or until the access control list associated with the root collection is reached. The program instructions of this embodiment also comprise program instructions configured, in an instance in which an access control attribute corresponding to the request attribute is found, to accumulate an ability associated with the corresponding access control attribute in a permission used to determine whether to grant the request.

In another example embodiment, an apparatus for controlling access to a resource contained within a hierarchy of one or more collections is provided. The apparatus of this embodiment comprises means for determining a request attribute associated with a request for access to the resource. The apparatus of this embodiment further comprises means for accessing an access control model comprising a hierarchy of linked access control lists. The hierarchy of linked access control lists of this embodiment comprises an access control list associated with the resource and one or more additional access control lists. Each additional access control list of this embodiment is associated with a respective one of the one or more collections and comprises one or more access control attributes. The apparatus of this embodiment additionally comprises means for iteratively accessing the access control lists in the hierarchy of linked access control lists beginning with the access control list associated with the resource and proceeding to an access control list associated with a root collection in the hierarchy of collections and comparing the request attribute to the access control attributes in each accessed access control list until an access control attribute associated with the request attribute is found or until the access control list associated with the root collection is reached. The apparatus of this embodiment also comprises means for, in an instance in which an access control attribute corresponding to the request attribute is found, accumulating an ability associated with the corresponding access control attribute in a permission used to determine whether to grant the request.

The above summary is provided merely for purposes of summarizing some example embodiments of the invention so as to provide a basic understanding of some aspects of the invention. Accordingly, it will be appreciated that the above described example embodiments are merely examples and should not be construed to narrow the scope or spirit of the invention in any way. It will be appreciated that the scope of the invention encompasses many potential embodiments, some of which will be further described below, in addition to those here summarized.

DETAILED DESCRIPTION

FIG. 1illustrates an access control apparatus102for controlling access to a resource according to an example embodiment of the present invention. It will be appreciated that the access control apparatus102is provided as an example of one embodiment and should not be construed to narrow the scope or spirit of the invention in any way. In this regard, the scope of the disclosure encompasses many potential embodiments in addition to those illustrated and described herein. As such, whileFIG. 1illustrates one example of a configuration of an access control apparatus for controlling access to a resource, numerous other configurations may also be used to implement embodiments of the present invention.

The access control apparatus102may be embodied as a server, desktop computer, laptop computer, mobile terminal, mobile computer, mobile phone, mobile communication device, audio/video player, television device, network node, multiple computing devices in communication with each other, any combination thereof, and/or the like. In an example embodiment the access control apparatus102includes various means for performing the various functions described herein. These means may include, for example, one or more of a processor120, memory122, communication interface124, user interface126, or access control unit128for performing the various functions herein described. The means of the access control apparatus102as described herein may be embodied as, for example, circuitry, hardware elements (e.g., a suitably programmed processor, combinational logic circuit, and/or the like), a computer program product comprising computer-readable program instructions (e.g., software or firmware) stored on a computer-readable medium (e.g. memory122) that is executable by a suitably configured processing device (e.g., the processor120), or some combination thereof.

The processor120may, for example, be embodied as various means including one or more microprocessors with accompanying digital signal processor(s), one or more processor(s) without an accompanying digital signal processor, one or more coprocessors, one or more multi-core processors, one or more controllers, processing circuitry, one or more computers, various other processing elements including integrated circuits such as, for example, an ASIC (application specific integrated circuit) or FPGA (field programmable gate array), or some combination thereof. Accordingly, although illustrated inFIG. 1as a single processor, in some embodiments the processor120comprises a plurality of processors. The plurality of processors may be embodied on a single computing device or may be distributed across a plurality of computing devices collectively configured to function as the access control apparatus102. The plurality of processors may be in operative communication with each other and may be collectively configured to perform one or more functionalities of the access control apparatus102as described herein. In an example embodiment, the processor120is configured to execute instructions stored in the memory122or otherwise accessible to the processor120. These instructions, when executed by the processor120, may cause the access control apparatus102to perform one or more of the functionalities of the access control apparatus102as described herein. As such, whether configured by hardware or software methods, or by a combination thereof, the processor120may comprise an entity capable of performing operations according to embodiments of the present invention while configured accordingly. Thus, for example, when the processor120is embodied as an ASIC, FPGA or the like, the processor120may comprise specifically configured hardware for conducting one or more operations described herein. Alternatively, as another example, when the processor120is embodied as an executor of instructions, such as may be stored in the memory122, the instructions may specifically configure the processor120to perform one or more algorithms and operations described herein.

The memory122may include, for example, volatile and/or non-volatile memory. Although illustrated inFIG. 1as a single memory, the memory122may comprise a plurality of memories. The plurality of memories may be embodied on a single computing device or distributed across a plurality of computing devices. The memory122may comprise, for example, a hard disk, random access memory, cache memory, flash memory, a compact disc read only memory (CD-ROM), digital versatile disc read only memory (DVD-ROM), an optical disc, circuitry configured to store information, or some combination thereof. The memory122may be configured to store information, data, applications, instructions, or the like for enabling the access control apparatus102to carry out various functions in accordance with example embodiments of the present invention. For example, in some example embodiments, the memory122is configured to buffer input data for processing by the processor120. Additionally or alternatively, in some example embodiments, the memory122is configured to store program instructions for execution by the processor120. The memory122may store information in the form of static and/or dynamic information. This stored information may be stored and/or used by the access control unit128during the course of performing its functionalities.

The communication interface124may be embodied as any device or means embodied in circuitry, hardware, a computer program product comprising computer readable program instructions stored on a computer readable medium (e.g., the memory122) and executed by a processing device (e.g., the processor120), or a combination thereof that is configured to receive and/or transmit data from/to another device, such as, for example, a server, a user terminal (e.g., a user terminal206illustrated inFIG. 2), a data source (e.g., the data source306illustrated inFIG. 3), and/or the like. In some example embodiments, the communication interface124is at least partially embodied as or otherwise controlled by the processor120. In this regard, the communication interface124may be in communication with the processor120, such as via a bus. The communication interface124may include, for example, an antenna, a transmitter, a receiver, a transceiver and/or supporting hardware or software for enabling communications with another computing device. The communication interface124may be configured to receive and/or transmit data using any protocol that may be used for communications between computing devices. The communication interface124may additionally be in communication with the memory122, user interface126, and/or access control unit128, such as via a bus.

The user interface126may be in communication with the processor120to receive an indication of a user input and/or to provide an audible, visual, mechanical, or other output to a user. As such, the user interface126may include, for example, a keyboard, a mouse, a joystick, a display, a touch screen display, a microphone, a speaker, and/or other input/output mechanisms. In embodiments wherein the access control apparatus102is embodied as a server, aspects of the user interface126may be reduced or the user interface126may even be eliminated. In another example embodiment wherein the access control apparatus102is embodied as a server, at least some aspects of the user interface126may be embodied on an apparatus used by an end user that is in communication with the access control apparatus102, such as for example, a user terminal206illustrated inFIG. 2. The user interface126may, for example, provide means for a user to initiate a request for access to a resource. The user interface126may be in communication with the memory122, communication interface124, and/or access control unit128, such as via a bus.

The access control unit128may be embodied as various means, such as circuitry, hardware, a computer program product comprising computer readable program instructions stored on a computer readable medium (e.g., the memory122) and executed by a processing device (e.g., the processor120), or some combination thereof and, in some example embodiments, is embodied as or otherwise controlled by the processor120. In embodiments wherein the access control unit128is embodied separately from the processor120, the access control unit128may be in communication with the processor120. The access control unit128may further be in communication with one or more of the memory122, communication interface124, or user interface126, such as via a bus.

FIG. 2illustrates a system200for controlling access to a resource according to an example embodiment of the present invention. The system200of this embodiment comprises an access control apparatus202and one or more user terminals206configured to communicate over a network204. The access control apparatus202may, for example, comprise an embodiment of the access control apparatus102wherein the access control apparatus102is embodied as one or more servers, one or more network nodes, or the like that is configured to control access to a resource in response to a request for access to the resource initiated by a remote user terminal or user thereof. The network204may comprise a wireless network (e.g., a cellular network, wireless local area network, wireless personal area network, wireless metropolitan area network, and/or the like), a wireline network, or some combination thereof, and in some embodiments comprises the interne. A user terminal206may comprise any device configured for use by a user to access a resource, such as may be stored on the access control apparatus202, over the network204. In this regard, a user terminal206may be embodied as a desktop computer, laptop computer, mobile terminal, mobile computer, mobile phone, mobile communication device, audio/video player, television device, any combination thereof, and/or the like.

In the example system illustrated inFIG. 2, at least some aspects of the user interface126may be embodied on the user terminal206. For example, the access control apparatus202may be configured to provide a network service, such as a web service, for accessing resources stored on or otherwise accessible via the access control apparatus202to one or more user terminals206. A user of the user terminal206may accordingly initiate a request for access to a resource and the access control apparatus202may be configured to determine whether to grant the request in accordance with one or more of the example embodiments disclosed herein. Accordingly, where a request for access to a resource is described herein, it will be appreciated that the request may be a locally initiated request (e.g., by a user of an access control apparatus) or may be a remotely initiated request (e.g., by a user of a user terminal206in communication with an access control apparatus).

FIG. 3illustrates a system300for controlling access to a resource according to an example embodiment of the present invention. The system300of this embodiment comprises an access control apparatus302and one or more data sources306configured to communicate over a network304. The access control apparatus302may, for example, comprise an embodiment of the access control apparatus102. The network304may comprise a wireless network (e.g., a cellular network, wireless local area network, wireless personal area network, wireless metropolitan area network, and/or the like), a wireline network, or some combination thereof, and in some embodiments comprises the interne. In some embodiments, the network304may comprise the network204. In this regard, although not illustrated inFIG. 3, the system300may further comprise one or more user terminals206as illustrated and described in connection with the system200ofFIG. 2.

A data source306may comprise any computing device comprising a memory configured to store one or more resources such that the one or more resources are accessible over the network304. In this regard, a data source306may comprise, for example, a network attached storage device, a server, a desktop computer, laptop computer, mobile terminal, mobile computer, mobile phone, mobile communication device, audio/video player, any combination thereof, and/or the like. It will therefore be appreciated that when the access control unit128is described herein to determine whether to grant a request for access to a resource, the resource may be a locally stored resource (e.g., a resource stored on an access control apparatus) or a remotely stored resource (e.g., a resource stored on a data source306).

A resource may, for example, comprise any file, folder, executable, program, hardware resource, and/or the like. In some embodiments, a resource may be contained in a collection of resources. A collection may similarly be contained within another collection. In this regard, a resource may be contained within a hierarchy of one or more collections. For example, consider a resource: resource.jpg. The resource may be identified by a unique identifier, such as a uniform resource identifier (URI). In an example embodiment, the unique identifier for the resource may comprise the file path name used to access the resource. For example, the file path name may comprise: \folder_A\folder_B\resource.jpg. In such an embodiment, the resource may be contained within the collection folder_B and the collection folder_B may be contained within the collection folder_A. As another example, a unique resource identifier may comprise an interne protocol address, uniform resource locator, or the like which may be used to access a resource.

The access control unit128may be configured to use an access control model to facilitate controlling access to a resource. In this regard, an access control model may comprise one or more access control lists (ACLs) that may define access abilities for one or more resources to which access is controlled by the access control unit128based on the access control model.

An ACL may be associated with a resource or with a collection of resources and may comprise one or more access control attributes. An access control attribute contained in an ACL may correspond with a respective ability (or a plurality of abilities). An ability may define an access right or privilege with respect to a resource or collection of resources associated with an ACL. In this regard, an ability may comprise any action that may be performed on or using a resource. Example abilities include NONE, READ, WRITE, EXECUTE, ADMINISTER, CHANGE, DELETE, READ_WRITE, READ_DELETE, READ_WRITE_EXECUTE, READ_WRITE_DELETE, some combination thereof, or the like. An all-inclusive ability may comprise a combination of all possible abilities, for example, FULL_ACCESS, or the like. An ability may also comprise a negative ability indicating that a particular access ability for the resource is not allowed. For example, a negative ability may comprise NO_READ, NO_WRITE, NO_EXECUTE, NO_MODIFY, some combination thereof, or the like. An all-inclusive negative ability may comprise a combination of all negative abilities, for example, NO_ACCESS, or the like. An ability may have a unique value, such as may be specified using a hexadecimal value, octal value, or the like. Embodiments wherein abilities have unique values may facilitate accumulation of abilities into a permission mask, as will be described further below with respect to some example embodiments. For example, READ may have the value 0x02 and DELETE may have the value 0x10. Accordingly, READ_DELETE may have the value 0x12, representing the accumulation of the values of READ and DELETE, such as may be performed using a logical OR operation to combine the values of READ and DELETE.

Access control attributes may be grouped into attribute types. For example, an attribute type may comprise ROLE, GROUP, AGE, LOCATION, USER IDENTITY, SECURITY LEVEL, or the like. Example access control attributes for the attribute type ROLE may, for example, comprise MGR, ADMIN, USER, or the like. An access control attribute can also be defined as a value (e.g., 1), a range of values (e.g., 1-3), a list of values (e.g., 2, 3, 5), a list of names (e.g., MGR, ADMIN), or the like. Accordingly, an ACL may define access abilities associated with different access control attributes of a particular attribute type. In this regard, a first access control attribute of an attribute type may be associated with a different ability than a second access control attribute of the attribute type.

An ACL may comprise a plurality of access control attributes. The plurality of access control attributes may fall into a plurality of attribute types. The access control attributes contained in an ACL may be grouped by attribute type and may be set forth in any format that is interpretable by the access control unit128such that the access control unit128may determine the access control attributes included in an ACL. In some embodiments, an access control attribute may be specified in an ACL with a Boolean modifier or other operation. For example, given the access control attribute MGR of the attribute type ROLE, an ACL may include !MGR such that an ability may be associated with every role other than MGR.

Access control lists may be structured within an access control model in one or more hierarchical arrangements of linked access control lists. In this regard, a hierarchy of linked access control lists may be associated with a hierarchy of one or more collections containing a resource. For example, a hierarchy of linked ACLs may comprise an ACL associated with a resource, an ACL associated with a first collection containing the resource, and an ACL associated with a second collection containing the first collection. Each ACL in the hierarchy of linked ACLs may comprise one or more access control attributes. In this regard, a resource may inherit the access control attributes of a containing collection. In order to facilitate iterative traversal of a hierarchy of linked ACLS by the access control unit128when determining whether to grant a request for access to a resource, as will be further described herein below, an ACL may include a link to a higher ACL in the hierarchy. In this regard, an ACL associated with a resource contained in a collection may include a link to an ACL associated with the collection. If the collection is contained in a second collection, the ACL associated with the collection may include a link to an ACL associated with a second collection, and so on until an ACL associated with a root collection in the hierarchy of collections is reached. A link to a higher ACL may comprise a reference to a URI of the ACL, a reference to a location in memory of the ACL, or the like. A hierarchy of ACLs may be contained in a hierarchical data structure, such as a linked list, tree, or the like. Such a hierarchical data structure may further facilitate iterative traversal of the hierarchy.

Having now described the structure of an access control model in accordance with some example embodiments, construction of an access control model will now be described. In this regard,FIG. 4illustrates a flowchart according to an example method for constructing an access control model according to an example embodiment of the invention. The operations illustrated in and described with respect toFIG. 4may, for example, be performed by, with the assistance of, and/or under the control of one or more of the processor120, memory122, communication interface124, user interface126, or access control unit128. Operation402may comprise creating an empty access control model404. In this regard, the access control model404could be considered the resultant of the collective operations inFIG. 4which may serve to populate the empty access control model404created in operation402. Operation406may comprise initializing a collection resource cache408. The collection resource cache408may comprise a container used to store collection resources (e.g., resources that are also collections) encountered during the construction of an access control model to facilitate quick lookup of a collection resource. Operation410may comprise building a URI/attribute/permission mask list412where each entry in the list consists of a URI that references a resource to be placed under access control, an attribute, and a permission mask which may specify one or more abilities. The list412built in operation410may be used for iterative construction of an ACL for each URI in the list.

Operation416may comprise creating a resource418using a URI414from the list412. Operation420may comprise generating an ACL422associated with the resource418. Each attribute424and associated permission mask (or other indication of one or more abilities associated with a respective attribute)426may be added to the ACL, at operation428. The ACL and an indication of the associated URI (e.g., the associated resource) may be added to the access control model, at operation430. Operations416-430may be iteratively repeated for each URI/attribute/permission mask entry in list412.

Referring now toFIG. 5,FIG. 5illustrates a flowchart according to an example method for building a list of resource identifiers, attributes, and permission masks for use in an access control model according to an example embodiment of the invention. In this regard,FIG. 5illustrates operations that may collectively comprise operation410as illustrated inFIG. 4. The operations illustrated in and described with respect toFIG. 5may, for example, be performed by, with the assistance of, and/or under the control of one or more of the processor120, memory122, communication interface124, user interface126, or access control unit128.

Operation502may comprise creating a new URI/attribute/permission mask list504. The list may initially be empty, but may be filled with a list of URIs and for each URI, associated access control attributes and the abilities (e.g., permission masks) associated with the access control attributes by way of the other operations illustrated inFIG. 5. In this regard, the URI/attribute/permission mask list504may be considered the resultant of the collective operations inFIG. 5. Operation506may comprise selecting a list of resources508to be included in the access control model.

Operations510-530will now be described in the context of a single resource. However, it will be appreciated that operations510-530may be repeated for each resource included in the list of resources508. Operation510may comprise getting the URI512of the resource. Operation514may comprise adding the URI of the resource to the list of URIs/attributes/permission masks. Operation516may comprise determining the attribute type518of the attribute522to be associated with the resource. Operation520may comprise creating an attribute522of the attribute type518, which are to be associated with the resource. The created attribute522may be added to the URI/attribute/permission mask list in association with the URI of the resource, at operation514. Operation528may comprise constructing a permission mask530for the created attribute522. The permission mask530may comprise a combination of the one or more abilities associated with the attribute (e.g., the ability1524and ability2526). A constructed permission mask may be added to the URI/attribute/permission mask list504in association with its associated attribute, at operation514. Operations516-530may be repeated for the purpose of associating additional attributes and permission masks to the resource.

Referring now toFIG. 6,FIG. 6illustrates a flowchart according to an example method for creating a resource according to an example embodiment of the invention. In this regard,FIG. 6illustrates operations that may collectively comprise operation416as illustrated inFIG. 4. The operations illustrated in and described with respect toFIG. 6may, for example, be performed by, with the assistance of, and/or under the control of one or more of the processor120, memory122, communication interface124, user interface126, or access control unit128.

Operation602may comprise accessing a URI of a resource. Operation604may comprise determining whether the URI is contained in a collection. If the URI is not contained in a collection, the method may proceed to operation606, where resource608may be created without reference to a collection resource. In this regard, resource608may be considered the resultant of the collective operations inFIG. 6. If, however, the URI is contained in a collection, the method may proceed to operation610where an attempt may be made to find the collection resource in a cached list of collection resources612. Operation614may accordingly comprise determining whether the collection resource was found in the cache612. If the collection resource was not found, a collection resource618may be created, at operation616. The created collection resource618may be added to the cache612, at operation620. The method may return to operation610. In an instance in which a collection resource is found in the cached list of collection resources612, operation622may comprise retrieving the collection resource from the cache612. Operation624may comprise creating the resource with a reference to the collection resource (e.g., the collection resource retrieved in operation622or created in operation616) and the created resource may be output, at operation608.

Referring now toFIG. 7,FIG. 7illustrates a flowchart according to an example method for generating an access control list according to an example embodiment of the invention. In this regard,FIG. 7illustrates operations that may collectively comprise operation420as illustrated inFIG. 4. The operations illustrated in and described with respect toFIG. 7may, for example, be performed by, with the assistance of, and/or under the control of one or more of the processor120, memory122, communication interface124, user interface126, or access control unit128.

Operations702and704may comprise accessing a resource and access control model, respectively. Operation706may comprise attempting to obtain the ACL associated with the resource from the access control model. Operation708may comprise determining whether the resource ACL710associated with the resource was found in the access control model (e.g., based on the results of operation706). In this regard, resource ACL710may be considered the resultant of the collective operations inFIG. 7.

In an instance in which the ACL associated with the resource is not found, the method may proceed to operation712, wherein it may be determined whether the resource is contained in a collection. In an instance in which it is determined that the resource is not contained in a collection, the method may proceed to operation714, where an resource ACL710associated with the resource may be created. Operation716may comprise adding the created ACL to the access control model

In an instance in which it is determined at operation712that the resource is contained in a collection, operation718may comprise accessing the ACL associated with the collection from the access control model. Operation720may comprise determining whether the ACL associated with the collection was found in operation718. In an instance in which the ACL associated with the collection is not found, the method may proceed to operation722wherein the method illustrated inFIG. 7may be recursively performed with the resource accessed in operation702being the collection. In an instance in which the ACL associated with the collection is found, the method may proceed to operation724wherein the ACL associated with the collection is retrieved and used to spawn resource ACL710associated with the resource, at operation726. Operation716may comprise adding the spawned resource ACL710to the access control model.

Referring now toFIG. 8,FIG. 8illustrates a flowchart according to an example method for spawning an access control list associated with a resource from an access control list associated with a collection containing the resource according to an example embodiment of the invention. In this regard,FIG. 8illustrates operations that may collectively comprise operation726as illustrated inFIG. 7. The operations illustrated in and described with respect toFIG. 8may, for example, be performed by, with the assistance of, and/or under the control of one or more of the processor120, memory122, communication interface124, user interface126, or access control unit128. Operation802may comprise accessing the ACL associated with the collection resource. Operation804may comprise creating a resource ACL806associated with the resource. In this regard resource ACL806may be considered the resultant of the collective operations inFIG. 8. Operation804may further comprise including a link or other reference to the ACL associated with the collection resource in the created resource ACL806. In this regard, the link may indicate the hierarchy of ACLs corresponding to the collection hierarchy and may facilitate iterative traversal of the linked hierarchy of ACLs when determining whether to grant a request for access a resource.

The access control unit128may be configured in some example embodiments to load and cache a copy of an access control model, such as in a cache section of the memory122or in other cache memory accessible to the access control unit128. In this regard, when determining whether to grant a request for access to a resource, the access control unit128may access ACLs contained in the cached copy of the access control model without making repeated database queries, which may be both processing intensive and time inefficient. Accordingly, example embodiments wherein a copy of the access control model is cached for use in determining whether to grant a request for access to a resource may facilitate more efficient determination of whether to grant the request.

In example embodiments wherein a copy of the access control model is cached, the access control unit128may be configured to refresh the cached copy of the access control model. In this regard, the original access control model may be updated, such as when new resources, users, and/or the like are added to or removed from a secured system. Accordingly, a cached copy of the access control model may be out of date after the access control model has been updated. The access control unit128may be configured to refresh the cached copy in accordance with any appropriate refresh policy. The access control unit128may, for example, be configured to refresh the cached copy periodically (e.g., once every hour, once a day, once a week, or the like). As another example, the access control unit128may be configured to refresh a cached copy in response to updating of the access control model. It will be appreciated that the refresh policy may be tailored for a secured system on which an embodiment of the invention is implemented. In this regard, some secured systems may be more frequently updated with new resources, users, or the like while other secured systems may be more static. It may be advantageous to refresh a cached copy of the access control model more frequently in a secured system that is updated more frequently.

The access control unit128may be configured to receive a request for access to a resource. The request may, for example, be initiated by a user, by a computing device, or the like. The request may be associated with one or more request attributes. The request attributes may describe characteristics of a user initiating the request, characteristics of a computing device initiating the request, characteristics of a purpose of the request, and/or the like. For purposes of describing some example embodiments, user attributes will be discussed further below. However, it will be appreciated that wherever user attributes are discussed, other types of request attributes may be substituted for user attributes or considered in addition to user attributes. The request may be further associated with one or more abilities. In this regard, a request may require one or more abilities. For example, if the request is to open and edit a file, the request may require both READ and WRITE abilities.

The resource for which access is requested may be indicated by a unique identifier of the resource, such as a URI. The access control unit128may be configured to use the identifier to access an ACL associated with the resource from the access control model (e.g., from a cached copy of the access control model). The access control unit128may be further configured to determine a permission defining one or more access abilities for the resource at least in part by comparing the request attributes to the access control attribute(s) contained in the ACL. In this regard, the access control unit128may be configured to determine whether an access control attribute in the ACL corresponds to a request attribute. This determination may, for example, be performed with respect to each request attribute. If an access control attribute is found that corresponds to a request attribute, the access control unit128may include the ability (or abilities) associated with the access control attribute in the permission. In this regard, the permission may comprise an accumulation of one or more abilities corresponding to the request attributes associated with the request. If a negative ability is accumulated in the permission, then a corresponding positive attribute included in the permission may be removed from the permission. Thus, for example, if a permission includes READ ability and a NO_READ ability is accumulated in the permission, then the READ ability may be removed from the permission, as the requestor is not entitled to have READ ability due to negation by the NO_READ ability. Accordingly, the permission may define the access abilities that the requestor is entitled to and may be used to determine whether to grant the request.

In some example embodiments, the permission is defined as a permission mask. In such embodiments, the access control unit128may initialize an initial empty permission (e.g., 0x00) in response to receipt of a request for access to a resource. As previously discussed, an ability may have a unique value. Accordingly, an ability found to correspond to a request attribute may be accumulated in the permission by performing a logical OR operation on a current value of the permission and the ability such that the ability is accumulated in the permission. Thus, for example, if a user is found to have READ ability (e.g., 0x02) and WRITE ability (e.g., 0x04) for a resource based on a comparison of the request attributes to the access control attributes in the ACL, the determined permission mask may have the value 0x06 (e.g., 0x00 OR 0x02 OR 0x04=0x06).

In some embodiments wherein the permission is defined as a permission mask, the access control unit128may be configured to determine the permission mask by combining two or more intermediate permission masks. In this regard, the access control unit128may be configured to accumulate positive abilities in a first permission mask (e.g., a positive permission mask) and negative abilities in a second permission mask (e.g., a negate permission mask). The access control unit128may be configured to determine the final permission mask by performing a logical AND operation on the first permission mask and the second permission mask such that any negative abilities accumulated in the negative permission mask may cancel out corresponding positive abilities in the positive permission mask. As an example, assume a user is found to have READ ability (e.g., 0x02), WRITE ability (e.g., 0x04), and NO_WRITE ability (e.g., −0x04) for a resource. The resulting positive permission mask may have the value 0x06 (e.g., 0x00 OR 0x02 OR 0x04=0x06) and the resulting negate permission mask may have the value −0x04 (e.g., 0x00 OR −0x04). Accordingly, the resulting permission mask may have the value 0x02 (e.g. 0x06 AND −0x04), indicating the user has only READ ability, as the WRITE ability and NO_WRITE abilities canceled out.

In an instance in which the an access control attribute corresponding to a request attribute is not found in the ACL associated with the requested resource, the access control unit128may be configured to determine whether the resource is contained in a collection. For example, the access control unit128may be configured to determine whether the ACL includes a link to a hierarchically higher order ACL associated with a collection containing the resource. If so, the access control unit128may access the ACL associated with the collection and determine whether the ACL associated with the collection includes an access control attribute corresponding to the request attribute. If the ACL associated with the collection does include an access control attribute corresponding to the request attribute, the access control unit128may include the ability associated with the corresponding access control attribute in the permission as previously described. If, however, the ACL associated with the collection does not include an access control attribute corresponding to the request attribute, the access control unit128may continue to iteratively access the access control lists for collections containing the resource (e.g., by using links contained in the ACLs) until an access control attribute corresponding to the request attribute is found or until an ACL associated with the root collection in the hierarchy of collections containing the resource is accessed. In this way, the access control unit128may be configured to determine access control attributes and associated abilities inherited by a resource contained in a hierarchy of one or more collections.

The access control unit128may use a determined permission to determine whether to grant a request. In this regard, since the permission may comprise an accumulation of determined abilities, the access control unit128may be configured to determine whether an ability required for the request is included within the determined permission. If the required ability is included in the permission, the access control unit128may grant the request. If, however, the required ability is not included in the permission, the access control unit128may deny the request.

In embodiments wherein the permission comprises a permission mask, the access control unit128may be configured to determine whether the permission comprises an ability required for the request by performing a logical AND operation on the permission mask and the value of the ability required for the request. If the result of the AND operation is a non-zero value, then the ability is contained within the request. Thus, for example, if the value of a determined permission mask is 0x12 and the request requires a READ ability having the value 0x02, 0x12 AND 0x02 results in 0x02, indicating that READ ability is included in the permission mask.

As an example, consider a collection of game resources, as described in Table 1 below:

The resources are listed in the left most column and their respective containing collections are indicated in the center column. In this regard, for example, the SLOTS game may be contained in the collection MEMBERS section, which may be contained in the collection GAMES website. The access control attributes and associated abilities included in ACLs associated with the resources are set forth in the right most column. As described previously, a resource may inherit the access control attributes and associated abilities of its containing collections. Accordingly, the SLOTS game may inherit access control attributes and associated abilities contained in ACLs associated with the MEMBERS section and the GAMES website.

Considering the resources, collection hierarchies, and associated ACL contents as set forth in Table 1, given five example users having various example user attributes, the determined access permissions for the resources may be determined as set forth in Table 2:

In this regard, User 1 having the attribute “guest” for the attribute type “ROLE” may have READ ability for the GAMES website, but may not have any access ability for the resources contained in the GAMES website collection. As another example, User 2 may have the attribute “member” for the attribute type “ROLE,” the attribute “NC” for the attribute type “STATE,” the attribute “current” for the attribute type “ACCTSTATUS,” and the attribute “20” for the attribute type “AGE.” Given these attributes, User 2 may have READ ability for the GAMES website due to being a “member.” User 2 may not have any access ability to the PREMIUM section because User 2's ROLE is a “member” and not a “premium-member.” User 2 may have EXECUTE ability for the HUNT′IN game due to having an AGE greater than 14. User 2 may not have any access to the HUNT′IN (LA edition) game. In this regard, while User 2's age is greater than 12 and this attribute is associated with the EXECUTE ability, User 2's state is not LA, which is associated with the ability !EXECUTE, which negates the EXECUTE ability associated with User 2's age attribute.

Considering another example, assume there is a collection of documents that need to be kept secure based on a user's security clearance level, having the attribute type “SECURITYLVL.” The URI for the root collection may be defined as \docs. The ACL for the root collection may, for example, be defined as:

In this regard, a user having a security clearance level between 1-5 may be granted READ ability for a resource contained in the collection \docs, unless the ability is contravened by an ACL associated with a collection or resource contained in the collection \docs. Now, assume the collection \docs includes a collection of secure documents which are only accessible to a user having a security clearance level between 3-5. The URI for this collection may be defined as \docs\secure. The ACL for the \docs\secure collection may, for example, be defined as:

Now assume a resource payrates.pdf is added to the \docs\secure collection and has the URI \docs\secure\payrates.pdf. A user having the role of Payroll Administrator (PRADMIN) may be granted the ability to READ/WRITE/DELETE payrates.pdf. Accordingly, the ACL for payrates.pdf may be set forth as:

Thus, in order to determine if a user requesting READ access to payrates.pdf, a list of the request attributes may be determined. For example, the user may have the attributes ROLE=MGR, SECURITYLVL=3. The access control unit128may, for example, perform the following operations to determine whether to grant the request:Initialize empty permissionLook for attribute type of ROLE and attribute name MGR in the ACL associated with payrates.pdf. (not found)Look for attribute type of ROLE and attribute name MGR in the ACL associated with the \docs\secure collection. (not found)Look for attribute type of ROLE and attribute name MGR in the ACL associated with the \docs collection. (not found)Look for attribute type of SECURITYLVL and attribute name 3 in the ACL associated with payrates.pdf. (not found)Look for attribute type of SECURITYLVL and attribute name 3 in the ACL associated with the \docs\secure collection.Found a SECURITYLVL attribute with attribute name 1-2. Evaluate and find false.Found a SECURITYLVL attribute with attribute name 3-5. Evaluate and find true. Permission=permission ORed with READ.No more attributes in user attribute list. Done.Permission is READ.Required READ attribute is contained in permission. Grant Request.

If, in contrast, the requesting user had the attributes ROLE=USER, SECURITYLVL=1, the request would not have been granted based on the respective ACLs above. If, however, the ACL associated with the \docs\secure collection was instead defined as:

Attribute TypeAttributeAbilitySECURITYLVL3-5READ
the requesting user may have READ permission and the request may be granted. In this regard, the access control unit128may, for example, perform the following operations:Initialize empty permissionLook for attribute type of ROLE and attribute name MGR in the ACL associated with payrates.pdf (not found)Look for attribute type of ROLE and attribute name MGR in the ACL associated with the \docs\secure collection. (not found)Look for attribute type of ROLE and attribute name MGR in the ACL associated with the \docs collection. (not found)Look for attribute type of SECURITYLVL and attribute name 1 in the ACL associated with payrates.pdf (not found)Look for attribute type of SECURITYLVL and attribute name 1 in the ACL associated with the \docs\secure collection.Found a SECURITYLVL attribute with attribute name 3-5. Evaluate and find false.Look for attribute type of SECURITYLVL and attribute name 1 in the ACL associated with the \docs collection.Found a SECURITYLVL attribute with attribute name 1-5. Evaluate and find true. Permission=permission ORed with READ.No more attributes in user attribute list. Done.Permission is READ.Required READ attribute is contained in permission. Grant Request.

Having now described control of access to a resource in accordance with some example embodiments, a more detailed description of some example embodiments will now be described in the context ofFIGS. 9-10. In this regard,FIG. 9illustrates a flowchart according to an example method for determining whether to grant a user request for access to a resource according to an example embodiment of the invention. The operations illustrated in and described with respect toFIG. 9may, for example, be performed by, with the assistance of, and/or under the control of one or more of the processor120, memory122, communication interface124, user interface126, or access control unit128.

Referring now toFIG. 9, when determining whether to grant a user request for access to a resource, the access control unit128may consider a plurality of inputs. The inputs may, for example, comprise an indication (e.g., an identity) of a requesting user902, which may be used to derive the user's attributes. It will be appreciated that while the example embodiments described with respect toFIGS. 9-10discuss user attributes, other types of request attributes may be considered in addition to or in lieu of user attributes. The inputs may additionally comprise an identifier (e.g., a URI)904of the requested resource. The inputs may further comprise an access control model906for the secured system containing the requested resource. The access control model906may comprise a cached copy of the access control model. The inputs may also comprise an ability908required for the request.

Operation910may comprise determining the user's attributes912. Operation914may comprise using the URI904to obtain the requested resource916. Operation918may comprise accessing the ACL920associated with the resource from the access control model906. Operation922may comprise determining the permission for the user's attributes912at least in part by comparing the user's attributes912to the access control attributes in the ACL920. The permission924may be determined as a result of operation922. Operations926and928may comprise determining whether the required ability908is contained within the permission924. In an instance in which the required ability908is determined to be included within the permission924, the request for access to the resource may be granted, at operation930. If, however, the required ability908is determined to not be included within the permission924, the request for access to the resource may be denied, at operation932.

Referring now toFIG. 10,FIG. 10illustrates a flowchart according to an example method for determining a permission according to an example embodiment of the invention. In this regard,FIG. 10illustrates operations that may collectively comprise operation922as illustrated inFIG. 9. The operations illustrated in and described with respect toFIG. 10may, for example, be performed by, with the assistance of, and/or under the control of one or more of the processor120, memory122, communication interface124, user interface126, or access control unit128.

The method illustrated inFIG. 10may utilize a list of request attributes1002(e.g., the list of user's attributes determined in operation910). The method illustrated inFIG. 10may further utilize an ACL1004associated with a requested resource (e.g., the ACL accessed in operation918). Operation1006may comprise initializing a permission1008. The initialized permission may comprise an empty permission that does not yet contain any abilities (e.g., 0x00). Operations1010-1024may be performed iteratively for each request attribute in the list of attributes1002.

Operation1010may comprise accessing a request attribute from the list of attributes1002. Operations1012and1014may comprise comparing the request attribute to the access control attributes in the ACL1004and determining whether the ACL1004includes an access control attribute corresponding to the request attribute. This comparison may be performed using any appropriate comparison method, such as by using a string comparison (e.g., request attribute=access control attribute?), searching for an access control attribute corresponding to the request attribute in a comma separated list of access control attributes in the ACL1004, or the like. The comparison method used may be selected based on the attribute type of the request attribute. In an instance in which the ACL1004is found to include an access control attribute corresponding to the request attribute, operation1016may comprise including an ability associated with the corresponding access control attribute in the permission1008by performing a logical OR operation to combine a value of the permission1008with a value of the ability.

In an instance in which the ACL1004does not include an access control attribute corresponding to the request attribute, the method may proceed to operation1018, in which an ACL1020associated with a collection containing the resource may be accessed. Operations1022and1024may comprise comparing the request attribute to the access control attributes in the ACL1020and determining whether the ACL1020includes an access control attribute corresponding to the request attribute. In an instance in which the ACL1020is found to include an access control attribute corresponding to the request attribute, the method may proceed to operation1016, in which an ability associated with the corresponding access control attribute may be added to the permission1008by performing a logical OR operation to combine a value of the permission1008with a value of the ability. In an instance in which the ACL1020does not include an access control attribute corresponding to the request attribute, the method may return to operation1018wherein a hierarchically higher order ACL associated with a hierarchically higher order containing collection may be accessed. In this regard, operations1018-1024may comprise iteratively accessing ACLs until a corresponding access control attribute is found or until an ACL associated with a root collection containing the resource is accessed.

One exception to operation1016as described is that in an instance in which one or more ability values are negative, the positive ability values may be accumulated in the permission1008and the negative ability values may be accumulated in a second permission mask (e.g., a negatePermission mask). After abilities associated with all request attributes in the list of attributes1002have been determined, the negatePermission mask may be used to remove abilities from the permission1008, such as by performing a logical AND operation to combine the permission mask and the negatePermission mask.

FIG. 11illustrates a class diagram of an example implementation of an example embodiment of the invention. In this regard, the classes1102-114may be respectively implemented as computer program products comprising a computer readable storage medium (e.g., the memory122) storing computer readable program instructions executable by a processing device (e.g., the processor120). In this example embodiment, AccessControlModel1102serves as a container of Resource1106and AccessControlList1104pairs. Resource1106may serve as a container of a resource's identifying and processing information and may include a link to a parent collection (which is also a Resource) containing the resource. AccessControlList1104may serve as a container of Attribute1112and Permission1110pairs. Attribute1112may serve to identify a unique attribute value within attributes of the same AttributeType1114. Permission1110may contain a hex value that represents one or more Ability1108values.

FIG. 12illustrates a flowchart according to an example method for controlling access to a resource according to an example embodiment of the invention. The operations illustrated in and described with respect toFIG. 12may, for example, be performed by, with the assistance of, and/or under the control of one or more of the processor120, memory122, communication interface124, user interface126, or access control unit128. Operation1200may comprise determining one or more request attributes associated with a request for access to a resource. Operation1210may comprise accessing an ACL associated with the resource. Operation1220may comprise determining a permission defining one or more access abilities for the resource. In this regard, operation1220may comprise comparing the request attributes determined in operation1200to access control attribute(s) included in the ACL and, for any access control attribute corresponding to a request attribute, including an ability associated with the corresponding access control attribute in the permission. Operation1230may comprise determining whether to grant the request based at least in part on the determined permission.

FIG. 13illustrates a flowchart according to an example method for controlling access to a resource contained within a hierarchy of one or more collections according to an example embodiment of the invention. The operations illustrated in and described with respect toFIG. 13may, for example, be performed by, with the assistance of, and/or under the control of one or more of the processor120, memory122, communication interface124, user interface126, or access control unit128. Operation1300may comprise determining a request attribute associated with a request for access to the resource. Operation1310may comprise accessing an access control model. The access control model may comprise a hierarchy of linked access control lists, which may comprise an access control list associated with the resource and one or more additional access control lists. Each additional access control list may be associated with a respective one of the one or more collections. Operation1320may comprise iteratively accessing the access control lists in the hierarchy of linked access control lists beginning with the access control list associated with the resource and proceeding to an access control list associated with a root collection in the hierarchy of collections and comparing the request attribute to the access control attributes in each accessed access control list until an access control attribute corresponding to the request attribute is found or until the access control list associated with the root collection is reached. Operation1330may comprise, in an instance in which an access control attribute corresponding to the request attribute is found, accumulating an ability associated with the corresponding access control attribute in a permission used to determine whether to grant the request.

FIGS. 4-10and12-13each illustrate a flowchart of a system, method, and computer program product according to example embodiments of the invention. It will be understood that each block or step of the flowcharts, and combinations of blocks in the flowcharts, may be implemented by various means, such as hardware and/or a computer program product comprising one or more computer-readable mediums having computer readable program instructions stored thereon. For example, one or more of the procedures described herein may be embodied by computer program instructions of a computer program product. In this regard, the computer program product(s) which embody the procedures described herein may be stored by one or more memory devices of a server, desktop computer, laptop computer, mobile computer, or other computing device (e.g., the access control apparatus102, user terminal206, data source306, combination thereof, and/or the like) and executed by a processor (e.g., the processor120) in the computing device. In some embodiments, the computer program instructions comprising the computer program product(s) which embody the procedures described above may be stored by memory devices of a plurality of computing devices. As will be appreciated, any such computer program product may be loaded onto a computer or other programmable apparatus to produce a machine, such that the computer program product including the instructions which execute on the computer or other programmable apparatus creates means for implementing the functions specified in the flowchart block(s) or step(s). Further, the computer program product may comprise one or more computer-readable memories on which the computer program instructions may be stored such that the one or more computer-readable memories can direct a computer or other programmable apparatus to function in a particular manner, such that the computer program product comprises an article of manufacture which implements the function specified in the flowchart block(s) or step(s). The computer program instructions of one or more computer program products may also be loaded onto a computer or other programmable apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block(s) or step(s).

Accordingly, blocks or steps of the flowcharts support combinations of means for performing the specified functions and combinations of steps for performing the specified functions. It will also be understood that one or more blocks or steps of the flowcharts, and combinations of blocks or steps in the flowcharts, may be implemented by special purpose hardware-based computer systems which perform the specified functions or steps, or combinations of special purpose hardware and computer program product(s).

The above described functions may be carried out in many ways. For example, any suitable means for carrying out each of the functions described above may be employed to carry out embodiments of the invention. In one embodiment, a suitably configured processor may provide all or a portion of the elements of the invention. In another embodiment, all or a portion of the elements of the invention may be configured by and operate under control of a computer program product. The computer program product for performing the methods of embodiments of the invention includes a computer-readable storage medium, such as the non-volatile storage medium, and computer-readable program code portions, such as a series of computer instructions, embodied in the computer-readable storage medium.