Access Negotiation within XACML Architecture

Access Negotiation within XACML Architecture Diala Abi Haidar 1,2 , Nora Cuppens-Boulahia 1 , Frederic Cuppens 1 , Herve Debar 2 1 ENST 2

Bretagne, 2 rue de la Chˆataigneraie, 35512 Cesson-S´evign´e Cedex France Telecom R&D Caen, 42 rue des Coutures BP 6243, 14066 Caen France

Web services offer a possibility of exchanging data between entities from different organizational bounderies. Keeping sensitive resources private in a public world is a common concern of service providers. Thus, there is a need for access control management at the level of the web services in addition to a prior negotiation of access. This negotiation is the first step in the access control management to establish trust and gather the needed resources for access request’s evaluation. We propose in this article an negotiation methodology based on resource classification. This methodology is used in the negotiation process. We present the architecture used for negotiation of access and access control management. We decide to use the XACML architecture since we have proposed to investigate the web service applications. Thus, we choose the extended RBAC profile of XACML. This extended profile responds to advanced access control requirements and allows the expression of several access control models within XACML. Keywords: Access control, XACML, RBAC, OrBAC, Interoperability

1 Introduction Combining access control and trust is essential to enforce security of web services and resources shared between entities from different security domains. The negotiation of access is the first step before the authorization management. It allows the establishment of a required level of trust and collect resources needed in the access request’s evaluation process. In [SCC+ 03, SSJ04, SWY+ 03] authors suggest a prototype for trust establishment called TrustBuilder. It allows negotiating trust across organizational boundaries, between entities from different security domains. The TrustBuilder project is investigating trust negotiation, using an attribute-based access control (ABAC) [YT05] model. Using TrustBuilder, parties conduct bilateral and iterative exchanges of policies and certified attributes to negotiate access to system resources including services, roles, capabilities, personal credentials, and sensitive system policies. The TrustBuilder approach consists in gradually disclosing credentials in order to establish trust. The prototype also incorporates policy disclosure; only policies that are relevant to the current negotiation may be disclosed by the concerned parties. They specify what combinations of credentials one can present in order to gain access to a protected resource of the accessed service. In this way it is possible to focus the negotiation and base disclosures on need to know requirements. Since these policies may contain sensitive information, their disclosure must also be controlled [SWY01]. Trust may be gradually established and policies referencing sensitive credentials or containing a sensitive constraint is not disclosed to a stranger. As far as trust is established, sensitive policies may be disclosed if permitted by the policy. Regarding access control management, there are many access control models in the literature (TBAC [TS97], DAC [HRU76], OrBAC [Mie05], ABAC [YT05]...), the most frequently cited being the Role Based Access Control (RBAC) [SCFY96] model. There are also many languages that have been proposed for expressing access control, the most important is the eXtensible Access Control Markup Language (XACML), an OASIS standard [XaO05].

Diala Abi Haidar 1,2 , Nora Cuppens-Boulahia 1 , Frederic Cuppens 1 , Herve Debar 2 In this article we have tried to bring together negotiation for trust establishment and access control management within the same architecture. We propose an architecture for XACML Negotiation of Access. Within this architecture we have combined our methodology of negotiation based on resource classification with an extended XACML architecture. In this process we consider that negotiation is upstream in the access control evaluation. Since negotiation allows the collection of resources needed to establish a required level of trust and to permit the success of the access control evaluation. This paper is organized as follows. In section 2 we explain our resource classification based negotiation. Within this section we propose a negotiation architecture that illustrates our classification methodology. Section 3 presents the access control architecture that we are going to use. In this section we detail our previous work on an extended RBAC profile of XACML on which our architecture is based. In section 4 the negotiation architecture is integrated within the extended XACML architecture. In section 5 we investigate the negotiation treatment module that is the core of the negotiation process. Finally section 6 concludes the article and proposes some perspectives for our work.

