Ernesto Damiani, Pierangela Samarati
Department of Information Technology
University of Milan, Italy
In this document some observations are made about what should be considered when specifying the XACML policy model and language. We sacrifice preciseness and, to some extent, rigorousness to conciseness and, hopefully, clarity. Of course, all the material covered by this document is pretty basic; our aim is to establish some common terminology and shared ground for discussion, as a preliminary to the evaluation of proposals. As many excellent documents about AC requirements and the relevant literature have already been posted to the group, we shall deal here with AC requirements only inasmuch they are relevant to modelling choices.
First of all, a clarification on the use of the term model: A security model defines in a precise and unambiguous way the security policy and its working. A model is usually expressed in a "formal" way to provide preciseness and unambiguousness.
Generally speaking, a model defines
We now discuss some open issues related to XACML standardization activity by posing three basic questions, each developed in a number of detailed questions followed by notes and hints for discussions. The list does not try to be exhaustive; comments and corrections are welcome.
Adopting a reference model means clearly providing implementers of XACML systems with the concepts of interests, such as policy, authorization, user/group, role, credential, resource, response and the like, together with:
More specifically, the model must define the kind of rules (authorizations) that can be specified.
Questions to address in this context include the following:
I. against which subjects authorizations can be specified ? (e.g., user identity, location, role, group, ..)
II. can authorizations have additional conditions ? (e.g., restriction-of-use or dynamic conditions such as payment procedures)
The model may be flexible with respect to some of the decisions that can be taken. For instance, the support of profiles associated with users can allow the specification of authorizations valid for all users satisfying a given property (e.g., like a dynamic group).
The model will have to include a description of the process for evaluating a request against a set of authorizations and returning the decision of whether the request should be denied or authorized. This response can also be a set of conditions that the requestor needs to satisfy to have her request accepted (e.g., accept an agreement). This notion will be developed later when dealing with questions about the operational semantics of enforcement.
Concept definitions are also important because they provide a basic vocabulary. Some of them may well be borrowed by overlapping work of other Oasis TCs. Concepts list as attributes all the information required to specify them, e.g. stating that subject identification is made via triples or quadruples.
Generalization hierarchies are commonplace in AC research.
Composition hierarchies may pose subtler problems, likely to have an impact on syntax definition (e.g., is, is there a canonical order for the authorizations composing a policy? Should the order in which they are written matter?).
As far as other relationships are concerned, examples of valid relationships are holds (a credential), plays (a role), belongs to (a group) or submits (a request). Regarding this kind of relationship, the positive side of adopting a reference model is that questions like “Must a user hold at least a credential to play a role?”, which often pop up in informal discussions, are readily and unambiguously answered simply by referring to the model.
Hints for discussion:
Many interesting models for AC have been proposed in the literature, including some by XACML TC members. It may be argued that starting with choosing or providing a full model definition, however elegant it may be, might have unforeseen impacts on implementations, especially because XACML systems will not be designed in a vacuum, but will have to co-exist with other systems (e.g., network- or operating system-based user authentication) that may pose constraints. Therefore, a layered approach could be adopted: a core model could be defined as a first step including the least possible amount of concepts (e.g., handling discretionary access control only), and subsequently adding layers (e.g. for role-based access control and credential handling). This could ensure the modularity of the XACML standard and pave the way to partial, nevertheless correct, reference implementations.
The TC charter clearly states that XACML will be defined via an XML namespace definition. Such namespace will have to complement other related namespaces (e.g., SAML). There is however a question related to model layering that should be addressed, namely:
Layering can be explicit (i.e. correspond to a specific notation) or implicit by means of XML Schema modularity.
While defining an XML namespace may seem somewhat arbitrary, the definition of standard mark-up languages is usually made by strictly following the guidelines given by the reference model. Specifically, model concepts are mapped into XML complex elements, while their attributes are mapped into XML simple elements or attributes. There are many technicalities to be taken into account in this deceivingly simple operation, e.g. the ones concerned with order mentioned above.
Hints for discussion:
Generalization hierarchies are usually dealt with using XML Schema is-a representation, while other hierarchies and relationships may be represented in XML using different techniques, such as elements, attributes or implicit/explicit links. Element inclusion can also be used, with some precaution, as it may have side effects. For instance, the fact that a policy is composed by authorizations can be modelled either specifying authorizations as sub-elements of a <policy> element (thereby implicitly defining an order among authorizations) or by providing implicit/explicit links from authorizations to the policies they belong to.
Question 3. How do we specify the semantics?
A clear specification of XACML semantics is crucial to the correctness of implementations. Aspects to be taken into account include:
Questions to be addressed include
I. Do we provide a formal definition? If so, which formal technique should we adopt?
Though the first mapping could be stated formally, e.g. by means of a common logical representation, it can be ensured by careful derivation of the XML syntax from the model itself accompanied by a clear explanation in natural language.
As far as the second mapping is concerned, there is an important problem to be taken into account. For some of the domains we are interested in (e.g. if XPaths and URIs are used to identify XML resources to be protected) the mapping is already defined by a standard: given an XPath, its mapping to an XML nodeset is unambiguously defined by XPath and XSLT. On the other hand, the mapping the domain of a protocol attribute into, say, TCP packet types or HTTP headers must be defined within XACML. This problem has been dealt with by other standardization efforts by limiting usable domains to standard resource spaces, such as Internet URIs. This may not be entirely possible in our case: for instance, how do we map to well-defined operations the values of an attribute action specifying the action that the subject is allowed to perform?
The operational definition of the enforcement process must be *unambiguous* and *deterministic* meaning the response to a request against a given state is unique. Note that a state includes besides authorizations all variables that can affect the process such as time and location of the request.
In defining the model we will have to decide whether the evaluation process is embedded in the model or can be flexible in some way. For instance, if we support both positive and negative authorizations, we can decide that our evaluation process always solves conflicts in a specific way; flexibility in handling conflicts can be provided giving the administrator the possibility of specifying how conflicts should be resolved (this can be done by associating priorities to the authorizations or allowing the specification of a conflict resolution policy -- as in Apache).
Hints for discussion:
The operational definition of enforcement is crucial to making predictable the behaviour of any XACML-compliant system when presented with a request and a policy. This definition is sometimes done in research papers simply by giving the algorithm used for enforcement. However, immediately providing pseudo-code for the XACML enforcement algorithm may be a bit of an overkill. Declarative definitions, e.g. via logic, could be contemplated; but many other standardization committees started with informal explanations and a set of meaningful examples.
 As suggested by Simon Blackwell, “we could have a core model or implementation that speaks only of groups since all roles could be mapped back to real or virtual groups by inverting the role tree”.