OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: What needs to be specified by the XACML policy model?


Please find enclosed a (strawman) contribution by Pierangela and myself. The title should be self-explanatory :-). A copy in HTML is also attached.
I hope this document may be of some use at this stage of our discussion. Simon already provided some observations I tried to take into account. Corrections, comments, etc. are very welcome.  
Rgds to all
 
Ernesto
 
 
Prof. Ernesto Damiani
Dipartimento di Tecnologie dell'Informazione
Università di Milano - Polo di Crema
Via Bramante 65 26013 Crema, Italia
tel 0373-898240
fax 0373-898253

What needs to be specified by the XACML policy model.doc

Title: What needs to be specified by the XACML policy model

What needs to be specified by the XACML policy model?

 

Ernesto Damiani, Pierangela Samarati

Department of Information Technology

University of Milan, Italy

 

Introduction

 

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.

 

Preliminary observations

 

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

  1. The syntax used to specify concepts of interest and their relationships. Syntax can be specified as a formal grammar, in a visual fashion or using any suitable interchange format definition technique such as XML DTDs or Schema. Goals of syntax specification that can be readily reached using XML include:
    1. Machine and human readability
    2. Multiple encoding, including some character based representation (ensuring low obsolescence)
    3. Modularisation and easy expandability
    4. Fast parsing

 

  1. The concepts’ and relations’ semantics, i.e. the definition of suitable domains for attribute values via a formal or semi-formal mapping between the syntax granules and the objects of another domain, e.g. a resource space. The expressive power of a syntax roughly amounts to how precise and complete this mapping can be.

 

  1. The operational definition of enforcement.

 

 

Open Issues

 

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.

 

 

Question 1. What should the XACML reference model  specify?

 

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:

 

  1. generalization hierarchies
  2. composition hierarchies (e.g. for policies and resources)
  3. legal relationships between concepts

 

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)

       III.      can authorizations be in positive and/or negative form ?

        IV.      are relatioships among policies represented in the model? If so, how?

 

Notes:

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)[1]. This could ensure the modularity of the XACML standard and pave the way to partial, nevertheless correct, reference implementations.

 

 

Question 2. How do we specify the syntax?

 

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:

 

             I.      Do we support model layering in syntax definition? If so, how?

 

Layering can be explicit (i.e. correspond to a specific notation) or implicit by means of XML Schema modularity.

 

Notes:

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:

 

  1. The mapping between XACML syntactic granules (XML elements and attributes) and the reference model concepts and relations.
  2. The mapping between domains of attributes’ values and the involved resource spaces.
  3. The operational definition of enforcement.

 

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?

 

Notes:

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.

 

 



[1] 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”.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC