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] | [List Home]


Subject: [xacml] Backgrounds of properties for new combining algorithm


Setting aside the discussion about how to handle priority (or the ordered
version of combining algorithm), I still feels the need for the property in
XACML. The following are backgrounds:

1) Placeholder for some information used in another access control policy
language

I think XACML can be used to represent various access control policy
language as a generic representation media. The problem occurs when a local
language holds extra information that cannot be mapped to the existing
XACML elements. In the following examples, I am assuming that a vendor uses
a new combining algorithm to simulate the semantics represented in XACML.

ASL (Authorization Specification Language) supports three hierarchies for
each rule (base rule, derived rule, decisional rule). By nature, it is
impossible to use standard combining algorithms to simulate their
semantics. Then the vendor develops the new algorithm. Although such
hierarchical information (base, derived, decisional) must be mapped to each
rule element to be correctly handled by the algorithm, there is no space to
put those information in the current schema.

Our XACL (XML Access Control) language supports some fine-grained semantics
of rules such as rule-wise propagation (none, upward or downward) on
resource hierarchy. In mapping to XACML, such propagation property must be
mapped to somewhere in XACML but there is no place in the current XACML
schema.

To support such mappings for the future languages, I think we need a place
holder to store it.

2) Placeholder for storing implementation specific information

This requirement is weaker than the previous one but still valid for
requiring property element of XACML.

Suppose a condition is a disjunctive clause consisting of functions and
each function varies in execution time (e.g. needs access DB or just
arithmetic computation). If we know that beforehand, it might be good to
attach such information to each apply statement. (e.g. fast, normal, slow)
to optimize the runtime performance of the disjunctive clause (usually the
evaluation should begin with the fastest function). Then such information
is consumed by vendor-specific implementation to optimize the performance.

Michiharu Kudo




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