xacml — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
proposal for #27
MHonArc v2.5.0b2 -->xacml message
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: proposal for #27
- From: Seth Proctor <[email protected]>
- To: [email protected]
- Date: Mon, 22 Dec 2003 15:55:38 -0500
Work Item 27 proposes a version string for policies, such that revised
policies can be recognized in a standard way. This will also allow
policy references to specify version constraints, which is especially
important if the referenced policy may change in ways that the
referencing policy can't handle. In brief, the new features are:
1. Define a new type that describes a dotted version string (eg 1.2.3),
and a couple of very simple regular expression characters to match
these version strings: * for a single value, and + for any trailing
values. For example, both 2.*.4 and 2.+ match 2.3.4. I think that
using a full-blown regexp syntax is overkill and will make this less
useful, but since there is already a requirement in XACML to support
pattern matching, I'm willing to discuss this issue.
2. Include a new XML attribute in Policy and PolicySet that uses the
new version type to optionally declare the policy's version. If not
included, then the version is defined to be "1.0".
3. Include three new (optional) XML attributes in PolicyIdReference and
PolicySetIdReference. One attribute defines a single version string
(or regular expression) that matches a required version or set of
versions. The other two attributes decribe the earliest and latest
acceptable versions (or regular expressions). Any combination of
these attributes may be used. If none of the three is included, then
any version is acceptable (this is like using "+" in all three
attributes). In all cases, the most recent version available should
be used.
If none of the attributes from items 2 and 3 is used, then policies
and references look and act exactly as they do in 1.0/1.1. I think that
this is the right way to go.
The schema changes might look something like this (note that I haven't
run these through a schema checker, but I think they're about right):
<xs:element name="PolicySetIdReference" type="xacml:IdReferenceType"/>
<xs:element name="PolicyIdReference" type="xacml:IdReferenceType"/>
<xs:complexType name="IdReferenceType">
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="Version" type="VersionMatchType"
use="optional"/>
<xs:attribute name="EarliestVersion" type="VersionMatchType"
use="optional"/>
<xs:attribute name="LatestVersion" type="VersionMatchType"
use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="PolicyType">
...
<xs:attribute name="Version" type="VersionType" use="optional"
default="1.0"/>
...
<xs:complexType name="PolicySetType">
...
<xs:attribute name="Version" type="VersionType" use="optional"
default="1.0"/>
...
<xs:simpleType name="VersionType">
<xs:restriction base="xs:string">
<xs:pattern value="(\d+\.)*\d+"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="VersionMatchType">
<xs:restriction base="xs:string">
<xs:pattern value="((\d+|\*)\.)*(\d+|\*|\+)"/>
</xs:restriction>
</xs:simpleType>
Given this, there is a very simple system for defining the revision
number of a policy, and for ensuring that you're referencing an
acceptable version (if needed). This is also very useful for policy
writers and management tools. Comparison is done using simple equality
and greater-than/less-than, and the regular expressions are fairly
trivial to use. Thoughts?
Note that this intentionally doesn't say anything about how policies are
retrieved. As with the current mechanisms, the version tags can be used
as hints in indexing policies or in deciding which policies to fetch,
but only one policy may be presented for evaluation. Also, while it's
probably best to present the most recent version of a policy, a custom
retriever may decide to use some other heuristic (eg, the oldest one)
that makes sense in a given environment.
seth
ps I'll be (mostly) on vacation until the new year, though I'll try to
keep up with my email for the next week. Happy holidays all!
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]