A Model for Access Control Management in Distributed Networks

Transcription

1 A Model for Access Control Management in Distributed Networks Master of Science Thesis Azadeh Bararsani Supervisor/Examiner: Dr. Johan Montelius Royal Institute of Technology (KTH), Stockholm, Sweden, 2006

2

3 Abstract Nature of the networks has migrated from pure client-server nature to distributed networks in which many machines share their resources and functionalities with others. As the resources become distributed in the network, providing security in such systems becomes a challenging problem. What makes the problem interesting is that we would like to provide security for a system that is dynamic and does not have any centralization in its nature. The main challenge about management in such systems is that whether the management of the resources should be distributed or centralized. There have been many efforts to address this problem and there are several solutions available, each of which answers special needs and fits for a specific system. However when it comes to resource providers contribution in managing access to their resources there exists some cases that the current models do not cover very well. As an evolution on this way, we propose a solution that let the providers contribute in managing access to their resources. Though the access management would be distributed in the network, but still there will be the possibility to have an overall view about permissions and resource allocations.

4 Dedicated To My Loving Parents

5

6 Acknowledgement I would like to thank my supervisor and examiner Dr. Johan Montelius, for being such a nice and supportive teacher and friend to me. Despite all my fluctuations through my work, he guided me patiently all the time.

7

8 Table of Contents 1 Introduction 1.1 Motivation Problem Definition Thesis Outline Background 2.1 Peer-to-Peer Networks Authentication Authorization Access Control List (ACL) Role Based Access Control Access Control Policies Policies vs. Security Mechanisms Access Control in Distributed Networks 3.1 Distributed Networks and Access Control Distribution of Policies Centralization of Policies Criteria for Choosing a Proper System Some Current Models Which model to use? The suggested model in this thesis Access Control Standard 4.1 extensible Access Control Markup Language XACML Advantages XACML Framework More on PDP XACML Policies Policy and PolicySet Combining Algorithms Deny-overrides Combining Algorithm Ordered-deny-overrides Combining Algorithm Some Open issues of XACML Fitting in the Desired Model into the Standard i

9 5 Proposed Solution 5.1 Problem Review Distribution of Access Management in XACML More on Distribution of Policies Evaluation of Policies Distribution of Policies and Central Evaluation Multiple Policies for a Resource Combining Policies Administration and Supervision Results and Future Work 6.1 Results Achieved Failures Future Work References Appendix A A.1 Policy Target A.2 Policy Rule ii

10 iii

11 Chapter 1 Introduction 1.1 Motivation As the number of resources 1 grows in the networks, nature of the networks is changing from centralization to distribution of the resources and services. Several computers on the networks may share their resources and form peep-to-peer distributed networks. While we benefit from the various resources availability in the network, managing secure access to those resources becomes a challenging problem. There are many security aspects to be considered when one node in the network asks for accessing another node s resource. Apart from confidentiality and data integrity, it is important to know about the identity of the requester. This is the process of authentication that makes sure that the requester is actually the one who he or she claims to be. A common example for authentication is the usual login mechanism that asks the users for their identity by providing a user name and password. Apart from authenticating the requester it is important to know about whether he or she is allowed to access the requested resources or not, and if allowed what type of access is permissible for him or her. This process, which is called authorization, is necessary to be done after authentication, because then the system knows about the identity of the requester. Therefore it can, based on the defined restrictions for 1 A resource could be anything to which access may need to be controlled, such as a file, an application, a printer, a special service, etc. 1

12 accessing each resource the system, make a decision about whether to grant access to the requester or not. Regarding users authorization, each system and network can define and use its own access control mechanism. However, this makes systems collaboration very hard, specially in the case of distributed networks where nodes from different networks may connect to each other. Therefore using a common standard for managing access control would be a solution to handle communication between different access control systems [14]. In order to address this issue, OASIS 1 has defined extensible Access Control Markup Language (XACML). XACML provides an access control policy language that is for defining restrictions for accessing each resource together with a request and response language. It also provides a framework which uses the policy language. 1.2 Problem Definition Authorization is based on the considerations and restrictions that are defined in each system for resource usages. In non-distributed systems it is natural to consider that point to be the central resource providers. So each user who wants to access a resource queries that central point. Based on the considered restrictions, the central resource provider would decide whether to grant access or not. In distributed networks the resources are not all located on central points, but rather they may belong to different distributed nodes. There is no central point in the nature of the network structure. Though it is possible to consider such a point for controlling the resource assignments, and some models do it [4, 11], it may not always be desired. The reason could simply be that the distributed resource providers may also want to play a role in managing access to their resources. They 1 OASIS (Organization for the Advancement of Structured Information Standards) is a notfor-profit, global consortium that drives the development, convergence, and adoption of security and e-business standards, 2

