Towards a Rule-based Access Control Framework for Distributed Information Systems

Transcription

1 Towards a Rule-based Access Control Framework for Distributed Information Systems Sergey Afonin Institute of Mechanics, Moscow State University Michurinskij av., 1, Moscow, Russian Federation serg@msu.ru Abstract Rule-based access control is a powerful and flexible paradigm for specifying security policies in information systems. Access may be granted or denied depending on object s and subject s properties, or the context of the request, such as current time. Complex access control rules are typically implemented at application level. In this paper we describe a framework targeted to separation of access control rules from the main application logic. It is assumed that access policies are managed in a distributed fashion (discretionary access control), objects are stored in relational database, and requests are independent. Such assumptions correspond to a RESTful web application. We describe a proof of concept implementation and discuss efficiency and decidability issues of access checking and policy verification problems. I. INTRODUCTION In many information systems access control rules are hardcoded into main application logic. This is typically so for Web-centric systems. When page request arrives, the server first validates that the requested operation can be executed by the requester. Application level access control rules could be quite complex and depend on various parameters, including object s and subject s properties and context of the request. For example, one can define that a user is allowed to modify document if he belongs to some group (subject s property) and the document was signed (object s property) no more than two days ago (request context). Such rules can be easily implemented in the target programming language (PHP, Python, Ruby or Java in case of web application) and typical application contains code like return an error message when access conditions are not met, or process the request. The obvious drawback of hard-coded access control rules is that application code should be altered each time the security policy changes. Any modification of the source code, in turn, requires repeated testing, and so on. Moreover, if access control rules are implemented in a Turing-complete language one can not automatically validate any non-trivial property of the implemented security policy. Classical and the most frequently used in real systems Role-based Access Control (RBAC) model [1] separates application logic form users grouping. It is based on the assumption that roles of an organization are static, while users and their responsibilities might change frequently. RBAC standard provides mechanisms for reducing cost and potential for errors when assigning users to roles within an organization. Static nature of RBAC model makes it less useful for web applications characterized by dynamic access control rules. In basic RBAC model it is difficult to express many natural constraints, such as rule registered users can modify their own objects. In order to overcome limitations of RBAC model, a number of extensions have been proposed in the literature. These extensions form an actively developing research area frequently referenced to as attribute-based access control (ABAC) or rule-based access control, allow one to specify security policy by means of rules that depend on application level objects attributes. According to [2], [3] such extensions fall into following three classes: Dynamic roles. Roles are assigned to user dynamically, depending on user s and/or context s attributes. Attribute-centric. Roles are considered as subject s attributes. In contrast to RBAC model this approach does not assume permission to role relation. Role-centric. Attributes are used to constrain RBAC roles. Constraint rules can only reduce user s permissions. Rule-based access control appears in many domains, including information systems, database systems, GRID and Cloud computing, Linux kernel, social networks, XML document-security and many others, see e.g. [4] [9]. For the moment there exists no commonly adopted model for attributebased access control. In this paper we discuss a framework motivated by the development of a real system. We believe that methods and tools could be abstracted from the needs of that particular system, yielding a general framework suitable for wide class of information systems. Our goals are: separation of security policy from application logic and ability to perform static analysis of the policy. It is worth noting that development of a general rule-based security framework requires number of complex issues to be solved. First of all, security policy should be defined in terms of application-level objects, so a kind of object-relational mapping (ORM) have to be supported. In many research, e.g. [5], [10], rules can use fixed number of application level objects properties, and these properties are computed by dedicated functions or services written in general purpose programming languages. Application developers need to implement appropriate set of functions, so this approach can not be considered as a general solution. The second issue that should be addressed, is the efficiency of an on-line permission checker. As final decision depends on database state, permission checks might produce undesirable database workload, so permission checker s efficiency may be measured in terms of number of database queries. Finally, static validation of specified policy for redundant or conflicting rules, similar to [11], [12], has to be done MIPRO 2015/ISS

