Representation and Reasoning on Role-Based Access Control Policies with Conceptual Graphs

Transcription

1 Representation and Reasoning on Role-Based Access Control Policies with Conceptual Graphs Romuald Thion and Stéphane Coulondre LIRIS: Lyon Research Center for Images and Intelligent Information Systems, Bâtiment Blaise Pascal (501), 20, avenue Albert Einstein, Villeurbanne Cedex, France Abstract. This paper focuses on two aspects of access control: graphical representation and reasoning. Access control policies describe which operations are granted to which users, w.r.t. some resources. The Rolebased access control introduces the concept of role to model user permissions. Currently, there is a need for tools allowing security officers to graphically describe and reason on their policies. Thanks to conceptual graphs, we can provide a consistent graphical formalism for role-based access control policies, which is able to deal with particular features such as role hierarchy and constraints. Moreover, once a policy is modelled by CGs, graph rules and inference procedures can be used to reason on it; This allows security officers to understand why some permissions are granted or not and to detect whether integrity constraints are violated. 1 Introduction Opening our information systems to the world-wide web is really seducing, but highlights a problem which becomes more and more crucial: security. Nowadays, every on-line computer must be equipped with security update agent, firewall, anti-virus software and even anti-spyware, otherwise within a few minutes information system can become the target of automated scanning scripts, hackers, malicious websites, etc.: security is now of main importance. In this paper, we are dealing with a particular aspect of security process: access control. 1.1 Reasoning on access control policies Access control denotes the fact of determining whether a user (process, computer, human user, etc.) is able to perform an operation (read, write, execute, delete, search, etc.) on an resource (a tuple in a database, a table, an object, a file, etc.). An operation right on a resource is called permission. Access control policies describes define the users rights on resources, in order to enforce security of an organization. As a matter of fact, a large part of flaws in information systems are due to administration mistakes or security misconceptions: the number of users is increasing, rules are more and more complex, constraints are introduced to deal

2 2 with border-line cases. As policy engineering is considered to be of high pratical importance [4], we do think there is a need for tools facilitating design and maintenance of security policies, to avoid mistakes and misconceptions. Such tools need to meet several requirements: have an appropriate graphical interface, be able to capture access control model mechanisms and constrainted policies, be able to check consistency of policies, be able to answer queries for particular permissions or relation holdings in the policies, have comprehensible inference mechanism, even by non-logicians. According to [5], we do think that such functionnalities cannot be designed without a proper formal framework. 1.2 Why conceptual graphs? Rather than tailoring a dedicated fragment of first-order logic [6](FOL) or using a pure logic-based approach [5, 4] with traditional resolution methods (such as Robinson principle), we focused on conceptual graphs (CGs) and their dedicated inference procedures. The CGs framework meets the requirements described in section 1.1: CGs is a formal system (using the function Φ gives a straight equivalence in FOL), the CGs support can model complex structures such as hierarchies, individual markers and graph rules are expressive engough to capture authorization mechanisms of access control models, chaining procedures allow direct graphical-based inferences on graphs. This paper presents how to use the conceptual graphs framework to design and infer on Role-Based Access Control (RBAC) policies. CGs applied on RBAC allow graphical representation of policies and graph rules inferences can capture underlying authorization mechanisms and allows reasoning on policies. 2 Fundamentals 2.1 Role Based-Access Control Policies Role-Based Access Control models constitute a family in which permissions are associated with roles (roles can be seen as collections of permissions), and users are made members of appropriate roles. The definition of a role is quoted from [12]: A role is a job function or job title within the organization with some associated semantics regarding the authority and responsibility conferred on a member of the role.

3 3 Figure 1 is common representation of the RBAC model. In this figure, URA is a short for user-role assignment and PRA for permission-role assignment. In the RBAC model, permissions are not directly assigned to users. Thus, access to a resource is granted to a user if he/she endorses a role which is assigned to this permission. The role hierarchy is a way of minimizing the number of roles in RBAC policies: a role specializing another one inherits all its permissions. As the major part of access control decisions is based on user functions or jobs, the introduction of roles greatly simplifies policies management. Since roles in an organization are usually stable with respect to users turnover and tasks reassignment, RBAC provides a powerful mechanism for reducing complexity, cost, and mistakes sometimes entailed by permission management [1]. RBAC was found to be among the most attractive solutions for providing access control in e-commerce, e-government or e-health, and is also a very active research field. However, organizations may involve thousands of roles [10] and administration of RBAC policies can still be complex. Graphical based modelling and reasoning is a step beyond easy-to-use policy administration interfaces and better comprehension of policies. Fig. 1. RBAC Model (no specific formalism) 2.2 Representation and reasoning with conceptual graphs The following definitions are quoted from [11]. A rule R : G 1 G 2 is composed of two CGs G 1 and G 2, respectively called hypothesis and conclusion. There may be co-reference links between concepts of G 1 and G 2. There are no constraints on types for individual markers common to G 1 and G 2 : the type considered in operations is the smallest type that can be associated with the marker. We call a support the structure that represents the ontology for a specific domain application, it is composed a concept type lattice and a relation type set. A knowledge base is composed of a support S, a set of simple CGs (facts), and a set of rules.

