Towards a Secure and Borderless Collaboration between Organizations : An Automated Enforcement Mechanism

During the last decade, organizations have been more and more aware of the benefits of engaging in collaborative activities. To attain a required collaborative objective, they are obligated to share sensitive resources such as data, services, and knowledge. However, sharing sensitive and private resources and exposing them for an external usage may prevent the organizations involved from collaborating. Therefore, this usage requires more preoccupation with security issues. Access control is one of these required security concerns. Several access control models are defined in the literature and this multitude of models creates heterogeneity of access control policies between the collaborating organizations. In this paper, we propose Access Control in CrossOrganizational coLLABoration ACCOLLAB, a solution for automatic mapping between heterogeneous access control policies in cross-organizational collaboration. To carry out this mapping, we suggest a mechanism founded mainly on XACML profiles and on a generic language derivative of XACML we define as Generic-XACML. We also formally prove that the mapping does not affect decision evaluation of policies. Thereby the proposed contribution ACCOLLAB allows each collaborating organization to communicate their access control policies and adopt other’s policies without affecting their existing access control systems.


Introduction and Motivation
Collaborative activities have received a lot of attention from organizations due to the important need to address specific and common goals, to combine knowledge, skills, and experiences, to share resources (data, services, knowledge, and/or expertise) to meet a particular task.To succeed such collaboration, involved actors must first trust each other and communicate effectively to overcome the obstacles brought about by the benefits of collaboration.
During the last decade organizations have been more and more aware of the benefits of engaging in collaborative activities.Then in most of cases and in order to attain an ultimate objective or to answer required needs, they are obligated to share sensitive resources such as data, services, and knowledge.However, sharing sensitive and private resources, especially data and services, and exposing them for an external usage may prevent the organizations involved from collaborating.Hence, the focus on protecting data privacy and security issues in interorganizational collaboration represents a crucial requirement and becomes one of the most pressing concerns.Security issues aim at guaranteeing information availability, confidentiality, integrity, authenticity, and accountability.Data privacy known also as data protection aims to prevent sensitive information from being leaked or breached to unauthorized parties.
Several scientific research studies in the literature have raised this challenge, and identified that access control is one of the most important concerns of privacy and security.A number of access control models such as RBAC [1], TBAC [2], and ABAC [3] have been developed to address various aspects of access control problem.
In cross-organizational collaboration, additional requirements for access control arise like trust management, high level of privacy, interoperability, and dynamicity.Several access control solutions proposed in the literature have addressed this challenge.Some of them have proposed outright a new access control model [4,5], or extended existing models to be suitable for cross-organizational collaboration [6,7].However, most of the suggested solutions require that Security and Communication Networks collaborating organizations profoundly modify their existing access control models, a situation that is difficult to achieve and is impractical in heterogeneous real systems.Other works have assumed that collaborating organizations are adopting the same access control model and proposed centralized solutions like [8,9] or distributed solutions like [10,11] to control access cross-organizations.Few works have tackled the heterogeneity of access control models problem [12][13][14], and none of them according to our knowledge has given a complete solution for automatic policy mapping between heterogeneous systems that covers both syntactic and semantic transformation.
Moreover, to enhance security interaction between organizations, we consider that enabling access control policy enforcement in customer organization is mandatory.However this property is not met by the evoked solutions.The need to enable provider policy enforcement by consumers system is motivated by multiple reasons: (1) The need to ensure the fine grained access control defined by the provider policy.Usually a policy specifies fine grained constraints related to the subject who can access to a resource, but when the subject is in a foreign organization, the provider would be unable to determine the capability of the subject.Wherefore we need to enforce provider policy in the consumer side.
(2) The need to enforce context aware constraints defined by the provider policy when the policy specifies context constraints that could be determined only in the consumer organization.
(3) The need of high level of trustworthiness between collaborating organizations.Usually collaboration is regulated by contracts or agreement [15].For a consumer organization, to keep a high level of trustworthiness, it should fulfill the provider policy, especially access control policy.To do so, consumer organization should be able to enforce the provider policy.
Reviewing the contributions presented in the literature in response to this challenge motivated us to believe in the need for a solution for collaborative access control that has the advantage to (1) tackle the heterogeneity in access control models, (2) allow automatic mapping of access control policies between collaborating organizations based on syntactic and semantic transformations, and (3) respect the legacy systems.
The aim of our contribution ACCOLLAB is to propose a new mechanism that ensures mapping between heterogeneous models automatically.This mechanism will help organizations to communicate their access control policies and adopt others' policies automatically without affecting the existing access control systems.In addition we have considered both syntactic and semantic mapping to propose a complete solution.To deal with semantic mapping, we have proposed an ontology-based semantic mapping process in [16].In this paper, we focus on syntactic mapping, to which we have given a skeleton outline to syntactic mapping in a previous work [17].
The rest of this paper is organized as follows: Section 2 exposes related work, whereas Section 3 describes the mechanism of automatic mapping between access control models by means of XACML profiles and a proposed language Generic-XACML.In Section 4 we show in details how to map from XACML profiles to our Generic-XACML, while Section 5 is dedicated to present the reverse mapping.Finally, we conclude in Section 6.

