Schema "pdp.xsd" | XML Schema Documentation

<xs:import namespace="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"/>

<xs:import namespace="http://authzforce.github.io/xmlns/pdp/ext/3"/>

<xs:annotation>

<xs:documentation xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">

Data model of AuthZForce PDP configuration.

XML schema versioning: the

version

attribute of the root

schema

element identifies the

Major.Minor

version of this
schema. The

Minor

version is used for any backwards-compatible change. The

Major

version is
incremented after any change that is NOT
backwards-compatible.
The

Major

version part
must be suffix of the target namespace - but
not the

Minor

version - to
separate namespaces that
are not backwards-compatible.

</xs:documentation>

</xs:annotation>

<xs:element name="pdp">

<xs:annotation>

<xs:documentation>

PDP configuration

</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>

<xs:element maxOccurs="unbounded" minOccurs="0" name="attributeDatatype" type="xs:anyURI">

<xs:annotation>

<xs:documentation>

URI of an XACML attribute datatype to be added to supported datatypes. Policies require datatypes for function arguments and AttributeAssignment expressions. For every datatype,
there
must be one and only one Java class on the classpath - say

com.example.FooValueFactory

- implementing interface

org.ow2.authzforce.core.pdp.api.value.AttributeValueFactory

with zero-arg
constructor, and this URI must match the one returned by

new com.example.FooValueFactory().getId()

More info about Attribute Data-types is available on

<a href="https://github.com/authzforce/core/wiki/XACML-Data-Types">AuthzForce wiki</a>

</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element maxOccurs="unbounded" minOccurs="0" name="function" type="xs:anyURI">

<xs:annotation>

<xs:documentation>

URI of a XACML function to be added to supported functions. For every function, its return type and all its parameter types must be either standard mandatory ones enabled by

useStandardDatatypes

attribute, or custom ones declared in previous

attributeDatatype

elements; and there must be one and only one Java class - say

com.example.FooFunction

- on the
classpath implementing interface

org.ow2.authzforce.core.pdp.api.func.Function

with zero-arg constructor, and this URI must match the one returned by:

new com.example.FooFunction().getId()

More info about Functions is available on

<a href="https://github.com/authzforce/core/wiki/XACML-Functions">AuthzForce wiki</a>

</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element maxOccurs="unbounded" minOccurs="0" name="combiningAlgorithm" type="xs:anyURI">

<xs:annotation>

<xs:documentation>

URI of a XACML policy/rule-combining algorithm to be added to supported algorithms. There must be one and only one Java class - say

com.example.FooCombiningAlg

- on the
classpath
implementing interface

org.ow2.authzforce.core.pdp.api.combining.CombiningAlg

with zero-arg constructor, and this URI must match the one returned by:

new
com.example.FooCombiningAlg().getId()

More info about Policy and Rule Combining Algorithms is available on

<a href="https://github.com/authzforce/core/wiki/XACML-Combining-Algorithms">AuthzForce wiki</a>

</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element maxOccurs="unbounded" minOccurs="0" ref="tns:attributeProvider"/>

<xs:element maxOccurs="1" minOccurs="1" name="policyProvider" type="authz-ext:AbstractPolicyProvider">

<xs:annotation>

<xs:documentation>

XACML Policy Provider that resolves

Policy(Set)IdReference

s. There must be one and only one Java class on the classpath - say

com.example.FooPolicyProviderFactory

- implementing interface

org.ow2.authzforce.core.pdp.api.policy.CLoseablePolicyProvider.Factory<CONF_T>

with zero-arg constructor, where

CONF_T

is the JAXB type bound
to this XML element type.

More info about Policy Providers (how to make/use one) is available on

<a href="https://github.com/authzforce/core/wiki/Policy-Providers">AuthzForce wiki</a>

Implementation classes can use

org.ow2.authzforce.pd.api.EnvironmentProperties#replacePlaceholders()

method to replace

${property_name}

placeholders with such properties. You
may use

!

(exclamation mark) as a
separating character between the placeholder property name and a default value that is used if the property is undefined. E.g.

${PARENT_DIR!/home/foo/conf}

will be replaced with

/home/foo/conf

PARENT_DIR

is undefined.

In the location, you may use placeholders enclosed between

${

and

}

for the following properties:

<ul>

<li>

the global property

PARENT_DIR

for
defining - in a generic way
- a path relative to the parent directory to the XML file where this is used;

</li>

<li>

Java system properties;

</li>

<li>

System environment variables.