4 4 Forward chaining is typically used in order to enrich knowledge base with new facts, implicitly present in the base [11]. It is used to prove a goal graph G goal is implied by a knowledge base KB. Main idea is to calculate the closure of the set of facts of KB by the set of rules of KB. Basic outline of procedure is: chose a rule R from KB, let be G a fact from KB. If G fullfills the hypothesis of R, then the conclusion of R can be added to KB, if it is not already present (to avoid redundant informations), repeat until no new facts can be produced, if there exists a projection from G goal to facts from KB, then G goal is implied by the knowledge base. This knowledge addition principle is the graph dual of bottom-up resolution approach in first-order logic. Backward chaining is typically used to find a linear resolution of a goal (a request). Whereas forward chaining acts from facts to goal, backward chaining is top-down: from conclusion (G goal ) to hypothesis (the facts from KB). Here we use the piece unification [11]. The basic outline of this procedure is: find a rule on which the goal can unify by pieces, remove the piece from the goal, add the specialized rule hypothesis to the goal, which produces a new subgoal, repeat until the subgoal is empty. 3 Conceptual Graphs for RBAC representation and inference In section 2, we described the role-based access control model and we outlined two inference procedures. In this section we present how a knowledge base can model a RBAC policy. A knowledge base is composed of a support S, a set of simple CGs (facts), and a set of rules. 3.1 Modelling basic concepts of RBAC The core elements of RBAC models are described in figure 1. For sake of readability, we do not include sessions (which lead to more complex authorization rules) in examples. Indeed, according to [2], it is possible to model sessions by adding a special relation. The support must include the following concepts and relations: Role concept type, Resource concept type,

5 5 Operation concept type, User concept type, ura of arity 2 (User,Role) relation type, pra of arity 3 (Role,Operation,Resource) relation type. Once the RBAC model is translated into a conceptual graph support, we need to add the different roles, users, operations and resources involved in the policy: for each resource within the policy, add a conformity relation resource id : Resource, for each role within the policy, add a conformity relation role id : Role, for each operation within the policy, add a conformity relation operation id : Operation, for each user within the policy, add a conformity relation user id : User. Fig. 2. user-role and role-permission assignments sample graph Once the basic concepts and relations are created, the next step towards a complete modelling of a RBAC policy (figure 1) is to translate user-role and permission-role assignment. The authorization decision in RBAC is based on user role assingments: a user is granted access to a resource if he/she is assigned to a role which is assigned to this permission (possibly through inheritance). The user-role and permission-role assignments are translated into the knowledge base by a set of simples CGs, called facts. The facts describe which roles are granted to users, and which operations are granted to roles. The figure 2 is an example of these assignments. In this graph, the user Bob is made member

6 6 of roles student and phdstudent (multiple user-role assignment), the user Charly is made member of the role lecturer, and the user Alice is made member of the role postphd. The role teacher is granted write access on resource test and the role student is granted execute access on resource test. Thus, we need to add some facts into the knowledge base: for each permission-role assignment in the policy, add a relation pra between the role, the operation and the resource into the knowledge base, for each user-role assignment in the policy, add a relation ura between the user and his/her roles into the knowledge base. 3.2 Modelling role hierarchy Fig. 3. A sample role hierarchy (no specific formalism) Figure 3 is a sample role hierarchy. For example, a user assigned to a role Sr. Lecturer will be granted every permissions granted to role Lecturer, Teacher and Researcher. Graph rules are used to represent the inheritance relation properties. Direct inheritance (e.g. Lecturer directly inherits permissions from both Teacher and Researcher roles) is modelled by an annex relation seniordirect. The complete inheritance relations are modelled with the senior relation. To model the RBAC inheritance in conceptual graphs, we need to: add the relation type seniordirect of arity 2 (Role,Role) to the support, add the relation type senior of arity 2 (Role,Role) to the support, add an order relation seniordirect < senior, add a graph rule (figure 4) settling that the inheritance relation is reflexive, add a graph rule (figure 5) settling that the inheritance relation is transitive,

