XACML NG - Text Representation #54
steven-legg
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Introduction
This is an experiment in creating a domain-specific language, i.e. a text representation, for XACML artifacts. The end goal would be to provide complete coverage of all the features in XACML NG so that any policy in any representation can be translated to and from this text representation; this isn’t there yet.
I particularly wanted to push the envelope by considering how the capabilities introduced by the Entities profile might be represented. I’ve chosen examples out of the Entities profile and the Separation of Duties profile as test cases.
Before presenting the examples here are some notes on the text representation.
An identifier in the XML representation, which was exclusively a URI in XACML 3.0 but can now make use of shorties, is encapsulated in double quotes. The identifier can still be within double quotes in the text representation. However, in the case where the identifier is just a shortie name it can appear without the quotes.
These are equivalent representations of the identifier for the string data-type:
The last form would be the common usage, but we need to retain the full URI as an option because shorties are not required.
In the XML representation it is always clear whether a name is a variable name or a shortie because the name appears in an XML attribute that fixes the context, e.g., a name in a
VariableId
XML attribute is a variable name and a name in aDataType
XML attribute is a shortie. However, in a text representation of a policy these XML attribute cues will be missing, so we need another way to tell them apart. For this text representation I am choosing to distinguish variable names by prefixing a ‘$’ character to the variable name. Variable names are not shorties, though they may end up matching the same pattern.Even with shorties, an
AttributeDesignator
orEntityAttributeDesignator
is far from convenient in a concise text representation of an expression. We would rather have a simple mnemonic name stand in for anAttributeDesignator
orEntityAttributeDesignator
instead of quoting theCategory
,AttributeId
andDataType
on every usage.EntityAttributeDesignator
doesn’t necessarily specify a category so it turns out cleaner to associate an attribute name with just theAttributeId
andDataType
(andIssuer
andMustBePresent
, if desired) and nominate the category separately. This is the declaration of the product-code attribute used in the first example:No issuer is specified and
MustBePresent
defaults to false. With appropriate shorties the declaration can become:The
product-code
attribute is a resource attribute so the text representation of anAttributeDesignator
for this attribute prepends the identifier for the resource category:The shortie for the resource category is assumed to be ‘resource’.
Despite the attribute name being the same as a shortie in this example there is no ambiguity because an attribute name in the text representation is always preceded by a ‘.’ while a shortie never is. Most attributes are associated with only one data-type so it is convenient to use the
AttributeId
shortie as the attribute name as well in such cases.With the attribute declared we can now look at the text representation of an expression. An
Apply
expression is represented in the familiar style of a function call with the function identifier first followed by a comma-separated list of argument expressions within parentheses. The function identifier can be, and typically would be, represented by a shortie.Certain frequently-used functions have alternative representations as operators. The
and
andor
functions can be represented by theand
andor
infix operators. Thenot
function can be represented by thenot
unary operator. Thetype-equal
functions can be represented by the=
operator (the type is determined by the arguments). Similarly for the relational operators<
,<=
,>
and>=
. Thetype-add
,type-subtract
,type-multiply
andtype-divide
functions can be represented by the+
,-
,*
and/
operators.Precedence rules are required for these operators in the absence of parentheses. The following table defines the operator precedence from high to low.
Operators with the same precedence are applied from left to right in an expression. The precedence for the
not
operator follows typical programming language convention but I’m not convinced that is best for us. We can’t ‘not’ an arithmetic expression, so a precedence between=
andand
makes more sense.A parser that follows the ABNF given later will automatically associate arguments according to these precedence rules.
We might also represent
integer-mod
by%
andstring-equal-ignore-case
by~=
.The
ForAny
quantified expression is represented by the keywordany
followed by the variable name, domain expression and iterant expression within parentheses and separated by colons. TheForAll
,Select
andMap
quantified expressions follow the same pattern.Now for the examples. The examples in the Entities Profile are isolated expressions. The Separation of Duties Profile has full policies.
Entities Profile Figure 7
This is the XACML 3.0 expression as it appears in Figure 7 of the Entities Profile with the XML entity references expanded out:
Here is a rewriting of the expression for XACML 4.0. The URIs are replaced with shorties and the
MustBePresent
XML attribute is omitted (default false).A preamble will declare the
product-code
attribute:A text representation of the expression without using any infix operators is:
With infix operators:
The infix operators have single values as arguments (not bags) but if we apply a general assumption of implied existential quantification (the
any
expression above is explicit existential quantification) we can compare bags to single values and bags to bags. This assumption reduces the text expression to:Entities Profile Figure 9
This is the XACML 3.0 expression as it appears in Figure 9 of the Entities Profile with the XML entity references expanded out:
Here is a rewriting of the expression for XACML 4.0. The URIs are replaced with shorties, the
attribute-designator
function is replaced by theEntityAttributeDesignator
expression and theMustBePresent
XML attribute is omitted (default false).A preamble will declare the attributes used in this example:
A text representation of the expression is:
The
any-of
functions are explicit existential quantification, as are theany
expressions. They can all be simplified:This example shows referencing through related and nested entries.
Entities Profile Figure 11
This is the XACML 3.0 expression as it appears in Figure 11 of the Entities Profile with the XML entity references expanded out:
Here is a rewriting of the expression for XACML 4.0. The URIs are replaced with shorties, the
attribute-designator
function is replaced by theEntityAttributeDesignator
expression and theMustBePresent
XML attribute is omitted (default false).A preamble will declare the attributes used in this example:
The
product-type
andae-product-type
are effectively the same thing in different entities and could be unified as a single attribute in practice. The profile kept them separate for clarity. Similarly for thedestination
andae-destination
attributes.A text representation of the expression is:
Switching to implicit existential quantification:
Entities Profile Figure 12
This is the XACML 3.0 expression as it appears in Figure 12 of the Entities Profile with the XML entity references expanded out:
Here is a rewriting of the expression for XACML 4.0. The URIs are replaced with shorties, the
attribute-designator
function is replaced by theEntityAttributeDesignator
expression and theMustBePresent
XML attribute is omitted (default false).A preamble (the same as the preceding example) will declare the attributes used in this example:
A text representation of the expression is:
Switching to implicit existential quantification:
The preceding examples dealt with standalone expressions. The next example is a complete policy.
Separation of Duties Profile Example 8.1
This is the XACML 3.0 policy as it appears in example 8.1 of the Separation of Duties Profile with the XML entity references expanded out:
Here is a rewriting of the policy for XACML 4.0. The URIs are replaced with shorties, the
attribute-designator
function is replaced by theEntityAttributeDesignator
expression, theTarget
is converted to a boolean expression and theMustBePresent
XML attribute is omitted (default false).A preamble will declare the attributes used in this example:
A text representation of the policy is:
Switching to implicit existential quantification:
The collection of attribute assignment expressions is almost like an entity value constructor. We don’t currently have an entity value constructor (other than for literal values) but maybe we can exploit a synergy here.
Notation Defined in ABNF
Here is the ABNF definition of the grammar used for these examples. It provides substantial coverage but is not complete or unambiguous. The notation for attribute values definitely needs more work.
The simple pattern for shortie names is not intended to be final. If we get serious about a text representation then there are some reserved words here that should be prohibited as shortie names.
I’ve used commas to separate fields. I haven't looked closely at whether they have value in resolving ambiguity.
Implicit Existential Quantification and Determinism
The concept of implicit existential quantification (IEQ) allows for significant simplification of expressions but it also results in policies that don't have a single, definitive translation into the other syntaxes. Consider the case of an attribute compared to another attribute. First I need to define the attributes :
Suppose I want to test if the access-subject owns an approved device for the resource. With IEQ I can simply write:
This doesn't have a direct translation into, e.g., XML, because IEQ isn't a feature of the XML representation, but there are eight obvious, semantically equivalent expressions without IEQ that do have a direct translation:
There are other more exotic ways of getting the same effect.
So to translate the simple equality expression with IEQ into XML I have to choose one of the equivalent expressions without IEQ. So there are at least eight different outcomes from translating the simple equality expression. Going in the opposite direction, an expression in XML corresponding to one of those eight possibilities could be directly translated without loss, but the desirable outcome would be the simplest expression, which is the one with IEQ. Round-tripping that expression by translating back to XML would probably come up with something different from the original XML (though semantically equivalent), so it's lossy.
Translating between the text representation without IEQ and the other representations, and between the other representations, is one to one. Translating to and from the text representation with IEQ is many to many.
Beta Was this translation helpful? Give feedback.
All reactions