13 may have their own local restrictions to be considered that the central administration might not be aware of. Moreover the resource providers can reduce the burden of handling the policy management from the central administration. On the other hand, leaving the whole responsibility to the resource providers [3], is not always desired either. There are some cases where the central administration may want to contribute in access management. Or if they do not contribute, they may need to have an overall view about permissions and resource assignments in the system. But if the resource principals manage access to their resources by their own, without any contact with the systems administration, it would be impossible for the administration to have a true view about the resource assignments in the network. The question is how to let the resource providers contribute in managing access to their resources. This thesis provides a model that considers the providers restrictions about accessing their resources, but it does not leave the whole management to them. The central administration, too, can have its own restrictions. This results in a combination of distributed and central management. As a second goal it investigates how to change the model that it prioritizes the local providers decision over that of the administrator. The proposed model uses XACML standard as an access control framework. 1.3 Thesis Outline Chapter 2 describes the technical background of the thesis work. After a brief introduction to distributed networks, it explains about some security issues and then focuses on authorization and different ways of doing it. Chapter 3 talks about access control in distributed networks, reviews some existing models and mentions each one s pros and cons. At the end it points to the suggested model that this thesis work suggests. Chapter 4 introduces the XACML standard and how is handles access control. It points out open issues of this standard that will be later used for the suggested model. Chapter 5 reviews the problem and proposes a solution and 3

14 explains how it covers the required characteristics. Chapter 6 talks about the results of this work and suggests some future works. 4

15 Chapter 2 Background 2.1 Peer-to-Peer Networks Peer-to-peer networks, as the name implies, are networks that all the peers (machines) play the same role. Peer-to-peer networks are different from the clientserver networks where the communication is to and from a central server. In peer-topeer systems, resources are distributed in the network. In many such networks, nodes communicate with each other without interference of any central server, i.e. each node is both client and server to the other nodes. Whenever a node is sharing its resources with other nodes it acts as a server, while later when that same node is using another node s resource it acts as a client. Peer-to-peer networks may consist of nodes from widely heterogeneous systems. Although peer-to-peer networks are mostly known as file-sharing networks, the resources that each peer may share could be either its storage (files) or computation (CPU). The latter is also called grid networks. In this thesis the main focus would be on file-sharing networks, though they share a lot in the concept. Any machine that receives a request for accessing its resource needs to make sure whether it should share its resource with the requester or not. Such assurance is addressed by some security mechanisms in the networks. The resource owner needs both to authenticate the requester and authorize him or her; meaning that it needs to 5

16 make sure if the requester is the one who he or she claims to be (authentication), and also it needs to make sure if the requester has the right to have access to that resource or not (authorization). 2.2 Authentication Authentication is the process of identifying an individual and making sure that an entity is actually the one that he or she claims to be. Authentication does not say any thing about whether the authenticated identity has the right to access a resource or not. Regarding authentication, there are quite a few security mechanisms that give the possibility to authenticate users who want to access resources of the network. Depending on the sensitivity of the data, different methods could be used to provide the level of protection that is needed. 2.3 Authorization Authentication alone could not be enough for granting access to the resources. The fact that you are you does not mean that you have the right to access any resource that you ask for. However you need to be authorized too. Authorization is the process of determining whether an identity has the right to access a resource or not, and based on that, whether the access should be granted or not. Determining about the access rights could be based on several aspects. It could be based on things like identity of the requester or whether the requester has enough qualifications. Moreover, Access control could be based on some environmental aspects like time of requesting, the domain or the IP address of the machine from which the request is coming from, etc. Some systems differentiate between these two types, calling the first type as authorization and the second as access control. However, this context does not separate them. It refers to either authorization or access control as permission i.e. whether one is allowed to be granted access to a resource or not, be it correlated with the identity, or some environmental conditions. 6

