Abstract: This disclosure relates generally to access request evaluation and, more particularly, to access request evaluation based on policy metrices and chaining technique. The access request evaluation is an authorization process of giving a user/an entity the ability to access a resource by evaluating policies. The existing state-of art access request evaluation techniques usually result in erroneous authorization decisions due to improper evaluation order of applicable policies, non-inclusion of indirect applicable policies. The disclosure is an access request evaluation technique based on policy metrices and chaining technique. The disclosed techniques evaluate the policies in several steps including determination a set of policy metrices, performing chaining techniques and a decision helper technique. The set of policy metrices comprises information regarding a number of rules, a number of environment attributes, a common count list, a span level and a priority level. [To be published with FIG. 2]
Description:FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See Section 10 and Rule 13)
Title of invention:
METHOD AND SYSTEM FOR ACCESS REQUEST EVALUATION BASED ON POLICY METRICES AND CHAINING TECHNIQUE
Applicant
Tata Consultancy Services Limited
A company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th floor,
Nariman point, Mumbai 400021,
Maharashtra, India
Preamble to the description:
The following specification particularly describes the invention and the manner in which it is to be performed.
TECHNICAL FIELD
The disclosure herein generally relates to access request evaluation and, more particularly, to access request evaluation based on policy metrices and chaining technique.
BACKGROUND
Access request evaluation or authorization is the process of giving a user/an entity the ability to access an entity. Access request evaluation are determined by evaluating policies, wherein the policies define a collection of requirements, that the user must satisfy to access an entity. The authorization decisions can be based on several factors such as allowable policies, deniable policies, indirect policies, priority of the policy and policy conflicts.
The traditional policy-based access control methods usually arrive at authorization decisions without a detailed analysis/evaluation of the policies. Further existing state-of art access request evaluation techniques usually result in erroneous authorization decisions due to improper evaluation order of applicable policies, non-inclusion of indirect applicable policies and hence could resulting in permit instead of denying. In an example scenario is a first policy requires an employee working from office to be complaint to certain rules to access an entity, however the same employee is allowed to access the entity without the need to be compliant to rules due to a second policy, wherein the second policy may not be directly associated with the entity. In the example scenarios it is necessary to consider the order of the policy evaluation and the decision techniques that govern the decision for the access request. Hence due to non-consideration of applicable policies, indirect policies, priority of policies, extent of the influence of policies on access decision and common processing system for offline and online authorization decisions, there is a requirement for a technique involving evaluation of contextual features of policy and message-based decision wavering for addressing conflicting policies.
SUMMARY
Embodiments of the present disclosure present technological improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems. For example, in one embodiment, a method to access request evaluation based on policy metrices and chaining technique is provided.
The system includes a memory storing instructions, one or more communication interfaces, and one or more hardware processors coupled to the memory via the one or more communication interfaces, wherein the one or more hardware processors are configured by the instructions to receive a plurality of inputs, via one or more hardware processors, receiving a plurality of inputs from a plurality of sources, via one or more hardware processors, wherein the plurality of inputs is associated with information regarding a plurality of policies, a knowledge graph and an access request, wherein the access request comprises a subject, an object and an action and the knowledge graph comprises a plurality of entities. The system is further configured for identifying a set of first policies from the plurality of policies based on the subject and the object of the access request using the knowledge graph. The system is further configured for determining a set of policy metrices for each of the policies from the set of first policies, wherein the set of policy metrices comprises information regarding a number of rules, a number of environment attributes, a common count list, a span level and a priority level. The system is further configured for re-ordering the first set of policies based on a pre-determined order to obtain a second set of policies. The system is further configured for evaluating each policy from the second set of policies to obtain a chain of blocks for each policy in the second set of policies based on a chaining technique, wherein the chaining technique comprises: generating a block of each policy from the second set of policies, wherein the block comprises of the policy and the access request, analyzing the block by evaluating the access request and the policy of each block based on the knowledge graph and the plurality policies to obtain the decision, a list of resultant entities and the message, identifying the list of resultant entity policies for the block using the knowledge graph, wherein the list of resultant entity policies comprises of a list of policies associated with the list of resultant entities from the plurality of policies and mapping the block to the decision, the message and the list of resultant entity policies to form the chain of blocks for each of the policy from the second set of policies. The system is further configured for determining an evaluation decision for the access request using the chain of blocks of the second set of policies based on a set of pre-defined rules and a decision helper technique, wherein the evaluation decision for the access request comprises one of an allow access and a deny access.
In another aspect, a method to access request evaluation based on policy metrices and chaining technique is provided. The method includes receiving a plurality of inputs from a plurality of sources, wherein the plurality of inputs is associated with information regarding a plurality of policies, a knowledge graph and an access request, wherein the access request comprises a subject, an object and an action and the knowledge graph comprises a plurality of entities. The method further includes identifying a set of first policies from the plurality of policies based on the subject and the object of the access request using the knowledge graph. The method further includes determining a set of policy metrices for each of the policies from the set of first policies, wherein the set of policy metrices comprises information regarding a number of rules, a number of environment attributes, a common count list, a span level and a priority level. The method further includes re-ordering the first set of policies based on a pre-determined order to obtain a second set of policies. The method further includes evaluating each policy from the second set of policies to obtain a chain of blocks for each policy in the second set of policies based on a chaining technique, wherein the chaining technique comprises: generating a block of each policy from the second set of policies, wherein the block comprises of the policy and the access request, analyzing the block by evaluating the access request and the policy of each block based on the knowledge graph and the plurality policies to obtain the decision, a list of resultant entities and the message, identifying the list of resultant entity policies for the block using the knowledge graph, wherein the list of resultant entity policies comprises of a list of policies associated with the list of resultant entities from the plurality of policies and mapping the block to the decision, the message and the list of resultant entity policies to form the chain of blocks for each of the policy from the second set of policies. The method further includes determining an evaluation decision for the access request using the chain of blocks of the second set of policies based on a set of pre-defined rules and a decision helper technique, wherein the evaluation decision for the access request comprises one of an allow access and a deny access.
In yet another aspect, a non-transitory computer readable medium for access request evaluation based on policy metrices and chaining technique is provided. The method includes receiving a plurality of inputs from a plurality of sources, wherein the plurality of inputs is associated with information regarding a plurality of policies, a knowledge graph and an access request, wherein the access request comprises a subject, an object and an action and the knowledge graph comprises a plurality of entities. The method further includes identifying a set of first policies from the plurality of policies based on the subject and the object of the access request using the knowledge graph. The method further includes determining a set of policy metrices for each of the policies from the set of first policies, wherein the set of policy metrices comprises information regarding a number of rules, a number of environment attributes, a common count list, a span level and a priority level. The method further includes re-ordering the first set of policies based on a pre-determined order to obtain a second set of policies. The method further includes evaluating each policy from the second set of policies to obtain a chain of blocks for each policy in the second set of policies based on a chaining technique, wherein the chaining technique comprises: generating a block of each policy from the second set of policies, wherein the block comprises of the policy and the access request, analyzing the block by evaluating the access request and the policy of each block based on the knowledge graph and the plurality policies to obtain the decision, a list of resultant entities and the message, identifying the list of resultant entity policies for the block using the knowledge graph, wherein the list of resultant entity policies comprises of a list of policies associated with the list of resultant entities from the plurality of policies and mapping the block to the decision, the message and the list of resultant entity policies to form the chain of blocks for each of the policy from the second set of policies. The method further includes determining an evaluation decision for the access request using the chain of blocks of the second set of policies based on a set of pre-defined rules and a decision helper technique, wherein the evaluation decision for the access request comprises one of an allow access and a deny access.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles:
FIG. 1 illustrates an exemplary system for access request evaluation based on policy metrices and chaining technique according to some embodiments of the present disclosure.
FIG. 2 is a functional block diagram for access request evaluation based on policy metrices and chaining technique according to some embodiments of the present disclosure.
FIGS. 3A to FIG.3B is a flow diagram illustrating a method (300) for access request evaluation based on policy metrices and chaining technique in accordance with some embodiments of the present disclosure.
FIGS. 4 is a flow diagram illustrating a method (400) for decision helper technique during access request evaluation based on policy metrices and chaining technique in accordance with some embodiments of the present disclosure.
DETAILED DESCRIPTION OF EMBODIMENTS
Exemplary embodiments are described with reference to the accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the scope of the disclosed embodiments.
The traditional policy-based access control methods usually arrive at authorization decisions without a detailed analysis/evaluation of the policies. Further existing state-of art access request evaluation techniques usually result in erroneous authorization decisions due to improper evaluation order of applicable policies, non-inclusion of indirect applicable policies and hence could resulting in permit instead of denying. In an example scenario is a policy requires an employee working from office to be complaint to certain rules to access an entity, however the same employee is allowed to access the entity without the need to be compliant to rules due to another policy. These policies may not be directly applied to same entity. Due to the policy processing and the decision techniques, all the applicable policies, direct and indirect, may not be selected and processed based on their influence on access decision resulting in incorrect decision for access request. In another example scenario: one policy allows user to access an entity if user's role matches with entity's role. However, there can be another policy that says user is not allowed to access a same entity that is associated to user's role. If allow policy is executed first and deny policy is not executed, then the access will be allowed. In these scenarios the order of the policy evaluation and the decision techniques govern the decision for the access request. Hence due to non-consideration of applicable policies, indirect policies, priority of policies, extent of the influence of policies on access decision and common processing system for offline and online authorization decisions, there is a requirement for a technique involving evaluation of contextual features of policy and message-based decision wavering for addressing conflicting policies.
Referring now to the drawings, and more particularly to FIG.1 through FIG.4, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments and these embodiments are described in the context of the following exemplary system and/or method.
FIG.1 is an exemplary block diagram of a system 100 for access request evaluation based on policy metrices and chaining technique in accordance with some embodiments of the present disclosure.
In an embodiment, the system 100 includes a processor(s) 104, communication interface device(s), alternatively referred as input/output (I/O) interface(s) 106, and one or more data storage devices or a memory 102 operatively coupled to the processor(s) 104. The system 100 with one or more hardware processors is configured to execute functions of one or more functional blocks of the system 100.
Referring to the components of the system 100, in an embodiment, the processor(s) 104, can be one or more hardware processors 104. In an embodiment, the one or more hardware processors 104 can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the one or more hardware processors 104 is configured to fetch and execute computer-readable instructions stored in the memory 102. In an embodiment, the system 100 can be implemented in a variety of computing systems including laptop computers, notebooks, hand-held devices such as mobile phones, workstations, mainframe computers, servers, a network cloud and the like.
The I/O interface(s) 106 can include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, a touch user interface (TUI) and the like and can facilitate multiple communications within a wide variety of networks N/W and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. In an embodiment, the I/O interface (s) 106 can include one or more ports for connecting a number of devices (nodes) of the system 100 to one another or to another server.
The memory 102 may include any computer-readable medium known in the art including, for example, volatile memory, such as static random-access memory (SRAM) and dynamic random-access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.
Further, the memory 102 may include a database 108 configured to include information regarding access request evaluation. The memory 102 may comprise information pertaining to input(s)/output(s) of each step performed by the processor(s) 104 of the system 100 and methods of the present disclosure. In an embodiment, the database 108 may be external (not shown) to the system 100 and coupled to the system via the I/O interface 106.
Functions of the components of system 100 are explained in conjunction with functional overview of the system 100 in FIG.2 and flow diagram of FIGS.3A and FIG.3B for access request evaluation based on policy metrices and chaining technique.
The system 100 supports various connectivity options such as BLUETOOTH®, USB, ZigBee and other cellular services. The network environment enables connection of various components of the system 100 using any communication link including Internet, WAN, MAN, and so on. In an exemplary embodiment, the system 100 is implemented to operate as a stand-alone device. In another embodiment, the system 100 may be implemented to work as a loosely coupled device to a smart computing environment. The components and functionalities of the system 100 are described further in detail.
FIG.2 is an example functional block diagram of the various modules of the system of FIG.1, in accordance with some embodiments of the present disclosure. As depicted in the architecture, the FIG.2 illustrates the functions of the modules of the system 100 that includes for access request evaluation based on policy metrices and chaining technique.
As depicted in FIG.2, the functional system 200 of system 100 system 200 is configured for access request evaluation based on policy metrices and chaining technique.
The system 200 comprises an input module 202 configured for receiving a plurality of inputs from a plurality of sources, wherein the plurality of inputs is associated with information regarding a plurality of policies, a knowledge graph and an access request, wherein the access request comprises a subject, an object and an action and the knowledge graph comprises a plurality of entities. The system 200 further comprises a first policies module 204 configured identifying a set of first policies from the plurality of policies based on the subject and the object of the access request using the knowledge graph. The system 200 further comprises a policy metrices module 206 configured for determining a set of policy metrices for each of the policies from the set of first policies. The system 200 further comprises a re-ordering module 208 configured for re-ordering the first set of policies based on a pre-determined order to obtain a second set of policies. The system 200 further comprises a chaining module 210 configured for evaluating each policy from the second set of policies to obtain a chain of blocks for each policy in the second set of policies based on a chaining technique. The system 200 further comprises an evaluation decision module 212 configured for determining an evaluation decision for the access request using the chain of blocks of the second set of policies based on a set of pre-defined rules and a decision helper technique, wherein the evaluation decision for the access request comprises one of an allow access and a deny access.
The various modules of the system 100 and the functional blocks in FIG.2 are configured for access request evaluation based on policy metrices and chaining technique are implemented as at least one of a logically self-contained part of a software program, a self-contained hardware component, and/or, a self-contained hardware component with a logically self-contained part of a software program embedded into each of the hardware component that when executed perform the above method described herein.
Functions of the components of the system 200 are explained in conjunction with functional modules of the system 100 stored in the memory 102 and further explained in conjunction with flow diagram of FIGS.3A-3B. The FIGS.3A-3B with reference to FIG.1, is an exemplary flow diagram illustrating a method 300 for access request evaluation based on policy metrices and chaining technique using the system 100 of FIG.1 according to an embodiment of the present disclosure.
The steps of the method of the present disclosure will now be explained with reference to the components of the system 100 of FIG.1 for access request evaluation based on policy metrices and chaining technique and the modules 202-212 as depicted in FIG.2 and the flow diagrams as depicted in FIGS.3A-3B. Although process steps, method steps, techniques or the like may be described in a sequential order, such processes, methods and techniques may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described does not necessarily indicate a requirement that the steps to be performed in that order. The steps of processes described herein may be performed in any order practical. Further, some steps may be performed simultaneously.
At step 302 of the method 300, a plurality of inputs is received from a plurality of sources at the input module 202. The plurality of inputs is associated with information regarding a plurality of policies, a knowledge graph and an access request, wherein the access request comprises a subject, an object and an action and the knowledge graph comprises a plurality of entities
In an embodiment, access request is received from a plurality of sources including a user, an entity, a system generating requests for local evaluation and storing the results for further use. The subject in the access request is an accessor id of the user who is requesting access. The object is an entity id, wherein the entity could be a resource, location, project, unit, or batch jobs written as policies (policies with target names as batch job names – for example, allocation batch job, identify privileges batch job). The action is a privilege /access permission requested by the user over object. The action could be null when object id is batch jobs.
The plurality of policies is a collection of policies on entities and users. Each policy is a collection of rules, wherein each rule is made of conditions and attributes. Each of the rule, condition and attribute can be defined as a component of policy. The policy is associated with a target, that can be an entity. Further each policy is assigned a priority value.
The knowledge graph contains all the information regarding an institution or an enterprise. The nodes of the knowledge graph are made of entities like users, employees, resources, organizations, projects and all such details and the relationships among these entities (considered as edges). The nodes and edges can further contain various attributes providing additional information about the entities and relationships. Additional attributes may include but not limited to entity security level, user clearance level, entity valid up to date, entity preconditions, entity owner, entity hierarchy, entity groupings.
At step 304 of the method 300, a set of first policies is identified from the plurality of policies at the first policy metrices module 204. The set of first policies is identified based on the subject and the object of the access request using the knowledge graph.
In an embodiment, wherein the identification of the set of first policies comprises several steps including:
identifying a list of applicable entities in a hierarchy of the object and the subject,
identifying a first list of policies from the plurality of policies and
identifying the set of first policies associated with the list of entities and the first list of policies.
In an example scenario - considering an "enterprise" is made of employees and resources along with other entities like project, account and unit in that order. Each entity may host or contain other entities, for an example - an access request (UserA, Unit1.Printer1, read) is made, wherein UserA is requesting print access over Printer1 which is present under Unit1 entity. Now, to determine applicable policies, a first list of applicable entities is identified from the hierarchy of object and subject of access request, wherein “UserA, GroupA” are the entities found from the hierarchy of subject and similarly, “Printer1, Unit1, Organization” are the entities from the hierarchy of subject. So, now, the list of applicable policies will be the policies with policy target as one of the entities from the list of applicable entities.
At step 306 of the method 300, a set of policy metrices is determined for each of the policies from the set of first policies in the policy metrices module 206. The set of policy metrices comprises information regarding a number of rules, a number of environment attributes, a common count list, a span level and a priority level. The set of policy metrices are computed using one of a pattern matching technique, the knowledge graph, a search string technique and a count function-based technique.
In an embodiment, the number of rules is the count of the components in policy matching the pattern of a rule pre-determined, wherein a pattern matching technique like regular expressions, the metric “number of rules” are utilized, which can be expressed using the formula shown below:
Rules_Count=COUNT (? MATCH(Pattern_Rule) in Policy) (1)
where,
Policy ? set of first policies,
Pattern_Rule is a pattern for rule as found in a policy,
Rules_Count=count of rules in Policy.
The number of environment attributes is the count of the components present in the policy found by matching the pre-determined string pattern of an environment attribute in the policy or by searching strings equal to the pre-determined list of strings of environment attributes using a string search technique like regular expressions, fuzzy matching, the metric “number of environment attributes”, which can be expressed using the formula shown below:
EnvAtt?rs?_Count=COUNT ( ?(Attr ? AttrSet)?MATCH(Pattern_Attr ))
in Policy (2)
where,
Policy?set of first policies,
Pattern_Attr is a pattern for environment attributes as found in a policy,
AttrSet=predetermined list of environment attributes,
EnvAttr_Count=count of environment attributes in Policy.
The common count list for each policy is determined as the count of entries having the policy name in the list of policies column of the final tabular list. The final tabular list is created from the summarization of all the rules and conditions present in one or more of the second set of policies, wherein the table has headers of Attribute or Condition Name, Number of policies with these components and the list of policies. Then, entries with value less than one in column ‘number of policies with attribute or condition components’ generating the final tabular list is removed. A “Condition” is a subcomponent of a rule in a policy that is not an attribute.
The span level is the maximum of the intermediate entity (or node) counts of all the paths among the subject entity, object entity and policy target entity. The paths are identified among these entities using the knowledge graph.
SpanLevel=?max ??(¦(PathLength_(Subject-Object),@ PathLength_(Subject-PolicyTarget),@PathLength_(Object-PolictTarget) )) (3)
where,PathLength_iToj=max?(length of all paths between i and j)
The priority level is the value assigned to a priority attribute of a policy, which is identified using string search for a priority level attribute using a predetermined identifier. The priority level is determined based on the search string technique.
Priority_Level={¦(NA,& Pattern_Priority not found in Policy@Value(Pattern_Priority,Pattern_Priority found in Policy)¦ (4)
where,Pattern_Priority=pattern for priority attribute as found in Policy,
Policy ? set of first policies
At step 308 of the method 300, the first set of policies is re-ordered in the re-ordering module 208.The first set of policies is re-ordered based on a pre-determined order to obtain a second set of policies.
The pre-determined order is determined based on the priority level, the span level, the number of environment attributes, the number of rules and the common count list.
In an embodiment, the pre-determined order is decided based on extent of the metrices’ influence on any access request. In an example scenario – the pre-determined order is set in the order of the priority level, the common count list, the number of environment attributes, the number of rules, the span level.
At step 310 of the method 300, each policy from the second set of policies is evaluated in the chaining module 210. The second set of policies is evaluated to obtain a chain of blocks for each policy in the second set of policies based on a chaining technique. The chaining technique comprises several steps which is explained in the section below using steps 310A to 310D.
At step 310A of the method 300, a block of each policy is generated from the second set of policies. The block comprises of the policy and the access request.
In an embodiment, a block can be treated as an object from an object-oriented programming or as a set of key-value pairs. So, for each policy from second set of policies a block is created with the initial key-value pairs as “policy:, access_request: <(subject, policy target entity, action)>. Policy key has value as policy-id or any suitable policy identifying value so that wherever policy is to be loaded for processing, this id will be used to identify the policy from second set of policies.
Considering an example scenario - if the second set of policies contain a policy_unit1, a policy_organization1 and a policy_printer1. Then, for each of the policies a block is created as an object based on object-oriented programming, a structure from structured programming language, or a key-value pairs as in dictionary model. For example, a block be visualized as shown below:
{ Policy_id: Policy_Organization1,Access Request: (user1,Organization1,print}.
At step 310B of the method 300, the block is analyzed by evaluating the access request and the policy of each block based on the knowledge graph and the plurality policies to obtain the decision, a list of resultant entities and the message.
In an embodiment, a policy in each block is evaluated over the access request in the block. Result could be one or more of the following new key-value pairs in the block: decision, message, list of resultant entries.
In an example scenario, a policy_printer1 is evaluated over access request (User1, Printer1, print) and a decision is obtained from the policy, a set of messages after evaluating the policy and since, for example, Printer1 is also dependent on the decision from other entities, (in an example: LocationA, DeliveryCenterA) then the policy may also list {LocationA, DeliverCenterA} for the list of resultant entities key.
At step 310C of the method 300, identifying the list of resultant entity policies for the block using the knowledge graph, wherein the list of resultant entity policies comprises of a list of policies associated with the list of resultant entities from the plurality of policies.
In an embodiment, applicable policies are determined for each of the entities from the list of resultant entities using the decision, a list of resultant entities and the message.
At step 310D of the method 300, mapping the block to the decision, the message and the list of resultant entity policies to form the chain of blocks for each of the policy from the second set of policies.
In an embodiment, considering an example scenario, an organization policy may require decision from another organization policy, a printer policy may require decision from a location policy which may require decision from a delivery center policy. Hence these inter-dependent policies forms a chain of blocks for each of the policies from the second set of policies.
The steps 310A, 310B, 310C, 310D are iteratively repeated until there is no list of resultant entities from any block.
At step 312 of the method 300, an evaluation decision is determined for the access request using the chain of blocks of the second set of policies. The evaluation decision for the access request comprises one of an allow access and a deny access.
The evaluation decision is determined for the access request based on a set of pre-defined rules and a decision helper technique.
In an embodiment, the set of pre-defined rules is comprises:
(a) “Deny” overrides any other “Allow” if the deny is from policies with higher rank or priority.
(b) “Deny” overrides any other “Allow” if the entity is of high security level.
(c) If the “Deny” is from a rule of lower security level and common in nature, allow or deny in this case can be decided using the decision helper technique based on subscription to it by a resource. For example, CEO of an enterprise is requesting access to a project level document “DocumentP” with security level “low”. There may exist some enterprise level policies may allow access to any document of the enterprise. There may also exist some project level policy denying access to the project documents to employees outside the project. Arriving at decision for such access request does not depend entirely on appearance of “Allow” and “Deny” decisions from individual policies but also depends on the extent of the policies’ influence on the decision. Decision helper technique considers various metrices on the policies to rank the policies and uses these ranks along with the messages given by the policies when evaluated on access request to arrive at a contextually aware access decision for the given access request.
(d) If the gap between the clearance level of user and security level of entity is high and the positivity and negativity polarity values are of close range in the decision helper, then an allow decision can be given.
(e) “Deny” overrides in any other case.
In this embodiment Decision helper technique is used only in rule (d) and rule (e) but, it is to be noted that these rules are just for example and the decision helper technique can be used in conjunction with any rule defined in the system.
The decision helper technique comprises several steps which is explained in the flowchart 400 using FIG.4.
At step 402 of the method 400, a plurality of words is grouped from the message of the chain of blocks using a similarity model.
In an embodiment, the messages from all the blocks are consolidated into a list. Then, using a similarity model trained on entity labels from the knowledge graph and other synonym dataset such as Word2Vec, Glove, words from messages are grouped based on the trained similarity model, repetition of the words, contextual meaning of the words in the messages.
In an example scenario - For example, {[PolicyB – Decision: Allow, Messages: {Condition2: Compliance ending soon}],[PolicyG – Decision: Deny, Messages: {Condition13: Under revocation, Condition18: Compliance unsupported}], [PolicyF – Decision: Deny, Messages: {Condition10: Compliance expired}]}. These are the obtained messages. Grouping of words will create the following groups {Compliance, ending, revocation, unsupported, expired}.
At step 404 of the method 400, a context polarity value is assigned for the plurality of words based on a contextual negativity/a contextual positivity of the word.
In an embodiment, based on the positivity/ a contextual negativity of the word as per the context in the message, a context polarity value is assigned, wherein context polarity value is given on a scale from 0 to 1 in one embodiment or from -1 to 1 in another embodiment. The value 0 or -1 is being assigned for completely negative context and 1 for completely positive context respectively. To identify the context polarity of a word, Bag of words, (text mining) SentiWordNet, sentiment Analysis algorithms are utilized.
Based on the similarity model, repetition of words and contextual meaning of these words in the messages, in an example scenario: the words are assigned context polarity value as shown here - {compliance: -1, revocation: -0.8, ending: -0.5.
At step 406 of the method 400, the plurality of words is ordered based on the context polarity value.
In an embodiment, the words are sorted based on context polarity value of the words. The sorting is performed based on techniques including a bubble sort, a selection sort, an insertion sort and a merge sort.
At step 408 of the method 400, an evaluation decision is determined based on a pre-defined decision threshold using the context polarity value.
In an embodiment, a total positive context polarity and a negative context polarity is computed using a pre-determined threshold for the context polarity. The decision can be an allow or deny based on the maximum of decisions given by the policies whose messages contain words greater than the selected threshold context polarity value.
In an example scenario - if a threshold is -0.4 and if the negative polarity value is less than -0.4 as seen in this example where the combined average polarity value is less than -0.4, the decision will be from the policies with the messages containing words compliance, revocation, ending which is deny as it appeared in decisions (Allow, Deny, Deny) for more number of times in the selected policies.
In an example scenario: In a health care institution, wherein a patient is requesting access to their documents, but, due to the continuous creation and inflow of patient documents creation of access policies for individual documents is not feasible. In this situation, policies from the departments creating or handling these documents can be used to process access requests. Due to this, many policies, direct and indirect, are to be involved and their decisions may sometime be contradictory. Decision combining techniques focusing solely on the appearance of Allow and Deny decisions from policies cannot always result in correct decision for the access request.
For example, a department has policy denying access to documents to any user outside the department. At the same time, another institution level policy states that patients can view their documents. In such scenarios, a decision combing technique like “Deny Overrides” may result in ‘Deny” decision for the access request. Thus, it is necessary to consider the contextual and influencing metrices of the policies to rank the decisions from the policies so that higher ranked policy decisions are considered than lower ranked policies. In another scenario: an employee access is just renewed by a policy and is in processing to reflect the same in other databases. A normal processing of access request based on just policies may not understand that the access is renewed until the rules are updated. Thus, it is necessary to consider the contextual information present in the messages given by the policies. Using decision helper technique in this scenario can provide accurate decision for the access request as it can understand that access renewal has been performed giving more importance to the decision given by that policy in arriving at a decision for the access request.
The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments. The scope of the subject matter embodiments is defined by the claims and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the claims if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language of the claims.
This disclosure relates generally to access request evaluation and, more particularly, to access request evaluation based on policy metrices and chaining technique. The access request evaluation is an authorization process of giving a user/an entity the ability to access a resource by evaluating policies. The existing state-of art access request evaluation techniques usually result in erroneous authorization decisions due to improper evaluation order of applicable policies, non-inclusion of indirect applicable policies. The disclosure is an access request evaluation technique based on policy metrices and chaining technique. The disclosed techniques evaluate the policies in several steps including determination a set of policy metrices, performing chaining techniques and a decision helper technique. The set of policy metrices comprises information regarding a number of rules, a number of environment attributes, a common count list, a span level and a priority level.
It is to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g., any kind of computer like a server or a personal computer, or the like, or any combination thereof. The device may also include means which could be e.g., hardware means like e.g., an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g., an ASIC and an FPGA, or at least one microprocessor and at least one memory with software processing components located therein. Thus, the means can include both hardware means and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software means. Alternatively, the embodiments may be implemented on different hardware devices, e.g., using a plurality of CPUs.
The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various components described herein may be implemented in other components or combinations of other components. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope of the disclosed embodiments. Also, the words “comprising,” “having,” “containing,” and “including,” and other similar forms are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.
Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
It is intended that the disclosure and examples be considered as exemplary only, with a true scope of disclosed embodiments being indicated by the following claims.
, Claims:We Claim:
1. A processor implemented method, comprising:
receiving a plurality of inputs from a plurality of sources, via one or more hardware processors, wherein the plurality of inputs is associated with information regarding a plurality of policies, a knowledge graph and an access request, wherein the access request comprises a subject, an object and an action and the knowledge graph comprises a plurality of entities (302);
identifying a set of first policies from the plurality of policies, via one or more hardware processors, based on the subject and the object of the access request using the knowledge graph (304);
determining a set of policy metrices for each of the policies from the set of first policies, via one or more hardware processors, wherein the set of policy metrices comprises information regarding a number of rules, a number of environment attributes, a common count list, a span level and a priority level (306);
re-ordering the first set of policies, via one or more hardware processors, based on a pre-determined order to obtain a second set of policies (308);
evaluating each policy from the second set of policies to obtain a chain of blocks for each policy in the second set of policies, via one or more hardware processors, based on a chaining technique (310), wherein the chaining technique comprises:
generating a block of each policy from the second set of policies, wherein the block comprises of the policy and the access request (310A);
analyzing the block by evaluating the access request and the policy of each block based on the knowledge graph and the plurality policies to obtain the decision, a list of resultant entities and the message (310B);
identifying a list of resultant entity policies for the block using the knowledge graph, wherein the list of resultant entity policies comprises of a list of policies associated with the list of resultant entities from the plurality of policies (310C); and
mapping the block to the decision, the message and the list of resultant entity policies to obtain the chain of blocks for each of the policy from the second set of policies (310D); and
determining an evaluation decision for the access request using the chain of blocks of the second set of policies, via one or more hardware processors, based on a set of pre-defined rules and a decision helper technique, wherein the evaluation decision for the access request comprises one of an allow access and a deny access (312).
2. The processor implemented method of claim 1, wherein the identification of the set of first policies comprises: identifying a list of entities in a hierarchy of the object and the subject, identifying a first list of policies from the plurality of policies and identifying the set of first policies associated with the list of entities and the first list of policies.
3. The processor implemented method of claim 1, wherein the set of policy metrices are computed using one of a pattern matching technique, the knowledge graph, a search string technique and a count function-based technique.
4. The processor implemented method of claim 1, wherein the pre-determined order is determined based on the priority level, the span level, the number of environment attributes, the number of rules and the common count list.
5. The processor implemented method of claim 1, wherein the decision helper technique (400) comprises:
grouping a plurality of words from the message of the chain of blocks using a similarity model (402);
assigning a context polarity value for the plurality of words based on a contextual negativity/a contextual positivity of the word (404);
ordering the plurality of words based on the context polarity value (406); and
determining an evaluation decision based on a pre-defined decision threshold using the context polarity value (408).
6. A system (100), comprising:
a memory (102) storing instructions;
one or more communication interfaces (106); and
one or more hardware processors (104) coupled to the memory (102) via the one or more communication interfaces (106), wherein the one or more hardware processors (104) are configured by the instructions to:
receive a plurality of inputs from a plurality of sources, via one or more hardware processors, wherein the plurality of inputs is associated with information regarding a plurality of policies, a knowledge graph and an access request, wherein the access request comprises a subject, an object and a action and the knowledge graph comprises a plurality of entities;
identify a set of first policies from the plurality of policies, via one or more hardware processors, based on the subject and the object of the access request using the knowledge graph;
determine a set of policy metrices for each of the policies from the set of first policies, via one or more hardware processors, wherein the set of policy metrices comprises information regarding a number of rules, a number of environment attributes, a common count list, a span level and a priority level;
re-order the first set of policies, via one or more hardware processors, based on a pre-determined order to obtain a second set of policies;
evaluate each policy from the second set of policies to obtain a chain of blocks for each policy in the second set of policies, via one or more hardware processors, based on a chaining technique, wherein the chaining technique comprises:
generating a block of each policy from the second set of policies, wherein the block comprises of the policy and the access request;
analyzing the block by evaluating the access request and the policy of each block based on the knowledge graph and the plurality policies to obtain the decision, a list of resultant entities and the message;
identifying a list of resultant entity policies for the block using the knowledge graph, wherein the list of resultant entity policies comprises of a list of policies associated with the list of resultant entities from the plurality of policies; and
mapping the block to the decision, the message and the list of resultant entity policies to obtain the chain of blocks for each of the policy from the second set of policies; and
determine a evaluation decision for the access request using the chain of blocks of the second set of policies, via one or more hardware processors, based on a set of pre-defined rules and a decision helper technique, wherein the evaluation decision for the access request comprises one of an allow access and a deny access.
7. The system of claim 6, wherein the identification of the set of first policies comprises: identifying a list of entities in a hierarchy of the object and the subject, identifying a first list of policies from the plurality of policies and identifying the set of first policies associated with the list of entities and the first list of policies.
8. The system of claim 6, wherein the set of policy metrices are computed using one of a pattern matching technique, the knowledge graph, a search string technique and a count function-based technique.
9. The system of claim 6, wherein the pre-determined order is determined based on the priority level, the span level, the number of environment attributes, the number of rules and the common count list
10. The system of claim 6, wherein the decision helper technique comprises:
grouping a plurality of words from the message of the chain of blocks using a similarity model;
assigning a context polarity value for the plurality of words based on a contextual negativity/a contextual positivity of the word;
ordering the plurality of words based on the context polarity value; and
determining an evaluation decision based on a pre-defined decision threshold using the context polarity value.
Dated this 8th Day of November 2022
Tata Consultancy Services Limited
By their Agent & Attorney
(Adheesh Nargolkar)
of Khaitan & Co
Reg No IN-PA-1086
| # | Name | Date |
|---|---|---|
| 1 | 202221063670-STATEMENT OF UNDERTAKING (FORM 3) [08-11-2022(online)].pdf | 2022-11-08 |
| 2 | 202221063670-REQUEST FOR EXAMINATION (FORM-18) [08-11-2022(online)].pdf | 2022-11-08 |
| 3 | 202221063670-FORM 18 [08-11-2022(online)].pdf | 2022-11-08 |
| 4 | 202221063670-FORM 1 [08-11-2022(online)].pdf | 2022-11-08 |
| 5 | 202221063670-FIGURE OF ABSTRACT [08-11-2022(online)].pdf | 2022-11-08 |
| 6 | 202221063670-DECLARATION OF INVENTORSHIP (FORM 5) [08-11-2022(online)].pdf | 2022-11-08 |
| 7 | 202221063670-COMPLETE SPECIFICATION [08-11-2022(online)].pdf | 2022-11-08 |
| 8 | Abstract1.jpg | 2023-01-09 |
| 9 | 202221063670-FORM-26 [15-02-2023(online)].pdf | 2023-02-15 |