2 Resource classification based negotiation 2.1 Resource classification We define a new methodology for resource classification. This classification is used to formalize the negotiation process. Resources, including credentials, are classified within three levels: • Level 1: is the less sensitive level; In fact all the resources that are managed by direct policies are grouped within this level. Direct policies are policies that can be evaluated directly to (1) grant access and the resources can be revealed without any constraint or to (2) deny access and the negotiation process abort without any policy returned. • Level 2: is assigned to the resources that are managed by an access control policy that can be revealed. Whenever the policy is satisfied the resources can be revealed. • Level 3: is the most sensitive level; All the resources that are managed by sensitive policies that cannot be revealed immediately belong to this level. In this category we define a strategy to reveal policies. Sub-policies should be derived from this strategy and revealed.

In our proposition of classification we have suggested not to assign sensitivity to the policies but to the resources. It will be helpful that the administrator may use contextual information to dynamically change the classification of the resource. In this case, the policy will be related to that new level. The level of sensitivity of resources depends on many parameters. Actually each administrator can define a level by default for each resource accessed taking into account some criteria. Depending on the sensitivity level of the resources the administrator assigns the necessary access policies.

Definition 2.1.1 Initial Negotiation Level (INL): It is the sensitivity level that the administrator assigns to each resource. The INL of a resource is invariant. Definition 2.1.2 Current Negotiation Level (CNL): It is the sensitivity level of a resource within a specific negotiation process. It will be the same as the INL only at the beginning of the negotiation process. The CNL is derived by a negotiation process. The CNL can decrease at a given step of this process because more trust has been established for instance. Actually, if the accessed resource has an INL equal to 2 or 3 and whenever its access policies are satisfied, this resource will be accessible and its CNL will be decreased to 1.

Access Negotiation within XACML Architecture

2.2 Negotiation process In a negotiation process, an entity may ask that some other entity reveals a resource (credential). Whenever the resource has an INL equal to 1 then there is a direct policy that manages it, the process can continue and the access can be granted (or not). Whenever the required resource has an INL equal to 2, then the requested entity, before revealing the required resource, may in turn ask the requester entity to reveal another resource. A policy is returned to the requester. A problem arises when the needed resources have an INL equal to 2 for the requester entity. In this case, the process may require additional rounds to converge to a decision of granting or not the access. Finally, whenever the required resources have an INL equal to 3, then we apply a strategy of revealing policies. Once the revealed policies are all satisfied then the process may complete. In fact the negotiation process may not complete because of some exceptional cases. These exceptional cases may be grouped into two categories: • The non access exceptions: are situations where (1) the required resource does not exist at the level of the requested entity or (2) the evaluation of the access request leads to a deny decision • The loop exceptions: are situations where the negotiation process is locked in a loop; Let us suppose that one of the entities involved in the negotiation E1 is waiting for a resource A from the other entity E2 . This latter cannot reveal this resource unless E1 reveals B. If the access policy of B requires A then E1 will be asking for A and E2 for B and this creates a deadlock situation. Exceptions are raised after the detection, by the negotiating entities, of such situations and an exception treatment module is called. This module should propose alternatives so that the negotiation process can complete. Property 2.2.1 Negotiation termination: The negotiation process completes if for each requested resource (including credentials), the CNL is decreased to 1. The level 1 derivation may conclude on (1) on a grant access decision or, (2) on a deny access decision or, (3) whenever exceptions are raised (because of a denied access or loop), an alternative is found or, (4) the process fails

2.3 Negotiation architecture We have defined a basic architecture that shows the main actors within the negotiation process. Each entity should have a classification of its own sensitive resources and its specific access control policies to protect these resources. It should also have negotiation policies and exception treatment policies. We have defined, for each entity involved in the process, a specific module that is in charge of the negotiation process. This negotiation module uses the negotiation policies to negotiate access to the protected resources. If an exception is raised, this module calls the exception treatment module so that it checks the exception treatment policies to find if, according to the existing strategy, there is a possible alternative. The global data-flow is presented in figure 1. Each request for an access is intercepted by the negotiation module. If the requested resource has an INL equal to 1, the request is relayed for evaluation on the server side. When the negotiation module receives the response, it checks if there is a non access and calls the exception treatment module to check if there is an alternative. If not, the response is returned to the client. Now if the resource has an INL equal to 2 or 3 then the negotiation module will start the negotiation. It checks what are the defined negotiation policies, what policies should be returned to the requester and what are the requested credentials. This module ensures that all the required credentials are collected and derives the level of sensitivity of the resource (CNL see section 2.1). When the CNL is 1, the request with the collected credentials is sent to the service evaluation point. In section 4, we shall present our proposed architecture that shows how to put together this negotiation architecture and an XACML architecture. Before, we present the extended profile of XACML that we use for access control management.

