Hi David and Danny,
Thanks for your feedback. I agree that there probably is no
immediate
need to change the spec, itself to address this issue. However, I
think
it would be desirable to have a vocabulary for discussing XACML
security policies, recognizing that the terminology in the spec is
not well-suited for this job.
In particular, both Attributes and Category are flawed in similar
fashions
in the sense that subdivide a larger concept and also represent that
concept as well. If we just look at the vocabulary of simple
grammar,
we can see the issue. The two major grammatical entities are noun
and verb, and they have associated modifiers: adjective and adverb
respectively. i.e.
- a noun can have zero or more adjectives describing and
classifying it.
- a verb can have zero or more adverbs describing and
classifying it.
The XACML 3.0 "vocabulary" scheme applied above would effectively
replace the term "noun" with the term "adjectives", and the term
"verb"
with the term "adverbs".
Using 2.0 as a conceptual baseline, we basically had the following
model:
The PEP submits an "Authorization Request" to a PDP
specifying:
- a set of attributes describing the "Subject" who is making
the request
- a set of attributes describing the "Resource" to which
access is being requested
- a set of attributes describing the "Action" that is being
requested to perform if access is granted
- a set of attributes describing the "Environment" in which
this access is taking place
The PDP returns an "Authorization Response" that the PEP is
obligated to enforce, specifying
- the "Decision" that has been made for the request
- sets of attributes associated with "Obligations" the PEP is
expected to fulfill associated w the request
XACML 2.0 went further and specified that there were different
"kinds" of
Subjects that could be involved in a single request, and represented
this
as a "Category attribute" associated with the Subject element, such
that
a single request could have multiple Subjects associated with it, as
long
as each Subject had a distinct "Category" attribute.
The terms that are needed in 3.0 are the following:
- A general term, such as "Entity" or "Object" or "Actor", etc.
to refer to
any of the high level constructs: Subject, Resource, Action,
Environment.
In 2.0 the term "entity" was almost used for this purpose, in
the sense
that it showed up properly in several places, but was not
formalized.
Unfortunately, in 3.0, the term "Attributes" was used for this
purpose,
which is redundant "Attribute" which is used do describe each
high
level entity.
- A term to subdivide a high level entity object into specific
subtypes.
Unfortunately, the term "Category" is used as a 2 dimensional
divider
in 3.0, to both subdivide the Entities between each other and to
subdivide a single entity w sub-types of the high level entity.
This approach is totally extensible, and allows for:
- new Entity types to be defined, if necessary
- new sub-types to be defined within an Entity type
Note: if we try to substitute the term "category" as used in 3.0
for the term "type", it breaks down, because there is no provision
for a "sub-category" in 3.0.
A final comment is that, again, the purpose of this email is to
"suggest"
an improvement to the language we use to describe the XACML
specification and concepts, which is intended to augment/replace
the current terminology, which does not translate to sensible
grammatical constructs.
I would be satisfied with any set of 3 terms, I suppose, that
capture:
- entity
- entity-type
- sub-type of entity-type
Thanks,
Rich
On 7/28/2012 1:01 PM, David Brossard wrote:
I agree with Danny.
In the future though, maybe we should call a set of attribute
elements a category or category instance or a facet, but not
entity. After all, the set of attributes does describe that.
There are other items that would probably require streamlining in
XACML 4.0 such as the presence of conditions at all levels, the
renaming of policy set to policy and changing policies so that
they can contain policies and rules (to eliminate policy sets).
Do we want to start a list with all the items we would want to
change?
Cheers,
David.
On Sat, Jul 28, 2012 at 12:34 AM, Danny
Thorpe <Danny.Thorpe@quest.com>
wrote:
I appreciate the desire to make the
XACML schema element names fit more naturally into
English grammar patterns, but now is really not the
time to be introducing breaking changes into the XACML
3.0 spec. XACML 3.0 is already out the door with
implementations in the field. All we have remaining
is the TC formality of crossing T’s and dotting I’s
and declaring it done. Let’s not derail that process.
Awkward as the current element names may be, let’s
just accept it and push ahead.
We can take this up again when new
feature work requires breaking schema changes and
forces us to bump the spec version to 4.0.
Sincerely,
-Danny
Danny Thorpe
Product Architect |
| Quest Software - Now including the people
and products of BiTKOO |
www.quest.com
To
TC:
This is an issue that has been bugging me for some
time, and I have tried
to raise it in years past. Since we have a fairly
new group participating now,
I am going to re-raise it to see if it resonates
more than it has in the past.
This issue has existed since XACML 2.0 and before,
but XACML 3.0 raises
it to what I consider a crisis level, and if we
hope that XACML will gain
wide-spread acceptance, my suggestion is that we
fix it sooner, rather
than later, preferably in XACML 3.0, but if not
then, then immediately
thereafter.
The issue is that the XACML 3.0 <Attributes>
element (plural) is not only
misnamed, but misnamed in such a way as to render
the XACML Policy
model indescribable using common English grammar.
I think the problem is best described by a simple
analogy. Let's consider
an application for a bookstore where the
application did stuff associated
with "books". Now, in order to write this
application, the developers
came up with an XML model for books, and
presciently recognizing
that books, in general, are comprised of
"chapters" decided to represent
the book as a collection of <Chapter>
elements.
Now, the developers recognized that they would
need to be dealing
with collections of these <Chapter>
elements, and decided to name
the collection <Chapters>.
So, now in a truly efficient manner, we can
represent a book as follows:
<Chapters title="Gone w the
Wind">
<Chapter chapnum="One">
<Chapter chapnum="Two">
...
In the process we have tossed
out the word "book" since we no longer
need it to represent the collection of chapters.
Now, we are faced with the following problem when
talking about
this application. Let's say we wanted to know how
many books
an author has written, we'd have to say something
like:
"How many <Chapters>s has
author X written?"
Similarly, if we wanted to know
how many chapters of a specific
book a person has read, we would say something
like:
"How many <Chapter>s of
the <Chapters> you bought have you read?"
This is exactly the position
that using the name <Attributes> to
represent
a collection of <Attribute>s puts us in.
Policies are written to determine what Subject
entities are authorized
to perform what Action type on what Resource
entities under what
conditions in the Environment scope.
XACML 3.0 provides no convenient way to talk about
these entities
that are the main components about which Policies
are written,
without first defining a parallel vocabulary and
grammar that
can be used to resolve the obvious ambiguities
that result
from using the XACML element and attribute names.
One suggestion to resolve this issue would be:
Replace the term
<Attributes>
with the term <Entity>
Every application deserves to
have an "Entity element" to represent the
general notion of an object that is a significant
component of the
application's operational structure. Objects can
have a category
that represents the type of object it is to
distinguish between
different objects in semantic descriptions of the
application.
One final note is that the term "entity" is used
in the XACML spec,
sometimes in the sense described above, other
times to describe
things like a PDP vs a PEP, and other times where
it doesn't seem
to represent anything at all, for example in
section 5.9 <Match>,
the Match element is defined as:
"The <Match> element
SHALL identify a set of entities
by matching attribute values
in an <Attributes> element of the request
context
with the embedded attribute value."
I
cannot seem to come up with anything meaningful
that
the above statement is saying or even trying to
say.
My understanding is that similar to a
<Condition> element,
that a <Match> element is "a Boolean
function over attributes".
In any event, the purpose of this email has been
to try to raise
awareness of what I consider to be a pretty
serious issue wrt
usability of the XACML specification, namely
simply being able
to talk about the spec and what it means in real
world terms.
Thanks,
Rich
--
David Brossard, M.Eng, SCEA, CSTP
Product Manager
+46(0)760 25 85 75
Axiomatics AB
Skeppsbron 40
S-111 30 Stockholm, Sweden
Get your free XACML 3.0 editing tool: the ALFA plugin for
Eclipse at http://www.axiomatics.com/axiomatics-alfa-plugin-for-eclipse.html
http://www.linkedin.com/companies/536082
http://www.axiomatics.com
http://twitter.com/axiomatics
|