Related Work on Access Control in Cross-Organizational Collaboration
In the literature, several contributions have addressed the problem of access control in cross-organizational collaboration.Some of them have proposed outright a new access control model, or extended existing models to be suitable for cross-organization collaboration.While the majority of works have assumed in their approaches that collaborating organizations are adopting the same access control model to propose architectures, frameworks, or solutions to control access cross-organizations, few works have tackled the heterogeneity of access control models problem, and none of them has given a complete automatic solution for policy mapping between heterogeneous systems.To more organize this section, we introduce as follows three cases that are as follows: Case 1: proposition of new access control model or extending an existing one; Case 2: solutions to control access across organizations adopting the same access control model; Case 3: approaches tackling the interoperability between heterogeneous models.

Case 1: Proposition of New Access Control Model or Extending an Existing
One.Some works define of a new access control model or extend existing models in order to be suitable for cross-organization collaboration.
OrBAC [4] is an example of innovative models which is centered on the concept of Organization.Each access control policy is defined for and by an organization.OrBAC defines the notion of role, view, and activity that refer to subject, object, and action, respectively, from the perspective of an organization and includes also the notion of context.Using these concepts, policies are defined homogeneously in all collaborating organizations.
Authors in [18] propose a federated capability-based access control (FedCAC) system to tackle the challenges of access control for heterogeneous devices over IoT.They propose the delegation of domain-specific access control policies and identity management tasks from the centralized Policy Decision making Center PDC to fog computing nodes called coordinators.Authors in this work consider one homogeneous definition of access control policies and then they are synchronized among the PDC and coordinators.
Reference [6] is another example that extends RBAC model with new concepts required for collaborative environments in both intra-and interorganizations.Authors of that paper propose a generic access control ontology and a framework supporting administration and enforcement.The proposed model has been specified to protect data access in intra-and interorganizations collaboration, but it focuses on organizations using only RBAC model and excludes other models.
Policies in these works will be defined in the same way for all collaborating organizations.Access requests will be homogeneous with enforcement mechanisms of the collaborating organizations.Meanwhile, adopting a new access control model requires rebuilding the whole access control system of collaborating organizations, which is impractical and sometimes refused by organizations.

Case 2: Solutions to Control Access across Organizations
Adopting the Same Access Control Model.Many works have proposed solutions for access control in cross-organizational collaboration where all organizations adopt the same model (ABAC or RBAC are the most used).While reviewing the most interesting contributions we have concluded that two main architectures are proposed: centralized architecture and distributed architecture.