Diala Abi Haidar 1,2 , Nora Cuppens-Boulahia 1 , Frederic Cuppens 1 , Herve Debar 2

Fig. 1: The negotiation global architecture

3 An extended RBAC profile of XACML The eXtensible Access Control Markup Language (XACML) is an OASIS standard [XaO05]. It is expressed in XML and describes both a policy language and an access control decision request/response language. The policy language is used to describe general access control requirements to resources in the information system. The request/response language allows us to form a query to ask whether or not a given action should be allowed and the response will convey the answer for this query. The answer should contain one of these four values: Permit (access allowed), Deny (access denied), Indeterminate (an error occurred or some required value was missing, so a decision cannot be made) or Not Applicable (this service has no policy that applies to this request). The OASIS standard defines a data-flow diagram (see the figure 2). The typical setup is that someone or a process wants to perform some action on a resource. So a request is sent (2) to whatever actually protects that resource (like a filesystem or a web server), which is called a Policy Enforcement Point (PEP). The PEP will form a request, in its native request format, based on the requester’s attributes, the resource in question, the action and other information pertaining to the request. This request is sent to the context handler (3) that constructs an XACML request context for a Policy Decision Point (PDP) (4), which will look at the request and some policy that applies to the request. The policies have been written by the Policy Administration Point (PAP) and made available to the PDP (1). Sometimes, the PDP may require additional attributes while evaluating the request. In this case attribute queries are sent to the context handler (5), this latter requests the attributes from the Policy Information Point (PIP) (6) then (7, 8, 9) sends them back to the PDP (10). The PDP will finally evaluate the policy and come up with an answer about whether access should be granted (11). That answer is returned to the PEP, via the context handler that translates it to the native response format of the PEP (12). The PEP can then allow or deny access to the requester and possibly fulfills some obligations (13).

3.1 The extended RBAC profile of XACML OASIS has defined profiles for XACML that address various requirements in the access control field. The Security Assertion Markup Language (SAML) profile of XACML [SaX05] provides means to write assertions regarding the identity, attributes, and entitlements of a subject, and defines a protocol for exchanging these assertions between entities. The core and hierarchical role based access control (RBAC) profile of XACML [RbX05] defines a profile for the use of XACML to meet the requirements of RBAC [FSG+ 01, SCFY96]. In previous work [HCBCD06] we have proposed an extended RBAC profile of XACML with an extended architecture for the XACML architecture (see the figure 3). This extended profile responds to more advanced access control requirements such as user-user delegation, access elements abstractions and contextual applicability of the policies. Every access request is composed of a user asking if his/her action over a given resource is allowed or not. In our profile we have used the concrete entities of the request (subject, action and object) but also we have defined the abstract entities (roles, activities, views) in addition to the context. We have chosen the following terminology for the abstract entities: View and Activity are used to respectively classify the objects and actions to which the same security rules apply and

Access Negotiation within XACML Architecture

Fig. 2: The OASIS XACML data-flow diagram

Role is kept as abstraction of subjects. The context is used to express the contextual information (temporal, spatial, provisional, prerequisite and user-declared [Mie05]). These different abstracts are managed in our architecture by different Enablement Authorities (EA) that are in charge of the translation between the concrete entities of the request and the abstract ones. There are four different EA for respectively managing role (REA), view (VEA), activity (AEA) and context (CEA). Each EA can query the corresponding assignment policy. We consider that there is a Role Assignment Policy (RAP) that defines which roles are assigned to a given subject. The REA maintains a list of all the roles that are defined in the organization and when asked about the role that can be assigned to a subject, the REA makes a request to the RAP to get the set of candidate roles. The VEA can similarly make requests to a View Assignment Policy (VAP) to determine to which view(s) the accessed object belongs. And the AEA similarly manages activity assigned to actions via an Activity Assignment Policy (AAP). Finally, the contextual conditions are taken into consideration by the CEA. The new data-flow is presented in figure 3. The policies are written by the PAP (1). When the PEP receives a concrete request (2) it is relayed to the context handler (3). The context handler then collects the assignments of the requested subject to its roles, the requested resource to its views, the requested action to its activities and finally gets the value of the contexts. This is done by sending requests to the corresponding Enablement Authorities (4). Once all the responses have been collected (5), the context handler sends a request to the PDP for evaluation (6). This request contains the abstract values and the concrete values of the subject, action and object of the initial request in addition to the value of the context(s). The PDP evaluates the request according to the policies and sends back a response to the context handler (7) that will transmit it to the PEP in its native response language (8). The PEP may have to fulfill some obligations (9) before allowing or denying the access.