2 The paper is organized as follows. Next section contains brief description of key properties of information system that triggered this research. We also formulate main goals of the proposed security framework. In Section III we describe rule definition language. Algorithmic issues related to policy enforcement and verification are discussed in Section IV. II. A. Motivating Example MOTIVATION AND GOALS This research was motivated by the development of a Current Research Information System named ISTINA 1 for Moscow State University. Let us briefly describe its properties and security-related issues. The system is used to collect information about research and teaching activities (publications, research projects, participation in scientific conferences, membership in program committees, awards, etc.) of university s staff. Some information, such as list of publications in scientific journals, may be imported or verified by accessing external resources, but significant amounts of data are not available from other sources in unified form. As a result, researchers registered in the system are allowed to maintain their own pages. In order to perform more or less reliable scientometric reporting, most critical information is manually verified by authorized users. An authorized user can modify any object authored by anybody from his area of responsibility. Our access control rules are heavily based on authorship relations, object s ownership information, and organization hierarchical structure. For example, an article can be edited by any of its authors, or an authorized user can modify any object created or authored by researchers from his department or its child departments. Some information, such as financial data, may be inaccessible to anybody but authorized users. Role membership, e.g. who are considered as authorized user, may be parameterized by department or other data. For example, membership of a user in administrative staff role is limited to department and its descendant departments. Both permissive (or positive) and restrictive (or negative) rules, defining who are allowed (or not allowed) to perform an operation on specified object are used. Access to individual objects should also be managed. For example, one can grant or revoke editing permissions on specific object to someone who is not in the list of authors, or in the authors list, respectively. Time constrained access is also important, for example, when an administrator wants to be sure that no objects will be modified after the specified deadline. Another usage scenario of the security framework is related to reporting subsystem [13]. Roughly speaking, a report is a parameterized SQL query. Depending on supplied parameters values, a user may be granted access to the report, or not. For example, a dean can access data about his department and its parts, but should not access information about other departments. In both cases, the same report is requested, and this problem can not be resolved by standard access control approaches. In this paper we address only one scenario when all access requests are treated independently and each request is 1 performed on only one object. In other words, there is no interaction between subsequent requests from the same user. This assumption is reasonable for RESTful web applications. If a web page contains information collected from several objects, then this page may be protected as a whole. It is assumed that each department, or each university that uses the system, can define its own security policy and these policies are managed independently. This distributed nature can produce conflicts in case of joint work. For example, if department A allows anybody to delete any object, and department B does not allow to delete objects at all, is it possible to delete a paper authored by researchers from both A and B? At runtime restrictive rule would take precedence as a safer option, but system s behavior will be surprising for some users, regardless of the decision made. Finally, some rules of the policy defined at top administrative level, e.g. university, may be redefined on lower levels, e.g. faculties and departments. The list of rules that may be redefined or overwritten by a subordinate policy writers should be defined by the top level administrator. From the other hand, policy writers from hierarchically unrelated administrative units could produce any rules. Policy conflicts, similar to conflicts caused by coauthored objects, arise when a user has relation to several administrative domain, for example, as a coworker in two institutions. Such conflicts should be resolved dynamically (at runtime), or statically, during policy validation step. B. Goals and Requirements The main goals of the security framework are: Separation of access control logic from application s code. Modifications of security policy should not lead to any changes in application s source code. Static policy checking. In a distributed environment, when several organizations manage their own policies affecting common database, an automated testing for potential conflicts should be possible. It is assumed that application developers provide atomic permissions that are checked in appropriate points. For example, if a user sends a request for object deletion, then application checks that this user can delete this object by issuing function like has_permission(user, object, "delete"). If an object consists of several parts, e.g. paper title and authorship information, access to that parts could be controlled by additional rules and verified by dedicated calls to above mentioned function. For example, a policy could specify that every author of a paper can update title, abstract, and his own authorship information but can not update information about his coauthors. In any case, all checks for specific permissions must be hard-coded, because providing fine-grained access to object s parts can not be realized without programming efforts. Specific security policy should not be defined or implemented in application s source code. When application calls has permission function providing it with information about MIPRO 2015/ISS 1545