Centralized Architecture.
The work [8] proposes a centralized architecture for access control across organizations where each collaborating organization defines policies associated to their shared resources.Then these policies are managed by a coordination organization depending on each collaboration incident and enforced by centralized components which bases on ABAC model.
Authors in [9] propose a Multiple-Policy supported Attribute-Based Access Control model (MPABAC) with a centralized architecture.This model extends the traditional ABAC model by providing cross-domain authentication and authorization.They propose a priority description to combine policies among multiple domains and adopt a hierarchical structure for policies enforcement.
Authors in [19] address the issues of combining multiple XACML policies in cross-organizational collaboration.They present a policy combination architecture that consists of classifying the rules based on attribute constraints in each policy of collaborative organizations and then reduce the rules of the corresponding classes to one with the same attribute constraints.The reduced rules are then combined into a new global policy by choosing the appropriate rule combining algorithm.
This kind of contributions proposed centralized solutions for access control in cross-organizational collaboration assuming that all collaborating organizations are using the same access control model.So they try to find a way to combine access control policies of collaborating organizations or to combine access control decisions.

Distributed Architecture.
The work [10] proposes a policy distribution and synchronization schema for an IoT environment.It is based on virtual channels technique for the propagation and synchronization of policies across different domains in real-time.The paper presents a mechanism to dynamically enforce and propagate policies across heterogeneous domains.However it does not consider the heterogeneity of the policies themselves which can be expressed different ways according to each domain.It considers only ABAC model and assumes that no heterogeneity exists in policy definitions among different organizations.
Authors in [11] proposed a distributed access control architecture to address authorization issues across multiple clouds.The architecture is based on service-level agreement SLA component to allow peer to peer interoperation.SLA performs role mapping and evaluates policy constraints defined in a mediated SLA policy.This mediated policy is defined using RBAC XML-based declaration.Authors propose a solution for interoperability in multiple clouds collaboration assuming all clouds are adopting the same access control model RBAC.
Authors in [20] adapt and implement RBAC for a multidomain grid access control.Their approach includes an architecture for role mapping cross-domain based on role ranking mechanism.Authors consider only RBAC.Additionally this approach is not suitable for fine-grained authorization.
Authors in [21] address access control in dynamic crossenterprise collaborations by proposing a framework for attribute and policy reconciliation, where attribute definitions or their interpretations are not standardized.The framework externalizes domain knowledge in order to dynamically infer attribute relationships during the evaluation of authorization decisions.Authors in this paper address the interoperability challenge for access control in cross-enterprise collaborations but they only consider ABAC model.
Even though these works give interesting solutions to manage access control in cross-organizations collaboration, they do not consider heterogeneity in access control models adopted by collaborating organizations.

Case 3: Approaches Tackling the Interoperability between
Heterogeneous Models.An interesting work [22] proposed an ontological approach to deal with the interoperability between heterogeneous access control models by matching different ontologies that describe the diverse access control models of the interconnected organizations.Yet, authors focus on access control for cloud data storage when integrating heterogeneous organizations, which make it useless in a cross-organizational collaboration with segregated systems.
Authors in [12] address the heterogeneity problem of access control models across collaborating organizations.They proposed an equivalent based access collaboration model EABC to protect shared resources.This model covers multiple domains that are adopting different access control models and is based on defining equivalent access which involves entity mapping and entity linking relationships.They propose a formal definition of policy mapping across organizations.Unfortunately they do not give any details about mapping process.
Reference [13] proposed an enforcement architecture that evaluates the possibility of potential cross-domain policy deployment through model-driven mapping and translation using ontology-based mapping and query-based mapping.The paper presented a solution similar to ours.Meanwhile, it focuses on defined logical models, representing common operation rules, to ensure the semantic mapping.However, each logical model is defined by domain administrators, which can generate heterogeneity in logical models themselves.
The paper [14] analyzed the common knowledge of access control models, and proposed an ontology-based model which can describe different access control models.This work gives a formal description of access control ontologies and proposes a connection algorithm, which is based on access ontology.However, neither details about the connection algorithm nor the mechanism of mapping between organizations' policies are provided, giving that each collaborating organization adopts its own access control mechanism.
These evoked contributions tackle the problem of access control in cross-organizational collaboration where each collaborating organization adopts a different access control model.Unfortunately none of them gives a complete solution using syntactic and semantic transformations.
This motivates us to come up with a solution characterized by (1) Respect of legacy systems, (2) Automatic policy mapping between collaborating organizations based on syntactic and semantic transformations, (3) Tackling the heterogeneity in access control models.

