WO2008037005A1

WO2008037005A1 - Access management system and method

Info

Publication number: WO2008037005A1
Application number: PCT/AU2007/001418
Authority: WO
Inventors: Chaoyi Pang; David Hansen
Original assignee: Commonwealth Scientific And Industrial Research Organisation
Priority date: 2006-09-25
Filing date: 2007-09-25
Publication date: 2008-04-03

Abstract

A method of creating a role based access control model for use in determining the grant of privileges of a set of groups having a set of roles, the method including the steps of: (a) defining a group graph (Gu) and a role graph (Gr); (b) assigning groups predetermined roles (Lur); (c) forming a model graph combining the group graph, role graph and assigned roles; (d) removing redundant arcs and nodes from the model graph to produce a role based access control graph; (e) utilising the role based access control graph as the role based access control model.

Description

ACCESS MANAGEMENT SYSTEM AND METHOD

FIELD OF THE INVENTION

[0001] The present invention relates to the field of access control systems and, in particular, discloses a role based access control model for efficient use in an access control system.

BACKGROUND OF THE INVENTION

[0002] Any discussion of the prior art throughout the specification should in no way be considered as an admission that such prior art is widely known or forms part of common general knowledge in the field.

[0003] In complex organisations such as hospitals or defence networks, providing users with access to sensitive information is often problematic. This is especially the case where the role of a user evolves over time. As access rights can change over time and users come and go, a system must be able to deal with a highly dynamic environment.

[0004] Ideally, a control models should have support for changes, manipulation and specifications made for groups and roles under the existence of conflict constraints.

SUMMARY OF THE INVENTION

[0005] It is an object of the present invention to provide for an improved access control method and system.

[0006] According to a first aspect of the present invention there is provided a method of creating a role based access control model for use in determining the grant of privileges of a set of groups having a set of roles, the method including the steps of:

(a) defining a group graph (Gu) and a role graph (Gr);

(b) assigning groups within the group graph to predetermined roles within the role graph (Lur); (c) building a model graph by combining the group graph, the role graph and the assignment of groups to roles;

(d) removing redundant elements from the model graph to produce a role based access control graph; (e) utilising the role based access control graph as the role based access control model.

[0007] The redundant elements of the model graph include one or more selected from the group comprising a redundant arc and a redundant node.

[0008] Preferably, step (a) further includes forming the transitive closure of the group graph and role graph and the step (d) further includes utilising the transitive closures to determine redundant elements of the model graph. More preferably, step (d) includes computing the transitive closure of the model graph from the transitive closure of the group graph and the role graph.

[0009] The steps are preferably carried out utilising first order logic predicates. More preferably, the first order logic predicates are formed as SQL queries.

[0010] The method described previous preferably comprising the step of performing operational queries on the role access control graph. The method preferably further comprising the steps of performing maintenance operations on the role bases access control graph, the maintenance operations including at least one of: adding a node; deleting a node; adding a set of assignments from LUR; deleting a set of assignments from LUR; adding a user to a group; deleting a user from a group; adding a privilege to a role; deleting a privilege from a role; and removing redundancy from a set of conflict constraints. [0011] According to a second aspect of the present invention there is provided a system for creating a role based access control model to use in determining the grant of privileges of a set of groups having a set of roles, the system adapted to perform a method as described previously. [0012] According to a third aspect of the present invention there is provided a system for creating a role based access control model to use in determining the grant of privileges of a set of groups having a set of roles, the system including: a processor adapted to receive data indicative of a group graph, a role graph, and an assignment of groups within the group graph to predetermined roles within the role graph; the processor further adapted to build a model graph by combining the group graph, the role graph and the assignment of groups to roles, and remove redundant elements from the model graph to produce a role based access control graph; the processor further adapted to utilise the role based access control graph as the role based access control model.

[0013] The processor is preferably further adapted to performing maintenance operations on the role bases access control graph, the maintenance operations including at least one of: adding a node; deleting a node; adding a set of assignments from LUR; deleting a set of assignments from LUR; adding a user to a group; deleting a user from a group; adding a privilege to a role; deleting a privilege from a role; and removing redundancy from a set of conflict constraints.

