METHOD AND SYSTEM FOR OPTIMIZING ACCESS CONTROL

Description

[0001] The present invention relates to a method and system for multi-attribute request-based access control, for access to a part of a computer system, the access control allowing to authorize or deny access to a request issuer according to attribute values ​​contained in the request.

[0002] The invention lies in the field of computer system security.

[0003] In many application areas it is necessary to control user or remote application access to IT systems and services, in order to protect confidential data and prevent potential hacking.

[0004] In the field of computer system security, attribute-based access control, also known as ABAC, is well-known. It defines access control based on a set of access rules forming an access policy. This policy defines access rules for parts of the computer system associated with resources based on attribute values ​​(e.g., user attributes, resource attributes, action attributes, environment attributes), operations on the attributes to form predicates, and logical operators, such as conjunction (Boolean AND operator) or disjunction (Boolean OR operator), applied to the predicates. This allows for the definition of complex and context-dependent access rules. In the remainder of this document, we will therefore refer to... access policyall the aforementioned access rules, bearing in mind that a access policy may itself contain access policies (sub-policies) or call on others policies via references, and recursively in both cases.

[0005] ABAC (Active-Based Access Control) addressed the limitations of Role-Based Access Control (RBAC), which defined access privileges solely based on the role of the requesting user, such as system administrator, primary user, or guest user. ABAC, on the other hand, allows access to be granted based on context. For example, a rule can be defined allowing a user (the subject, such as a doctor) to access a file (the resource, such as a medical record) associated with a person (such as a patient) if and only if a specific relationship between the user and the person is met (for example, the person is the doctor's patient). Thus, ABAC enables the definition and verification of complex access policies, but also introduces computational complexity in evaluating these policies.

[0006] One of the standards for implementing attribute-based access control is the XACML language (for "eXtensible Access Control Markup Language"), standardized by OASIS ("Organization for the Advancement of Structured Information Standards"), which defines an architecture and a language to express an access policy and to specify access requests and responses.

[0007] An access request contains a set of attributes that provide information about the context of an attempt to access a protected resource. This includes information about the subject initiating the attempt, the requested resource, the requested operation, and so on. In simpler terms: who is trying to do what to what / whom, and under what circumstances? The access response essentially consists of an authorization decision (permitted or denied), possibly accompanied by orders or recommendations for the module implementing the decision. PEP -as described in the following paragraph.

[0008] The XACML v3.0 architecture comprises several types of modules, also called points: a Policy Decision Point (PDP), which is a centralized decision point designed to communicate with distributed Policy Enforcement Points (PEPs), which protect specific resources from unauthorized access by systematically enforcing the PDP's decision. This distributed architecture offers advantages in terms of modularity and security, but also has drawbacks, as it increases system latency. Communication between the PDP and PEPs, particularly secure communication with mutual authentication, leads to increased processing times, and the PDP, as a centralized decision point, has a very high computational load.

[0009] The article "Na Kika: Secure Service Execution and Composition in Open Edge-Side Computing Network" by Robert Grimm et al, published in 2006, is in the field of web services and secure access to content via communication networks linking computing servers, and describes the implementation of security policies.

[0010] It is known that, in order to reduce access control latency, caching mechanisms can be used to reuse previously calculated access decisions for requests with the same attributes.

[0011] Caching mechanisms rely on data structures that facilitate fast access to previously stored data, such as hash tables and cache memory, which is volatile memory with fast read / write access. However, the efficiency of such a mechanism is generally limited to identical or near-identical repeated queries, meaning queries with exactly the same attribute values, attributes presented in the same order, and without any additional attributes.

[0012] Indeed, in the case where requests include attributes that are not useful for the decision to allow or deny access, and which take different values, such as the date of issue of a request, a simple caching mechanism does not allow a decision to be made based on the memorization of attribute values ​​from previous requests.

[0013] Therefore, with a simple caching mechanism, as soon as requests differ, a decision based on the cache is considered impossible, and full access control performed by the PDP in conjunction with the PEP is implemented. The complexity of the access control remains significant.

[0014] Therefore, there is a need to optimize attribute-based access control to reduce complexity and latency.

[0015] To this end, the invention proposes, according to a first aspect, a multi-attribute query-based access control method according to claim 1.

[0016] Advantageously, the access control method according to the invention makes it possible to optimize the use of a decision cache system, and the computation time, thanks to the memorization of attribute values ​​- relevant for policy evaluation - of prior queries in the form of decision trees.

[0017] The access control method according to the invention may have one or more of the features of dependent claims 2 to 7, taken independently or in combination.

[0018] According to another aspect, the invention relates to a multi-attribute query-based access control system according to claim 9.

[0019] According to another aspect, the invention relates to a computer program comprising software instructions which, when implemented by an electronic computing device, implement an access control method as briefly described above.

[0020] According to another aspect, the invention relates to an information carrier on which software instructions are recorded which, when implemented by an electronic computing device, implement an access control method as briefly described above.

[0021] Other features and advantages of the invention will become apparent from the description given below, by way of example and not limitation, with reference to the attached figures, including: [ Fig 1 ] there figure 1 is an example of an access control architecture in a use case scenario for the invention; [ Fig 2 ] there figure 2 schematically illustrates an access control system according to one embodiment of the invention; [ Fig 3 ] there figure 3 illustrates the updating of a stored decision tree in an example; Fig 4 ] there figure 4 is a synoptic diagram of the functional blocks of an electronic computing device adapted to implement steps of the access control process of the invention according to one embodiment; [ Fig 5 ] there figure 5 is a synoptic diagram of the main steps of an embodiment of an access control method according to the invention.