Our Proposed Mechanism of Automatic Mapping between Heterogeneous Models
Our current contribution aims to suggest a solution for Access Control in Cross-Organizational coLLABoration (ACCOLLAB) that respects legacy systems of each organization in the collaboration and aims to enable the enforcement of providers' policies in the consumers' organizations.Figure 1 shows an example of two collaborating organizations using heterogeneous access control systems.The provider organization that offers a requestee (e.g., service, resource, data. ..) defines a policy using RBAC model and enforces access control using an adequate mechanism.So, the consumer organization that uses ABAC model and enforces access control using a different mechanism should be able to read provider's policy and enforces it using its own access control mechanism.Thus, we propose a mechanism for automatic policy mapping between organizations adopting heterogeneous access control models.The automatic policy mapping involves two transformations: syntactic transformations that concern the form of the policy, which is our focus in this paper, and semantic correspondences we tackled in the previous contribution [16] Where we relied on a generic representation of access control concepts and proposed an ontology-based semantic mapping.
Thus, we assume, in this paper, that every single constraint in an access control policy expressed in an access control model has a semantic corresponding constraint in any other model and we focus on automatic mapping between models in term of policy definition.
To ensure an effective mapping we use XACML as an intermediate policy definition language for mapping.The motivation behind this choice is that XACML can be used to implement any access control model and that a number of XACML profiles are already defined.
Figure 2 depicts the global architecture of the mapping.Hence, to be able to map from a policy written according to a particular model to another model (e.g.RBAC model to ABAC model), we resort to XACML profiles as an intermediate language.So we define a high level syntax of XACML that we call Generic-XACML (detailed in Section 3.3).From this syntax we can switch to any XACML profile, and thereafter it will be translated to the target policy language which is specific to the model.
Our solution is distributed, but unlike existing distributed solutions [10,11,20,21], we consider heterogeneous existing access control systems adopting heterogeneous models (ABAC, RBAC, UCON. ..).Our solution will be implemented as an additional layer on the top of existing access control systems; existing systems will not be changed only policies will be automatically translated.
In the next subsections we give an overview of XACML and XACML profiles.Then we give a definition of our generic-XACML language.
3.1.XACML: Overview.Recall that XACML (eXtensible Access Control Markup Language) [23] is a standardized access control policy and decision language based on XML.The core of XACML defines policies by hierarchical components.The root element is the PolicySet, it contains Policy or/and other PolicySet elements.Policy element contains a set of one or more Rule elements.A Rule element contains a condition that is evaluated to either True or False.A Rule element represents a single authorization or prohibition depending on its effect, which is either Permit or Deny.XACML provides Combining Algorithms that operate to combine decisions or effects of multiple Policy or Rule elements into a single decision via a Policy Combining Algorithm for Policy elements and via a Rule Combining Algorithm for Rule elements.
Rule, Policy and PolicySet elements include a Target element to specify their applicability to the access control request and optionally an obligationExpressions element or an adviceExpressions element to define obligations or advices respectively.The Target element may be empty or a conjunction of a disjunction (AnyOf elements) of a conjunction (AllOf element) of Subject, Resource, Action and/or Environment conditions expressed as Match elements.Subject, Resource, Action and Environment are the four attribute categories defined by XACML.