Diala Abi Haidar 1,2 , Nora Cuppens-Boulahia 1 , Frederic Cuppens 1 , Herve Debar 2

Fig. 3: The extended profile architecture

4 Negotiation within XACML architecture 4.1 An extended negotiation architecture We propose to use our classification methodology and extended RBAC profile within an architecture that can be used in web services. The negotiation is considered first to collect all the necessary credentials that permits to take a decision. The data-flow in this new architecture will be as follows (see figure 4). After an access request arrives to the PEP (2) this latter relays it to the context handler. At this level the negotiation module acts as a hook; it intercepts all the requests that are destined to the context handler (3). If the requested resource has an INL equal to 1, the negotiation module sends the request to the context handler and the data-flow will be the same as the one defined in our extended profile (see figure 3). If the requested resource has an INL equal to 2 or 3, then the negotiation module will start the negotiation after checking the defined negotiation policies made available to it by the administrator. The negotiation will continue until the CNL of the requested resource is 1 (see section 2.2). At this point the request enriched with the collected credentials is relayed to the context handler (3’). The context handler executes the normal actions (4,5,6) and the evaluation of the request is done at the level of the PDP. The PDP sends the evaluation result (permit or deny) to the context handler (7) this latter sends it back to the PEP (8). The negotiation module also intercepts this response to check if there is a non access exception. In this case, the exception treatment module is called. Afterwards, the negotiation module sends the response back to the PEP (8’) that applies the decision. Till now, we did not take into consideration the requested credentials that the other entity involved in the negotiation process may require. In fact we consider that the negotiation module is in charge of negotiating the access by collecting credentials and revealing policies. It is up to the negotiation module to submit an access request concerning the required credential to the context handler. This request is similar to any request received from the PEP. The requester should be the other negotiating entity and the requested resource is the credential that is required within the negotiation process. If the access policies evaluated by the PDP permit the access to that resource, it will be revealed so that the other entity gives the initial requested credentials and the negotiation continues. Elsewhere, an alternative should be proposed by the exception treatment module that allows the negotiation module to continue the negotiation.

Access Negotiation within XACML Architecture

Fig. 4: Data-flow in the new architecture

4.2 The XACML exceptions We already defined the exceptions as a deadlock in the negotiation process, a lack of the requested resource or a deny access decision. The exceptions are raised by the negotiation modules of the two entities involved in the negotiation process. The detection of loop decisions may occur whenever the same sequence of requested resources is repeated continuously without changes. The lack of resource and the deny decision are exceptions raised after receiving the request evaluation decision of the PDP. These exceptions are expressed within the response that is intercepted by the negotiation module. In fact within XACML the element values may be (1)“Indeterminate” whenever there are missing attributes and (2)“NotApplicable” whenever the PDP fails to find a policy that applies to the request. Both of these decision values are seen as exceptions by the negotiation module. Whenever the element value is “Indeterminate” some additional information may be given within the element values, that is missing attributes or network errors or syntax errors, etc. The missing attributes case implies that the exception treatment module queries the system to find such an attribute or asks the negotiation module to negotiate with the other entity to reveal these attributes. One of the “NotApplicable” cases is raised when the requested resource does not exist. In this situation alternatives may be proposed by the exception treatment module. To be able to use our negotiation methodology, we should assume that decisions sent by the PDP should be as expressive as possible to permit the negotiation module to find the adequate reactions. That is, not all the “NotApplicable” and “Indeterminate” decisions may be really exceptions; they may be the final decision that is returned to the requester.