[0014] In accordance with an aspect of the present invention, there is provided a method of creating a role based access control model for use in determining the grant of privileges of a set of groups having a set of roles, the method including the steps of: (a) defining a group graph (Gu) and a role graph (Gr); (b) assigning groups predetermined roles (Lur); (c) forming a model graph combining the group graph, role graph and assigned roles; (d) removing redundant arcs and nodes from the model graph to produce a role based access control graph; (e) utilising the role based access control graph as the role based access control model.

[0015] The step (a) further preferably can include forming the transitive closure of the group graph and role graph and the step (d) further preferably can include utilising the transitive closures to determine redundant arcs and nodes of the model graph. The step (d) preferably can include computing the transitive closure of the model graph from the transitive closure of the group graph and the role graph.

[0016] The steps are preferably carried out utilising first order logic predicates. The steps first order logic predicates are preferably formed as SQL queries. [0017] The method preferably also includes the step of performing operational queries on the role access control graph and the steps of performing a series of maintenance operations on the role bases access control graph, the maintenance operations including at least one of: -inserting a new group or role; -deleting a new group or role; -adding or deleting a role for a predetermined group.

BRIEF DESCRIPTION OF THE DRAWINGS

[0018] A preferred embodiment of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:

Fig. 1 illustrates an example group graph and its transitive closure; Fig. 2 illustrates an example role graph and its transitive closure;

Fig. 3 illustrates and example role assignment and redundancy;

Fig. 4 illustrates the process of removal of redundant arcs from Fig. 3;

Fig. 5 illustrates the removal of redundant nodes from Fig. 4;

Fig. 6 illustrates the computation of TCu; Fig. 7 illustrates Gm with redundant nodes;

Fig. 8 illustrates TCm;

Fig. 9 illustrates Gm with the removal of redundant arcs;

Fig. 10 illustrates an example of constraint processing;

Fig. 11 illustrates steps in forming Gm; and Fig. 12 illustrates a schematic of a system adapted to perform a method for forming

Gm.

DESCRIPTION OF PREFERRED AND OTHER EMBODIMENTS

[0019] As there are typically a number of different users who undertake a number of different roles within an organisation, access can typically be determined by roles. This has lead to a desire for a role based access control system, wherein a role based access control (RBAC) model is utilised to represent the roles and privileges of users in a complex organisation. Preferably, this control model should have support for changes, manipulation and specifications made for groups and roles under the existence of conflict constraints. [0020] In a preferred embodiment, by way of example only, a simplified RBAC model, along with corresponding relationships between user groups and privileges, is provided by integrating a user group graph (Group Hierarchy) and a role graph (Role Hierarchy) in a combined graph. A transitive closure procedure is used on the graphs for mainstreaming the RBAC models reach ability between, and within, the graphs.

[0021] A number of basic notations used in this description are described. There is also provided: example embodiments that are utilised in throughout the description, a description of how graphs are used to construct an RBAC model, and a discussion of possible operations that that can be performed once this RBAC model is constructed.

[0022] It will be appreciated that a preferred embodiment of the method can provides three main features:

1. The definition of an integrated RBAC model which contains no redundant information.

2. The use of transitive closure relations as the auxiliary relation for maintaining the RBAC model.

3. The algorithms used for maintaining the RBAC models are first order and hence can be implemented easily in a relational database system.

[0023] It will also be appreciated that a preferred embodiment of the method can provide a number of advantages including: 1. A model more easily supports common RBAC queries such as

(a) which roles can be accessed from a user or group; and

(b) which groups can access a given privilege.

2. A proposed integrated RBAC model contains no redundancy, hence:

(a) retrieving information less prone to error; (b) changing the graph when role, group , user or privilege information changes is less prone to introducing error; and

(c) the model is more adaptable to new information being added.