</li>

</ul>

</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element maxOccurs="1" minOccurs="0" name="rootPolicyRef" type="tns:TopLevelPolicyElementRef">

<xs:annotation>

<xs:documentation>

Identifies the root policy from which the policy evaluation begins. This identifier must be resolved by the Policy Provider configured previously (cf.

policyProvider

element). In case this is not specified, the policy returned by the

PolicyProvider#getCandidateRootPolicy()

method is used as root policy. Refer to the respective PolicyProvider's documentation for more information.

</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element maxOccurs="1" minOccurs="0" name="decisionCache" type="authz-ext:AbstractDecisionCache">

<xs:annotation>

<xs:documentation>

Decision cache that, for a given request, provides the XACML policy evaluation result from a cache if there is a cached result for the given request. There must be
one and
only one Java class on the classpath - say

com.example.FooDecisionCacheFactory

-implementing interface

org.ow2.authzforce.core.pdp.api.DecisionCache.Factory<CONF_T>

with zero-arg
constructor, where

CONF_T

is the JAXB type bound to this XML element type.

More info about Decision Cache extensions is available on

<a href="https://github.com/authzforce/core/wiki/Decision-Caches">AuthzForce wiki</a>

</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element maxOccurs="unbounded" minOccurs="0" name="ioProcChain" type="tns:InOutProcChain">

<xs:annotation>

<xs:documentation>

I/O processing chains if specific processing before and/or after policy evaluation by the PDP engine is required. Each chain must handle a different input datatype. In
other words,
there is no more than one I/O processing chain per supported input type, e.g. one for XACML/XML input, another for XACML/JSON input.

</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

<xs:attribute name="version" type="xs:token" use="required">

<xs:annotation>

<xs:documentation>

Version of the current schema for which the instance
document is valid. Must match the

version

attribute value of the
root

schema

element in the corresponding version
of
this
schema.

</xs:documentation>

</xs:annotation>

</xs:attribute>

<xs:attribute default="true" name="useStandardDatatypes" type="xs:boolean" use="optional">

<xs:annotation>

<xs:documentation>

Enable support for XACML core standard mandatory
datatypes. If

false

, only datatypes specified in

attributeDatatype

elements are available to the PDP, and therefore
only these
datatypes may be be used in policies.

</xs:documentation>

</xs:annotation>

</xs:attribute>

<xs:attribute default="true" name="useStandardFunctions" type="xs:boolean" use="optional">

<xs:annotation>

<xs:documentation>

Enable support for XACML core standard mandatory
functions. Requires

useStandardDatatypes=true

if true; if false, only functions specified in

function

elements are
available to
the PDP, and therefore only these
functions may be be used in policies.

</xs:documentation>

</xs:annotation>

</xs:attribute>

<xs:attribute default="true" name="useStandardCombiningAlgorithms" type="xs:boolean" use="optional">

<xs:annotation>

<xs:documentation>

Enable support for XACML core standard combining
algorithms. If false, only algorithms specified in

combiningAlgorithm

elements are available to the PDP, and therefore
only these
algorithms may be be used in policies.

</xs:documentation>

</xs:annotation>

</xs:attribute>

<xs:attribute default="REQUEST_ELSE_PDP" name="standardEnvAttributeSource" type="tns:StandardEnvironmentAttributeSource" use="optional"/>

<xs:attribute default="false" name="enableXPath" type="xs:boolean" use="optional">

<xs:annotation>

<xs:documentation>

Enable support for

AttributeSelectors

xpathExpression

datatype and

xpath-node-count

function. This
overrides

useStandardDatatypes

parameter, i.e.

xpathExpression

is
not
supported
anyway if

enableXpath

is false. This feature is
experimental (not to be used in
production) and
may have a negative
impact on performance. Use
with caution. For your
information,

AttributeSelector

and

xpathExpression

datatype support is marked
as
optional in XACML 3.0 core specification.

</xs:documentation>

</xs:annotation>

</xs:attribute>

<xs:attribute default="false" name="strictAttributeIssuerMatch" type="xs:boolean" use="optional">

<xs:annotation>

<xs:documentation>

true iff we want strict Attribute Issuer matching and we require that all AttributeDesignators set the
Issuer field.

Strict Attribute Issuer matching

means that an AttributeDesignator without Issuer matches only request
Attributes without Issuer. This mode is not fully compliant with XACML 3.0,
§5.29, in the
case that
the Issuer is not present in the Attribute Designator, but
it performs better and is recommended when all AttributeDesignators have an Issuer (best
practice). Indeed, the XACML 3.0
Attribute Evaluation section
§5.29 says:

