ACAL - 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 ACAL artifacts. The end goal would be to provide complete coverage of all the features in ACAL 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 short identifiers, 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 short identifier 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 short identifiers are not required.
In the XML representation it is always clear whether a name is a variable name or a short identifier because the name appears in an XML attribute that fixes the context, e.g., a name in a
VariableIdXML attribute is a variable name and a name in aDataTypeXML attribute is a short identifier. 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 short identifiers, though they may end up matching the same pattern.Even with short identifiers, an
AttributeDesignatororEntityAttributeDesignatoris far from convenient in a concise text representation of an expression. We would rather have a simple mnemonic name stand in for anAttributeDesignatororEntityAttributeDesignatorinstead of quoting theCategory,AttributeIdandDataTypeon every usage.EntityAttributeDesignatordoesn’t necessarily specify a category so it turns out cleaner to associate an attribute name with just theAttributeIdandDataType(andIssuerandMustBePresent, 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
MustBePresentdefaults to false. With appropriate short identifiers the declaration can become:The
product-codeattribute is a resource attribute so the text representation of anAttributeDesignatorfor this attribute prepends the identifier for the resource category:The short identifier for the resource category is assumed to be ‘resource’.
Despite the attribute name being the same as a short identifier in this example there is no ambiguity because an attribute name in the text representation is always preceded by a ‘.’ while a short identifier never is. Most attributes are associated with only one data-type so it is convenient to use the
AttributeIdshort identifier 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
Applyexpression 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 short identifier.Certain frequently-used functions have alternative representations as operators. The
andandorfunctions can be represented by theandandorinfix operators. Thenotfunction can be represented by thenotunary operator. Thetype-equalfunctions can be represented by the=operator (the type is determined by the arguments). Similarly for the relational operators<,<=,>and>=. Thetype-add,type-subtract,type-multiplyandtype-dividefunctions 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
notoperator 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=andandmakes more sense.A parser that follows the ABNF given later will automatically associate arguments according to these precedence rules.
We might also represent
integer-modby%andstring-equal-ignore-caseby~=.The
ForAnyquantified expression is represented by the keywordanyfollowed by the variable name, domain expression and iterant expression within parentheses and separated by colons. TheForAll,SelectandMapquantified 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 short identifiers and the
MustBePresentXML attribute is omitted (default false).A preamble will declare the
product-codeattribute: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
anyexpression 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 ACAL 1.0. The URIs are replaced with short identifiers, the
attribute-designatorfunction is replaced by theEntityAttributeDesignatorexpression and theMustBePresentXML attribute is omitted (default false).A preamble will declare the attributes used in this example:
A text representation of the expression is:
The
any-offunctions are explicit existential quantification, as are theanyexpressions. 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 ACAL 1.0. The URIs are replaced with short identifiers, the
attribute-designatorfunction is replaced by theEntityAttributeDesignatorexpression and theMustBePresentXML attribute is omitted (default false).A preamble will declare the attributes used in this example:
The
product-typeandae-product-typeare 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 thedestinationandae-destinationattributes.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 ACAL 1.0. The URIs are replaced with short identifiers, the
attribute-designatorfunction is replaced by theEntityAttributeDesignatorexpression and theMustBePresentXML 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 ACAL 1.0. The URIs are replaced with short identifiers, the
attribute-designatorfunction is replaced by theEntityAttributeDesignatorexpression, theTargetis converted to a boolean expression and theMustBePresentXML 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 short identifier 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 short identifier 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