3 current user, object and requested operation, that function should perform all necessary checks in accordance to specified policy. In order to guarantee policy enforcement, such calls to has permission function may be performed automatically when the request arrives to application server. This can be done by variety of means, including preprocessing of incoming HTTP requests, defining appropriate middleware of application server framework, or using programming language tools, such as Python s function decorators. The actual implementation of policy enforcement in real application depends on available software or hardware tools, and should be as much mandatory as possible. Another typical problem that arise in Web-centric information system is generation of links available to the user. If user has no rights to perform some operation, e.g. object deletion, then it should be reflected by user interface, for example, by removing or disabling corresponding links. Clearly, generation of a set of active links can be done on top of has permission function. From the other hand, if we know that several permissions have to be checked in a row a more efficient solution could exists. So, from the programming point of view, the framework should support two functions: check for specified permission, and list of all operations that user can perform on given object. Input parameters for check operation are subject (user), object, and requested operation label (required permission). Second function returns list of valid operations for given user and object. We can also specify following additional requirements: rules should be defined in a human-friendly formal language (XML-based languages, such as XACML, is not a suitable option); both permissive and restrictive rule should be supported; if an access is denied, then it should be possible to identify the rule leading to that decision; modification of security policy should be controlled by the same access control system. administrative domains should be separated in the sense that policy writer from one organization can not specify a policy affecting another organization; all conflicts, caused by existence of coauthored objects or coworkers, should be identified at runtime, or discovered statically. III. RULE DEFINITION LANGUAGE As access rule may refer to object s attributes, rule definition language consists of three parts: definition of objects, roles, and rules itself. First part defines set of entities, attributes and relations that can be used in other parts. Parameterized roles are listed in roles definition. Access control rules defines under what constraint a user has permission to evaluate action on specified object. Our proof of concept implementation is performed in Common Lisp (due to Lisp s ability of rapid development of domain specific languages), so we use lisp-friendly syntax for all three parts. A. Definition of Objects and Attributes Objects definition is a kind of Object-Relational Mapping that reflects database structure. Each statement in this section defines an object an access control entity. In terms of target application, objects correspond to a classes or types. In order to simplify descriptions in our proof of concept implementation we associate an object with database table only. (defobject department (table department)) All other relevant information, including attributes, identifiers and related objects, is extracted from the database dictionary. If a table associated with object A contains a foreign key to a table of object B, then an attribute named As (plural form of A s name) is added to B. It is assumed that every database table is equipped with surrogate primary key, so foreign key references are simply integers. In addition to database table name, a list of possible operations on that object can also be specified: (defobject article (table article) (operations (read update delete))) This definition means that only that three operations are relevant for article objects. B. Roles In many applications, user s membership in a role depends on administrative structure of organization, or other parameters. Technically, one can specify the set of roles as a Cartesian product of real roles by departments and manage hierarchical department s structure by means of roles inclusion. Clearly, such system is extremely difficult to support and security policy has to be modified every time department s structure changes. In this work we adopt notion of parameterized roles. Userto-role relation is computed dynamically because the decision on whether or not a user belongs to a role depends on current state of the database. Roles are defined by the following statement. (defrole dean (parameters department)) ;; membership is limited to department C. Rules Rules are used to define conditions what should be satisfied in order to perform operation on object. In terms of [2] this models follows role-centric approach: attributes are used to constraint permissions assigned to roles. Each rule is characterized by: 1546 MIPRO 2015/ISS