If the Issuer is not present in the AttributeDesignator, then the matching of the
attribute to the named
attribute SHALL be governed by AttributeId and
DataType attributes alone.

Therefore, if

strictAttributeIssuerMatch

is false, since policies may use

AttributeDesignator

s without
Issuer,
if the requests are using matching Attributes but with
none, one or more different Issuers, this PDP
engine has to gather all the values from all the attributes with
matching Category/AttributeId but
with any Issuer or no Issuer. Therefore, in order
to stay compliant with §5.29 and still enforce best
practice, when

strictAttributeIssuerMatch =
true

, we also require that all
AttributeDesignators set the Issuer field.

</xs:documentation>

</xs:annotation>

</xs:attribute>

<xs:attribute default="2147483647" name="maxIntegerValue" type="xs:positiveInteger" use="optional">

<xs:annotation>

<xs:documentation>

Maximum absolute integer value. This is the expected maximum absolute value for XACML attributes of standard type

http://www.w3.org/2001/XMLSchema#integer

(requires

useStandardDatatypes
= true

). Decreasing this value as much
as
possible helps the PDP engine optimize the processing of integer
values (lower memory consumption, faster computations).

</xs:documentation>

</xs:annotation>

</xs:attribute>

<xs:attribute name="maxVariableRefDepth" type="xs:nonNegativeInteger" use="optional">

<xs:annotation>

<xs:documentation>

Maximum depth of Variable reference chaining:

VariableDefinition1 -> VariableDefinition2 -> ...

; where

->

represents a
VariableReference. It is recommended to
specify a
value for this attribute in production for security/safety reasons.
Indeed, if not specified, no maximum is enforced (unlimited).

</xs:documentation>

</xs:annotation>

</xs:attribute>

<xs:attribute name="maxPolicyRefDepth" type="xs:nonNegativeInteger" use="optional">

<xs:annotation>

<xs:documentation>

Maximum depth of Policy(Set) reference chaining:

PolicySet1 -> PolicySet2 -> ... -> Policy(Set)N

; where

->

represents
a

Policy(Set)IdReference

. It is
recommended to
specify a value for this attribute in production for security/safety reasons.
Indeed, if not specified, no maximum is enforced (unlimited).

</xs:documentation>

</xs:annotation>

</xs:attribute>

<xs:attribute default="0" name="clientRequestErrorVerbosityLevel" type="xs:nonNegativeInteger" use="optional">

<xs:annotation>

<xs:documentation>

Level of verbosity of the error message trace returned in case of client request errors, e.g. invalid requests. Increasing this value
usually helps the clients better
pinpoint the
issue with their Requests. This parameter is relevant to the Result postprocessor (

resultPostproc

parameter) which is expected to
enforce this verbosity level when
returning
Indeterminate Results
due to client request errors. The Result postprocessor must return all error messages in the Java stacktrace up to the same level as this parameter's
value if
the stacktrace is bigger, else the
full stacktrace.

</xs:documentation>

</xs:annotation>

</xs:attribute>

</xs:complexType>

<xs:key name="datatypeKey">

<xs:selector xpath="tns:attributeDatatype"/>

<xs:field xpath="."/>

</xs:key>

<xs:key name="functionKey">

<xs:selector xpath="tns:function"/>

<xs:field xpath="."/>

</xs:key>

<xs:key name="algorithmKey">

<xs:selector xpath="tns:combiningAlgorithm"/>

<xs:field xpath="."/>

</xs:key>

<xs:key name="refPolicyProviderKey">

<xs:selector xpath="tns:refPolicyProvider"/>

<xs:field xpath="@id"/>

</xs:key>

<xs:key name="attributeProviderKey">

<xs:selector xpath="tns:attributeProvider"/>

<xs:field xpath="@id"/>

</xs:key>

<xs:key name="requestPreprocKey">

<xs:selector xpath="tns:ioProcChain/tns:requestPreproc"/>

<xs:field xpath="."/>

</xs:key>

</xs:element>

<xs:element name="attributeProvider" type="authz-ext:AbstractAttributeProvider">

<xs:annotation>

<xs:documentation>

XACML Attribute Provider that provides attributes not already provided
in the XACML request from PEP, e.g. from external sources. There must
be one and
only one Java class on the classpath - say

com.example.FooAttributeProviderFactory