17 Authorization, or access control, is the process of determining whether permission should be granted to an entity to use a resource or not. There are some authorization methods available in order to determine if an entity holds a right for a type of access Access Control List (ACL) Access Control List (ACL) is a traditional method for authorization. ACL provides a list of entities along with the resources that they can use, and type of access that they can have to those resources. The list is provided based on the identity of the requester or the process that is making the request. ACLs could be implemented either on a separate central server that others would query it, or it could be implemented on each resource. However, each case has its own problems. Having the list on a separate server is good in the sense that if there are any changes regarding some authorized entities or resource usages, it has to be applied to one place only. For example if a new user joins the network, it is just the central ACL who needs to update its list regarding which resources the new user is authorized to access and what type of access he or she has. Then whenever each resource gets a request from any user it only have to query the central ACL to know whether it should grant access to that resource or not. However, this means that the server is like a bottleneck for keeping the list updated. On the other hand, each resource can have an ACL of its own. This way, in case of any changes in the network, keeping the ACLs updated would be a trouble. Updating messages makes a burden on the network traffic. In addition, having delay in updates may lead to unwanted grants. Using ACLs, whether implementing them centrally or distributed, is not known an efficient solution any more. The reason is that ACL does not cover all the restrictions one may want to apply for accessing a resource. It might be desirable to grant access to entities based on some attributes that they hold, or some other environmental restrictions. For example a resource provider may want to permit 7

18 access to its resource based on time of the request. ACL, as the name implies, consists of list of authorized entities and the resources that they are allowed to access. It grants permission or denies the requests based on the identity of the requester. In other words, it gets user s identity together with the resource being asked and checks it against the list that it possesses, and says whether the access should be granted or not Role Based Access Control Role Based Access Control or RBAC in short, is another approach in access control [2]. In RBAC, users are assigned to different roles, and each role is assigned to some privileges. So the access decisions would be based on the role that each user has. For example, if an RBAC system is used in a hospital, a user that is known as a doctor would have all the privileges that are define for the role of doctor. In RBAC, each user might be assigned to one or more roles, and each role is assigned to one or more privileges Access Control Policies A policy is a set of rules that is considered for accessing a resource. Whenever a request comes for accessing a resource, the corresponding policy for that resource would be checked. A policy has one or some conditions and based on meeting the conditions it decides about whether to grant permission to the requester for accessing a resource or not. Most access control models have some entities: Subject that could be a user or process, Right that could be reading a file or editing it, and Object that is actually the resource, e.g. a file or service. So a policy is about all these entities, plus that it can filters the subjects by some Conditions. Therefore, a policy could be such a combination: Allow subject S to have the right R on the object O under the Condition C. 8

19 Note that policies are related to resources not the requesters. So whenever a requester wants to access a resource, the corresponding policy for that resource is checked before granting access, but not the reverse. Policies could be based on different attributes, i.e. if the requester qualifies some attributes the permission would be granted. This is a more general approach than relying on user s identity (as in ACLs). Moreover attributes could be based on environmental features, e.g. the IP address of the machine that the request is coming from or time of the day that the request is made. In other words, policies select legal requests based on its condition. Therefore, in this thesis work, policies are chosen as a more general way of access control. 2.4 Policies vs. Security Mechanisms A security policy, as we just went through, defines the legal actions for authorized users. However, a security mechanism is the procedure, method or tools that those policies could be enforced. For example, think of a user who is trying to access a specific service on the network. And let s suppose that the requested service has a policy for accessing it. The security mechanism will activate a pop up window on the user s screen for authenticating and authorization of him or her. Therefore, it is the security mechanism that is responsible for performing the authentication and authorization process and then will lead him or her to access that resource if allowed. Access control actually consists of both policies and security mechanisms. In this thesis, the focus is on managing policies for accessing a resource. It does not investigate how the user is actually granted access to the resource, but rather it is about figuring out if the permission should be granted for accessing the resource or not. 9

20 Chapter 3 Access Control in Distributed Networks 3.1 Distributed Networks and Access Control Managing access control in distributed networks is a tough problem, since there is no centralization in the nature of the network. In distributed environments, many nodes may share their resources, and many of those resources might need to consider restrictions for accessing them. So here comes the question of who should take care of the policies and set them up? Should each resource have its own local policy, or should there be a central administration? Where to locate them? And how should we keep them up-to-date? There might be more than one principal regarding one same resource, each of which may want to set its own policy and consideration for that resource. This is especially true in distributed networks. For example owner of a mainframe may want to restrict the run time that each user can have, and the author of a program may like only special users have the possibility to run her code. Therefore, running that specific code on that mainframe needs satisfying two different policies. How to sum up different policies for one same resource is sometimes a challenging problem. In the above example the decision should be made by both policies together, i.e. users allowed by the program s author can run the code on the mainframe on the specific 10

