[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
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:
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:
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