[0022] There figure 1 schematically illustrates a use case of a system for accessing a computer system or service according to the invention.

[0023] Users U1, U2 request access to a part of a computer system 2, which is a system protected by access rights and includes several servers 4a, 4b, as well as a data storage system 6, which stores protected data.

[0024] The issuer of an access request is either a user, as illustrated in the example of the figure 1 , or an application.

[0025] The part of the computer system for which access is requested is generally a sensitive resource, for example a database or file server, a connected device, or a service or set of executable services.

[0026] The part of the computer system for which access is requested is also called a protected resource.

[0027] In one embodiment, the requested access is characterized by action attributes; for example, if the part of the computer system for which access is requested is a set of files, the requested access may be read and / or write access. If the requested access relates to the execution of software, several service levels may be associated with the access.

[0028] To access part of the computer system 2, a multi-attribute access control system 8 is put in place.

[0029] The multi-attribute access control system 8 includes an electronic storage unit 10, which stores one or more access policies 12 (or "access policies" (in English), each access policy 12 includes a set of rules to be validated to access the required part of the computer system 2.

[0030] For example, several access policies are stored, corresponding to different administrative domains, according to the organizational constraints of the company, and therefore managed by specific administrators.

[0031] Access policies 12 can only be modified by authorized US users with a given security clearance level. Therefore, the access policies are secure.

[0032] The multi-attribute access control system 8 also includes an electronic computing device 14, for example a computer, adapted to implement a centralised module 15 for granting / denying access based on multi-attribute queries, according to the access policy 12. According to XACML terminology, the device 14 performs a PDP function, but this function is enhanced by the invention as explained below.

[0033] In one embodiment, the multi-attribute request-based access authorization / denial module 15, the main component of the PDP, is implemented as a computer program comprising software instructions, stored on a computer-readable medium (not shown). The computer-readable medium is, for example, a medium capable of storing electronic instructions and being connected to a bus of a computer system. Examples of such readable media include optical discs, magneto-optical discs, ROMs, RAMs, any type of non-volatile memory (e.g., EPROM, EEPROM, FLASH, NVRAM), magnetic cards, or optical cards.

[0034] Alternatively, module 15 is implemented as a programmable logic component, such as an FPGA (from the English Field Programmable Gate Array), a GPU (graphics processing unit) or a GPGPU (from English) General-purpose processing on graphics processing), or in the form of a dedicated integrated circuit, such as an ASIC (from the English Application Specific Integrated Circuit).

[0035] The multi-attribute access control system 8 also includes storage and computing devices 16, adapted to store and provide additional attributes to module 15 (PDP) which complement the attributes already provided in the request by module 20 (PEP) for processing user access requests, for example databases or identity services.

[0036] The multi-attribute access control system 8 also includes one or more electronic computing devices 18, each implementing a user access request processing module 20. According to XACML terminology, each module 20 performs a PEP function, which is enhanced by the invention as explained below.

[0037] Each user U 1 (resp. U 2) makes an access request R 1 (resp. R 2) called a user request.

[0038] For example, each user U1, U2 wants to access a file stored on server 4b of computer system 2 for reading.

[0039] Module 20 is configured to format multi-attribute access queries REQ 1, REQ2 from user queries, and to check for the possibility of granting or denying access based on data stored in the decision cache system of computing device 18, described in detail below.

[0040] Examples of attributes include: attributes relating to the request sender, or subject (user U1 or U2), for example, their identifier, their role in their organization, their level of authorization; attributes relating to the action of the subject; attributes relating to the part of the system or the resource to be accessed, for example, an identifier, a type, an address; attributes relating to the environment, for example, the current date / time.

[0041] If it is impossible to make a decision from the data stored in the decision cache system, the multi-attribute access control queries REQ 1, REQ 2 are, if necessary, formatted according to an appropriate predetermined format, for example the XACML format, and transmitted to the centralized module 15 according to access policy 12.

[0042] In the example illustrated in the figure 1, access to computer system 2 is denied in response to the multi-attribute access request REQ 1, therefore user U 1 who issued the user request R 1 is not authorized to access part of computer system 2.

[0043] Access to computer system 2 is authorized in response to the multi-attribute access request REQ 2, therefore user U 2, who issued user request R 2, is authorized to access computer system 2, as indicated by arrow 25 in the figure 1 .

[0044] In one embodiment, the user access request processing module 20 is implemented as computer programs comprising software instructions. Each computer program is stored on a computer-readable medium (not shown). The computer-readable medium is, for example, a medium capable of storing electronic instructions and being connected to a bus of a computer system. Examples of such readable media include optical discs, magneto-optical discs, ROMs, RAMs, any type of non-volatile memory (e.g., EPROM, EEPROM, FLASH, NVRAM), magnetic cards, or optical cards.

[0045] Alternatively, module 20 is implemented as programmable logic components, such as an FPGA (from the English Field Programmable Gate Array), a GPU (graphics processing unit) or a GPGPU (from English) General-purpose processing on graphics processing ), or in the form of a dedicated integrated circuit, such as an ASIC (from the English Application Specific Integrated Circuit).

[0046] The access control system 8, with all its hardware and software components, acts as a protective barrier for access to the computer system 2.

[0047] There figure 2 illustrates components, also called modules, of module 20 for processing user access requests and of centralized module 15 for authorizing / denying access based on multi-attribute requests based on rule sets forming access policies 12, implemented in an access control system 8 according to an embodiment of the invention.

[0048] In one embodiment, each module is implemented either as computer programs with software instructions as explained above, or as programmable logic components.

[0049] The user request processing module 20 includes a request transformation module 30, configured to receive requests for access to a part of a computer system 2, transmitted by a client computer system 28 operated by a user.

[0050] The request transformation module 30 is also adapted to transmit the result of authorization or refusal to the client computer system 28. In case of authorization, access to the part of the computer system is provided to the client system.

[0051] The query transformation module 30 is configured to apply ordering and factorization of the attributes of a multi-attribute access query, in order to obtain a set of attributes in a format called canonical format.

[0052] For example, the attributes of a multi-attribute query are reordered according to a predetermined order, and attribute values ​​are grouped if the same attribute identifier is repeated. For example, if an attribute has several associated attribute values ​​in the query, these values ​​are grouped, for example, as a list of values. Thus, a second set of attributes is obtained from a first set of attributes.

[0053] The attribute values ​​of a multi-attribute query are referred to below as query attribute values.

[0054] A multi-attribute access request, with the values ​​of the request attributes, is transmitted to a decision cache system 32 allowing, in some cases, a quick decision to authorize or deny access to the part of the computer system, based on data relating to previously stored multi-attribute access requests.