21 time allocated to them. However, there might be some conflicts among the existing policies of a resource. Then it is necessary to decide which policies have priority over the others. Moreover, the policies are better to be set by an entity in the network that knows enough about resources, their restrictions, special resource sensitivities, and also about existing entities, etc., so that it can set up policies appropriately. Therefore, here comes the question of who should take the responsibility of access control policies. There are two main strategies regarding access control. One strategy is to let each resource provider manage access to its resource by itself, or in other words having distribution of policies. The other one is to have a centralized policy system. One can also think of combining these strategies and defining some kind of cooperation. The requirements enforced by the networks make each one be the right choice for different cases. 3.2 Distribution of Policies Resource owners may be reluctant to share their resources if they cannot have any control over their resources. The reason could be that a resource owner does not completely trust the central administration, and it wants to decide about the access to its resources by its own. In addition, resource providers may want to play a role in controlling their resources, not because they do not trust the administrator, but because there might be some immediate local considerations that only the resource owner is aware of, and it should influence the policies considered for accessing that resource. Instead of following the process of informing the central administrator about the new considerations, we can think of giving the resource providers the possibility to define some policies locally. 11

22 3.3 Centralization of Policies Since there might be several principals for one same resource, it is natural to consider policies distribution. However, if there is more than a single policy for accessing a resource, we need to have some kind of centralization for considering all of those policies together and coming up to one result. Also there might be some conflicts among those policies. Applying an algorithm for coming up to a final result would not be possible unless all those policies are evaluated in one point. As an advantage of centralized policy management it should be mentioned that it provides the possibility for the centralized administration to have a global view about available resources and entities of the system. Moreover, it knows about what kind of access permissions each entity holds regarding the resources. In addition, a centralized model can better keep the authentication and authorization information updated. Therefore, it seems that a centralized management can handle setting up policies better than the distributed management model. 3.4 The Criteria for Choosing a Proper Strategy Either to implement distributed or centralized management of access control depends on the characteristics of the specific network and application. There are several considerations that lead a system to define its desired access management model. Among others, these are some factors that are of importance when deciding about which strategy to choose: 1. The resource providers may want to play a role in managing access to their resources. 2. There might be more than one principal regarding some resources, each of which may want to contribute in managing access to that resource. 3. It may happen that the system s administrator also wants to have a role in controlling access to the resources. 12

23 4. It might be desired to have an overall view about the resource allocations in the network. 5. One other point is that neither the resource providers nor the system administrator may want to leave the control completely to the other one. 6. It is desired that the system needs the least possible changes in its configuration when a new user joins the network. 3.5 Some Current Models There are several systems defined that use either centralization or distribution or the combination of both for managing access control. Each model fulfills some of the defined criteria. 1. The Community Authorization Service [5, 15] solves the access management issue by distinguishing authorization and permission. In this model a resource owner creates permissions for accessing its resource, saying that for example the authorized users can access my resource. However this is the central administration who defines users authorization regarding access to the network resources. This prevents the administration to take the whole control of accessing resources, and also take the whole burden of access control from the provider. However, there is the risk that the local providers may misuse their role and imposing the administrator to obey it or the reverse. In order to prevent this and provide more balance, this model adds sanctions and rewards to the system. In brief, it is a centralized management model being controlled by distributed resource providers. 2. The Tivoli Policy Director [11] provides a centralized management model. Such a centralized model has an overall view of the network resources, and this means that it can set up appropriate privileges. In this model, there is no distribution in this solution, which means that the resource providers cannot contribute in managing access to their resources. 13

24 3. Automated Configuration of Grid Services [4] puts a step forward and defines two hierarchies of administration for setting up policies. It gives the lower hierarchy higher priority, so that it would override the other one in case of any conflict between the policy of two hierarchies. The reasoning behind this strategy is the belief that the more local administrator is more likely to know about the restrictions of the resources. However, even though the lower hierarchy is more local than the higher, both are administrators and the real resource providers play no role in managing access control for their resources. 4. Administrative Delegation in XACML [17, 18] explains a controlled policy model by using extensible Access Control Markup Language, which is an access control standard. It addresses administrative control over the resources. In this model, the privileges could be delegated to other entities too. This gives the possibility of defining different levels of administration, starting from the central administration down to the resource providers. However, all the work is under the supervision of the central administration; meaning that the resource owners could only contribute in access management if the central administration permits them for that. 5. GRUBER [8] is an architecture that is defined for resource usage service level agreement (SLA). It addresses the providers' contribution regarding resource usage policy (that is about restrictions of the resources). However, it does not address the resource access policy (that covers authorization of the requesters). 6. The Manager-Agent Delegation (MAD) is a framework that is defined for distributed management applications [11]. The purpose behind this work is again to avoid having a bottleneck for managing the resources. It reduces the central management burden by delegating it to other agents. In this framework, a process that delegates responsibilities to another process is referred to as a MAD manager. The process that receives the delegated responsibilities is referred to as a MAD agent. It enables a manager to transfer the responsibility for performing certain functions to a remote agent. It allows the agent to perform these functions independently of the 14