XACML Profiles
3.2.1.XACML-RBAC Profile.[24] defines a profile to meet the requirements for RBAC.The RBAC profile of XACML (XACML-RBAC) expresses a way to use the standard XACML within the RBAC model.
In this profile each Role is defined by a PolicySet element.It contains a Target element that makes the PolicySet applicable only to Subjects having the XACML Attribute associated with the given Role.The Target element does not restrict the Resource, Action, or Environment.This Role PolicySet element contains a unique PolicySet that defines the actual Permissionsassociated with the Role.Such a PolicySet contains PolicySet, Policy and Rule elements that describe the resources and actions that subjects are permitted to access, along with any further environmental conditions, such as time of day.A given Permission PolicySet may also contain references to Permission PolicySet elements associated with other Roles (hierarchy).
The Target element of a Permission PolicySet, and its included or referenced PolicySet, Policy, and Rule elements, must not limit the subjects to which the PolicySet is applicable.

XACML-UCON Profile.
[25] defines a profile (XACML-UCON) for the use of XACML in expressing policies that would ensure usage control as defined in UCON model.In this profile, Authorizations are specified by XACML Subject and XACML Resource in the Target element.Obligations are specified by XACML Condition.Conditions (the UCON concept) are specified by XACML Environment, Rights are specified by XACML Action.Continuity of usage decision will be expressed in the XACML Obligation within the Policy element.It would contain an AttributeAssignment which will specify the time interval between continuous policy reevaluations.
Mutable Attributes are specified within XACML Obligations as XACML AttributeAssignment.The AttributeId is where the name of the mutable attribute is specified.

Other XACML Profiles.
Other works like [26][27][28] define XACML profiles for Access Control List (ACL) and ABAC models.In the same way other profiles for other models can be developed, since XACML offers the possibility to express any concept as attributes.Thus, we can map any existing policy into the XACML policy language.The profile will specify the particularity of the model by specifying: (i) The correlation between the model concepts and the categories of attributes, (ii) The categories of attributes to put in for some Target elements, (iii) The nesting of the XACML elements (specify the number of children of some elements).
(iv) The combining algorithms that are used.

Generic-XACML.
When organizations engage in collaboration, access control policies related to the shared Requestees (services or resources. ..) are translated to the XACML profile for the model adopted by the provider organization.Then these policies are automatically mapped to Generic-XACML and shared jointly with the requestees.Later, these policies are automatically mapped to the XACML profile for the model adopted by the consumer organization and finally translated to the consumer model.So, Generic-XACML is a high level language that serves as intermediate for the mapping.Generic-XACML is inspired from XACML such as it matches the XACML specifications for policy definition and restricts the core XACML by the following constraints: (i) It contains a root PolicySet element with an empty Target.
(ii) The root PolicySet contains exactly one nested Policy element with an empty Target as well.
(iii) The Policy element contains a set of nested Rule elements and optionally a set of Obligation and/or Advice elements.
Figure 3 depicts a pseudo code of the structure of a Generic-XACML policy.
In the next Sections 4 and 5, we show in more details how to map between Generic-XACML and XACML profiles.And we prove the equivalence between policies.

Policy Decision Evaluation for XACML and Generic-XACML.
The Rule evaluation depends on the Target evaluation and the Condition evaluation [23].The Target value can be either match, not match or indeterminate.The value indeterminate can be obtained if an error occurred or some required value was missing, so a decision cannot be made.The Condition element is a set of propositional formulae which is evaluated to either True, False or Indeterminate.An empty Condition or an empty Target is always evaluated to True.The evaluation of a Rule element is either applicable, not applicable or Indeterminate.An applicable Rule has effect either deny or permit.Finally, the evaluation of Policy and PolicySet elements is based on a combining algorithm of which the result can be either applicable with its effect either deny or permit, not applicable or indeterminate.
In this paper, we refer to the formal XACML elements evaluation developed in [29].In this work the authors use a three-valued logic represented by the three symbols: (⊤, ⊥ , ) that correspond to XACML elements evaluation.Table 1 depicts the mapping between these three logic values and XACML elements evaluation.
In order to distinguish either an applicable policy permit access or deny it, this three-valued logic is extended to a multivalued logic represented by the set  6 = {⊥ ,   ,   ,   , ⊤  , ⊤  }, where the subscript d denotes Deny, the subscript p denotes Permit, and the subscript dp denotes Deny Permit.

Mapping from XACML Profiles to the Generic-XACML
In this section we show that any policy written in an XACML profile can be mapped into our generic language.We explain how to proceed in order to map to the Generic-XACML without altering the logic of the policy and its decision evaluation.The following are steps of transformation of the original policy written in an XACML profile: Step 1. Unifying the combining algorithms (in our study we focus on case where we have the same combining algorithm in all Policy and PolicySet elements).
Step 2. Nesting the Target of the Policy and PolicySet elements into their composite Rule elements and combining them with the Rule Target so that we obtain all Policy and PolicySet elements with an empty Target.
Step 3. Nesting of all ObligationExpression and AdviceExpression elements of the Policy and PolicySet elements into their composite Rule elements by inserting them into the ObligationExpressions element or into the AdviceExpressions element of the Rule.
Step 4. If a PolicySet is nested into another PolicySet, its Target is empty and its combining algorithm is the same as the container PolicySet; then it will be eliminated and substituted by its content.
Step 5.In order to obtain only one Policy element, we substitute all Policy elements by one Policy element that contains the content of all nested Rules together (they must have the same combining algorithm and an empty Target).
These steps can be carried out through Algorithm 1 that allows mapping from any XACML document to a Generic-XACML document.In the next subsections we prove that these transformations do not affect the decision evaluation of the policy.

Unifying the Combining Algorithms.
To carry out the above transformations without affecting the global decision evaluation, we should have the same combining algorithm in the transformed elements.However, to come up with equivalence between combining algorithms, we need to extend XACML by proposing other elements.To avoid encumbering this paper we suppose we have the same combining algorithm in all Policy and PolicySet elements.We base on the truth tables (Tables 2 and 3) [23] to prove that the evaluation of the Policy  is the same as   : [] = [  ] we use the notation [] to express the evaluation of a Rule, Policy or PolicySet.

Policy and PolicySet Elements with an Empty
If  = ⊤ then for any  ∈ [1 − ]  ∧  =  so the evaluation the nested Rules does not change [  ] = [] and then An empty Target always matches Then Case 2.
(because  = ⊤ or  = ) So (comAlg is the function that evaluates decisions of [1  ] . . .[  ] according to the combining algorithm used) So (at least one Rule evaluated to Indeterminate) On the other hand Case And

Target Policy or PolicySet PolicySet
And The same reasoning for a PolicySet composed by a set of policies or PolicySets with the truth Table 4.

Policy and PolicySet Elements with No Obligation or
Advice Elements.Obligation or Advice are operations that must be fulfilled in conjunction with an authorization decision (permit or deny authorization decision).Obligation-Expression or AdviceExpression elements may be added optionally in a Rule, Policy, or PolicySet elements.Obligation and Advice do not affect the access decision but they are fulfilled when the access decision is equal to the value specified in the FulfillOn attribute for Obligation element and AppliesTo attribute for Advice element.
So since Obligation and Advice do not affect the access decision we can imbricate them into the nested Rule elements.This results a redundancy in ObligationExpression and AdviceExpression elements but it will be overcome when mapping to another XACML profile.

Substitute Nested PolicySet Elements by Their Contents.
Generic-XACML is based on XACML but defines a specific arborescence of the elements.It contains a root PolicySet with an empty Target and a nested Policy element that has an empty Target as well and a set of nested Rule elements.In Section 4.2 we have proved that a Target of a Policy/PolicySet can be nested to their composite Rules/Policies/PolicySets without changing the global decision evaluation.In this section we prove that if a PolicySet is nested into another PolicySet, its Target is empty, and its combining algorithm is the same as the container PolicySet then it can be eliminated and substituted by its contents as illustrated in Figure 4.
1 . . .  are nested policies for the PolicySet NPSi and   is their number.
Let us prove that We use the multivalued approach presented in [29] where they define for each combining algorithm a lattice ( 6 , ≤  ), where  6 is the set {⊥,   ,   ,   , ⊤  , ⊤  } and the ordering ≤  is defined according to the combining algorithm specification.So the combining algorithm function applied to a set  of  6 is the least upper bound: the supremum (sup) of . Then We prove that If we follow the same reasoning as above and we suppose we have the same combining algorithm for all policies: the same ordering, we can prove that