3. An algorithms for the maintenance are first -order algorithms with simple structures. This implies a low parallel complexity and can be implemented in SQL. [0024] A way in which the RBAC model is built allows for easy interrogation of the RBAC model to determine a user's access and also maintenance operations which are of a first order. Being first order operations, they are amenable to translation into SQL queries.

[0025] The following basic notations are used in this description and can be described as follows:

[0026] By way of example only, a case of treatment at hospital where service provision is monitored from an external area manager is examined. A user needs access to various parts of data about each patient, where data for each patient is split into identifying data, hospital admissions and services data and clinical data. Groups along with relevant roles and privileges are given below.

[0027] Users can be grouped, for example, as follows: gl Hospital administrators; g2 Hospital services group; g3 Researchers - health service delivery; g4 Clinicians/surgeons; g5 Data quality group; g6 Data assurance; and g9 Area managers.

[0028] Rolls relevant to these users can, for example, be expressed collectively as follows: rl Cancer clinician; r2 Hospital administrator; r3 Health service delivery researcher; r4 Master patient indexer; r5 Clinical research; and r6 Data linker. [0029] Privileges relevant to these users and associated rolls can, for example, be expressed collectively as follows: pi Read access to identifying data; p2 Read and Write access to identifying data; p3 Read access to clinical data; p4 Read and Write access clinical data; p5 Read access to hospital stay and health procedure data; and p6 Read access to identifying and hospital stay data.

[0030] Defining a RBAC model, as shown in Fig. 11 and described in more detail below, can include the following four steps: Step 1 Building the Group and Role graphs 1 1 10;

Step 2 Assigning groups to roles 1120;

Step 3 Defining the RBAC model 1 130; and

Step 4 Removal of redundant arcs and nodes 1140.

[0031] Step 1, in an embodiment, involves building the group and role graphs, an initial stage of which is defining the Group (Gu) and Role graphs (G_R) and their corresponding transitive closure groups.

[0032] This first step is further explained as follows. A set of groups Vu is defined, and for each group g a set of users that belong to each group is defined.

[0033] By way of example only, of this assignment can be expressed as follows:

[0034] Referring to Fig. 1, a Group Graph (Gu) 100 and its transitive closure (TCu) 150 is shown. To build the group graph, groups are organized in a hierarchy based on a subsumption relationship, best shown in Fig. l(a) as Gu- The transitive closure graph of Gu, TCu, is indicative of the reachability of Gu, i.e. all possible transitive arcs of the graph are expressed.

[0035] Referring to Fig. l(a), in this example the Group Graph, Gu, shows that role 'g2' 110 has users of {ul, u2, u3} and role 'g3' 120 has users of {ul, u2, u3, u4}.