5 The negotiation treatment module We now focus on the negotiation process. It is considered to be a block that negotiates further information to be provided to the authorization block so that an access decision can be taken. The negotiation treatment module is the core of the negotiation process. This module interacts with the negotiation module of the negotiating entity. An instance of the negotiation process is created each time there is a need for resources from another entity. As already stated whenever the required resources have an INL equal to 1, there is no need for negotiation. If these resources have an INL equal to 2 or 3 then the negotiation process is launched by the negotiation module that creates an instance of the negotiation process and calls the other entity’s negotiation module. During this process, resources are revealed in addition to some policies. The

Diala Abi Haidar 1,2 , Nora Cuppens-Boulahia 1 , Frederic Cuppens 1 , Herve Debar 2

Fig. 5: The negotiation module’s architecture

negotiation module is split in two parts (see figure 5): the supervision layer that is responsible for the supervision tasks (see section 5.1) and the execution layer that enforces the negotiation protocol according to the directives of the supervision layer (see section 5.2). This abstraction is applied whatever the underlying implementation is. At this level of abstraction discussing the languages and protocols that can be used in the negotiation process is out of the scope of this article.

5.1 The supervision tasks The supervision layer has the following functions: 1. Checking the repository level: the negotiation module uses a repository of the levels assigned to all the resources within the organization. Each time the request for access to a resource is intercepted by the module, this latter looks at its level. If the resource has an INL equal to 1 then the request is forwarded to the context handler. Whenever the INL is 2 or 3, the negotiation module checks the negotiation policies repository. 2. Checking the negotiation policies repository: within this repository the administrator defines the policies for negotiation. These policies are a distillation of the access policies and define the necessary resources that should be collected so that the access control request may be evaluated. 3. Deriving the sensitivity level: the negotiation module should take into account our classification in the negotiation process. Each time the required resources (credentials) are collected and the resource’s negotiation policies are satisfied, the CNL of the resource is derived. If it is equal to 1 then the request with all the collected credentials is sent to the context handler. 4. Looking for policies and resources to reveal: within the negotiation and whenever it is possible, the module is able to reveal some policies and the required resources. To do that it should analyze a policy to determine the required resources that can be revealed. It should also check and derive the policies that should be revealed (in the case of level 3 accessed resource). 5. Creating an enriched request: each time the negotiation module collects credentials that are necessary for evaluating a request, it forms an enriched request where it brings in all the collected information. Then the context handler creates the XACML query and sends it to the PDP. 6. Creating a negotiation request: sometimes to be able to reveal a resource the other entity implied in the negotiation process may ask for a resource to be revealed. This query is sent to the negotiation

Access Negotiation within XACML Architecture module (it is different from the request for access sent to the PEP). Then the module sends a “formed” request to the context handler to be evaluated. 7. Calling the exception treatment module: whenever an exception is detected by the negotiation module, this latter calls the exception treatment module and sends the raised exception. The exception treatment module checks if there is any alternative. As stated before, the exception treatment module has some pre-defined policies that handle different cases of exceptions and suggest alternatives.

5.2 The execution layer The execution layer is in charge of executing the tasks of the supervision layer. It is also receiving information from the execution layer of another negotiating entity. There is an execution layer at the level of the (1) requester entity that requests resources but also at the level of the (2) requestee entity that receives requests for resources. The tasks of the execution layer are: 1. Receiving resources: The execution layer of the requester entity receives resources revealed by the requestee entity. These resources are relayed to the local supervision layer. 2. Receiving policies: If the requestee entity requests resources to be able to reveal some of its resources, the execution layer of the requester entity receives the corresponding policies to be enforced. These policies are then relayed to the supervision layer that can determine what are the required resources to enforce these policies. 3. Sending policies: Whenever the requested resources have an INL equal to 2 or 3, policies should be revealed by the requestee entity before getting access to these resources. The supervision layer determines the policies that can be revealed and passes them to the execution layer. This latter sends these policies to the requester entity. 4. Sending resources: If the supervision layer decides that the requested resources can be revealed it relays them to the execution layer so that this latter sends them to the requester entity.