7 7 add direct inheritance relations between roles to the knowldedge base (e.g. to model edges in the figure 3). Inheritance is used for authorization decision: a user is granted access to a resource, if he/she is made member of a role which inherits this access (a role also inherits itself). Fig. 4. A role inherits itself Fig. 5. Role inheritance is transitive 3.3 Modelling authorization decision mechanism and specific constraints The last step for modelling RBAC policies is to create a rule in the knowledge base for authorization decision. A user is granted access to a resource if he/she is assigned to a role which is assigned to this permission. Thus, a relation permitted of arity 3 (User, Operation, Resource) is added to the support, modelling which users are granted access. The graph rule given in figure 6 expresses how users are granted access on resources. This rule can be refered to as the core rule of the RBAC model. In the RBAC model, constraints are introduced to reflect peculiarities of organizations. Examples of such constraints are exclusions (e.g. no user can be

8 8 assigned both mutually exclusive roles) and prerequisites (e.g. if a user is assigned to a role in the policy, another user must be assigned prerequisited role, or each user must be assigned to at least one role). Both these constraints type can be modelled by graph rules. Other organization specific constraints can be expressed with CGs. For example, we can add a rule stating that the root role inherits all other ones. Fig. 6. The authorization decision rule 3.4 Reasoning on policies This subsection describes how graph rules inferences can be used to reason on RBAC policies. Our knowledge base includes: a set of concepts, the core elements of RBAC, a set of relation, used to model hierarchy, assignments and authorization, the core relations of RBAC, a set of rules, modelling properties of role inheritance, authorization core rule, constraints, a set of facts, modelling the users, roles, operations, resources and inheritance relations present in the policy. Given a query, graph rules inferences allow security officers (SOs): to know granted permissions,

9 9 to query the policy on more complex statements (e.g. figure 8), to find inconsistencies, to graphically follow the authorization mechanism, to test if adding new facts, new rules or modifying actual permission is coherent. Fig. 7. No user can be permitted both execute and write access on tests Let us consider a SO working on the university toy RBAC policy. Role hierarchy is described in figure 3, facts are pictured in figure 2, rules governing role inheritance and authorization mechanism are included in this knowledge base. The SO is defining constraints on the RBAC policy, to fit as best as possible the policy to his organization. In order to avoid any student from enter his/her own mark on a test, the SO adds the exclusion rule no user can be both granted execute and write access on tests (figure 7). He then runs an inference procedure on his policy to know if this new constraints produces an inconsistency... And it does! Following the steps of the inference, he is able (whitout specific requirements on resolution principle) to understand why this constraint can not be added to the policy. We illustrate here the backward chaining inference procedure, which starts with a graph goal modeling the inconsistency. The procedure is outlined as follows (the complete illustration can be found in annex) : there is an inconsistency if a user is both granted execute and write access on tests (step 1 to step 2), a user is granted access through his/her roles (step 2 to step 4), role student is execute granted access on test (step 4 to step 5) role teacher is write granted access on test (step 4 to step 5), a role inherits permissions of its siblings, role PostPhD inherits both roles student and teacher (step 5 to step 9), Alice is granted role PostPhD (step 9 to step 11),

10 10 thus the policy is not consistent according to the new rule. This example points out how an adequate graphical tool for RBAC policy can be useful for modelling purposes. Without such an inference tool, an SO can happen to add some contraints which can be violated but not detected, until he receives a complain from PostPhD users who may not login in the system anymore. Fig. 8. A sample query 4 Discussion In this paper, we have shown how to use the conceptual graphs framework to design and infer on role-based access control (RBAC) policies. Such inferences can be used to check policies consistency and to answer queries in order to formally test or debug policies. CGs have an appropriate graphical interface useful for specifying policies and especially for explaining inferences to security engineers. 4.1 Graphical representation of Role-Based Access Control Policies In [8], the authors point out that in order to avoid inconsistencies, it is appropriate to have a precise modelling of access control rules (their work is based on RBAC-like examples), and a visual modelling to make administration tasks easier. Their paper compare readability and checking ability of three approaches. The first approach is based on UML. The second model studied is Alloy: a structural modelling language based on first-order logic, for expressing complex structural constraints and behaviour. Finally, the third model is Graph Transformations. It is a graph model where transformation rules, which are rewriting rules, are used to deduce all possible knowledge. When a new constraint (e.g., mutually exclusive roles) is added to a given policy, these models can verify if the resulting policy is inconsistant, and give a counterexample. Nevertheless, the paper mainly focused on constraints: those