[0055] A decision caching system relies on a data structure optimized for read access, preferably stored in cache memory (volatile electronic memory with fast read and write access). Fast access is achieved through hash tables or other types of associative arrays optimized for fast access.

[0056] The decision cache system 32 is configured to manage a fast access authorization decision cache 34, which stores a decision tree associated with a centralized access authorization / deny decision module 15 (PDP module).

[0057] The decision cache system 32 is configured to implement a presence check in the data cache 34 (decision tree) to obtain a decision to allow or deny access based on the attribute values ​​of the current request, and past decisions already stored.

[0058] The authorization decision cache system 32 is also configured to perform updates to the decision trees stored in module 34.

[0059] Module 20 also includes a module 36 for interfacing with module 15 for deciding whether to grant / deny access based on sets of rules forming access policies 12.

[0060] It should be noted that, in a variant not illustrated in the figure 2 , if the user request processing module 20 (PEP) communicates with several PDPs, the PEP must use a decision tree and a specific interface module 36 per PDP.

[0061] Interface module 36 is specifically configured to format a multi-attribute access request into a format suitable for communicating with module 15, for example XACML, and to transmit such a formatted request to module 15 for granting / denying access decisions.

[0062] This module 36 is used in the case where the data stored in the decision cache 34 does not allow a decision to be made to grant or deny access.

[0063] Module 15 includes a module 38 for managing access requests and the decision evaluation contexts associated with each request. This module processes each authorization request coming from the interface module 36 and, based on this request, creates, maintains, and potentially enriches an associated evaluation context. It then communicates this context, based on the access request, to an access policy evaluation module 42, also called decision-making engine.Module 38 is adapted to communicate with a module 40 for collecting information - metadata - and monitoring policy evaluation by module 42. Module 40 is configured to transmit information relating to the implementation and evaluation of the access policy, including at least the list of attributes actually used by module 42 for decision-making, and possibly other information to improve the decision cache system 32 of module 20.

[0064] Indeed, a multi-attribute query may, in certain application scenarios, contain attribute values ​​that are not useful for policy evaluation. This information relating to policy implementation and evaluation is passed to module 38, which transmits it, as update parameters for the decision cache system 32, in the responses sent to the interface module 36.

[0065] There figure 3 This schematically illustrates updates to a decision tree, stored in the fast access cache 34 and associated with access requests to a computer system, for example, a portion of a stored database. For example, the portion of the system is a human resources database in a company.

[0066] Of course, this is a simplified example presented here for explanatory purposes.

[0067] Following an initial user access request, a first decision tree 50 is stored. Following a first update, a second decision tree 52 is stored. Following a second update, a third decision tree 54 is stored.

[0068] A decision tree is a hierarchical decision graph, formed of nodes comprising a root node, one or more intermediate nodes and one or more terminal or leaf nodes, each node having an associated level of depth as explained in detail below.

[0069] Each stored decision tree 50, 52, 54 includes a root node 60 associated with an attribute, which is the attribute "subject.role" in this example, representing the role of the subject (user requesting access to a part of the system) in the company.

[0070] The decision tree 50 further includes a terminal node 62 representing the decision to grant or deny access to the subject, characterized by the attribute value "subject.role" stored in connection with the edge 64 linking the root node 60 and the terminal node 62. In the example, the attribute value is "Chief_HR_Officer". In other words, access to the entire database is granted if the role of the subject identified in the user request is "Chief_HR_Officer".

[0071] Following a new multi-attribute access request REQ1, access authorization is obtained from the centralized decision module 15. In this example, the access request includes the following attributes: REQ1: Subject.id=Charlie Subject.role=Manager Action.id=read_HR_profile Resource.id=Bob Resource.mgr=Charlie

[0072] This request relates to access to a sub-part of the database concerning a person, also called a resource, whose identifier is Bob.

[0073] The RESP1 response to the REQ1 request containing the decision to authorize or deny access includes at least one update information intended for module 20, containing the attributes actually used by the policy evaluation by module 42 for the REQ1 request.

[0074] For example, the RESP1 response includes: Decision: Permit Advice: attributes: { subject.role, resource.mgr, subject.id}