Mapping from Generic-XACML to XACML Profiles
Once we obtain the Generic-XACML policy we can reform it into the desirable XACML profile.This involves encompassing Rules into policies and PolicySets according to the profile specifications.In this section, we describe how to map from Generic-XACML to a specific XACML profile.We follow two great steps: (1) Reproducing a customized policy conform to the profile specifications.
For both steps, the sorts of transformations we carry out are as follows: (i) Inserting container Policy or PolicySet elements having an empty Target element and the same combining algorithm as the initial policy.
(ii) Moving constraints that are common between the nested elements from their Targets to the Target of the container element.
(iii) Moving the ObligationExpression or AdviceExpression elements that are common between the nested elements to the container element.
These transformations do not affect the decision evaluation of the global policy as it is proved in the Section 4.

Conformance to Specific
Profile.For a generic policy to be conforming to profile specifications, it is transformed and customized by a specific algorithm that depends on the profile, and that differs from one profile to another.For illustration purposes we touch on RBAC and UCON profiles.

Mapping from Generic-XACML to XACML-RBAC
Profile.To translate a policy from Generic-XACML into XACML-RBAC profile we follow Algorithm 2.
In conformance with XACML-RBAC profile specifications, the resulting document will contain a root PolicySet element with an empty Target.On the other side, the original document is parsed.Then Targets of the Rules are browsed.So, for each possible value of the Subject we create a PolicySet element representing a Role and a nested PolicySet element with an empty Target representing the Role permissions.As for the PolicySet representing the Role, the Target will contain an imbrication of an AnyOf, an AllOf, and a Match element.The latter designates the current value of the Subject.Then, all Rules that contain a Match element that satisfy the current Subject are selected and inserted in a Policy element nested into the PolicySet representing permissions.Before rules are inserted, their Targets are altered in such a way to eliminate the Match element that designates the current value of the Subject.
Rules containing no Match element that designates a Subject are considered as Rules concerning all Subjects.Then these Rules are inserted into every PolicySet elements representing a role.Special Case.Algorithm 2 consists of factoring Rules into policies.The factor is a Match element that designates the Subject.This is only possible if Targets are logically expressed as conjunction of Match elements.If an AnyOf element contains more than one AllOf element the Target will be evaluated as a conjunction of disjunction of conjunction of Match elements.We cannot factorize by Match element.In this case, our algorithm will compare the AnyOf element as a whole rather than comparing only the Match element.[25] is an implementation for UCON ABC model [30]  Other constraints can be added to the algorithm depending on the profile specifications (e.g., Target of PolicySet representing a role in RBAC profile designates only Subject attributes).Special Case.Similarly to Algorithm 2, if an AnyOf element contains more than one AllOf element, the algorithm will compare the AnyOf element as a whole rather than comparing only the Match element.

Mapping from Generic-XACML to XACML-UCON Profile. XACML-UCON profile described in
As for obligations and advices, if all Rules within a Policy element have the same ObligationExpression or the same AdviceExpression element then this expression is moved to the parent Policy.

Conclusion and Future Research
In this paper, we propose Access Control in Cross-Organizational coLLABoration (ACCOLLAB) that tackles the problem of heterogeneity of access control models crossorganizations while respecting the internal access control model of each involved organization in a collaboration.
This solution is based on a mechanism for automatically mapping between policies in different models.We considered the previously proposed ontology-based semantic mapping process to deal with semantic correspondences and focus on syntactic transformations of the heterogeneous policies to propose a complete solution.
This automatic mapping is based on XACML profiles and the generic language Generic-XACML we have defined.Thus, we have given a logic proof for all of the mapping steps.
Thus, our generic access control model ACCOLLAB solves the heterogeneity problem, ensures the interoperability cross-organizations, and maintains the privacy of each collaborating organization.
We are working to implement our mapping algorithms using the XACML implementation Balana; then we are going to complete the implementation of the policy mapping architecture based on WSO2 servers.
Besides that, we intend to extend XACML in order to find equivalence between combining algorithms to make our proposed mechanism covering heterogeneous combining algorithms.