25 manager's execution, except were coordination is required. Even though this framework involves distribution of management, but it concerns about certain functions rather than the resources that the providers share. 7. After all, most of peer-to-peer file-sharing systems [3] consist of individual administered node. Such systems are completely self-organized, and there is no centralization as the configuration manager. Each resource owner would locally decide about whether to grant access to the coming requests or not. In such systems, it is not possible to have an overall view about resource allocation in the network. Another drawback of this model is that it does not address considering multiple principals for granting access. But it fits for the cases where the resources have only one principal and it wants to handle access permissions to its resource all by its own without any need for centralized control or vision. 3.6 Which model to use? Either to implement distributed or centralized management model for access control, or a combination of both depends on the characteristics of the specific network and the special functionality that is needed. Each of them has its own pros and cons that make it be a proper match for a specific system. Regarding the resource providers contribution, there exists some cases that the existing models do not cover properly. Some of them let the providers contribute after granting the permission by the central administration, which means that though they can play a role in access management, but their contribution is still dependant on the system s central administration. Some others leave the control completely to the providers, making it impossible for the administrator to have a correct picture of rights and resource usages in the systems. Some solutions work for the grid networks, but do not cover the file-sharing networks, and some others only care about resource usage policies and forget about resource access policies. 15

26 3.7 The Defined Model in this Thesis Resource providers may have their own criteria about accessing their resources. After all, the resource providers better know about local restrictions or they might not want to leave the whole control to the central administration. Therefore it is desired to consider their restrictions besides those of the administrator when making decision about access control. This thesis defines a model that gives the resource principals the possibility to define their own restrictions for accessing their resources, either resource usage policies or resource access policies. This could be together with the central administration s criteria as another principal of the resource. In case there are any conflict between the providers permissions and that of the administrator, it would be desirable to override the resource providers permission, since they better know about the local restrictions of the resource. Meanwhile the model gives the central administration the possibility to have an overall view about the resource allocations in the network, whether it participate in defining restrictions for access control or not. As an access control framework, this work uses the XACML standard. The reason why we chose a standard for access control is that it makes it possible to connect different systems together. Before putting the solution into the framework of the standard, we will have a short review on XACML in the coming chapter. 16

27 Chapter 4 Access Control Standard 4.1 extensible Access Control Markup Language extensible Access Control Markup Language or XACML in short, is an OASIS 1 standard that is designed for controlling access to connection of multiple networks. The XACML standard [8] defines both syntax and semantics of an access control language and a framework that the language works within. See Figure 4.1. Access Control Framework XACML Standard Policy Language Access Control Language Request/Response Language Figure 4.1 XACML Standard 1 OASIS (Organization for the Advancement of Structured Information Standards) is a notfor-profit, global consortium that drives the development, convergence, and adoption of security and e-business standards, 17

28 In order to consider restrictions about accessing resources, XACML defines policies. Policies are defined by the special policy language that is provided by the standard. Policy language gives the possibility to define rules for accessing the resources. A policy is simply in the form of who can do what on which resources. In addition, XACML defines another language that is a request-response language that is for expressing the request for accessing a specific resource and type of access, or for presenting the reply back to the requester. 4.2 XACML Advantages There are several advantages in using XACML as an access control framework [1]: It is a standard access control framework. Therefore it has been reviewed by a large community of many experts and users. Moreover, different systems using this standard can connect to each other without worrying about making any changes in their access control structure. XACML provides a generic access control language, which means it could be used for any kind of resource. In addition, it can cover any type of restriction, including authorization restrictions or environmental limitations. Once a policy is defined it can be used by any kind of application. This makes connection of systems very easy. It is a distributed framework; meaning that a policy can refer to other policies that might be in other locations. This gives the possibility to have different policies regarding one same resource managed by different entities. The standard also defines the way how to combine those policies together. It is a powerful standard. It supports a collection of data types, functions and rules. It also has extensions on integrating with other standards such as SAML [19] and LDAP [13]. 18