[0075] The "advice" parameter contains update information, in particular a list of the attributes actually used in the decision to allow or deny access according to the policy to be applied.

[0076] Decision tree 50 is updated, resulting in decision tree 52. In the example shown, the update consists of adding branches to decision tree 50 to obtain decision tree 52.

[0077] Intermediate nodes 66 and 68 are added, as well as another terminal node 70. Intermediate node 66 is a child node of root node 60, and is associated with the attribute "resource.mgr".

[0078] In one embodiment, increasing depth levels are associated from the root node to the terminal nodes.

[0079] Of course, this is a convention; another ordering is possible.

[0080] Thus, if we associate the depth level 0 with the root node, the intermediate node 66 has a depth level equal to 1.

[0081] A node (root node or intermediate node) of depth level N, where N is an integer greater than or equal to 0, is the parent of a node of depth N+1 when they are connected by an edge in the tree. A node of depth N+1 (intermediate node or terminal node) is the child of a node of depth N when they are connected by an edge in the tree.

[0082] For example, root node 60 is the parent of terminal node 62 and intermediate node 66. Intermediate node 66 is a child of root node 60. Intermediate node 68 is a child node of intermediate node 66 and is associated with the attribute "subject.id". In this example, intermediate node 68 has a depth level of 2.

[0083] Node 70 is a terminal node representing the authorization or denial of access. In decision tree 52, terminal node 70 is a child node of node 68.

[0084] The nodes are connected in the decision tree 52 by edges, associated with attribute values. Each edge 72, 74, 76 that connects two nodes is associated with the attribute value of the parent node, which is also the node of lower depth according to the chosen convention.

[0085] Thus, edge 72, connecting the root node 60 associated with the attribute "subject.role" and the intermediate node 66, is associated with the value "Manager" of the attribute "subject.role" of the REQ1 query.

[0086] Edge 74, connecting intermediate node 66 associated with the attribute "resource.mgr" and intermediate node 68, is associated with the value "Charlie" of the attribute "resource.mgr" of query REQ1.

[0087] Edge 76, connecting the intermediate node 68 associated with the attribute "subject.id" and the terminal node 70, is associated with the value "Charlie" of the attribute "subject.id" of the REQ1 query.

[0088] In other words, the subject Charlie, who has a manager role, is authorized to access, in the database, the information relating to the people he is registered as a manager of, in particular "Bob".

[0089] Following a new multi-attribute access request REQ2, an access denial is received from the PDP. In this example, the REQ2 access request includes the following attributes: REQ2: Subject.id=Dave Subject.role=Manager Action.id=read_HR_profile Resource.id=Bob Resource.mgr=Charlie

[0090] In other words, in this example, the REQ2 query is similar to the REQ1 query, but the subject of the query is Dave and not Charlie.

[0091] The RESP2 response to the REQ2 request containing the access refusal decision also includes at least one update information containing the attributes actually used for the evaluation of the access policy.

[0092] For example, the RESP1 response includes: Decision: Deny Advice: attributes: { subject.role, resource.mgr, subject.id}

[0093] The "Advice" parameter contains update information and provides a list of attributes actually used in the decision to allow or deny access according to the access policy to be applied.

[0094] Decision tree 52 is updated, resulting in decision tree 54. In the illustrated example, the update consists of adding branches to decision tree 54.

[0095] A terminal node 78, child of the intermediate node 68, is added, and this terminal node is associated with a "Deny" decision.

[0096] The edge 80 connecting the intermediate node 68 associated with the attribute "subject.id" and the terminal node 78 is associated with the value "Dave" of the attribute "subject.id" of the REQ2 query.

[0097] In other words, the subject Dave, who has a manager role, is not allowed to access, in the database, information relating to a person who has a different manager (Charlie in this example).

[0098] There figure 4 schematically illustrates the main functional blocks of an electronic computing device 82 adapted to implement steps of a multi-attribute query-based access control process as described.

[0099] Device 82 includes a central computing unit 84, or CPU, comprising one or more electronic processors, capable of executing computer program instructions when device 82 is powered on.

[0100] The device 82 also includes an electronic memory unit 86 adapted for storing information, in particular registers. Specifically, executable code instructions capable of implementing the access control method according to the invention are stored therein.

[0101] Device 82 includes a control interface 85 allowing parameters to be updated and commands to be received from an operator.

[0102] Optionally, the device 82 includes a screen 88 and an additional pointing device 90, such as a mouse.

[0103] The various functional blocks of device 6 described above are connected via a communication bus 92.

[0104] There figure 5 is a synoptic diagram of the main steps of an embodiment of an access control method according to the invention.

[0105] In the first step 100, a user access request is received by the user access request processing module 20.

[0106] In particular, the user access request includes attribute values ​​relating to the identification of the sender who formulates the request (the subject), the action he wants to perform on the resource, and the resource to be accessed.

[0107] Step 100 is followed by a step 102 of forming a first set of multi-attribute access query attributes from the user query attributes, enriched where appropriate with environment attributes, then a canonical form step (ordering and factoring of attribute values) of said first set of attribute values ​​allowing to obtain a second set of attribute values.

[0108] This step advantageously allows the attributes to be presented in a predetermined order and, where applicable, all values ​​associated with the same attribute to be grouped together. Indeed, the same attribute can, in some cases, take several values, such as the "subject.role" attribute in the example of the figure 3 because the same person can hold multiple roles in an organization such as a company.

[0109] Step 102, which involves constructing a multi-attribute query with a first set of attributes or a second set of attributes in canonical form, is followed by step 104, which verifies the possibility of obtaining an access authorization or denial decision based on the stored data from previous queries. Step 104 specifically implements a comparison of query attribute values ​​with attribute values ​​stored in the fast-access data cache, presented as a decision tree.

[0110] At least some of the query attribute values, from the first or second set of attributes after step 102, are compared to the stored values. This is because, as explained above, not all attribute values ​​in the query are necessarily used in the decision-making process.

[0111] For example, referring to the example of the figure 3 , if an access request with a "read_HR_profile" action is issued by a subject whose role is "Chief_HR_Officer", authorization is granted (decision tree 50) regardless of the values ​​of the other attributes of the request, for example "resource.id" and "resource.mgr".

[0112] In one embodiment, the nodes of the decision tree are traversed in ascending order of the levels of depth of the decision tree.

[0113] For each depth level, a current node with an associated current attribute is selected. If the current attribute is one of the query attributes, the query attribute value is compared to each attribute value associated with an edge connecting the current node to a child node. If the comparison is positive, this child node is selected as the new current node if it is an intermediate node. If it is a terminal node, the access decision is based on the node's value.

[0114] As soon as a terminal node containing an access or deny decision is reached, verification step 104 is completed with a positive result. If a given current attribute, corresponding to a node in the decision tree, has an attribute value in the query that differs from all attribute values ​​associated with edges in the decision graph, the decision cannot be obtained from the data stored in the cache, and the verification is completed with a negative result.

[0115] The result of the verification is tested in step 106.

[0116] If the verification is positive, step 106 is followed by step 108 of authorizing or refusing access to the applicant.

[0117] In the event of a negative check, step 106 is followed by step 110, which transmits the access request to module 15, which performs the policy evaluation. During this step 110, the access request is formatted according to an appropriate format, for example, XACML or any other language suitable for formatting multi-attribute requests.

[0118] Thus, advantageously, compatibility with a standardized format such as the OASIS XACML 3.0 standard is maintained.

[0119] The process includes a step 112 of receiving a formatted multi-attribute access request and initializing the evaluation context with the following elements: attributes from the access request (sent by module 20); attributes determined locally by module 38, such as the current date and time (date / time of receipt of the request); attributes retrieved from external sources (elements 16) such as database servers or services.

[0120] Step 112 is followed by step 114 of implementation of the evaluation of the access policy to be applied according to the context, allowing to obtain a decision of authorization or refusal of access.