11 11 tools do not answer questions such as which roles are allowed to execute this operation on this object, or other more complex queries. Indeed, UML is only a semi-formal model, Allow Constraint Analyser is a consistency checker, and Graph Transformations do not have FOL logical semantics. In [14], the authorization schema is described using Dynamically Types Access Control (DTAC) graphical formalism. The authors aim at graphically represent RBAC schemas. However they do not propose an inference method in order to ask queries or to check for inconsistencies. 4.2 Reasoning on Role-Based Access Control Policies In [2], constraint logic programming (CLP: first order predicate calculus + linear constraints over integers / rationals / reals, e.g., Prolog + CLP library) is used to express and infer on RBAC policy. The authors describe access control programs able to deal with roles hierarchy and objects hierarchy. The authors of [6] describe a fragment of FOL which is tractable and sufficiently expressive to capture policies for many applications. This work is really interesting and points out tractability and complexity results on their logic. Unfortunately, the authors did not investigate deeply some emerging problems when dealing with complex access control models involving abstract container between users and permissions (e.g.: groups, roles, tasks, etc.) and their hierarchies. We do agree with the authors statement about the use of logic programming by non-logicians, but we do not agree that a filling the blank on English sentences interface is sufficient for security administrators. We think that administrators must have a computer-aided software engineering (CASE) interface to design and check policies built on a consistent graphical model. Moreover such CASE should provide a comprehensible reasoning trace, which can be provided through graph operations (e.g. projection of a query onto the set of facts) 4.3 Modelling sessions and Administrative RBAC models For sake of clarity the example exposed in this paper does not include sessions. We are investigating the interest of chase procedure to check RBAC policies involving sessions. For example, using chase procedure we might answer queries like Are the policies consistent for all possible sessions?. Moreover, incorporating the model for administration of roles exposed in [13] is promising for distributed policies verification purpose. 4.4 Modelling role hierarchy using concept lattice One could notice that the conceptual graphs concept lattice might be useful to model the RBAC role hierarchy. While it is indeed well suited for role hierarchy modeling, some problems arise when it comes to describing relations between roles, resources and users. For example, a graph rule is not well-suited for modeling the fact that if a user is assigned two differents roles, then an inconsistency

12 12 holds. Indeed, it may require a coreference link between two generic markers within the same hypothesis, which adds additional graphical elements. We think is it not desirable, however it is still possible. 4.5 Modelling extended RBAC models The RBAC family includes some extensions, for example TRBAC [3], GTR- BAC [7], Context-Sensitive RBAC [9], etc. Such extensions cannot be taken in considerations in the present CGs model. Indeed, it may require the expression of built-in (i.e. whose semantics is hard-coded) concepts and relations such as linear constraints, set constraints, etc. Therefore we plan to study the extension of the CGs graphical formalism and inferences to arbitrary built-in elements. References 1. Ahn, G.-J., Sandhu, R. S.: Role-based authorization constraints specification. ACM Trans. Inf. Syst. Secur. 3 (2000) Barker, S., Stuckey, P. J.: Flexible access control policy specification with constraint logic programming. ACM Trans. Inf. Syst. Secur. 6 (2003) Bertino, E., Bonatti, P. A., Ferrari, E.: TRBAC: A temporal Role-Based Access Control model. ACM Trans. Inf. Syst. Secur. 4 (2001) Bertino, E., Catania, B., Ferrari, E., Perlasca, P.: A logical framework for reasoning about access control models. ACM Trans. Inf. Syst. Secur. 6 (2003) Bonatti, P. A., Samarati, P.: Logics for authorization and security. Logics for Emerging Applications of Databases. (2003) Halpern, J. Y., Weissman, V.: Using first-order logic to reason about policies. CSFW. (2003) Joshi, J., Bertino, E., Latif, U., Ghafoor, A.: A Generalized Temporal Role-Based Access Control model. IEEE Transactions on Knowledge and Data Engineering. 17 (2005) Koch, M., Parisi-Presicce, F.: Visual specifications of policies and their verification. FASE. Lecture Notes in Computer Science 2621 (2003) Kumar, A., Karnik, N. M., Chafle, G.: Context sensitivity in Role-Based Access Control. Operating Systems Review. 36 (2002) Roeckle, H., Schimpf, G., Weidinger, R.: Process-oriented approach for role-finding to implement role-based security administration in a large industrial organization. ACM Workshop on Role-Based Access Control. (2000) Salvat, E., Mugnier, M.-L.: Sound and complete forward and backward chaining of graph rules. ICCS. Lecture Notes in Computer Science 1115 (1996) Sandhu, R. S., Coyne, E. J., Feinstein, H. L., Youman, C. E.: Role-Based Access Control models. IEEE Computer. 29 (1996) Sandhu, R. S., Munawer, Q.: The ARBAC99 model for administration of roles. ACSAC. (1999) Tidswell, J., Potter, J.: A graphical definition of authorization schema in the DTAC model. ACM Symposium on Access Control Models and Technologies. (2001)

13 13 Annex: a graphical backward reasoning We here show the backward inference steps of section 3.4. The dotted lines show the pieces which are removed in every step by application of backward chaining.

14 14