4 access type (allow/deny), associated object, list of operations, grantees (roles or users), and access conditions. Formal grammar for rule definitions is presented in Table I. For the lack of simplicity some syntactic sugar constructions are omitted. Let us consider the following example: (rule (comment "Delete articles.") (access allow) ;; allow/deny (object type "article" alias "a") (operations ("delete")) (grantees (roles "admin" ("dean" a.authors.department)) (users "root")) (conditions (and (= a.journal.publisher.name "Springer") (< 2010 a.year)))) Here we define that user root or any member of dean or admin roles are allowed to delete articles that were published in Springer s journals after year The role dean is a parameterized role, so not every dean can delete articles: at least one author of the article should be from the dean s department. When this rule is evaluated during permission checking procedure, object alias a is assigned to the object from user s request. Similarly, a predefined name user is assigned to the structure representing the requester. Two points should be noted. First, a rule may be associated with a parameterized role, and values of role s parameters are related to target object s attributes. Second, conditions part of the definition consists of a list of logical expressions that define conditions required for treating this rule as applicable to given object. Each atomic expression has form (relational-operator operand operand). Operands are XPath-like expressions defining access path to desired property of target object. The above example may be rewritten as a oneliner: (= a[year > 2010].journal.publisher.name "Springer") Here, filtering condition [year > 2010] applied to the object. Filtering condition may contain standard logical connectors and may refer to deeper attributes by means of dot notation. Possibility to overwrite a rule in subordinate administrative unit is controlled like in [10]: a rule has special boolean property strict that states whether or not this particular rule can be redefined. The value of this property itself can be redefined (lowered from True to False) by a subordinate writer. It should be noted that set of objects affected by top-level and low-level rules may differ due to differences in specified RULE ::= (rule { ( clause ) } ) clause ::= comment string object type string [ alias string] access ( allow deny ) operations ( operation {operation} ) grantees ( grantee {grantee} ) strict [ True False ] condition ( expr ) operation ::= string grantee ::= (users user {user} ) (roles [role ( role {selector} ) ] ) user ::= string selector ::= ( object alias) [filter] {. attribute [filter] } alias ::= string filter ::= constant relation (attribute [filter] {. attribute [filter] }) ( filter ) filter [ and or ] filter expr ::= ( relation constant selector ) ( [ and or ] expr {expr} ) relation ::= > < = <= >= like in TABLE I. RULE DEFINITION GRAMMAR. constraints. For example, top level constraint may by stated as year > 2010, while lower level rule may be redefined using year > More than one rule may be defined for the same object type. In this case access is granted if there exists at least one rule that allows the access, and there are no rules that denies it. IV. ALGORITHMIC PROBLEMS In order to make the system useful in real situations, a number of algorithmic issues have to be resolved. First of all, due to highly dynamic nature of access control rules and high rate of such operations, efficient access checking methods should be designed. A. Checking for Access In this section we describe a straight forward algorithm for checking access of a user to specified object and discuss possible improvements. The general idea is to find all applicable rules, i.e. rules that are assigned to specified object and user, and verify whether an access should be granted, or denied. Rules are associated to users or roles. In order to compute a set of candidates of applicable rules, i.e. a set containing all correct items and some false positives, membership of the requesting user in roles has to be verified. Membership in a parameterized role depends on current state of the database, so user-to-role relation should be computed dynamically. Given an expression like (grantees (roles ("dean" a.authors.department))), where a stands for a reference to accessed object (effectively, this is the value of a primary key in corresponding database table), one should verify that current user is a member of any roles dean x, where x runs over the set of all departments accessed by path expression a.authors.department. The set of applicable rules candidates consists of all rules associated with such roles. Once the set of candidates is computed, additional constraints imposed by rule s conditions section will be verified MIPRO 2015/ISS 1547