Figure 1 :
Figure 1: Architecture of policy mapping in cross-organizational collaboration.

Figure 2 :
Figure 2: Mechanism of policy mapping between heterogeneous models.

Figure 3 :
Figure 3: A pseudo code of the structure of a Generic-XACML policy.
Target.We prove that a Target of a Policy/PolicySet element can be nested to their composite Rule/Policy/PolicySet elements without changing the global decision evaluation.So that by repeating this transformation we obtain an empty Target for any Policy or PolicySet element.Proof.Let  = ⟨, 1 . . ., ⟩ be a representation of a Policy where  is the Policy Target,  = ⟨, , ⟩ for  ∈ [1 − ] are  nested Rules with  the Rule Target and  the condition for the Rule , and  is the combining algorithm.And let   = ⟨, 1  . . .  , ⟩ be the transformed Policy where the Target is empty and   = ⟨, ∧, ⟩ for any  ∈ [1 − ] are nested Rules with  ∧  is the conjunction of  and .
Proof.Let  be the Container PolicySet element and  with  ∈ [1 − ] be its Nested PolicySet elements.All of container and nested PolicySet elements have an empty Target.

4. 5 .
Merging All Policy Elements into One Policy.Now we prove that all nested Rules can be merged into only one Policy element if all Policy elements have the same combining algorithm.We show that this transformation does not affect the decision evaluation of the container PolicySet.Proof.Let  be the Container PolicySet and  for  ∈ [1 − ] be the nested Policy elements and  the resulting nested Policy.All of these elements, container PolicySet, the nested policies and the resulting Policy, have an empty Target and the same combining algorithm.The evaluations of , , and  are [] =  ([1] , . . .[]) (17) [] = ([1], . . .[  ]) for any  ∈ [1 − ], where 1 . . .  are nested Rules for the Policy  [] =  ([11] , . . .[1 1 ] , . . .[1] , . . .[  ])

Table 1 :
Possible values of XACML elements.

Table 2 :
Rules truth table.

Table 3 :
Policy truth table.
that fulfills XACML specifications and categorizes policies into 3 types: Authorizations, oBligations, and Conditions.The particularity of UCON is the Continuity of Usage and Mutable Attributes that are expressed as XACML Obligations within the Policy element.So, mapping to UCON profile consists of categorizing original Rules into three categories: Authorizations A, oBligations B, and Conditions C. Then each category is Input: XACML document Forall attribute categories do Forall Policy elements do evaluate rulesnumber of current policy; If rulesnumber ≥ 2 then //policy with one rule does not need optimization For i=1 to rulesnumber do parse Target of rule i; If Target designates current attribute category then CurrentValue:=value(attribute category); combinedRules[]:= rule i; For j=i+1 to rulesnumber do parse Target of rule j; If value(attribute category)= CurrentValue then combinedRules[]:= rule j; If length(combinedRules) ≥ 2 then If length(combinedRules) = rulesnumber then alter Target of current Policy element; alter combinedRules Targets; Else create sibling policy with Target designating CurrentValue for attr category; alter combinedRules Targets; move combinedRules to the new sibling policy; Algorithm 4: Optimizing policies.category values are combined into a sibling Policy (new Policy having the same parent as the current Policy).Its Target will contain an imbrication of an AnyOf, an AllOf, and a Match element.The latter designates the current value of the current category of attribute.If a resulting document contains a large number of Policy elements, this algorithm can be extended to combine Policy elements into PolicySet elements with the same instructions.