AU2007229372A1 - An access control mechanism for web applications - Google Patents

Description

AUSTRALIA PATENTS ACT 1990 (CTH) COMPLETE SPECIFICATION FOR A STANDARD PATENT Name of Applicant IMTG Australia (ABN 72 802 715 273) Actual Inventor loakim Marmaridis Address for Service loakim Marmaridis c/o 25 Pittwater Rd Gladesville NSW 2111 Invention Title: An access control mechanism for web applications The following statement is a full description of this invention including the best method of performing it known to me: AN ACCESS CONTROL MECHANISM FOR WEB APPLICATIONS Field of the Invention The present invention relates generally to a mechanism for access control in web systems which is capability based, in particular, capabilities are encoded in simple English sentences. Background As the use of web applications has grown, so too has the risk of accidental data exposure unless a robust access control mechanism is employed. Current mechanisms for access control do not adequately cater for all aspects of securing web applications. In particular, applications used in collaboration or that employ workflows require a more capable access control mechanism. Generally, access control mechanisms define what resources (or objects) a user (or subject) is able to access given a set of rules. Prior to the inception of the World Wide Web (web) there were two major mechanisms for access control. These included Discretionary Access Control (DAC) and Mandatory Access Control (MAC). DAC systems allow owners of resources to specify which user had access rights over the resources by mapping one to the other. DAC systems can be defined by a Lampson matrix which offers a general model for mapping users to resources on a one-to-one basis. MAC is a lattice-based access control system and bases access rights on a sensitivity level and a category set. The disadvantages of MAC systems is that they are difficult to set up and configure and are of limited use given they are non discretionary, that is, users cannot give or take away access to resources as this can only be done centrally or delegated to a few authorised individuals. A more developed access control system which is widely used employs both DAC and MAC policies. This access control system is known at Role Based Access Control (RBAC). RBAC controls access through mapping access rights on resources to organisational roles effectively collapsing the Lampson matrix to a smaller, more manageable set. RBAC systems deal with additional temporal and inter-task 2 dependency constraints through roles assigned to tasks. Though, RBAC systems cannot deal well with temporal aspects of access control introduced by workflows. Task Based Access Control (TBAC) better deal with temporal aspects of access control introduced by workflows. However, inter-organisational collaborative web based systems require a more flexible, dynamic and granular model for access control. The current access control systems do not adequately facilitate from ad-hoc collaboration to pre-defined, workflow driven collaboration. Summary It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing access control systems. A method for offering access control services to computer applications and systems are disclosed which seek to address the above problems by establishing a Virtual Team Based Access Control System (VTMAC) which encodes access control rules using a 5-tuple English statement called a Capability. VTMAC can implement both discretionary access control (DAC) and mandatory access control (MAC) policies that control access to resources addressable in the computer system. Capabilities are designed to be easily understood and interpreted by users who can be allowed to create, remove or change them. At the same time, capabilities are easily parse-able by computer systems and lend themselves to an implementation using predicate logic or relational database systems. VTMAC capabilities maintain the relationships between projects, users and resources and each relationship is assigned an arbitrary operation. Finally permissions decide whether the capability offers rights or refuses them. VTMAC represents subjects at different levels of abstraction. A subject can be a project team, project group, project role and project user (team member). 3 Brief Description of the Drawings One or more embodiments of the present invention will now be described with reference to the drawings, in which: Fig 1 shows a schematic high level block diagram of a general purpose computer system upon which the described mechanism can be utilised; Fig 2 shows a schematic detailed diagram of the integrated technology wherein the described mechanism operates; Fig 3 shows a schematic functional diagram of the steps involved in the operation of the described mechanism; and Fig 4 is flow diagram that shows steps involved in the mechanism in accordance with one embodiment. Detailed Description including Best Mode In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however to one skilled in the art that the present invention be practised without these specific details. In other instances, well known devices are shown in block diagram form in order to avoid unnecessary obscuring the present invention. The present disclosure relates to a mechanism for providing access control in web systems designed to support workflow based activities and inter-organisational project based collaboration called Virtual Team Based Access Control (VTMAC). The disclosed mechanism of providing access control mechanisms for web applications may be implemented on a general purpose computer system 100, such as that shown in Fig 1. The computer system 100 is formed by a PC 99 including a web browser 98 and a web server 97. The web server 97 contains the VTMAC system including its capabilities, resources and optional workflows 96. 4 Fig 2 is a schematic block diagram illustrating the functions implemented on the integrated technology wherein the described mechanism operates 97. A user can either: (a) input a query/request 89 in order to validate the presence of a user, resource and/or operation; and/or (b) create or delete capabilities 87 or 86 via one or more web applications 91, 92 and 93 or a workflow engine 94 respectively. Input 90 such as a query/request 89 and/or the creation or deletion of capabilities 87 by a user may be via an online form or other means. User input is processed by the VTMAC mechanism. Subsequently a response 88 is returned to the user making the query/request. Similarly, input such as the creation or deletion of capabilities 86 may be via a workflow engine 94. Such input is again processed by VTMAC 95 with a response 85 returned to the workflow engine 94. Fig 3 shows a schematic functional diagram of the processing steps 77 of the described mechanism. A query/request is made by a user to say access a specific resource. The VTMAC system will: (a) identify the user; (b) identify the relevant project; (c) gather relevant capabilities; (d) evaluate capabilities; (e) determine the net effect of capabilities; and (f) return a response to user indicative of appropriate access rights. Capabilities 78 are a set of rules stored within VTMAC 95. Fig 4 is a flow diagram which represents the process employed by VTMAC 95 is authenticating a user's request/query 89 to access a resource for a given operation. A request 89 is received by VTMAC 95 which validates the presence of the user, resource and operation 84. If the request 89 is valid a list of resources accessible to relevant user 82 and a list of operations available to this user for the relevant 5 resources 81 will be returned. However, if the request 89 is not valid, a validation error 83 will be returned. Depending on the capabilities 78 created, the operation will be either allowed, returning an "Access Allowed" 79 response or denied, returning an "Access Denied" 80 response A VTMAC system defines teams, groups and roles of users in the context of each project. Projects within the system contain users, roles, groups and teams, together with resources and workflows. VTMAC projects are not subordinate to applications. Each project always has a team referred to as a Virtual Team since its members need not come from the same department or organisations. Projects are commonly used to store running instances of workflows. Anyone participating in a VTMAC project is automatically assigned to the Virtual Team. In addition, they may have one or more roles assigned to them and belong into one or more groups. No two users in the same project may have the same role. However, if this is desired, a group can be created instead.. VTMAC projects and resources can be mapped at different levels of abstraction to facilitate the system's behaviours. Resources are not pre determined and access rules allow anything that is URI addressable to be mapped as a resource. As a result resources can be defined at different levels of granularity within a single project. Access control in the VTMAC system is capability based where capabilities express what rights a user has to a particular resource within a project. VTMAC capabilities are encoded in simple English sentences to facilitate human readability and understanding. For example capability statements take the following format: In Tenderresponse forabc, allow Alice to edit clientcontact-details Or in the more generic format of: In <Project>, <permit or not> <Subject> to <perform Operation on> <Resource> 6 Apart from the use of the words "in" and "to" and the comma for readability, the rest of a capability is essentially a set of keywords corresponding to different elements that are related. Each of these elements is called a capability element. Each capability is made up of 5 elements. These include: Project: This is a simple, human readable unique string that typically maps to a VTMA-managed data record containing information about each given project. Projects are containers of Virtual Teams, capabilities and other optional data say a web designer may have determined as useful. Permission: This can be either "allow" or "deny". Permissions specify whether the capability grants the subject access or permission to something or explicitly denies it. Subject: A subject is something that performs an operation or action to the resource specified later on in the capability. Commonly subjects are associated with users, however while this may be true it is not universal. There are numerous Subjects inside a project team, individuals, roles, groups and the team itself so Subject can be any of all these and it can also be the keyword "all" which will match any Subject even for those not related to the virtual project team. Using "all: is good in situations where selective resources must be made accessible to everyone in the system without having to make them all members of the virtual team necessarily, thus significantly simplifying the number of capabilities that need to be set and managed. Operation: This defines what action the Subject is actually allowed (or denied) to/from performing. They are also simply string values whose interpretation is left to the calling application that makes use of this particular capability. Resource: A resource is anything that can be addressed via a string including an application or piece of data (as in a document). The resource is dependent upon how it can be accessed by the calling application. VTMAC capabilities are logically stored with each project and can be attached to a user within a Virtual Team, a role, a group or a team. The VTMAC capabilities are centrally stored by VTMAC itself for efficiency reasons. 7 VTMAC is a DAC based system by default with users able to change project related capabilities. On the other hand, it can be configured as a MAC system effectively taking away change rights to some or all of the project capabilities. To facilitate this feature capabilities are separated into 2 classes, Project and META capabilities. Most capabilities are typically Project ones, META capabilities are set in the context of the entire VTMA and govern access to Project capabilities. META capabilities are encoded using a special project keyword called METAL that is reserved by VTMAC for this purpose. To control who can and cannot create capabilities for projects across the entire environment, one then needs to simply set a META capability such as the following: In META, allow Alice to Create Capability If one was to assign this ability to say the administrators group within the entire framework the above capability could be re-written to read as follows: In META, allow Administrators to Create Capability If everyone in the framework is to have access to create capabilities another META capability would be added such as the following: In META, allow ALL to Create Capability The above META capability is set by default making VTMAC a DAC system. When all such META capabilities are removed VTMAC becomes a MAC system. Obviously one could likewise allow or restrict access for access for deleting capabilities just as easily by setting a META capability with a Delete instead of a Create operation. Also use of a resource named "Capability" is the above examples of META capabilities indicate that "Capability" is another reserved keyword in VTMAC. This keyword allows granular meta-access control to managing capabilities on a per project basis. This is archived by adding a project capability. Below are example capabilities for allowing the project team to manage per project capabilities. In 'Project A', allow 'project initiator' to Create Capability 8 In 'Project A', allow Team to Create Capability In 'Project A', deny Bob to Create Capability In 'Project A', allow Bob to Delete Capability In 'Project A', allow Bob to View Capability Subsequently, the person with the role of "project initiator" in the above example is able to create new capabilities for that project. Accordingly other users can perform some functions against the capabilities of this project. This is subject to META capabilities allowing such behaviour in the first place. In case of conflict the META capabilities take precedence. The default behaviour of VTMAC is template driven and like in many other access control systems this allows for rapid setting of default access control rules (in this case capabilities) and any associated groups, roles of users within the project. VTMAC evaluates capabilities based on 3 rules before acting upon their net effect. These 3 rules govern the evaluation of all capability sets, these are: 1. Deny wins over Allow: If a capability says to Deny an operation (to a given resource to a given project) from a user, no matter what other capabilities dictate, they will not be effective. 2. Rights are Cumulative: When evaluating a set of capabilities, all the matching ones are returned and therefore the rights offered in them are cumulative. 3. No Capability - No Access: If there is no capability for a project that say allows a user (directly or indirectly) access a resource this user is then not allowed to access that resource. 9

Claims (8)

1. A mechanism for controlling user access to resources in web applications comprising of: a plurality of project means wherein are a plurality of users, workflows and said resources are defined; storage means defining access control capabilities of said users to said resources; evaluation means defining the net effect of access capabilities of said users to said resources, wherein the net effect of the access capabilities of said users to said resources is represented via an output device.

2. A mechanism according to claim 1, the plurality of users further comprising of roles of users, teams and groups of users.

3. A mechanism according to claim 1, wherein said storage means is contained within the project means.

4. A mechanism according to claim 1 and 3, wherein the said storage means further comprises of access control capabilities encoded in simple English sentences via predicate logic in 5tuples.

5. A mechanism according to claim 1, 3 and 4, wherein said access control capabilities can be attached to a specific user within said project means.

6. A mechanism according to claim 1, 3, 4 and 5, wherein said access control capabilities further comprise of project, permission, subject, operation and resource elements.

7. A mechanism according to claim 1, wherein evaluation means further comprises of rules which govern the net effect of access control capabilities, said rules include Deny wins over Allow, Rights are Cumulative, and No Capability results in No Access. 10

8. A mechanism controlling user access to resources in web applications, said mechanism being substantially as herein described with reference to the drawings. 11