[0036] A Role Graph (G_R) 200, and transitive closure (TC_R) 250, for this example can also be built, as shown in Fig. 2. The Role Graph is organized in a hierarchy, which is based on the subsumption relationship of privileges, as best shown in Fig. l(a) as G_R. It would be appreciated that a group is said to subsume another group if the second group is a proper subset of the first. The Role Graph, G_R, is again a DAG where V_R is a set of roles and A_R C V_RXV_R is a set of arcs. Arc (r, r') of A_R means r'er (i.e. each privilege of r' is also a privilege of r) and can be denoted as r->r\

[0037] Referring to Fig. 2(a), in this example the Role Graph, G_R, shows that role 'rl' 210 has privileges of {pi, p2, p3, p4} and role 'r5' 220 has privileges of {p3, p4}. Therefore, in this example, rl ->r5 since {p3, p4}cz{pl, p2, p3, p4}.

[0038] The second step in building an RBAC model, as expressed above, is assigning groups to roles and is further explained as follows. An L_UR in this example is a relation such that L_URC V_UX V_R, and forms an assignment of a sets of groups to a set of roles.

[0039] Referring to Fig. 3, an example L_UR 300 assigns groups to roles, whereby an arc (g, r) of L_UR indicates that group 'g' assigns to role 'r'. By way of example only, an assignment (g9,r2) 310 of L_UR assigns group 'g9' to role 'r2', and assignment (gl,r5) 320 of L_UR assigns group 'gl ' to role ^ςr5'. The assignment (g9,r2) 310 of L_UR means that each user of g2 can perform operations relating the privileges of {pl,p2,p5,p6}. It will be appreciated that the dotted lines 320, 321, 322 and 323 are redundant links that can be subsequently removed.

[0040] The third step in building an RBAC model, as expressed above, is defining an RBAC model. This RBAC model is an integrated graph of the group graph, role graph, and assignment graph Le. G_M = GuU G_R UL_UR, as shown in Fig. 3.

[0041] The fourth step in building an RBAC model, as expressed above, is removal of redundant arcs and nodes from G_M- It will be appreciated that, in a distributed acyclic graph, G, the removal of redundant arcs will not change the reachability of the nodes in the graph.

[0042] Removal of redundant arcs and nodes from G_M can be achieved by the following operation. Finding the redundant tuples, RedAu= TCi/*¹ TCu, can be expressed as:

Select S.columnl, T.column2

From TCu S, TCu T

Where S.column2 = T.columnl

[0043] The result of finding redundant tuples in this example can be shown in the table below:

[0044] Referring to Fig. 3, in this example, arc (gl,g3) 321 is redundant since group gl can reach group g3 through group g2. For a similar reason, each dotted arc (320, 321, 322 and 323) is redundant. In this example, all members of the hospital administrators group (gl) are also members of the hospital services group (g2) and the health service delivery (g3), so this relationship can be represented by the arcs from gl->g2->g3. [0045] It will be appreciated that nodes that are not adjacent to any arc of LUR are redundant and can be removed. Referring to Fig. 4, in this example, nodes g2 410, g6 41 1 and r4 412 are redundant. These nodes do not play any function in the present RBAC model GM. Their removal can be illustrated by Fig. 5. In the present hospital example, all members of the hospital services group (g2, 410) are also members of the health service delivery (g3, 420) but the hospital service group has no additional roles. Since all members of the hospital administrators group are also members of the other group, the RBAC model does not require the hospital services group to efficiently access role and privilege information for those users.

[0046] Referring to Fig. 5, a new graph, GM 500, can be established by removing the redundant nodes and arcs. The steps utilised in removing redundant arcs and the removal of redundant nodes is now described more formally. It will be appreciated that these algorithms can be used in building the initial RBAC model and also in maintaining the model after changes are made, such as adding new users, groups or roles, changing groups or roles, or removing groups or roles.

[0047] A more formal description of this process of removing redundant arcs can be expressed using the following notation:

RedAx Denotes a set of redundant arcs of a graph Gx.

Gx Denotes a new graph after removing RedAx from Gx TCx∞ TCx Denotes a self join of the transitive closure graph, TCx, as

{(x,z)| TCχ (x,y) Λ TC_x (y,z)}

[0048] It will be appreciated that all of the above graphs, Gx and Gx, can represent a group, role or model graphs (i.e. X can be U, R, or M). Therefore, redundant arcs, RedAx, can be defined as:

RedAu Group Graph, Gu, RedAu = TC₁T TCu, and Gu = Gu - RedAu

RedA_R Role Graph, G_R, RedA_R = TC_R∞ TC_R, and QR = G_R - RedA_R

RedA_M Model Graph, G_M, RedA_M = TC_M ^M TC_M, and GM = G_M - RedA_M

[0049] In this present example this operation of removing a set of redundant arcs, expressed as dotted arcs in Fig. 3, is the self join of TCM, i-e. TCM^M TCM- Removing TCM^M TCM from Fig. 3, results in a model graph GM as shown in Fig. 4. [0050] A more formal description of the process of removing redundant nodes can be expressed using the following notation:

RedNx Denotes a set of redundant nodes of Gx.

G_χ Denotes a new graph after removing RedNx from Gx [0051] It will again be appreciated that all of the above graphs, Gx and Gx, can represent a group, role or model graphs (i.e. X can be U, R, or M). In the case of a group graph, a transitive closure graph, TCu, is defined as:

ICu

RedNu(y))} and the new group graph, Gu, can be defined as

Gu=JCv - IC₁T ICu

[0052] In the present example this operation of removing a set of redundant nodes in Gu can be performed.

[0053] Referring to Fig. 6, denoting RedNu={g2,g6} and TCu as the transitive closure of group graph 600, then TCu is a set of arcs (610, 611, 612, 613).

[0054] For the Role Graph, G_R, the transitive closure of TC_R, can be defined as, IC_R = {(x,y)| TC_R(x,y)Λ^(RedN_R(x)v RedN_R(y))}.

Wherein the set of arcs (x,y) where x and y are not redundant. The graph GR can then be defined as:

G_R=JO_R - TC_R ^X TC_R

[0055] Referring to Fig. 7, by way of example, a Model Graph G_M and G_M can be expressed whereby RedNM = {g2,g4₅g6.r4,r5}, using

TCM = {(x,y)| TC_M(x,y)Λ ^(RedN_M(x)v RedN_M(y))}

[0056] It would be appreciated that the version of the RBAC model, GM, expressed in Fig. 7 is different to that expressed in Fig. 5. In the present RBAC model the set of redundant nodes, RedN_M, are {g2₅g4,g6.r4,r5}, represented by nodes 710, 711, 712, 713 and 714 respecively. [0057] Fig. 8 shows the transitive closure TC_M of model GM 800 expressed in Fig. 7. It would be appreciated that the set of dotted or dashed arcs of Fig. 8 (represented by arc 810, 811, 812 and 813), is equal to TCM* TCM, and are redundant. Fig.9 shows the resulting model G_M 900, after removing redundant arcs from the graph of Fig. 8 (i.e., IC_M* IC_M).

[0058] The step of finding Gu (as TCu - RedAu) can proceed. The result for this example is shown in the table below.

[0059] Support for Common RBAC questions. In an embodiment the RBAC model G_M can be maintained, at least in part, by maintaining:

(a) Gu, G_R and L_UR

(b) TCu and TCR

[0060] It would be appreciated that, by way of example, the transitive closure of G_M, TC_M, can be computed from TCu, TC_R and L_UR by the following formula:

TCM = TCu u TCR U L_UR U TC_U* LUR U L_UR* TCR U TC₁T L_UR* TCR

[0061] It would be further appreciated that by maintaining these transitive closure graphs, a relatively simple method of asking questions, which systems typically ask of RBAC models, is provided.

[0062] For example, a set of privileges of group 'g' can access can be expressed as:

u{r|TCu(g, X) * L_UR(X, r)}.

Whereby, referring to Fig. 4, the above formula can be instantiated for group 'gl ' as:

{rl }u{ r5}u{ r3}u {r6}. [0063] For example, a set of users of role 'r' can be accessed:

u{g|TCu(g, X) * L_UR(X, r)}. Whereby, referring to Fig. 4, the above formula can be instantiated for role 'r3' as:

{g3}u {g9}. [0064] For example, a set of roles of group 'g' can access an be expressed as:

{r,r'|TCu(g, X) - L_UR(X, r); TC_R(r, r') }.

[0065] Whereby, referring to Fig. 4, the above formula can be instantiated for group 'gl ' as:

{rl, r5, r3, r6, r3}

[0066] It would be appreciated that the above queries are relatively straight forward queries to a database holding an RBAC model. Current RBAC models can further require either recursively tracing targets from a given group (role) or need back tracking through a graph.

[0067] A number of further maintenance operations are taught. It would be appreciated that these maintenance operations can be performed in combination with the above base operations. These maintenance operations include > Adding or deleting a node.

> Adding or deleting a set of assignments from L_UR.

> Adding or deleting a user (to or from a group).

> Adding or deleting a privilege (to or from a role).

> Removing redundancy from a set of conflict constraints. [0068] Adding a node typically result from an action including either adding a group or role to the RBAC model. Once a node is added the hierarchical structure of the appropriate graph, Gu or G_R, can require updating. Therefore, a method of adding a node can require the three steps of:

> associating groups with roles, (change the assignment graph, LUR) > generating differential hierarchy relationships, and

> removing redundant arcs.

[0069] Therefore it would be appreciated that this is a localised change to a sub tree of the hierarchy of the graph, and hence only a part of the model may need t be recalculated. [0070] Deleting a node typically results from an action including either the deletion of a group or role from the RBAC model. Once a node is deleted from the hierarchical structure of the appropriate graph, Gu or G_R, will require updating. Since this will not result in new arcs or nodes, the result of deleting a node will be to delete adjacent arcs of L_UR and to connect nodes whose reachability has been affected, i.e. to maintain the hierarchical structure of the graph. Therefore, a method of deleting a node can require the two steps of:

> removing the node and adjacent arcs; and

> connecting nodes whose reachability was affected. [0071] Adding or deleting a set of assignments from L_UR typically can occurs when a group is given additional roles or a role is removed from a group. This procedure will not affect the hierarchical structure of the graphs, but may result in the need to remove arcs from the graph which are redundant.

[0072] Adding (or deleting) a user to (or from) a group typically results in a change to the hierarchical structure of the group graph, Gu- In particular, groups that have been removed from a hierarchy as being redundant may need to be recovered. An algorithm for adding (or deleting) a user to (or from) a group can include the steps of first deleting the group and then inserting the new group with the updated user.

[0073] Adding (or deleting) a privilege to (or from) a role typically results in a change to the hierarchical structure of a role graph, G_R. An algorithm for adding (or deleting) a privilege to (or from) a role can include the steps of first deleting the role and then inserting the new role with the modified privilege.

[0074] Removing redundancy from a set of conflict constraints is also taught. It would be appreciated that the previous work has defined a taxonomy of conflict constraints which alter the way in which a RBAC model works. In the context of the RBAC model described in a preferred embodiment, it is desirable to be able to remove redundant conflict constraints from final graphs. The removal of a redundant tuple from the conflict constraint sets (Cxx) can be expressed by the following formulas:

[0075] It will be appreciated that removal of redundant conflict constraints can make the enforcement of these conflicts more efficient. For example, the set of redundant role- role conflicts (RedACrr) can be expressed as: RedACrr= Crr n (TC_R ^■* Crr u TC_R ^■» Crr *^■ TC_R U Crr ^«■ TC_R)

[0076] Removing redundancy from a set of conflict constraints can result in a much smaller set of conflict constraints to check.

[0077] Referring to Fig.lO, by way of example, a Role Graph G_R 1000 is shown. Assuming Crr = {(r3; r4), (r4; r5), (r3; r5), (r7; r4), (r7; r6)} (represented by arcs 1010, 1011, 1012, 1020 and 1021 respectively) the set of redundant conflict constraints, RedACrr, can be expressed as {(r7; r4), (r7; r6)} (represented by arcs 1020 and 1021 respectively). In this example, the enforcement of conflict constraints of Crr - RedACrr is more efficient than that of Crr as the former is smaller than the later.

[0078] The forgoing describes preferred forms of the present invention. Modifications, obvious to those skilled in the art can be made thereto without departing from the scope of the invention.

[0079] Referring to Fig. 12, an example schematic of a system adapted to perform a method as previously described. By way of example, an embodiment of a system can include an input module 1210 adapted to receive a question or data indicative of a graph from a database, and a processor 1220 adapted to perform a method as previously described. In an embodiment the processor can receive further input from a memory module 1230 coupled to the processor. The processor typically produces an output with is then provided to an output module 1215. This output module can be adapted to provide an output to a user or transmit a result to a database for later retrieval. It would be appreciated that in an embodiment, a memory module can include a database containing data indicative of a graph.

[0080] Methodologies described herein are, in one embodiment, performable by one or more processors that accept computer-readable (also called machine-readable) code containing a set of instructions that when executed by one or more of the processors carry out at least one of the methods described herein. Any processor capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken is included. Thus, one example is a typical processing system that includes one or more processors. Each processor may include one or more of a CPU, a graphics processing unit, and a programmable DSP unit. The processing system further may include a memory subsystem including main RAM and/or a static RAM, and/or ROM. A bus subsystem may be included for communicating between the components. The processing system further may be a distributed processing system with processors coupled by a network. If the processing system requires a display, such a display may be included, e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT) display. If manual data entry is required, the processing system also includes an input device such as one or more of an alphanumeric input unit such as a keyboard, a pointing control device such as a mouse, and so forth. The term memory unit as used herein, if clear from the context and unless explicitly stated otherwise, also encompasses a storage system such as a disk drive unit. The processing system in some configurations may include a network interface device. The memory subsystem thus includes a computer- readable carrier medium that carries computer-readable code (e.g., software) including a set of instructions to cause performing, when executed by one or more processors, one of more of the methods described herein. Note that when the method includes several elements, e.g., several steps, no ordering of such elements is implied, unless specifically stated. The software may reside in the hard disk, or may also reside, completely or at least partially, within the RAM and/or within the processor during execution thereof by the computer system. Thus, the memory and the processor also constitute computer- readable carrier medium carrying computer-readable code. Furthermore, a computer- readable carrier medium may form, or be included in a computer program product.

[0081] In alternative embodiments, the one or more processors operate as a standalone device or may be connected, e.g., networked to other processor(s), in a networked deployment, the one or more processors may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to- peer or distributed network environment. The one or more processors may form a personal computer (PC), a tablet PC, a set -top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.

[0082] Note that while the diagrams only shows a single processor and a single memory that carries the computer-readable code, those in the art will understand that many of the components described above are included, but not explicitly shown or described in order not to obscure the inventive aspect. For example, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[0083] Thus, one embodiment of each of the methods described herein is in the form of a computer-readable carrier medium carrying a set of instructions, e.g., a computer program that are for execution on one or more processors, e.g., one or more processors that are part of whatever the device is, as appropriate. Thus, as will be appreciated by those skilled in the art, embodiments of the present invention may be embodied as a method, an apparatus such as a special purpose apparatus, an apparatus such as a data processing system, or a computer-readable carrier medium, e.g., a computer program product. The computer-readable carrier medium carries computer readable code including a set of instructions that when executed on one or more processors cause the processor or processors to implement a method. Accordingly, aspects of the present invention may take the form of a method, an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of carrier medium (e.g., a computer program product on a computer-readable storage medium) carrying computer- readable program code embodied in the medium.

[0084] The software may further be transmitted or received over a network via a network interface device. While the carrier medium is shown in an exemplary embodiment to be a single medium, the term "carrier medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term "carrier medium" shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by one or more of the processors and that cause the one or more processors to perform any one or more of the methodologies of the present invention. A carrier medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical, magnetic disks, and magneto-optical disks. Volatile media includes dynamic memory, such as main memory. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise a bus subsystem. Transmission media also may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications. For example, the term "carrier medium" shall accordingly be taken to included, but not be limited to, solid-state memories, a computer product embodied in optical and magnetic media, a medium bearing a propagated signal detectable by at least one processor of one or more processors and representing a set of instructions that when executed implement a method, a carrier wave bearing a propagated signal detectable by at least one processor of the one or more processors and representing the set of instructions a propagated signal and representing the set of instructions, and a transmission medium in a network bearing a propagated signal detectable by at least one processor of the one or more processors and representing the set of instructions.

[0085] It will be understood that the steps of methods discussed are performed in one embodiment by an appropriate processor (or processors) of a processing (i.e., computer) system executing instructions (computer-readable code) stored in storage. It will also be understood that the invention is not limited to any particular implementation or programming technique and that the invention may be implemented using any appropriate techniques for implementing the functionality described herein. The invention is not limited to any particular programming language or operating system.

[0086] Unless the context clearly requires otherwise, throughout the description and the claims, the words "comprise", "comprising", and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in the sense of "including, but not limited to".

[0087] As used herein, unless otherwise specified the use of the ordinal adjectives "first", "second", "third", etc., to describe a common object, merely indicate that different instances of like objects are being referred to, and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner.

[0088] Reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment, but may refer to the same embodiment. Furthermore, the particular features, structures or characteristics may be combined in any suitable manner, as would be apparent to one of ordinary skill in the art from this disclosure, in one or more embodiments.

[0089] Similarly it should be appreciated that in the above description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the Detailed Description are hereby expressly incorporated into this Detailed Description, with each claim standing on its own as a separate embodiment of this invention. [0090] Furthermore, while some embodiments described herein include some but not other features included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the invention, and form different embodiments, as would be understood by those in the art. For example, in the following claims, any of the claimed embodiments can be used in any combination.

[0091] Furthermore, some of the embodiments are described herein as a method or combination of elements of a method that can be implemented by a processor of a computer system or by other means of carrying out the function. Thus, a processor with the necessary instructions for carrying out such a method or element of a method forms a means for carrying out the method or element of a method. Furthermore, an element described herein of an apparatus embodiment is an example of a means for carrying out the function performed by the element for the purpose of carrying out the invention.

[0092] In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

Claims

THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS:-

1. A method of creating a role based access control model for use in determining the grant of privileges of a set of groups having a set of roles, said method including the steps of: (a) defining a group graph and a role graph;

(b) assigning groups within said group graph to predetermined roles within said role graph;

(c) building a model graph by combining said group graph, said role graph and said assignment of groups to roles; (d) removing redundant elements from said model graph to produce a role based access control graph;

(e) utilising said role based access control graph as said role based access control model.

2. A method according to claim 1 wherein said redundant elements of said model graph include one or more selected from the group comprising a redundant arc and a redundant node.

3. A method according to any one of the preceding claims wherein said step (a) further includes forming the transitive closure of the group graph and role graph and said step (d) further includes utilising said transitive closures to determine redundant elements of said model graph.

4. A method according to claim 3 wherein said step (d) includes computing the transitive closure of said model graph from the transitive closure of said group graph and said role graph.

5. A method according to any one of the preceding claims wherein said steps are carried out utilising first order logic predicates.

6. A method according to claim 5 wherein said first order logic predicates are formed as SQL queries.

7. A method according to any one of the preceding claims further comprising the step of performing operational queries on said role access control graph.

8. A method according to any one of the preceding claims further comprising the steps of performing maintenance operations on said role bases access control graph, said maintenance operations including at least one of: adding a node; deleting a node; adding a set of assignments from LUR; deleting a set of assignments from LUR; adding a user to a group; deleting a user from a group; adding a privilege to a role; deleting a privilege from a role; and removing redundancy from a set of conflict constraints.

9. A method of creating a role based access control model, substantially as herein described with reference to any one of the embodiments of the invention illustrated in the accompanying drawings and/or examples.

10. A system for creating a role based access control model to use in determining the grant of privileges of a set of groups having a set of roles, said system adapted to perform a method according to any one of the preceding claims.

11. A system for creating a role based access control model to use in determining the grant of privileges of a set of groups having a set of roles, said system including: a processor adapted to receive data indicative of a group graph, a role graph, and an assignment of groups within said group graph to predetermined roles within said role graph; said processor further adapted to build a model graph by combining said group graph, said role graph and said assignment of groups to roles, and remove redundant elements from said model graph to produce a role based access control graph; said processor further adapted to utilise said role based access control graph as said role based access control model.

12. A system according to claiml 1 wherein said processor is further adapted to performing maintenance operations on said role bases access control graph, said maintenance operations including at least one of: adding a node; deleting a node; adding a set of assignments from LUR; deleting a set of assignments from LUR; adding a user to a group; deleting a user from a group; adding a privilege to a role; deleting a privilege from a role; and removing redundancy from a set of conflict constraints.

13. A system for creating a role based access control model, substantially as herein described with reference to any one of the embodiments of the invention illustrated in the accompanying drawings and/or examples.