5 for every candidate rule (this step is a subject to optimization). Each condition consists of number of expressions of the form (relational-operator value selector), e.g. (<= a[year = 2011 and journal.name like "Int.*J.*"].issue 2) Such expression can be translated into SQL statement naturally. Dots correspond to table joins, and filtering constraints yield conditions in WHERE clause of the SQL query. Consequently, whole constraints section may be represented as an SQL query. Let us recall that access is granted if and only if there exists at least one positive rule and there are no negative rules for given user, object, and operation. Final decision can be trivially made on basis of applicable rule set. If there exist an applicable rule that denies access, then the finial decision is negative. Otherwise, the decision is positive if an only if the set of applicable rules is not empty. Our proof of concept implementation supports automatic generation of SQL queries for checking rule s conditions and user s membership in parameterized roles. Checking that a rule matches request parameters is performed in statically defined order. First, matching between request s and rule s object and operation is validated. If this string equality check succeeded, role membership and additional access conditions are validated. This order based on assumption that last check is more complex and time consuming, because corresponding SQL query generated from a potentially complex expression. As long as the number of rules associated with each object and operation pair is small, this simple strategy produces reasonable performance: checking one or two extra rules yields only a couple of extra SQL queries. In general, one can expect that the number of rules will increase over time, so more sophisticated algorithm has to be developed. In the rest of this section we discuss possible improved to the described simple strategy. One possible approach to performance optimization based on the observation that, if the access was granted, then all candidates for applicable negative rules had to be checked. It is worth noting that long lists of negative rules could be inefficient in principle. Positive candidate rules have to be checked only until first match occurrence. Choosing the right order of search space exploration can speed up overall performance. Preference may be given to rules that do not require to much time to verify, and yield positive result with high frequency. Both values may be estimated using statistics of previous calls to the same rule. Frequency of positive results reflects the quantity of objects satisfying rule s conditions. Other directions of optimization include: choosing the right order of conditions processing, based on the similar statistics on hit rate and efficiency of SQL queries, and finding common sub-queries in rules and organize rules hierarchically. The latter approach is related to view selection techniques in relational database that allow to identify frequently used patterns in a set of queries. If conditions, or parts of conditions, of two or more rules are similar, they are probably may by approximated from above (with false positives) by a single query. If this generalized query produces negative result, then none of dependent rules can not be evaluated to positive result. Otherwise, some compensation queries are to be evaluated. B. Policy Validation Static validation of security policy is one of the goals of our work. In distributed environment searching for possible conflicts between access rules created by independent administrators is extremely important. Conflicts of two types are possible. Explicit conflict: there exists a triplet (user, object, operation) and two applicable rules such that one rule is positive, and the other one is negative. Implicit conflict: there exists an object, user, and applicable positive rule defined by a subordinate policy writer, such that there exists no applicable positive rule defined by a higher level administrator. Both types of conflicts can be detected at runtime. Dynamic detection is, certainly, a useful feature in practice, but static analysis is required for elimination of possible errors in advance. Methods for static analysis of access control systems were developed for classical RBAC model, e.g. [11], [12]. In [11] authors consider similar problem of collaborative editing of security policy under Administrative RBAC model. The decision problem in this case consists of establishing if a user can be assigned to certain role by a sequence of administrative actions. The problem is reduced to the reachability problem in some infinite transition system. Decision problems for attribute-based models should be harder because wider range of objects should be considered. Searching for explicit conflicts in some cases may be reduces to a well studied NP-complete problem of checking containment of conjunctive query in a union of conjunctive queries [14]. Indeed, suppose we are checking one particular rule for consistence with a policy. A conflict appears if a conjunctive query corresponding to the rule under consideration is not contained in union of all other queries generated by rules defined for the same object. In a more general case, policy checking problem may be reduced to a problem similar to [15]. A conflict appears if some counter-example object can be constructed under the specified policy. V. CONCLUSION In this paper a very basic role-centric attribute-based access control framework, motivated by the development of a real distributed application, is presented. It is targeted to support RESTful web application where each request is treated independently from all previous requests from the same user MIPRO 2015/ISS