[0121] A step 116, which obtains update information for the decision cache system 32, is also implemented. Alternatively, step 116 is implemented substantially in parallel with step 114. It consists of collecting information useful for updating the stored decision trees, in particular listing the attributes actually used for decision-making, as already explained above with reference to the example of the figure 3 (the "Advice" sections in the RESP1 and RESP2 responses given as examples).

[0122] In one embodiment, the update information also includes instructions for caching the authorization decision, such as a validity period (after which the decision is considered no longer valid and must be removed from the cache), also known as TTL for "time to live," for maintaining the decision associated with the request attributes. Once the TTL expires, the corresponding terminal node must be deleted along with all ancestor nodes left without descendants (recursive deletion).

[0123] The result of the decision to the access request, as well as update information, are obtained during step 118 of receiving the response to the multi-attribute access request.

[0124] When modules 15 for granting or denying access and 20 for processing user access requests are implemented by remote devices adapted to communicate via a telecommunications network, the response - including the decision to grant or deny access and update information - is transmitted from module 15 to module 20 via a chosen communication protocol.

[0125] Furthermore, step 118 is followed by step 120 of updating the decision tree corresponding to the query processed in the cache system 32.

[0126] Update 120 of a decision tree involves adding one or more intermediate nodes and a terminal node, along with edges connecting the added nodes, each with associated attribute values. Only nodes with associated attributes that appear in the list of attributes actually used in the decision are added to the stored decision tree structure, if they are not already present in the tree. The nodes are connected by edges to which the attribute values ​​of the processed access request are assigned.

[0127] The added terminal node is associated with the authorization or denial decision received in the response.

[0128] Step 120 is followed by step 108, previously described, of granting or denying access to the applicant based on the response received.

[0129] In one embodiment, steps 100 to 110 and 118, 120 are performed by a user request processing module 20, which acts as an input / output interface and grants or denies access to the request originator. Steps 112 to 114 are performed by the decision-making module 15, which is preferably centralized.

[0130] Preferably, the user request processing modules 20 are distributed, and the decision module 15 is centralized, and they are implemented respectively by different computing devices.

[0131] Alternatively, modules 15 and 20 are implemented by the same computing device.

[0132] Advantageously, the access control method according to the invention makes it possible to optimize the use of a decision cache system based on hash tables or other types of associative arrays optimized for fast access (in O(1)) to indexed values; and a fortiori the computation time, thanks to the canonical form of access queries and the storage of attribute values ​​- relevant for policy evaluation - of prior queries in the form of decision trees, and in particular to process complex queries from the fast access cache system.

Claims

1. An access control method based on multi-attribute requests, for access to a part of a computer system, the access control making it possible to authorise or deny access to a request sender as a function of attribute values contained in a request, with access control carried out by an access control system as a function of an access policy (12) comprising a previously stored set of rules, the access control system comprising a decision cache system adapted to store request attribute values in a cache and at least one calculation processor, the method comprising the following steps, implemented by a processor: - obtaining (100) a request for access to a part of the computer system, referred to as an access request being processed, comprising a plurality of attributes having request attribute values, - verifying (104) the presence in the cache, on the basis of at least one subset of said plurality of attributes of the access request being processed, having values of request attributes, of values of attributes resulting from prior requests and making it possible to obtain a decision to authorise or deny access to said part of the computer system, the verification comprising a comparison of query attribute values with attribute values stored in said decision cache system (32) in the form of a decision tree (50, 52, 54), in the event of successful verification, authorising or denying access (108) to said part of the computer system on the basis of the said decision tree (50, 52, 54), and in the event of unsuccessful verification; steps of: - transmitting (110) the access request being processed to a decision module (15) configured to perform an evaluation of the access policy (12) in the context of said request, - obtaining (118) a response comprising an access authorisation or denial decision as a function of said set of attributes having request attribute values, and comprising at least one item of information regarding the updating of the decision tree of the decision cache system (32), and - updating (120) of said decision tree as a function of said at least one update information, said updating comprising an addition of an intermediate node associated with an attribute indicated in said update information and / or an addition of an edge whose associated value is a request attribute value associated with an attribute indicated in said update information and an addition of a terminal node associated with the access authorisation or denial decision.