-
implementing interface

org.ow2.authzforce.core.pdp.api.CloseableDesignatedAttributeProvider.Factory<CONF_T>

with
zero-arg
constructor,
where

CONF_T

is the JAXB type bound to
this
XML element type. This Attribute
Provider may also depend on
previously defined

attributeProviders

, to find dependency
attributes, i.e.
attributes that
this
Provider does not support
itself, but requires to find its supported
attributes. Therefore, if
an

attributeProvider

AP1
requires/depends on an
attribute
A that is
not to be provided in the XACML request from the PEP,
another

attributeProvider

AP2
providing this attribute A must be
declared
before AP1.

More info about Attribute Providers (how to make/use one) is available on

<a href="https://github.com/authzforce/core/wiki/Attribute-Providers">AuthzForce wiki</a>

Such configurations (XML instances of this schema)
may use placeholders enclosed between

${

and

}

for the following properties:

<ul>

<li>

the global property

PARENT_DIR

for defining - in a generic
way - a path relative to the parent directory to the XML file where this is used;

</li>

<li>

Java system properties;

</li>

<li>

System environment variables.

</li>

</ul>

Implementation classes can use

org.ow2.authzforce.pd.api.EnvironmentProperties#replacePlaceholders()

to replace

${property_name}

placeholders with such properties.
You may use

!

(exclamation mark) as a separating character
between the placeholder
property name
and a default value that is used if the property is undefined.
E.g.

${PARENT_DIR!/home/foo/conf}

will be
replaced with

/home/foo/conf

PARENT_DIR

is undefined.

In the location, you
may use placeholders enclosed between

${

and

}

for the following properties:

<ul>

<li>

the global property

PARENT_DIR

for defining - in a generic way - a path relative to the parent directory to the
XML file where this is used;

</li>

<li>

Java system properties;

</li>

<li>

System environment variables.

</li>

</ul>

</xs:documentation>

</xs:annotation>

</xs:element>

<xs:simpleType name="StandardEnvironmentAttributeSource">

<xs:annotation>

<xs:documentation>

Defines the source for the standard environment attributes specified
in §10.2.5: current-time, current-date and current-dateTime.
The
options are:

<dl>

<dt>REQUEST_ELSE_PDP</dt>

<dd>

The default choice, that complies with the
XACML standard (§10.2.5):

If
values for these attributes are not
present in the
decision request,
then their
values MUST be
supplied
by
the context handler

. In our case,

context handler

means the
PDP. In other words, the
attribute values come from request by
default, or from the PDP
if (and *only if* in
this case) they are
not set
in the request.
More precisely, if
any of these standard environment attributes is provided in the request,
none of the PDP values is used, even if some
policy requires one that is
missing from the
request.
Indeed, this is to avoid such case when the decision request
specifies at least one date/time attribute, e.g.
current-time,
but not
all of them, e.g. not current-dateTime, and the policy
requires both the one(s) provided and the one(s) not provided.
In this case, if the PDP provides its own value(s)
for the missing
attributes (e.g. current-dateTime), this may cause some
inconsistencies since we
end up having date/time attributes coming
from two different sources/environments (current-time and
current-dateTime for instance).
In short, since this option introduces
some ambiguities with regards to the XACMl specification, we strongly recommend to use
the other options
below.

</dd>

<dt>REQUEST_ONLY</dt>

<dd>

Always use the value from the request, or nothing
if the value is not set in the request, in which case this results
in
Indeterminate (missing attribute) if the
policy
evaluation
requires it.

</dd>

<dd>

Always use the values from the PDP. In other words,
Request values are simply ignored; PDP values systematically
override the ones
from the request.
This also guarantees that
they
are
always set (by the PDP).
NB: note that the XACML standard
(§10.2.5) says: "If
values for these
attributes are not present in
the decision request,
then their
values MUST be supplied
by the
context
handler" but it does NOT
say "If AND ONLY IF
values..." So
this option could still be considered XACML compliant in a strict
sense.

</dd>

</dl>

</xs:documentation>

</xs:annotation>

<xs:restriction base="xs:string">

<xs:enumeration value="REQUEST_ELSE_PDP"/>

<xs:enumeration value="REQUEST_ONLY"/>

<xs:enumeration value="PDP_ONLY"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="InOutProcChain">

<xs:annotation>

<xs:documentation>

Pair of compatible PDP input/output processors - resp.

requestPreproc

and

resultPostproc

- where

compatible

means:

requestPreproc.getOutputRequestType() ==
resultPostproc.getRequestType()

</xs:documentation>

</xs:annotation>

<xs:sequence>

<xs:element name="requestPreproc" type="xs:anyURI">

<xs:annotation>

<xs:documentation>

URI of a XACML Request pre-processor to be enabled. A XACML Request
preprocessor is a PDP extension that applies some processing of the
request, such as
validation and
transformation, prior to
the
policy
evaluation. As an example of validation, a Request preprocessor
may reject a
request containing an
unsupported XACML element. As
an example of
transformation, it may support
the
MultiRequests
element, and more generally the Multiple Decision
Profile or
Hierarchical
Resource Profile by creating multiple
Individual
Decision
Requests from the original
XACML request, as defined in
XACML
Multiple Decision Profile specification, section 2; and then
call the
policy evaluation engine for each Individual
Decision
Request. At
the end,
the results (one per Individual Decision
Request)
may be combined by a Result postprocessor specified by next
attribute

resultPostproc

There must be one and only one Java class on the classpath - say

com.example.FooRequestPreproc

- implementing
interface

org.ow2.authzforce.core.pdp.api.DecisionRequestPreprocessor

with
zero-arg
constructor, and this URI must match the one returned by:

new
com.example.FooRequestPreproc().getId()

If the configuration parameter

enableXPath

is true, it is the
responsibility of the Request preprocessor to parse XACML
Request/Attributes/Content
nodes. If the configuration
parameter

strictAttributeIssuerMatch

is true, it is the responsibility of
the Request preprocessor to keep values of
Attributes with Issuer
separate from values of Attributes
without Issuer, in
the
attribute
map returned by

getNamedAttributes()

on
the
IndividualDecisionRequests produced by the Request preprocessor.

The following values of

requestPreproc

are natively supported:

<dl>

<dt>

urn:ow2:authzforce:feature:pdp:request-preproc:xacml-xml:default-lax

</dt>

<dd>

implements only XACML 3.0 Core (NO support for Multiple Decision)
and allows
duplicate <Attribute> with
same
meta-data in the
same <Attributes> element of a Request
(complying with XACML
3.0 core spec, §7.3.3)

</dd>

<dt>

urn:ow2:authzforce:feature:pdp:request-preproc:xacml-xml:default-strict

</dt>

<dd>

implements only XACML 3.0 Core (NO support for Multiple Decision)
and does not
allow duplicate
<Attribute>
with
same meta-data
in the same <Attributes> element of a
Request
(NOT complying
with XACML 3.0 core spec,
§7.3.3, but better
performances)

</dd>

<dt>

urn:ow2:authzforce:feature:pdp:request-preproc:xacml-xml:multiple:repeated-attribute-categories-lax

</dt>

<dd>

implements Multiple Decision Profile, section 2.3
(repeated
attribute
categories), and
allows duplicate <Attribute> with
same meta-data in the same
<Attributes> element of a Request
(complying with XACML 3.0
core spec, §7.3.3)

</dd>

<dt>

urn:ow2:authzforce:feature:pdp:request-preproc:xacml-xml:multiple:repeated-attribute-categories-strict

</dt>

<dd>

same as previous one, except it does not allow
duplicate
<Attribute>
with same
meta-data in the same
<Attributes> element of a Request (NOT complying with XACML
3.0 core spec,
§7.3.3, but better performances)

</dd>

</dl>

More info about Request Preprocessors is available on

<a href="https://github.com/authzforce/core/wiki/XACML-Request-Preprocessors">AuthzForce wiki</a>

</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element minOccurs="0" name="resultPostproc" type="xs:anyURI">

<xs:annotation>

<xs:documentation>

URI of a XACML decision Result post-processor to be enabled.
A decision Result post-processor is a PDP extension that process the
result(s) from the
policy evaluation before
the final
XACML
Response is created (and returned back to the requester). For
example, a
typical Result post-processor may combine
multiple individual
decisions -
produced by the

requestPreproc

- to a
single
decision
Result if and only if the XACML Request's

CombinedDecision

is
set to
true, as defined in XACML Multiple Decision Profile
specification,
section 3.
There must be one
and only one Java class on the classpath
-
say

com.example.FooResultPostproc

-
implementing interface

org.ow2.authzforce.core.pdp.api.DecisionResultPostprocessor

with
zero-arg
constructor, and this URI must match the one returned by:

new
com.example.FooResultPostproc().getId()

More info about Result Postprocessors is available on