6 Attribute-based rules restrict permissions assigned to parameterized roles. Additional constraints, specifying whether or not a rule is applicable to the request, are stated in an XPathlike language that automatically mapped into SQL statements during access checking stage. As access control rules are defined using special language, automated policy validation is possible. We briefly describe possible research directions in the areas of efficient implementation of decision procedure and static policy validation. Despite principal inefficiency of some operation, such as checking an access in presence of large number of negative rules, we believe that the described framework, which is in the very early stage of development at the moment, may be used in wider class of web-based application. REFERENCES [1] D. F. Ferraiolo, J. F. Barkley, and D. R. Kuhn, A role-based access control model and reference implementation within a corporate intranet, ACM Trans. Inf. Syst. Secur., vol. 2, no. 1, pp , Feb [Online]. Available: [2] D. R. Kuhn, E. J. Coyne, and T. R. Weil, Adding attributes to rolebased access control, Computer, no. 6, pp , [3] X. Jin, R. Sandhu, and R. Krishnan, RABAC: Role-centric attributebased access control, in Proceedings of the 6th International Conference on Mathematical Methods, Models and Architectures for Computer Network Security: Computer Network Security, ser. MMM- ACNS 12. Berlin, Heidelberg: Springer-Verlag, 2012, pp [Online]. Available: 8 [4] X. Jin, R. Krishnan, and R. Sandhu, A unified attribute-based access control model covering DAC, MAC and RBAC, in Data and Applications Security and Privacy XXVI, ser. Lecture Notes in Computer Science, N. Cuppens-Boulahia, F. Cuppens, and J. Garcia- Alfaro, Eds. Springer Berlin Heidelberg, 2012, vol. 7371, pp [Online]. Available: 4 [5] J. Fischer, D. Marino, R. Majumdar, and T. Millstein, Finegrained access control with object-sensitive roles, in ECOOP 2009 Object-Oriented Programming, ser. Lecture Notes in Computer Science, S. Drossopoulou, Ed. Springer Berlin Heidelberg, 2009, vol. 5653, pp [Online]. Available: [6] B. Carminati, E. Ferrari, and A. Perego, Rule-based access control for social networks, in On the Move to Meaningful Internet Systems 2006: OTM 2006 Workshops, ser. Lecture Notes in Computer Science, R. Meersman, Z. Tari, and P. Herrero, Eds. Springer Berlin Heidelberg, 2006, vol. 4278, pp [Online]. Available: 80 [7] B. Lang, I. Foster, F. Siebenlist, R. Ananthakrishnan, and T. Freeman, A flexible attribute based access control method for grid computing, Journal of Grid Computing, vol. 7, no. 2, pp , [Online]. Available: [8] E. Yuan and J. Tong, Attributed based access control (ABAC) for Web services, in Web Services, ICWS Proceedings IEEE International Conference on, July 2005, pp [9] J. Crampton and J. Sellwood, Path conditions and principal matching: A new approach to access control, in Proceedings of the 19th ACM Symposium on Access Control Models and Technologies, ser. SACMAT 14. New York, NY, USA: ACM, 2014, pp [Online]. Available: [10] G. Motta and S. Furuie, A contextual role-based access control authorization model for electronic patient record, Information Technology in Biomedicine, IEEE Transactions on, vol. 7, no. 3, pp , Sept [11] S. Ranise, A. Truong, and A. Armando, Boosting model checking to analyse large ARBAC policies, in Security and Trust Management, ser. Lecture Notes in Computer Science, A. Jsang, P. Samarati, and M. Petrocchi, Eds. Springer Berlin Heidelberg, 2013, vol. 7783, pp [Online]. Available: [12] M. Pistoia, S. Fink, R. Flynn, and E. Yahav, When role models have flaws: Static validation of enterprise security policies, in Software Engineering, ICSE th International Conference on, May 2007, pp [13] S. Afonin, A. Kozitsyn, and I. Astapov, SQLReports: Yet another relational database reporting system, in Proceedings of the 9th International Conference on Software Engineering and Applications, 2014, pp [14] Y. E. Ioannidis and R. Ramakrishnan, Containment of conjunctive queries: Beyond relations as sets, ACM Trans. Database Syst., vol. 20, no. 3, pp , Sep [Online]. Available: [15] N. Moore, Computational complexity of the problem of tree generation under fine-grained access control policies, Information and Computation, vol. 209, no. 3, pp , 2011, special Issue: 3rd International Conference on Language and Automata Theory and Applications (LATA 2009). [Online]. Available: MIPRO 2015/ISS 1549