2. The access control method according to claim 1, in which said at least one update information item comprises at least one list of attributes, a sub-set of the attributes of the access request being processed which are actually used for the evaluation of the access policy (12) by the decision module (15).

3. The access control method according to one of claims 1 or 2, wherein each decision tree (50, 52, 54) stored in said decision cache system (32) comprises a root node (60) associated with an attribute used to authorise or deny access according to the access policy (12) previously stored, at least one terminal node (62, 70, 78) representative of an access authorisation or denial decision, and at least one edge (64, 72) linking said root node (60) to an intermediate node (66) or to a terminal node (62), said edge being associated with a value of the attribute associated with the root node (60).

4. The access control method according to claim 3, wherein at least one stored decision tree (52, 54) further comprises at least one intermediate node (66, 68) between said root node (60) and a terminal node (70, 78), the intermediate node being associated with an attribute used to authorise or deny access according to the previously stored access policy (12), the intermediate node (66, 68) having an associated depth level, the intermediate node (66, 68) being connected by a first edge (72, 74) to a parent node (60, 66), said parent node being the root node (60) or a parent intermediate node (66) of lower depth level and by a second edge (74, 76, 80) to at least one child node (68, 70, 78), said child node (68, 70, 78) being a terminal node (70, 78) or an intermediate child node (68) at a greater depth level, said first edge (72, 74) being associated with the value of the attribute associated with the parent node (60, 66), said second edge (74, 76, 80) being associated with a value of the attribute associated with said intermediate node (66, 68).

5. The access control method according to claim 4, wherein said verification comprises, in an ascending order of the depth levels of the decision tree, for each depth level: - selecting a current node with an associated current attribute, - obtaining the value or values of the corresponding attribute in the access request being processed and comparing said value with each attribute value associated with an edge linking said current node to a child node, and in the event of a positive comparison, selecting said child node as the current node, and if the current node is a terminal node, obtaining the access authorisation or denial decision associated with said terminal node.

6. The access control method according to claim 5, wherein, if, for a depth level, the attribute value of the query being processed is different from each attribute value associated with an edge linking said current node to a child node, said verification is unsuccessful.

7. The access control method according to one of claims 1 to 6, wherein the plurality of attribute values of said access request form a first set of attribute values, further comprising a step (102) of canonically formatting said first set of attribute values making it possible to obtain a second set of attribute values, and wherein the cache match verification (104) is applied to the second set of attribute values.

8. A computer program comprising software instructions which, when implemented by a computing device, implement an access control method based on multi-attribute requests, for access to a part of a computer system, according to one of claims 1 to 7.

9. An access control system based on multi-attribute requests, for access to a part of a computer system, the access control making it possible to authorise or deny access to a request sender as a function of attribute values contained in a request, the access control being carried out as a function of an access policy comprising a set of previously stored rules, the access control system comprising a decision cache system (32), adapted to store request attribute values in a cache and at least one calculation processor configured to: - obtain a request for access to a part of the computer system, referred to as an access request being processed, comprising a plurality of attributes having request attribute values, - verify the presence in the cache, on the basis of at least one subset of said plurality of attributes of the access request being processed, having values of request attributes, of values of attributes resulting from prior requests and making it possible to obtain a decision authorising or denying access to said part of the computer system, the verification comprising a comparison of values of request attributes with values of attributes stored in said decision cache system (32) in the form of a decision tree (50, 52, 54), in the event of successful verification, authorise or deny access to said part of the computer system on the basis of said decision tree (50, 52, 54), and the calculation processor is configured, in the event of unsuccessful verification, to: - transmit the access request being processed to a decision module (15) configured to perform an evaluation of the access policy (12) in the context of said request, - obtain a response comprising an access authorisation or refusal decision as a function of said set of attributes having request attribute values, and comprising at least one item of information regarding the updating of the decision tree of the decision cache system (32), and - update said decision tree as a function of said at least one item of information regarding the updating, said updating comprising an addition of an intermediate node associated with an attribute indicated in said item of information regarding the updating and / or an addition of an edge whose associated value is a request attribute value associated with an attribute indicated in said item of information regarding the updating and an addition of a terminal node associated with the access authorisation or denial decision.