5.3 The negotiation and exception treatment policies Previous works in the field of the interoperability have influenced our choice of exporting a distillation of policies in the negotiation process [SWY01, CCBC06]. In [CCBC06] authors make use of the virtual private organizations (VPO) to manage the access control in an interoperability context. Their approach, called O2O (for Organization to Organization), is based on the idea that each organization should define a VPO that is associated with security policies managing the access to protected resources within this organization. VPOs manage the interoperability policies of each organization. In the same way in our architecture we assume that each negotiation module uses the negotiation policies. Due to space limitation, the formal specification of policies (languages and structure) in addition to the negotiation protocol will be detailed in a forthcoming paper.

5.3.1 Example of these policies The definition of the negotiation and exception treatment policies should be done by the administrator for all the resources classified level 2 or 3. The access control policies used by the PDP for request evaluation enclose rules such as ”it is permitted to a subject S to have the action Read on the resource R”. But there may be other kind of rules stating that it is permitted to the role physician to have the action Read on the resource medical record. In this case, the medical record should be classified as a level 2 resource since there is a policy that should be satisfied. The enablement authorities manage some rules that specify, in particular, the enablement conditions of the role physician. One of these rules may state that it is permitted to enable a subject in the role physician if he or she can provide a Physician Id card. This required resource (credential) is what the negotiation module should ensure the possession before submitting the request to the evaluation. The module checks the policies repository according to the accessed resource. Within this repository it should find a policy relative to the medical record access

Diala Abi Haidar 1,2 , Nora Cuppens-Boulahia 1 , Frederic Cuppens 1 , Herve Debar 2 (a level 2 resource), stating that the user should provide a Physician Id card. If the requester have enclosed this information in the access for request then the corresponding policy is satisfied and the CNL is decreased to 1. The request is sent to the evaluation. If the credential was not enclosed, the negotiation should start to collect it. In addition to these negotiation policies, the exception treatment policies can prevent the non access exception to resources that may be sometimes unjustified. Let us suppose that the requester is a physician and did not send this information to the PEP when requesting the access to the medical record. The medical record is a level 2 labeled resource for which there should be an access policy defined by the administrator. If the negotiation module fails to find such a policy then the request is sent, as it was received, to be evaluated (see section 5.3.2). Regarding the Role Enablement Authority some rule specifies that a subject is assigned to role physician if this subject possesses the Physician Id card credential. As this credential has not been provided by the requester, this rule does not apply and the requester is not assigned to the role physician. Likewise, regarding this request the PDP decision is “deny”. After receiving this deny decision the negotiation module should raise a non-access exception. It is now up to the exception treatment module to propose alternatives. The administrator may have defined a rule in the exception treatment policies stating that whenever there is a non-access decision and the requested resource is the medical record then the requester should provide its Physician Id card. Another way of resolving this exception may be to redirect the user on a logon page so that the user may be identified with its Physician Id card.

5.3.2 Failures in the negotiation Regarding failures in the negotiation, several cases may be considered: • Case 1: The negotiation module checks the level of the resource and does not find the corresponding negotiation policy that applies to that resource. It cannot launch the negotiation process. • Case 2: The negotiation module fails during the negotiation process while collecting resources because of a loop exception raised without alternative. • Case 3: The negotiation module fails during the negotiation process while collecting the required resources because of a non-access exception raised by the requester or the requestee without alternative. • Case 4: The negotiation module contacts the exception treatment module because there is a nonaccess exception. This is after the access decision has been already evaluated by the PDP. The exception treatment module has no alternative to suggest. In the cases 1, 2 and 3 there is a failure in the bottom-up flow (from the PEP to the PDP in the figure 4). Even though the INL of the resource is 2 or 3 and it is not possible to derive a CNL of 1, the negotiation module should relay the request to the context handler; the same as received by the PEP. The risk is that the access cannot be properly evaluated, in this case an alternative is to have an exception treatment solution handled by the exception treatment module. In the case 4, it is a failure in the top-down flow (from the PDP to the PEP in the figure 4), then the response is sent to the PEP so that it applies the decision. As we can see from these cases it is very important that the administrator defines precise negotiation and exception treatment policies so that negotiation has more chance to succeed.

6 Conclusion and perspectives In this article we have proposed a framework for access negotiation and access control management. The negotiation of access aims to establish trust and collect data necessary for a more successful access evaluation. This negotiation is processed by a negotiation module and based on a resource classification methodology. The access control management is done within an extended RBAC profile of XACML. Our proposition is based on this extended profile architecture to which we add the negotiation actors (negotiation module and exception treatment modules).

