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:
METHODS AND SYSTEMS FOR VALIDATING INCONSISTENT AND CONFLICTING ACCESS POLICIES

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
[001] The disclosure herein generally relates to the field of access control and management, and more specifically to methods and systems for validating inconsistent and conflicting access policies created for resources.

BACKGROUND
[002] Many organizations handle multiple projects and applications, and each application maintains multiple resources and users. Hence, access control and management of resources to users is a key aspect for information security and forms an integral part of the organization. The users are provided with the access to the resources by creating access policies. An administrator creates multiple access policies for each of the resources, and that may result in conflicting and inconsistent access policies. In some cases, multiple policies may be applicable to a single user due to some context or some other reason.
[003] The resources are associated with compliance rules, and for those resources, when users access the resources, the system checks the user's compliance status in an inefficient way. First, it searches for the applicable policies, identifies the applicable compliance rules, and then checks user compliance status by calling an associated application programming interface (API). Hence, the conventional techniques for validating the access policies not efficient and as a result the user access is affected, and performance of the application is degraded.

SUMMARY
[004] 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.
[005] In an aspect, a processor-implemented method for validating inconsistent and conflicting access policies is provided. The method including the steps of: receiving for each resource, (i) a plurality of users, (ii) one or more user roles associated with each user of the plurality of users, (iii) one or more compliance rules for each user role of the one or more user roles associated with each user, (iv) one or more user context types for each user role of the one or more user roles associated with each user, and (v) one or more access policies developed for each user role of the one or more user roles associated with each user of the plurality of users, from a policy repository, wherein the one or more user context types are: (i) a time slot context, (ii) a location context, (iii) a device context, and (iv) a network context; identifying, one or more users out of the plurality of users, having more than one user roles that resulted in development of more than one access policies, from the one or more user roles associated with each user of the plurality of users to form a first set of users; identifying, the one or more users out of the plurality of users, having a single user role but having more than one user context types, that resulted in development of more than one access policies, to form a second set of users; determining, (i) one or more conflicting access policies and (ii) one or more inconsistent access policies, for each user having more than one access policies, from the first set of users and the second set of users, based on the user context details of the associated user; validating and removing, (i) the one or more conflicting access policies and (ii) the one or more inconsistent access policies, for each user having more than one access policies, based on a validation criterion, to obtain one or more validated access policies associated with each user role of the one or more user roles associated with each user; generating, an access policy graph for each resource, using the one or more validated access policies associated with each user role of the one or more user roles associated with each user; receiving, an access request for the resource, from a user; retrieving, user details of the user from a user repository, wherein the user details comprise a user identity, a current user role and a current user context type; validating, the access request for the resource to the user, based on the current user role and the current user context type, using the access policy graph associated to the resource; and granting, a permission to the access request for the resource to the user, based on the validation.
[006] In another aspect, a system for validating inconsistent and conflicting access policies is provided. The system includes: a memory storing instructions; one or more Input/Output (I/O) interfaces; and one or more hardware processors coupled to the memory via the one or more I/O interfaces, wherein the one or more hardware processors are configured by the instructions to: receive for each resource, (i) a plurality of users, (ii) one or more user roles associated with each user of the plurality of users, (iii) one or more compliance rules for each user role of the one or more user roles associated with each user, (iv) one or more user context types for each user role of the one or more user roles associated with each user, and (v) one or more access policies developed for each user role of the one or more user roles associated with each user of the plurality of users, from a policy repository, wherein the one or more user context types are: (i) a time slot context, (ii) a location context, (iii) a device context, and (iv) a network context; identify, one or more users out of the plurality of users, having more than one user roles that resulted in development of more than one access policies, from the one or more user roles associated with each user of the plurality of users to form a first set of users; identify, the one or more users out of the plurality of users, having a single user role but having more than one user context types, that resulted in development of more than one access policies, to form a second set of users; determine, (i) one or more conflicting access policies and (ii) one or more inconsistent access policies, for each user having more than one access policies, from the first set of users and the second set of users, based on the user context details of the associated user; validate and remove, (i) the one or more conflicting access policies and (ii) the one or more inconsistent access policies, for each user having more than one access policies, based on a validation criterion, to obtain one or more validated access policies associated with each user role of the one or more user roles associated with each user; generate an access policy graph for each resource, using the one or more validated access policies associated with each user role of the one or more user roles associated with each user; receive, an access request for the resource, from a user; retrieve, user details of the user from a user repository, wherein the user details comprise a user identity, a current user role and a current user context type; validate, the access request for the resource to the user, based on the current user role and the current user context type, using the access policy graph associated to the resource; and grant, a permission to the access request for the resource to the user, based on the validation.
[007] In yet another aspect, there is provided a computer program product comprising a non-transitory computer readable medium having a computer readable program embodied therein, wherein the computer readable program, when executed on a computing device, causes the computing device to: receive for each resource, (i) a plurality of users, (ii) one or more user roles associated with each user of the plurality of users, (iii) one or more compliance rules for each user role of the one or more user roles associated with each user, (iv) one or more user context types for each user role of the one or more user roles associated with each user, and (v) one or more access policies developed for each user role of the one or more user roles associated with each user of the plurality of users, from a policy repository, wherein the one or more user context types are: (i) a time slot context, (ii) a location context, (iii) a device context, and (iv) a network context; identify, one or more users out of the plurality of users, having more than one user roles that resulted in development of more than one access policies, from the one or more user roles associated with each user of the plurality of users to form a first set of users; identify, the one or more users out of the plurality of users, having a single user role but having more than one user context types, that resulted in development of more than one access policies, to form a second set of users; determine, (i) one or more conflicting access policies and (ii) one or more inconsistent access policies, for each user having more than one access policies, from the first set of users and the second set of users, based on the user context details of the associated user; validate and remove, (i) the one or more conflicting access policies and (ii) the one or more inconsistent access policies, for each user having more than one access policies, based on a validation criterion, to obtain one or more validated access policies associated with each user role of the one or more user roles associated with each user; generate an access policy graph for each resource, using the one or more validated access policies associated with each user role of the one or more user roles associated with each user; receive, an access request for the resource, from a user; retrieve, user details of the user from a user repository, wherein the user details comprise a user identity, a current user role and a current user context type; validate, the access request for the resource to the user, based on the current user role and the current user context type, using the access policy graph associated to the resource; and grant, a permission to the access request for the resource to the user, based on the validation.
[008] In an embodiment, each access policy associated with each user role comprises one or more access privilege details to access the resource.
[009] In an embodiment, the one or more conflicting access policies and the one or more inconsistent access policies, for each user having more than one access policies, from the first set of users and the second set of users, based on the user context details of the associated user, are determined based on: (a) the one or more access privilege details associated with the access policy, if the one or more user context types are not same for each user having more than one access policies; (b) coincidence in time slot, if (i) the one or more user context types are same for each user having more than one access policies, and (ii) the context type is the time slot context; (c) the one or more access privilege details associated with the access policy, if (i) the one or more user context types are same for each user having more than one access policies, and (ii) the context type is either the device context or the network context; and (d) a location, if (i) the one or more user context types are same for each user having more than one access policies, and (ii) the context type is the location context.
[010] In an embodiment, the one or more conflicting access policies and the one or more inconsistent access policies, for each user having more than one access policies, are determined based on the one or more access privilege details and the one or more compliance rules associated with each user role, if the one or more user context types are not present for each user role.
[011] In an embodiment, the validation criterion validates at least of: (i) conflicts in multiple user roles, (ii) conflicts in multiple user context types.
[012] In an embodiment, generating the access policy graph for each resource, using the one or more validated access policies associated with each user role of the one or more user roles associated with each user of the associated resource, comprises: creating a parent node for each user role of the one or more user roles of each user of one or more users, associated with the one or more validated access policies; creating one or more child nodes for each parent node, based on (i) the associated one or more user context types, (ii) the associated one or more access privilege details, and (iii) the associated one or more compliance rules; and creating an edge between each parent node to each child node of the one or more child nodes associated to the parent node.
[013] 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
[014] 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:
[015] FIG. 1 is an exemplary block diagram of a system for validating inconsistent and conflicting access policies, in accordance with some embodiments of the present disclosure.
[016] FIGS. 2A and 2B illustrates exemplary flow diagrams of a processor-implemented method for validating inconsistent and conflicting access policies, in accordance with some embodiments of the present disclosure.
[017] FIG. 3 illustrates an exemplary flow diagram for generating an access policy graph for each resource, in accordance with some embodiments of the present disclosure.
[018] FIG. 4 illustrates an exemplary access policy graph, in accordance with some embodiments of the present disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS
[019] 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.
[020] The present disclosure solves the technical problems in the art for validating inconsistent and conflicting access policies using a graph mechanism. According to the present disclosure, one or more conflicting access policies and the one or more inconsistent access policies are determined and such inconsistent and conflicting polices are removed if they do not meet the validation criterion, to obtain the one or more validated access policies associated with each user role. Then, the access policy graph for each resource is generated using the one or more validated access policies associated with each user role. Using the generated access policy graph, new access requests for the resource the validated so as to reduce the conflicting and inconsistent access polices in future.
[021] 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 systems and/or methods.
[022] FIG. 1 is an exemplary block diagram of a system 100 for validating inconsistent and conflicting access policies, in accordance with some embodiments of the present disclosure. In an embodiment, the system 100 includes or is otherwise in communication with one or more hardware processors 104, communication interface device(s) or input/output (I/O) interface(s) 106, and one or more data storage devices or memory 102 operatively coupled to the one or more hardware processors 104. The one or more hardware processors 104, the memory 102, and the I/O interface(s) 106 may be coupled to a system bus 108 or a similar mechanism.
[023] The I/O interface(s) 106 may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like. The I/O interface(s) 106 may include a variety of software and hardware interfaces, for example, interfaces for peripheral device(s), such as a keyboard, a mouse, an external memory, a plurality of sensor devices, a printer and the like. Further, the I/O interface(s) 106 may enable the system 100 to communicate with other devices, such as web servers and external databases.
[024] The I/O interface(s) 106 can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, local area network (LAN), cable, etc., and wireless networks, such as Wireless LAN (WLAN), cellular, or satellite. For the purpose, the I/O interface(s) 106 may include one or more ports for connecting a number of computing systems with one another or to another server computer. Further, the I/O interface(s) 106 may include one or more ports for connecting a number of devices to one another or to another server.
[025] The one or more hardware processors 104 may 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 are configured to fetch and execute computer-readable instructions stored in the memory 102. In the context of the present disclosure, the expressions ‘processors’ and ‘hardware processors’ may be used interchangeably. In an embodiment, the system 100 can be implemented in a variety of computing systems, such as laptop computers, portable computers, notebooks, hand-held devices, workstations, mainframe computers, servers, a network cloud and the like.
[026] 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. In an embodiment, the memory 102 includes a plurality of modules 102a and a repository 102b for storing data processed, received, and generated by one or more of the plurality of modules 102a. The plurality of modules 102a may include routines, programs, objects, components, data structures, and so on, which perform particular tasks or implement particular abstract data types.
[027] The plurality of modules 102a may include programs or computer-readable instructions or coded instructions that supplement applications or functions performed by the system 100. The plurality of modules 102a may also be used as, signal processor(s), state machine(s), logic circuitries, and/or any other device or component that manipulates signals based on operational instructions. Further, the plurality of modules 102a can be used by hardware, by computer-readable instructions executed by the one or more hardware processors 104, or by a combination thereof. In an embodiment, the plurality of modules 102a can include various sub-modules (not shown in FIG. 1). Further, the memory 102 may include 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.
[028] The repository 102b may include a database or a data engine. Further, the repository 102b amongst other things, may serve as a database or includes a plurality of databases for storing the data that is processed, received, or generated as a result of the execution of the plurality of modules 102a. Although the repository 102b is shown internal to the system 100, it will be noted that, in alternate embodiments, the repository 102b can also be implemented external to the system 100, where the repository 102b may be stored within an external database (not shown in FIG. 1) communicatively coupled to the system 100. The data contained within such external database may be periodically updated. For example, data may be added into the external database and/or existing data may be modified and/or non-useful data may be deleted from the external database. In one example, the data may be stored in an external system, such as a Lightweight Directory Access Protocol (LDAP) directory and a Relational Database Management System (RDBMS). In another embodiment, the data stored in the repository 102b may be distributed between the system 100 and the external database.
[029] Referring to FIGS. 2A and 2B, components and functionalities of the system 100 are described in accordance with an example embodiment of the present disclosure. For example, FIGS. 2A and 2B illustrates exemplary flow diagrams of a processor-implemented method 200 for validating inconsistent and conflicting access policies, in accordance with some embodiments of the present disclosure. Although steps of the method 200 including 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 be performed in that order. The steps of processes described herein may be performed in any practical order. Further, some steps may be performed simultaneously, or some steps may be performed alone or independently.
[030] At step 202 of the method 200, the one or more hardware processors 104 of the system 100 are configured to receive (i) a plurality of users, (ii) one or more user roles associated with each user of the plurality of users, (iii) one or more compliance rules for each user role of the one or more user roles associated with each user, (iv) one or more user context types for each user role of the one or more user roles associated with each user, and (v) one or more access policies developed for each user role of the one or more user roles associated with each user of the plurality of users, for each resource.
[031] In an embodiment, the plurality of users refers to all the users who are in the need of access or accessed to the resource. In an embodiment, one or more user roles associated with each user refers to type of roles associated with each user. For example, the user roles include project developer role, a project programmer role, a team lead role, a tester role, and so on. In an embodiment, some users may be assigned with multiple user roles. For example, same user may be assigned with both the developer role and the team lead role. Hence there is a possibility to assign more user roles for the single user.
[032] In an embodiment, the one or more compliance rules associated with each user role refers to type of the project, or team or business unit, the user role is associated to. For example, the user roles of same business unit comprise same compliance rules.
[033] In an embodiment, the one or more user context types for each user role refers to type of context of the user for whom the access need to be provided for the given resource. In an embodiment, the one or more user context types are: (i) a time slot context, (ii) a location context, (iii) a device context, and (iv) a network context (202). In an embodiment, the time slot context is associated with the time period or number of hours corresponding to the user role. For example, the user role is to be active for 10 AM to 8 PM every day. The location context refers to the location or origin of the user role or other wise the user requesting the access for the resource. For example, in a given project, team members may be from different locations. The device context refers to the type of the device of the user or the user role. For example, the device type includes, a laptop, a desktop, a table, a personal laptop, a smart phone, and so on. Lastly, the network context refers to the type of network of the user of the user role through which the user is accessing from. For example, the home LAN, office LAN, a mobile network, a public wireless-fidelity (Wi-Fi) and so on.
[034] In an embodiment, the one or more access policies developed for each user role refers the access policies created or defined for each user role based on the access required for the resource. In an embodiment, each access policy associated with each user role comprises one or more access privilege details to access the resource. The one or more access privilege details refers to the access permissions such as read, write, read only, read and write, edit, and so on. There may one access policy for each user role. Similarly, there may be one access policy for each user role per context type. Hence, is there always a possibility or the requirement that multiple access policies are developed for each user to the resource. For example, the user having the multiple user role need multiple access policies. Similarly, the user having the single user role but having multiple contexts results in multiple access policies.
[035] In an embodiment, the resource is either a software resource such as module, program, routine, document and so on, or a hardware resource such as memory, processor, and so on, or a combination thereof. Further, in an embodiment, the resource (or multiple resources) is associated with a project, multiple projects, or present in a specific location or a building, or scattered across multiple locations such as cloud resources, or a combination thereof.
[036] Thus, the security mechanism maintains the multiple access policies for different user roles to access the resource. If the access policies are not validated, then the performance of the application is degraded when user access the resource. Hence, the security mechanism needs to validate the user access using the access policies in access management.
[037] The information related to the users, the user roles, the compliance rules, the user context types, and the access policies for each resource are stored in the policy repository. In an embodiment, the policy repository is stored in the repository 102b of system 100. The policy repository in general comprises resource details of each resource, user details of each user and access privilege details of each user which defines the access policy.
[038] The resource details of each resource include a resource identity, a resource type, and a resource association. The resource identity is a unique identity for identifying a particular resource. In an embodiment, the resource identity is a resource name or a resource identification number (ID), or a combination thereof with which the resource is uniquely identified among the other resources. The resource type defines the type of the resource such as software resource, hardware resource, and so on. In an embodiment, the resource type includes a document, a server, an offshore data center (ODC), memory, version control, and so on. The resource association defines how the resource is associated with a certain project, a team, a location, an office, and so on.
[039] The user details are for each user who may need access to each resource. The user details of each user include a user identity and one or more user roles. The user identity is a unique identity for identifying a particular user. In an embodiment, the user identity is a name of the user or a user identification number (ID), or a combination thereof with which the user is uniquely identified among the other users. Each user may be tagged to the one or more user roles, wherein the user role for each user defines the type of the user based on the work role and corresponding to a particular resource. For example, the user roles for a project include a project manager role, project developer role, administrator role, team member role, and so on.
[040] The access privilege details are associated with each resource and for each user. The access privilege details include one or more access privileges. In an embodiment, the access privilege details include opening the resource, editing the resource, viewing the resource, copying the resource and so on, or a combination thereof.
[041] At step 204 of the method 200, the one or more hardware processors 104 of the system 100 are configured to identify one or more users out of the plurality of users received at step 202 of the method 200, having more than one user roles that resulted in development of more than one access policies, from the one or more user roles associated with each user of the plurality of users. The one or more users out of the plurality of users having more than one user roles that resulted in more than one access policies form a first set of users.
[042] At step 206 of the method 200, the one or more hardware processors 104 of the system 100 are configured to identify the one or more users out of the plurality of users received at step 202 of the method 200, having a single user role but having more than one user context types, that resulted in development of more than one access policies. The one or more users out of the plurality of users having the single user role but with more than one user context type, that resulted in more than one access policies form a second set of users.
[043] At step 208 of the method 200, the one or more hardware processors 104 of the system 100 are configured to determine (i) one or more conflicting access policies and (ii) one or more inconsistent access policies, for each user having more than one access policies, from the first set of users identified at step 204 of the method and the second set of users identified at step 206 of the method 200. The one or more conflicting access policies and the one or more inconsistent access policies are determined based on the user context details of the associated user. More specifically, the user context types associated with each user are utilized for determining the one or more conflicting access policies and the one or more inconsistent access policies.
[044] The conflicting access policies basically occur when a single user has multiple user roles. When two or more such access policies are same since the user has multiple user roles, there arises a conflict in such developed access policies. Similarly, the inconsistent access policies basically occur when a single user or with single user role, has multiple access privileges. For example, the first access policy is created with access privileges of only read, but the second access policy is created with access privileges of both read and write, then the first and second access policies created for single user or user role is said to be inconsistent to each other.
[045] Further, in an embodiment, the one or more conflicting access policies and the one or more inconsistent access policies are determined based on the one or more access privilege details associated with the access policy, if the one or more user context types are not same for each user who has more than one access policy. In another embodiment, the one or more conflicting access policies and the one or more inconsistent access policies are determined based on coincidence in time slot of the user or the user role, if (i) the one or more user context types are same for each user who has more than one access policies, and (ii) the context type is the time slot context
[046] In another embodiment, the one or more conflicting access policies and the one or more inconsistent access policies are determined based on the one or more access privilege details associated with the access policy, if (i) the one or more user context types are same for each user who has more than one access policies, and (ii) the context type is either the device context or the network context. In another embodiment, the one or more conflicting access policies and the one or more inconsistent access policies are determined based on a location of the user, if (i) the one or more user context types are same for each user who is having more than one access policies, and (ii) the context type is the location context. The one or more conflicting access policies and the one or more inconsistent access policies, identified at this step to be carefully validated for taking a proper action.
[047] Further, sometimes for some users or user roles, the user context types may not exist or may not be relevant. Hence, if the one or more user context types are not present for each user role, then the one or more conflicting access policies and the one or more inconsistent access policies, for each user having more than one access policies, are determined based on the one or more access privilege details and the one or more compliance rules associated with each user role.
[048] At step 210 of the method 200, the one or more hardware processors 104 of the system 100 are configured to validate the one or more conflicting access policies and the one or more inconsistent access policies that are identified at step 208 of the method, for each user who is having more than one access policies. The conflicting access policies and the inconsistent access policies that do not meet the validation are removed.
[049] A validation criterion is used to validate and remove such conflicting access policies and the inconsistent access policies. In an embodiment, the validation criterion validates at least one of: (i) conflicts in multiple user roles, and (ii) conflicts in multiple user context types. For example, the single user may have multiple user roles, but has same or similar access policies which are said to be in conflict to each other. Similarly, the single user or for single user role, there may be multiple user context types, but having similar access polices with same or similar access privileges for the resource. Such conflicting and inconsistent access policies out of all the access policies for the resource are removed to obtain one or more validated access policies associated with each user role of the one or more user roles associated with each user. The one or more validated access policies associated with each user role are free from the conflicting and the inconsistent access policies.
[050] At step 212 of the method 200, the one or more hardware processors 104 of the system 100 are configured to generate an access policy graph for each resource. The access policy graph for each resource is generated using the one or more validated access policies associated with each user role of the one or more user roles associated with each user, obtained at step 210 of the method 200.
[051] FIG. 3 illustrates an exemplary flow diagram for generating the access policy graph for each resource, in accordance with some embodiments of the present disclosure. As shown in FIG. 3, at step 212a, a parent node for each user role of the one or more user roles of each user, having the one or more validated access policies, is created. In general, the parent node is created for each user role having at least one validated access policy.
[052] At step 212b, one or more child nodes for each parent node, are created based on (i) the associated one or more user context types, (ii) the associated one or more access privilege details, and (iii) the associated one or more compliance rules. More specifically, one child is used for denoting the one or more user context types, one child node is used for denoting the one or more access privilege details, and one child is used for denoting the one or more compliance rules. Once the parent node for each user role and the one or more child nodes for each parent node are created, then at step 212c, an edge between each parent node to each child node of the one or more child nodes associated to the parent node is created.
[053] FIG. 4 illustrates an exemplary access policy graph, in accordance with some embodiments of the present disclosure. As shown in FIG. 4, the parent node for user role, i.e., the developer role and the project leader role are created. The respective child node for the user context types (such as time, C1:- T=6:18; C2:- T=0:6, 18:24) is created (Ccondition) for the parent node developer. The respective child node for the access privilege details (such as first privilege (P1) having open edit and print, and second privilege (P2) having open and edit time is created (Pcondition) for the parent node developer. Similarly, the respective child node for the compliance rules (such as first compliance rule (R1) having iSQ (information security quiz), PC (personal checks), BGC (background checks) teams, and the second compliance rule (R2) having iSQ, PC, and BGC teams) is created (Rcondition) for the parent node developer.
[054] As the access policy graph for each resource is generated using the validated access policies, the generated access policy graph is free from the conflicting and the inconsistent access policies. Hence the generated access policy graph is used in future for validating the user access or access requests from new or existing users of user roles.
[055] At step 214 of the method 200, the one or more hardware processors 104 of the system 100 are configured to receive an access request for the resource, from the user. If the user role is assigned to the user, then the individual will get the access rights by the administrator by creating the access policy. If the user is a new user, then the administrator assigns a role to the user and grants access rights through the applicable policy. At step 216 of the method 200, the one or more hardware processors 104 of the system 100 are configured to retrieve user details of the user from a user repository. The user details comprise the user identity, the current user role, and the current user context type. In an embodiment, the user repository may be present in the user device.
[056] At step 218 of the method 200, the one or more hardware processors 104 of the system 100 are configured to validate the access request for the resource to the user, based on the current user role and the current user context type retrieved at step 216 of the method 200, using the access policy graph associated to the resource, generated at step 212 of the method 200. A graph traversal mechanism is employed to check whether the current user role and the current user context type at step 216 of the method 200, is present in the associated access policy graph or not. If present and matched with the associated access policy graph, then the user request is a successful access request, else it is considered as unsuccessful or invalid user access request.
[057] At step 220 of the method 200, the one or more hardware processors 104 of the system 100 are configured to grant a permission to the access request for the resource to the user, based on the validation checked at step 218 of the method 200. More particularly, of the validation is successful at step 218, then the permission for the resource to the user is granted, else the permission for the resource to the user is denied.
[058] The embodiments of present disclosure herein address unresolved problem of validating the inconsistent and the conflicting access policies, by first determining the one or more conflicting access policies and the one or more inconsistent access policies and such inconsistent and conflicting polices are removed if they do not meet the validation criterion, to obtain the one or more validated access policies associated with each user role. Then, the access policy graph for each resource is generated using the one or more validated access policies associated with each user role. Hence the access policy graph generated is used in future to validate all such requests and ensure the access policy developed is not redundant, not conflicting or not inconsistent. As there will be limited number of access policies, the performance of the resource is improved much better compared to the resource with many such conflicting and inconsistent access policies. Hence the method of the present disclosure is efficient for validating the inconsistent and the conflicting access policies.
[059] 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.
[060] 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.
[061] 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.
[062] 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.
[063] 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.
[064] 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 (200) for validating inconsistent and conflicting access policies, comprising the steps of:
receiving for each resource, via one or more hardware processors, (i) a plurality of users, (ii) one or more user roles associated with each user of the plurality of users, (iii) one or more compliance rules for each user role of the one or more user roles associated with each user, (iv) one or more user context types for each user role of the one or more user roles associated with each user, and (v) one or more access policies developed for each user role of the one or more user roles associated with each user of the plurality of users, from a policy repository, wherein the one or more user context types are (i) a time slot context, (ii) a location context, (iii) a device context, and (iv) a network context (202);
identifying, via the one or more hardware processors, one or more users out of the plurality of users, having more than one user roles that resulted in development of more than one access policies, from the one or more user roles associated with each user of the plurality of users to form a first set of users (204);
identifying, via the one or more hardware processors, the one or more users out of the plurality of users, having a single user role but having more than one user context types, that resulted in development of more than one access policies, to form a second set of users (206);
determining, via the one or more hardware processors, (i) one or more conflicting access policies and (ii) one or more inconsistent access policies, for each user having more than one access policies, from the first set of users and the second set of users, based on the user context details of the associated user (208);
validating and removing, via the one or more hardware processors, (i) the one or more conflicting access policies and (ii) the one or more inconsistent access policies, for each user having more than one access policies, based on a validation criterion, to obtain one or more validated access policies associated with each user role of the one or more user roles associated with each user (210); and
generating, via the one or more hardware processors, an access policy graph for each resource, using the one or more validated access policies associated with each user role of the one or more user roles associated with each user (212).

2. The processor-implemented method of claim 1, further comprising:
receiving, via the one or more hardware processors, an access request for the resource, from a user (214);
retrieving, via the one or more hardware processors, user details of the user from a user repository, wherein the user details comprise a user identity, a current user role and a current user context type (216);
validating, via the one or more hardware processors, the access request for the resource to the user, based on the current user role and the current user context type, using the access policy graph associated to the resource (218); and
granting, via the one or more hardware processors, a permission to the access request for the resource to the user, based on the validation (220).

3. The processor-implemented method of claim 1, wherein each access policy associated with each user role comprises one or more access privilege details to access the resource.

4. The processor-implemented method of claim 1, wherein (i) the one or more conflicting access policies and (ii) the one or more inconsistent access policies, for each user having more than one access policies, from the first set of users and the second set of users, based on the user context details of the associated user, are determined based on:
(a) the one or more access privilege details associated with the access policy, if the one or more user context types are not same for each user having more than one access policies;
(b) coincidence in time slot, if (i) the one or more user context types are same for each user having more than one access policies, and (ii) the context type is the time slot context;
(c) the one or more access privilege details associated with the access policy, if (i) the one or more user context types are same for each user having more than one access policies, and (ii) the context type is either the device context or the network context; and
(d) a location, if (i) the one or more user context types are same for each user having more than one access policies, and (ii) the context type is the location context.

5. The processor-implemented method of claim 1, wherein (i) the one or more conflicting access policies and (ii) the one or more inconsistent access policies, for each user having more than one access policies, are determined based on the one or more access privilege details and the one or more compliance rules associated with each user role, if the one or more user context types are not present for each user role.

6. The processor-implemented method of claim 1, wherein the validation criterion validates at least of: (i) conflicts in multiple user roles, (ii) conflicts in multiple user context types.

7. The processor-implemented method of claim 1, wherein generating the access policy graph for each resource, using the one or more validated access policies associated with each user role of the one or more user roles associated with each user of the associated resource, comprises:
creating a parent node for each user role of the one or more user roles of each user of one or more users, associated with the one or more validated access policies (212a);
creating one or more child nodes for each parent node, based on (i) the associated one or more user context types, (ii) the associated one or more access privilege details, and (iii) the associated one or more compliance rules (212b); and
creating an edge between each parent node to each child node of the one or more child nodes associated to the parent node (212c).

8. A system (100) for validating inconsistent and conflicting access policies, comprising:
a memory (102) storing instructions;
one or more input/output (I/O) interfaces (106); and
one or more hardware processors (104) coupled to the memory (102) via the one or more I/O interfaces (106), wherein the one or more hardware processors (104) are configured by the instructions to:
receive for each resource, (i) a plurality of users, (ii) one or more user roles associated with each user of the plurality of users, (iii) one or more compliance rules for each user role of the one or more user roles associated with each user, (iv) one or more user context types for each user role of the one or more user roles associated with each user, and (v) one or more access policies developed for each user role of the one or more user roles associated with each user of the plurality of users, from a policy repository, wherein the one or more user context types are (i) a time slot context, (ii) a location context, (iii) a device context, and (iv) a network context;
identify, one or more users out of the plurality of users, having more than one user roles that resulted in development of more than one access policies, from the one or more user roles associated with each user of the plurality of users to form a first set of users;
identify, the one or more users out of the plurality of users, having a single user role but having more than one user context types, that resulted in development of more than one access policies, to form a second set of users;
determine, (i) one or more conflicting access policies and (ii) one or more inconsistent access policies, for each user having more than one access policies, from the first set of users and the second set of users, based on the user context details of the associated user;
validate and remove, (i) the one or more conflicting access policies and (ii) the one or more inconsistent access policies, for each user having more than one access policies, based on a validation criterion, to obtain one or more validated access policies associated with each user role of the one or more user roles associated with each user; and
generate an access policy graph for each resource, using the one or more validated access policies associated with each user role of the one or more user roles associated with each user.

9. The system of claim 8, wherein the one or more hardware processors (104) are further configured by the instructions to:
receive, an access request for the resource, from a user;
retrieve, user details of the user from a user repository, wherein the user details comprise a user identity, a current user role and a current user context type;
validate, the access request for the resource to the user, based on the current user role and the current user context type, using the access policy graph associated to the resource; and
grant, a permission to the access request for the resource to the user, based on the validation.

10. The system of claim 8, wherein each access policy associated with each user role comprises one or more access privilege details to access the resource.

11. The system of claim 8, wherein the one or more hardware processors (104) are configured to determine (i) the one or more conflicting access policies and (ii) the one or more inconsistent access policies, for each user having more than one access policies, from the first set of users and the second set of users, based on the user context details of the associated user, based on:
(a) the one or more access privilege details associated with the access policy, if the one or more user context types are not same for each user having more than one access policies;
(b) coincidence in time slot, if (i) the one or more user context types are same for each user having more than one access policies, and (ii) the context type is the time slot context;
(c) the one or more access privilege details associated with the access policy, if (i) the one or more user context types are same for each user having more than one access policies, and (ii) the context type is either the device context or the network context; and
(d) a location, if (i) the one or more user context types are same for each user having more than one access policies, and (ii) the context type is the location context.

12. The system of claim 8, wherein the one or more hardware processors (104) are configured to determine (i) the one or more conflicting access policies and (ii) the one or more inconsistent access policies, for each user having more than one access policies, based on the one or more access privilege details and the one or more compliance rules associated with each user role, if the one or more user context types are not present for each user role.

13. The system of claim 8, wherein the validation criterion validates at least of: (i) conflicts in multiple user roles, (ii) conflicts in multiple user context types.

14. The system of claim 8, wherein the one or more hardware processors (104) are configured to generate the access policy graph for each resource, using the one or more validated access policies associated with each user role of the one or more user roles associated with each user of the associated resource, by:
creating a parent node for each user role of the one or more user roles of each user of one or more users, associated with the one or more validated access policies;
creating one or more child nodes for each parent node, based on (i) the associated one or more user context types, (ii) the associated one or more access privilege details, and (iii) the associated one or more compliance rules; and
creating an edge between each parent node to each child node of the one or more child nodes associated to the parent node.

Dated this 17th Day of January 2023

Tata Consultancy Services Limited
By their Agent & Attorney

(Adheesh Nargolkar)
of Khaitan & Co
Reg No IN-PA-1086