<a href="https://github.com/authzforce/core/wiki/XACML-Result-Postprocessors">AuthzForce wiki</a>

</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="StaticPolicyProvider">

<xs:annotation>

<xs:documentation>

Policy(Set) Provider loading policies
statically from URLs. Any

PolicyIdReference

used in a PolicySet here
must refer to a
Policy loaded here as well. Besides, a
PolicySet
P1
must be loaded before any other PolicySet P2 with a reference
(PolicySetIdReference) to P1. As
PolicySets are loaded in the order
of declaration of

policyLocation

s, the order
matters for
PolicySetIdReference resolution.
This PolicyProvider implements the

PolicyProvider#getCandidateRootPolicy()

- the method provides a default root policy to be used when the PDP's configuration parameter

rootPolicyRef

is undefined - as follows:

<ul>

<li>

If there is one and only one XACML Policy provided (e.g. one or more

policyLocation

s are defined, pointing to one or more versions of the same XACML Policy), return the latest version of this Policy;

</li>

<li>

Else apply the same rule to XACML PolicySet(s);

</li>

<li>

Else no candidate (e.g. there is more than one XACML Policy and more than one XACML PolicySet, in which case the

rootPolicyRef

must be explicitly defined in PDP's configuration to make the choice).

</li>

</ul>

</xs:documentation>

</xs:annotation>

<xs:complexContent>

<xs:extension base="authz-ext:AbstractPolicyProvider">

<xs:sequence>

<xs:element maxOccurs="unbounded" minOccurs="1" name="policyLocation" type="xs:anyURI">

<xs:annotation>

<xs:documentation>

Location of the XML file that is expected to
contain the Policy or PolicySet element to be referenced by a
Policy(Set)IdReference in the root PolicySet loaded by a
root
policy
Provider. The location may also be a file pattern in the
form

file://DIRECTORY_PATH/*SUFFIX

file://DIRECTORY_PATH/**...*SUFFIX

, etc. (arbitrarily long sequence of wildcard characters) in
which case the location is
expanded to all
regular
files in
the directory located at

DIRECTORY_PATH

with suffix

SUFFIX

, not crossing directory boundaries if using a single wildcard; but crossing
directory boundaries if using more than a single wildcard (there
may not be
a SUFFIX; in
other words, SUFFIX may be an empty
string). The number of wildcards in the sequence

**....*

defines the
maximum number of directory levels to search.

In the location, you may use placeholders enclosed between

${

and

}

for the following properties:

<ul>

<li>

The global property

PARENT_DIR

for
defining - in a generic way - a path relative to the
parent directory to the XML file where this is used;

</li>

<li>

Java system properties;

</li>

<li>

System environment variables.

</li>

</ul>

You may use

!

(exclamation mark) as a separating
character
between the placeholder property name
and a default value that is used if the property is undefined.
E.g.

${PARENT_DIR!/home/foo/conf}

will be
replaced with

/home/foo/conf

PARENT_DIR

is undefined.

</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

<xs:attribute default="false" name="ignoreOldVersions" type="xs:boolean" use="optional">

<xs:annotation>

<xs:documentation>

true iff all versions of any policy must be ignored except the last, i.e. whenever there are multiple versions for the same policy ID, do as if only the last one exists.

</xs:documentation>

</xs:annotation>

</xs:attribute>

</xs:extension>

</xs:complexContent>

</xs:complexType>

<xs:complexType name="TopLevelPolicyElementRef">

<xs:annotation>

<xs:documentation>

Reference to a policy element, i.e. a XACML PolicySet or XACML Policy

</xs:documentation>

</xs:annotation>

<xs:simpleContent>

<xs:extension base="xs:anyURI">

<xs:attribute name="version" type="xacml:VersionType" use="optional">

<xs:annotation>

<xs:documentation>

If version is not specified, look for the latest version.

</xs:documentation>

</xs:annotation>

</xs:attribute>

<xs:attribute name="policySet" type="xs:boolean" use="optional">

<xs:annotation>

<xs:documentation>

policySet=true

, then look for a XACML PolicySet matching the identifier and versions if defined.
If

policySet=false

, then look for a XACML Policy matching the identifier and versions if defined.
If this attribute is not specified, look for a XACML Policy matching the identifier and version, then if not found, look for a XACML PolicySet matching the identifier and version.

</xs:documentation>

</xs:annotation>

</xs:attribute>

</xs:extension>

</xs:simpleContent>

</xs:complexType>