Access Negotiation within XACML Architecture Now that we have proposed a structured framework for negotiation within XACML, we are aiming to propose a protocol for that negotiation process. Further work should be done on the way policies can be evaluated according to the resources. This is to determine what are the required resources to satisfy these policies. It is obvious here that the choice of the negotiation language is very crucial. We will also evaluate our model by implementing it and making some tests to measure the time it takes for a negotiation process to complete.

Acknowledgments The work presented in this paper is supported by funding from the ANR RNRT POLITESS Project.

References [CCBC06]

F. Cuppens, N. Cuppens-Boulahia, and C. Coma. O2O: Virtual Private Organizations to Manage Security Policy Interoperability. In ICISS, pages 101–115, 2006.

[FSG+ 01]

D. F. Ferraiolo, R. Sandhu, S. Gavrila, D. R. Kuhn, and R. Chandramouli. Proposed NIST Standard for Role-Based Access Control. ACM Transactions on Information and Systems Security (TISSEC), 4(3), 2001.

[HCBCD06] D. Abi Haidar, N. Cuppens-Boulahia, F. Cuppens, and H. Debar. An Extended RBAC Profile of XACML. Proceedings of 2006 ACM Secure Web Services Workshop (SWS), Fairfax, VA, USA, November 2006. [HRU76]

M.A. Harrison, M.L. Ruzzo, and J.D. Ullman. Protection in operating systems. Communications of the ACM, 19(8):461–471, 1976.

[Mie05]

Alexandre Miege. Definition of a formal framework for specifying security policies. The Or-BAC model and extensions. PhD thesis, ENST, June 2005.

[RbX05]

Core and hierarchical role based access control (RBAC) profile of XACML v2.0. Standard, OASIS, February 2005.

[SaX05]

SAML 2.0 profile of XACML v2.0. Standard, OASIS, February 2005.

[SCC+ 03]

K.E. Seamons, T. Chan, E. Child, M. Halcrow, A. Hess, J. Holt, J. Jacobson, R. Jarvis, A. Patty, B. Smith, T. Sundelin, and L. Yu. TrustBuilder: negotiating trust in dynamic coalitions. Proceedings DARPA Information Survivability Conference and Exposition, 2:49–51, April 2003.

[SCFY96]

R. S. Sandhu, E. J. Coyne, H. L. Feinstein, and C. E. Youman. Role-Based Access Control Models. Computer, 29(2):38–47, February 1996.

[SSJ04]

B. Smith, K.E. Seamons, and M.D Jones. Responding to policies at runtime in TrustBuilder. Proceedings of the Fifth IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY’04), pages 149–158, June 2004.

[SWY01]

K. Seamons, M. Winslett, and T. Yu. Limiting the Disclosure of Access Control Policies During Automated Trust Negotiation. In Network and Distributed System Security Symposium, San Diego, CA, April 2001.

[SWY+ 03]

K.E. Seamons, M. Winslett, T. Yu, T. Chan, E. Child, M. Halcrow, A. Hess, J. Holt, J. Jacobson, R. Jarvis, A. Patty, B. Smith, T. Sundelin, and L. Yu. Trust Negotiation in Dynamic Coalitions. Proceedings of the DARPA Information Survivability Conference and Exposition (DISCEX’03), 2:240–245, April 2003.

Diala Abi Haidar 1,2 , Nora Cuppens-Boulahia 1 , Frederic Cuppens 1 , Herve Debar 2 [TS97]

R. K. Thomas and R. S. Sandhu. Task-based Authorization Controls(TBAC): A Family of Models for Active and Enterprise-oriented Authorization Management. In Proceedings of the IFIP WG11.3 Workshop on Database Security, Lake Tahoe, California, August 1997.

[XaO05]

eXtensible Access Control Markup Language (XACML) Version 2. Standard, OASIS, February 2005.

[YT05]

E. Yuan and J. Tong. Attribute based access control (ABAC): a new access control approach for service oriented architectures. Ottawa New Challenges for Access Control Workshop, April 2005.