29 4.3 XACML Framework The typical XACML usage scenario is shown in Figure 4.2. The requesting entity sends a request to whatever is protecting the resource, e.g. a web server or file system. This point is called Policy Enforcement Point (PEP) in XACML standard. The PEP receives the requests and put them in the form of XACML request language. The reason why PEP form the request in the XACML request language is that PEP is in contact with Policy Decision Point (PDP), which understands the requests that are in XACML request language. Access Request (1) Granting Access (6) User PEP Policy Enforcement Point Resource XACML Request (2) XACML Response (5) PDP Policy Decision Point Request for Related Policies (3) Related Policies (4) PAP Policy Administration Point Figure 4.2 XACML Framework PDP, as its name implies, is the point where the decision is made about the coming request for accessing resources. It decides whether the requester should be granted the permission to access a resource or not. PDP makes the decisions based on the policy that is set for accessing that resource. PDP contacts Policy Administration Point (PAP) for getting the corresponding policy. There should be only one policy that applies to the request, otherwise it is an error. 19

30 PAP is actually where the security policies are defined. PAP may store policies in several repositories. However, as we will later talk more about it, the XACML specification [8] does not mention any restriction on location of the policies. Whenever PDP receives a request, it checks it with the corresponding policies and comes up to a decision about whether access should be granted to the requester or not. After making the decision it sends the reply back to the PEP. As the Figure 4.2 shows, PEP is actually on the way between the requester and the resource. Based on the decision, PEP would either grant access to the requester or deny it. It may happen that PEP, PDP and PEP are contained in a single point, or they might be distributed among several servers. Finally, after evaluation, the decision made for a request could be Permit, if the requested access is allowed for that entity, or it could be Deny if that entity is not allowed for having that type of access to the resource. In case where the PDP cannot find any Policy that matches the request, the result would be Indeterminate. After all, if the PDP cannot locate the Policy whose target matches the request, the result would be NotApplicable. 4.4 More on PDP What should not be misunderstood about the PDP is that it does not provide access to the resources, but rather it just makes the decision about which entities are permitted to access the resources. It makes the decision based on the policies that the resource principals have set up beforehand about accessing the resources. So when the PDP receives a request for accessing a resource 1, it checks the policy (policies) for accessing that resource. If it finds that the requester is not authorized to access that resource, it notifies the requester about it (see Figure 4.3). If the requester is known as authorized it passes the request to the resource. This means that no resource 1 Actually this is PEP that receives the requests, put them in the XACML request language and send them to the PDP. The assumption here is that PEP and PDP are combined together. 20

31 provider would receive an access request unless that request has passed through the PDP server. So the requester has the permission to access that resource. Then the resource provider would offer the requester the requested resource without interference of the server (see Figure 4.4). B A Request for Accessing B s Resource (1) You are not allowed to Access B s Resource (2) PDP Server Figure 4.3 A asks for accessing B s resource (1). Since A is not authorized to access B s resource, PDP server sends a negative response back to A (2). Offering the Resource (3) B Passing A s Request to B (2) A Request for Accessing B s Resource (1) PDP Server Figure 4.4 A asks for accessing B s resource (1). Since A is authorized to access B s resource, PDP passes the request to B (2), then B offers its resource to A (3). 21

32 4.5 XACML Policies A policy is a set of rules and actions together that restricts access to a resource. In other words, a policy defines which identities are allowed to access a resource, and what type of access they can have. It can also define some other environmental restrictions about the access. To have a better understanding about how a policy looks like we start with a simple example. Suppose that the sensitive resource that we want to protect is a book, and Alice wants to read that book. Then the policy associated to the book defines whether Alice can read it or not. In XACML, a policy for Permitting Alice to Read the Book can simply look like Figure 4.5. <Policy> <Target> <Subject>Alice</Subject> <Resource>Book</Resource> <Action>Read</Action> </Target> <Rule>Permit</Rule> </Policy> Figure 4.5 A Simple Schema of an XACML Policy In XACML, each access control policy consists of different elements. The main elements of each policy are target and rule (see Figure 4.6). Policy Target Rule Target Condition Figure 4.6 Components of an XACML policy 22

33 The policy target specifies what resources the policy is defined for. It is used for determining about which policy to use for a received request. In the above example, Alice s desire to read the book is the target. The policy rule may narrow down the conditions for which the policy could be used for and given that the stated conditions are met it defines whether the result is Permit or Deny. In the stated example, the rule does not have any condition and it Permits the access. More information about policy target and policy rule could be found in the Appendix A along with an example. 4.6 Policy and PolicySet There could be cases where it is needed to define more than one policy for a resource. For example a policy may restrict a resource usage by the requester s identity and another policy may put restrictions on the duration that the resource could be used. However, the PDP would apply only one policy to each request. Here is where the policyset comes in. A PolicySet is like a container that can include many other Policies or PolicySets inside, either explicitly or by reference to policies on remote locations (see Figure 4.7). Using a policyset, the PDP would apply only one policyset to the request. PolicySet PolicySet Policy Policy Policy Policy Figure 4.7 A policyset may consist of any number of policies or policysets 23

34 Since a PolicySet may contain multiple Policies or PolicySets, and each of them may result in different decisions, there needs to be a way for PDP to solve this confliction. This issue is addressed by using combining-algorithms. 4.7 Combining Algorithms As different policies may result in different decisions, it is needed to consider an algorithm for coming up to a final result. Combining algorithms are defined in XACML to address this issue. Combining Algorithms could be used either by a policy to apply it to its rules or by a policyset to use for its policies. In order for a combining algorithm to find a way to solve the confliction, it needs to prioritize some policies over the others. XACML standard [8] has defined six combining algorithms for combining policies, which are Deny-override, Ordereddeny-override, Permit-override, Ordered-permit-override, First-applicable, Only-oneapplicable. In addition to the existing algorithms one can also define an algorithm for special cases that is not addressed by the existing ones. We will review some combining algorithms that later on we will point to in this work Deny-overrides Combining Algorithm Deny-overrides is one of the combining algorithms that is defined in XACML. In this algorithm, the deny decision takes precedence over any other decision. In other words if any of the policies being evaluated result in deny, the evaluation of the policyset would be deny. If all the policies in a policyset evaluate to NotApplicable the evaluation of the whole policyset would be NotApplicable. If any error happens while evaluating the target of a policy, or if a policy reference could not be found or if the evaluation of the policy is Indeterminate the final result of the evaluation of the policyset would be deny. Table 4.1 shows the behavior of the Deny-override algorithm. 24

35 Table 4.1 The table shows the behavior of the Deny-override algorithm for combining two policies (X=anything, N/A=Not Applicable, Indet.=Indeterminate) Policy 1 Deny Permit Permit Permit Indet. Indet. N/A Policy 2 X Permit N/A Indet. N/A Indet. N/A Result Deny Permit Permit Deny Deny Deny N/A Ordered-deny-overrides Combining Algorithm The functionality of this algorithm is the same as Deny-override algorithm. The only difference is that in Ordered-deny-override policies would be evaluated based on the order that they come in the policyset. To difference between Deny-override and Ordered-deny-override algorithms is that Deny-override algorithm allows the PDP to optimize evaluation; meaning that it might have already obtained certain attributes that allows it to efficiently evaluate some policies, but not others. By evaluating those policies first, if it comes to any Deny result it does not need to evaluate other policies any more. Or regarding the policies that are included by reference in the policyset, the PDP may already have cached some of them, so it can evaluate them more efficiently than those it has not retrieved yet. Again, evaluating those cached policies may result in a Deny decision and it would not be needed any more to evaluate more policies. However, with Ordered-deny-override the evaluation will be done according to the order of the policies in the policyset, regardless of whether some of them could already be evaluated. 25

36 4.8 Some Open issues of XACML Regarding the location of policies, the XACML standard [8] says that XACML policy statements may be distributed in any one of a number of ways. But, XACML does not describe any normative way to do this. Therefore there is no special restriction about where the policies should locate. Members of the OASIS XACML language Technical Committee have suggested the use of Lightweight Directory Access Protocol (or LDAP in short) [10] for the distribution of XACML policies. So, after policies are set up by system s administrator, they could be distributed among some information directories. Though system s administrator, in most usages, is assumed to be centralized at PAP [12, 21], but the standard [8] does not make any restriction about whether the policies should be administrated centrally or in a distributed manner. 4.9 Fitting in the Desired Model into the Standard This work uses the openness of the XACML standard concerning the location of policies and policies administration and benefits these by defining a model that let the resource providers control access to their resources. This could be achieved by letting the resource providers define their own policies for accessing their resources. The administrator, too, may define its own policy for the resources. Finally the access management would be achieved by a cooperation of these two. 26

37 Chapter 5 Proposed Solution 5.1 Contribution of the Resource Principals in Access Management The model that is defined in this work lets the resource principals contribute in managing access to their resources. The principal of a resource is primarily the resource owner. The administrator might also be another principal of a resource. Therefore when we talk about contribution of the resource principals we mean having cooperation between the distributed resource owners and the central administration, in case the central administrator is another principal for the resource. 5.2 Distribution of Access Management in XACML The access management model that the XACML standard provides is controlled by policies. Therefore, in order to take the access management control in hand, one needs to set up policies and use them in the desired way. According to the specification [8], the Policy Administration Point (PAP) is the one that creates the policies. However, the standard does not mention anything specific about the identity of the administrator. In order for the resource providers to contribute in access management, it is essential to let them set up policies of their own. This way, just as the resources are distributed in the network, the policies would be as well. The administration may also have policies to be considered for accessing each resource. 27

38 5.3 More on Distribution of Policies The term Distribution of Policies as stated in the standard [8] points to the location of policies rather than distribution of the administration. In addition, distribution of policies to different locations is explained by using several databases [10, 13]. This is while the databases are administrated centrally by the PAP without any correlation to the resource providers. However, the idea here is to let the resource providers set up policies of their own. It also gives the resource providers the possibility to administrate their own local policies, and if necessary make some changes whenever needed. This does not mean that the central administration cannot set up any policy. Every resource may have different principals, each of which may want to have its own restrictions, and the central administration (here PAP) could be one of the resource principals. As an example we can think of a mainframe that shares its processor with different users programs. The administrator of the system may have his own restrictions about the duration of time that each user can use the processor. In addition, each user may have his own considerations about who should be able to run his code. In XACML the Policy Administration Point (PAP) provides policies for Policy Decision Point (PDP). So PAP should know about all the policies regarding the resources of the network. Regarding the policies that the PAP itself sets up, it obviously knows about their location. As for the policies that the resource principals want to consider, they should inform the PAP about them. Figure 5.1 illustrates this issue. This way, when there is a request for a resource, the PAP can find the related policies for that resource and pass them to the PDP for making decision about the request. 28

39 Policy Policy Policy Policy Administration Point (PAP) Policy Policy Policy Figure 5.1 The resource providers should inform PAP about their policies. It should be noted that in this scenario, a node in the distributed network could either act as resource provider that sets up a policy for accessing its resource, or it could be requesting another node s resource. 5.4 Evaluation of Policies So far we provided the resource principals the possibility to set up their own policies. Although this helps the local providers consider their own restrictions, but still policies should be considered centrally for coming up to a final decision. To clarify why centralization is needed for evaluation, consider the case where there is a request for accessing a resource that has more than one principal; one is the administrator and others are distributed providers. Each principal may have some restrictions in form of policies. And it is necessary to consider all those policies. If there is no central point that knows about all those policies, a request has to traverse to each and every point that has a policy for the requested resource and checks its decision. It means that the requester has to have a way to know about all the principals of a resource. 29

40 This could be possible either if each requester has such a knowledge itself, which is almost impossible and inefficient in big networks, or if a central point specifies which principals policies to check. Though the latter case is not impossible, but then combining those distributed policies without any centralization is not an easy task. This is especially true in cases where some strategies should be considered for prioritizing some decisions over the others. Therefore, even though the policies setup would be done in a distributed manner, but the evaluation of the policies has to be done centrally. 5.5 Distribution of Policies and Central Evaluation Access management would be distributed by letting the resource principals set up their own policies and self-administer their resources. However, we need to have some kind of centralization in order to come up to a final decision about accessing a resource. Even though these two scenarios may seem to be contradictory, but they are not. As we will see, XACML standard provides a way to support both ideas at the same time. In XACML, Policy Administration Point (PAP) is the point where it knows about all the policies. Even though this is mostly PAP that is considered as the writer of the policies [12, 21], but it is actually the point that should know about the existing policies. Therefore in our solution we provide an interface for the resource providers to upload their policies to PAP. This is actually a way to make the policy known to the system, since PAP is the point that is queried for fetching policies for each resource by the Policy Decision Point (PDP). Apart from the providers, the PAP itself can have some policies for different resources. As a result, when there is a request for accessing a resource, PAP will fetch local policies from the providers (local providers have informed PAP about their policies. See Figure 5.1) and together with its own policy will send to PDP for evaluation. Figure 5.2 illustrates this. 30