[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Minutes from March 2002 Face-to-Face
The draft minutes are attached. Please send me corrections or additions. Anne -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
Minutes of OASIS XACML Technical Committee Meeting
March 11-12, 2002
Burlington, MA
Scribe: Anne Anderson
CONTENTS:
o ACTION ITEMS
o ATTENDEES
o SUMMARY
o AGREEMENTS REACHED
o DEFERRED ISSUES AND QUESTIONS
o DETAILED NOTES
ACTION ITEMS:
[Tim] Update specification to Version 11, incorporating decisions
from this meeting.
[Tim, Michiharu] Propose specific set of mathematical operators
and associated syntax appropriate for XACML requirements.
Present at the subcommittee meeting on March 25, 2002.
[Hal, Konstantin] Provide more verbal text describing function
and use of the various element types. To be done after Tim
provides Version 11. The verbal text might be a type of
"primer" on XACML; something to introduce XML neophytes to the
way the language is intended to be used.
[Carlisle] Determine availability of sites and dates for next
face-to-face meeting. Date preference order: week of April 15,
week of April 22, week of April 29. Location preference order:
Univ. of Milan (Ernesto,Pierangela), SF Bay area (Ken),
Manhattan Beach (Bill), Burlington (Anne, Sekhar).
Constraints: Michiharu not available week of April 29. Sekhar
has problems with weeks of April 15 or April 22.
[All] Determine acceptability of Univ. of Milan as a site for the
next face-to-face meeting.
ATTENDEES:
Voting members:
Michiharu Kudo (IBM), Hal Lockhart (Entegrity), Sekhar Vajjhala
(Sun Microsystems), Carlisle Adams (Entrust),
Don Flinn (Hitachi), Bill Parducci (self), Polar
Humenn (Syracuse Univ.), Simon Godik (self), Anne Anderson (Sun
Microsystems), Tim Moses (Entrust), Pierangela Samarati
(Univ. of Milan)
Probationary members:
Konstatin Beznosov (Hitachi) (konstantin.beznosov@quadrasis.com)
SUMMARY:
We resolved most issues related to the overall policy model. The
following chart lists overall areas that are still OPEN, those on
which we are in AGREEMENT, and those where we have done some
work, but need more work (?). Most of the OPEN areas have to do
with details of the XML syntax rather than the policy model
itself.
Operators Boolean ? [1]
Math OPEN
Predicates Predefined ? [2]
Definition OPEN
Values Boolean ? [1]
Math OPEN
SAML:attribute OPEN
Expression Boolean ? [1]
Math OPEN
Condition ? [1]
Obligation AGREEMENT
Obligation arguments OPEN
rule ref AGREEMENT
statement AGREEMENT
ruleCombiner OPEN
ruleSet AGREEMENT
policy ref AGREEMENT
statement AGREEMENT
saml:assertion AGREEMENT
policySetCombination OPEN
policySet AGREEMENT
policyCombination ref AGREEMENT
statement AGREEMENT
saml:assertion AGREEMENT
[1] We have not written out and agreed upon Boolean expressions,
but we expect we are in agreement modulo nits.
[2] We have discussed some predicates that would be predefined,
but there is more closure required on this.
AGREEMENTS REACHED:
Three major elements from which a policy is constructed:
1. low level <rule>s,
2. <policyStatement>s that combine rules, and
3. <policyCombinationStatement>s that combine policies.
<rule>
<target>
<subject>..</subject>
<action>..</action>
<resource>..</resource>
</target>
<ruleMetaData name="anyURI" value="any"/>
<condition>
[arbitrary boolean predicate over subject, action, resource]
</condition>
<effect>..</effect> [CHOICE: Permit or Deny]
<obligations> [OPTIONAL]
<obligation>
<obligation>
...
</obligations>
</rule>
<target> allows efficient indexing. <target> MUST contain only
references that will always be available in the SAML request
because the <target> MUST NOT return an "indeterminate" result.
Another reason for requiring <target> references to be readily
available is to support the use of <target> for efficiently
eliminating clearly inapplicable <rule>s without requiring
extensive evaluation.
A <rule> can produce one of three possible results: grant/deny,
inapplicable, indeterminate. The same <rule> will never return
"grant" from some <authorizationDecisionRequests> and "deny" from
others: a <rule> has a single associated <effect> and either
returns that one effect or inapplicable or indeterminate.
The <condition> element participates equally with the <target>
element in determining the applicability of the <rule>. <target>
is the easily-computed first stage, and <condition> is the
arbitrarily complex second stage.
<rule> Truth Table:
Target Condition Effect
------ --------- ------------
T T [Effect]
T F Inapplicable
T Indet. Indet.
F T Inapplicable
F F Inapplicable
F Indet. Inapplicable
Scope of <rule> does not go beyond the <policyStatement> that
references it.
Policy is smallest unit that can be signed. Rules can stand by
themselves, but can't be signed. Policy can include a hash of
the actual syntax content of a <rule>. In this case, the policy
writer wants this particular <rule> content. If no hash, then
then policy writer wants current rule associated with this
<ruleId>. Example: a <ruleId> may be associated with the
semantic "conditions under which someone is allowed to access
Anne's files". Anne may change the specific conditions over
time, but might retain the same <ruleId> so that the current rule
can be referenced in a policy without having to rewrite the
policy.
<policyStatement> extends saml assertion:
<MajorVersion>
<MinorVersion>
<IssuerInstant>
<Issuer>
<AssertionId>
<policyStatement>
<target>
<subjects>
<resources>
<actions>
</target>
<ruleSet Combiner="myURI">
<ruleDesignator>
<ruleMetadata>
<ruleReference> or <ruleInstance>
</ruleDesignator>
<ruleDesignator>...</ruleDesignator>
<obligations>
<onPermit>
<obligation uri="myobligation1" value="abc"/>
<obligation uri="myobligation2" value="cde"/>
</onPermit>
<onDeny>
<obligation>
</onDeny>
</obligations>
</ruleSet>
</policyStatement>
<policyStatement> Evaluation Table:
Target RuleSet Result
------ ------- --------
match [effect] [effect]
match Inappl. Inappl.
match Indet. Indet.
no-match Inappl.
<ruleReference uri="http://..."
authority="..."
hash="..." [OPTIONAL: only if ruleId content must be fixed]
</ruleReference>
A <ruleSet> is a set of <rule>s along with a way to combine the
rules. A <ruleSet>s "combiner" is a URI associated with a
description of the algorithm for producing a result from the
given set of rules. The "combiner" MAY be a textual
description.
Examples of possible <rule> combiners:
o If any <rule> evaluation returns "inapplicable", "deny", or
"indeterminate", return "deny". Otherwise, return "permit".
o If any <rule> evaluation returns "deny" or "indeterminate",
return "deny". Otherwise, if at least one <rule> evaluation
returns "permit", return "permit". Otherwise, return
"inapplicable".
o Return effect of the rule whose <target> "most closely
matches" the request (for some definition of "most closely
matches").
o Return effect of first rule from list that returns "permit"
or "deny".
<policyCombinationStatement>
<target>
<subjects>
<resources>
<actions>
</target>
<policySet Combiner="myURI">
<policyDesignator>
<policyRef> or <policyStatement> or
<policyCombinationRef> or <policyCombinationStatement> or
<saml:assertion>
<policyMetadata>
</policyDesignator>
<policyDesignator>...</policyDesignator>
<obligations> OPTIONAL
<onPermit>
<obligation uri="myobligation1" value="abc"/>
<obligation uri="myobligation2" value="cde"/>
</onPermit>
<onDeny>
<obligation>
</onDeny>
</obligations>
</policySet>
</policyCombinationStatement>
The <policyCombinationStatement> "combiner" is a URI associated
with a description of the algorithm for producing a result from
the given list of policies. The "combiner" MAY be a textual
description.
If you want to select policies based on data other than <target>
and <ruleSet>, then you have to embed policyStatement in SAML
assertion. Then the "combiner" can select on things like the
issuer of the policy, whether policy is signed, etc.
We may decide for simplicity to remove some choice options from
<policyCombinationStatement> in Version 1.0, but we are going to
leave it all in for now and flesh it out.
We will use the term "obligation" to mean what we have previously
been calling "post condition".
An Obligation is specified via URI and optional value attribute.
<policyStatement>
<target>
<subjects>
<resources>
<actions>
</target>
<ruleset>...</reuleset>
<obligation>
<onPermit>
<operation uri="http://www.xyz.com/obligation/log"
value="abc" />
</onPermit>
</obligation>
</policyStatement>
The set of <obligations> returned by each level of evaluation
includes only those <obligations> associated with the <effect>
being returned by the given level of evaluation. For example, a
<policySet> may include some policies that return Permit and
other policies that return Deny for a given request evaluation.
If the policy combiner returns a result of Permit, then only
those obligations associated with the policies that returned
Permit are returned to the next higher level of evaluation. [If
the PDP's evaluation is viewed as a tree of
policyCombinationStatements, policyStatements, and rules, each of
which returns "Permit" or "Deny", then the set of <obligations>
returned by the PDP will include only the obligations associated
paths where the effect at each level of evaluation is the same as
the effect being returned by the PDP.]
If the PEP does not understand an obligation, it should deny access.
The PDP just collects obligations.
policyStatement and policyCombinationStatement allow determinism:
their "combiner"s can control order or completeness of
evaluation. If determinism is desired at the expense of
performance, then the combiner algorithms can force evaluation of
all rules and policies.
XACML will not define "profiles" for specific application domains
such as J2SE. XACML will try to anticipate issues that may arise
in using XACML within various domains, and may give examples of
how those issues can be resolved using XACML.
DEFERRED ISSUES AND QUESTIONS:
This is a list of issues and topics that came up, but that we
deferred. Some of these may have been effectively closed, but I
am erring on the side of caution in listing possible open issues
here.
[Sekhar]PDP-oriented versus Policy Writer oriented? Wants to
keep all rules from one policy writer as a discrete collection.
What do you call this thing?
Exchanging <rule>s: is this valid XACML?
[Carlisle]Does PRP/PDP have a base policy? Does PDP publish its
base policy?
[Anne/Sekhar]See a need to allow a PEP to provide a Base policy
to the PDP as part of or in conjunction with the
authorizationDecisionQuery.
[Tim]Special case for hierarchical subjects and resources to
make merging targets simpler. Or is higher-level target just
the union of lower level targets? Anne: but doesn't this only
apply when the meta-policy uses "closest match"?
[Anne]Is higher-level target derived or declared? If derived, by
whom? On what trigger? At time a new <rule> or
<policyStatement> is added to a list?
Which <rule> combiners will we spell out?
[Carlisle]Extensibility points. Is <rule><effect> extensible?
If additional values, then have to define a new
<rule> combiner that references them?
[Simon] syntax for referring to resource in SAML
authorizationDecisionQuery. This is a SAML and XACML syntax
issue: they have to be coordinated.
How do we know whether an attribute is of subject, resource,
etc.?
How is obligation returned to PEP? SAML changes required. [Hal]
Is a SAML response that has advices and conditions the right way
to return obligations.
[Konstantin] can same PDP, with different extension profiles,
handle J2EE, J2SE, .NET, etc.?
[Anne] Does Predicate in referencing an attribute need the
attribute authority name, authority key, ClassName, class base
location?
[Hal] Need to have way to restrict XACML to subsets so that a
given PDP/PRP can handle. E.g. PDP might be "J2SE-compliant".
E.g. [blue sky] limit on numbers of rules, only certain
combiners supported, limits on # of levels of
policyCombiners, only certain ways to reference a policy
inside a policyCombinationStatement, only those things required
to support J2SE. Spell out to a PAP how it is limited to apply
to a given PDP. PDP spells out what it can support.
[Konstatin] wants more verbal text around element types. Have
UML as well as XML. Purpose is to sell ideas behind XACML to
someone who does not understand XML.
Are obligations mandatory to implement for XACML compliance?
DETAILED NOTES:
These are my sequential notes. I have made some of the
terminology a bit more consistent with our final agreements, but
in general, information is presented here as it evolved.
Syntax often represents intermediate discussion proposals, and
should not be confused with the AGREEMENTS REACHED above.
Agenda:
Monday, March 11
9:00 a.m. - 5:00 p.m. (or later):
- aside from roll call, etc., for the first 10 minutes or so,
we take as much of the day as necessary to come to consensus
on the definition and high-level contents of
RULE,
("basic" or "elementary") POLICY,
("compound" or "higher-level") POLICY, and
META-POLICY
- breaks: roughly 10:30-10:45; 12:00-1:00; 3:00-3:30
- be prepared to camp out in the Sun conference room if
necessary. I would really like these basic definitions to
be closed before we adjourn on Monday.
Tuesday, March 12th
9:00-10:30: Post-conditions / Obligations discussion (led by Michiharu)
10:30-10:45: BREAK
10:45-11:15: Post-conditions / Obligations discussion
11:15-12:00: Arithmetic Operators discussion (led by Ernesto or Tim)
12:00-1:00: LUNCH
1:00-2:00: Extensibility discussion (led by Simon)
2:00-3:00: Use Case discussion (Michiharu on protecting XML resources; Sekhar or Simon
on J2SE; any others?)
3:00-3:30: BREAK
3:30-5:00: Resolve as many remaining issues from the Issues List as practical
5:00: Adjourn
March 11, 2002
Agenda:
o Resolve Rule, Policy, MetaPolicy
o
RULE/POLICY/METAPOLICY
Simon: Presented following model:
r1: g+(view, /dir1/file1.html, user1) if a>b and c>d.
r2: g+(view, /dir1/file*, user1) if c>d.
r3: r(view, /dir1/file1.html, user1) if e>f
Request: g(view, /dir1/file1.html, user1)
Can say have to solve restriction first, then positive rules.
Answer to request will be yes/no.
Now say don't care about restrictions first, just match in
order. Will arrive at a yes/no.
Now if have separate policies administered by different
authorities. Each can answer yes/no. Need way to combine:
solve P[A](P,R,A), P[B](P,R,A)
Need another meta-policy: P[A] OR P[B]
P[A] AND P[B]
Metapolicies for rules and policies are different.
Can match query against rule and see which one applies.
Simon suggests taking two rules, grouping into the policy, but
don't try to make one rule out of the two.
Sekhar: "policy" versus "rule"
Now PDP-oriented. ebXML has Registry Client, Registry Server.
Client wants to impose conditions on server access for business
partners. So client writes XACML policy. Policy is submitted
as part of the content. Policy contains rule statements of some
sort: resources to be protected, rule for each resource.
What do you call the thing where set of rules is submitted by a
policy writer.
Wants to keep all rules from one policy writer as a discrete
collection. Wants to be able to send this collection as part of
a SOAP request. Simon: Target is union of all targets in
rules.
Carlisle: PDP only evaluates policies, which are fully worked out
rule statements or policy combination statements. It doesn't
make any sense to assign an effect to a rule unless you have a
meta-policy. Policy writer can override the meta-policy. At
rule level, effect is a hint.
Pierangela: Is meta-policy associated with policies or with
rules?
Simon: same two rules may be used in different ways in two
different policies. Carlisle says this is same as no effect on
the rule: the policy writer who includes the rules will
determine the effect in this case.
Don: might want to include effect in the metapolicy without
implying use of a specific metapolicy.
Polar: even policy writer does not know how his policy will be
combined administratively. Effect determines how evaluation
gets mapped to the higher logic.
Hal: thinks <effect> is a hack. It is when you have loosely
coupled policy administrators that you really need metapolicy.
Each needs to see how his piece fits into the whole world only
enough to do his job.
Konstantin: only one person writes rules for one policy.
[Tim Moses came in here]
Anne: two models: database of rules that are sorted into a
logical statement according to a metapolicy; high-level policy
that refers to specific rules or sub-policies.
Why have metapolicy ref in rule?
Don: have we removed requirement for not wanting to have to
retrieve all rules. [NO]
Simon: proposes only policy writers, no rule writers.
Hal: proposal "rule is atomic unit of administration". Policy is
combination of policies or rules.
Simon: merge vs. combine. disagrees because no semantics. Two
cases: two policies from different sources to be combined
(="policy combination"); take two policies, super-administrator
will merge the two policies. Super-administrator can choose to
combine vs. to merge. Rule=authorization to perform an action
on a resource. One target, one effect. Polar says merge vs
combine must be equivalent by Church-Rosser property.
Hal: still need finer grained targetting.
Assume for now that targets are defined: may be complex, may be
simple.
Curently, metaPolicyRefs always point up: from rule or from
policy. ruleCombiners and policyCombiners now point down.
<rule>
<target>
<subject>..</subject>
<action>..</action>
<resource>..</resource>
</target>
<condition>
P(S,A,R, ...)
</condition>
<effect>..</effect> Permit, Deny
</rule>
<policy>
<target> optional. For finding applicable
policies when have multiple ones either
in database or when will need to
combine.
<subject>..</subject>
<action>..</action>
<resource>..</resource>
</target>
<metaPolicyRef>..</metaPolicyRef>
<rule>..</rule>
<rule>..</rule>
</policy>
Given a particular request, PDP only acts on a policy that has
all applicability elements resolved. Rule-combination policy
already applied or not?
Exchanging rules: is this valid XACML? Role of targets in the
policy. PRP returns one completely applicable policy to PDP.
PRP needs a base policy that applies to everything. It returns
a metaPolicyRef and set of rules.
Is XACML for policy writers (PAPs) or for PDP?
[LUNCH BREAK]
Meta-policy now associated with policy, not rule. Meta-policy
points down, not up now. Meta-policy1 is a rule-combiner.
Metapolicy2 is a real metapolicy (combining policies).
Pierangela gives 5 min. How do you combine boolean policy with
metapolicy. Carlisle: you don't. You deal with one or the
other.
Pierangela: if multiple levels of composition, is one level the
root?
Polar: role of PRP and how many levels of metapolicy? Have to
guarantee top level returns only one, or else have to have a way
to combine them.
Carlisle: suggestion that PDP publishes its base policy. Anne:
case where PEP provides the base policy.
Simon: PDP should know which resources it is intended to
protect. Hal: PRP sits in front of huge database of policies and
returns the applicable ones to the PDP.
Hal,Sekhar: policy is what policy writer writes. Applicable
policy is the set of policies that apply to a given request.
Set of applicable policies will be determined depending on
matching the request against the target, and will be retrieved by
the PRP.
Tim: special case for hierarchical subjects, resources. Makes
combining policies much simpler. Anne: but doesn't this only
apply when the meta-policy uses "closest match"?
Proposal: Policy target is derived from the targets in the
rules. Alternative is that policy target is Declarative,
specified by policy writer as "intended target". Consequences:
Derived:
- complex calculation
- updated whenever a rule is added to database?
- simplify target to make this feasible
- derived subject is difficulty
Declarative:
- declare intention of use
- target is broader than true applicability
- lower policies and rules may not be consistent with each
other.
- can have rules that never fire.
- Could write tools to analyze consistency.
PDP looks at target in its directly referenced policies, and
selects based on that.
Note: target specification must enter in to the logic. It is the
first hurdle. There may be more in the <condition>.
Pierangela: deriving targets much harder if conditions are
included in applicability. Tim suggests conditions are handled
in the policy that includes the rules:
<or>
<and>
<equals>
<resource>
<T1>
</equals>
<C1>
</and>
...
...
</or>
Polar:
<rule>
<target>
<subject>
<action>
<resource>
<additionalCriteria>
</target>
<condition>
<effect>
</rule>
<policy>
<target>
<subject>
<action>
<resource>
<additionalCriteria>
</target>
<ruleCombinerRef>
<rule1>
<rule2>
</policy>
<policyLevel2>
<target>
same
<metaPolicy1>
<policy1>
<policy2>
</policyLevel2>
Rule produces three results: grant, deny, inapplicable.
Conditions are always applicable from the rule writer's point
of view.
Polar: OwnerOf(R,S) -> [R is "old", Permit]
target cond effect
<policy>
<target>
<resourceName>=Age is "old"
<subject> any
</target>
<condition>
OwnerOf(R,S)
</condition>
<effect>Permit</effect>
</policy>
If <condition> is false, then return <not applicable>. By
metaPolicyOne, this will result in <deny>?
Need different rule-combiner from the "MetaPolicy One" to get
the intended semantics.
Pierangela: Need way to indicate that someone gets permit without
implying that everyone else gets deny.
semantics:
condition
target T F
T effect inapp
F inapp inapp
Polar: then rule and policy same. Move these semantics up to
higher level.
Michiharu: specific use cases. Simple example does not use
<condition>. More complex example uses conditions and
meta-policy-hierarchy. His example also implies complexity in
the <target>, at least at the level of using subject role
(attribute), but Michiharu says that can be moved out to
<condition> in newer proposal.
Polar: so scope of rules does not go beyond the policy.
Michiharu's <ruleSet> is equivalent to rule-combiner policy
level.
Pierangela: what if not all information available? Answer:
indeterminate. Error condition. Rule-combiner handles this
case. Rule combiner can specify algorithm in plain English
referenced via a URI.
Now don't need permitOnlyIf because now have Deny and way for
<rule> combiner to give "permitOnlyIf" semantics to <not>Deny if
that is what is desired.
Issues:
- Do we need more than one RuleCombiner
- Syntax for specifying RuleCombiner (URI; can be English text)
- Effect extensible or just Permit/Deny?
Resolution: if additional values, then have to define a new
RuleCombiner that references them.
<rule> = v10 minus metapolicyref; effect={permit,deny}; target and
condition equally participate in applicability. Effect
returned only if both are true.
<rule> Truth Table:
Target Condition Effect
------ --------- ------------
T T [Effect]
T F Inapplicable
T Indet. Indet.
F T Inapplicable
F F Inapplicable
F Indet. Inapplicable
[AFTERNOON BREAK]
POLICY: generated and manipulated by one person in one place.
<policy>
<target>
<ruleSet>
</policy>
Fits into data model in case where you want to write a policy
down. Could pass policy back to a PDP, in which case the
target is then superfluous.
<ruleSet xsi:".....">
<ruleCombinerRef>
<rule>...</rule> Can contain rule syntax or ruleId.
<rule>...</rule>
</ruleSet>
Need for ruleSet depends on whether ruleCombiner is associated
with ruleSet or whether ruleSet is re-usable with other rules.
Signature on policy <rule>: can also include hash of <rule>, or just
(hash of?) <RuleId>. If hash of <rule> syntax, then policy
writer wants this particular <rule> content. If just (hash of?)
<ruleId>, then policy writer wants current rule associated with
this ruleId. Example: a <ruleId> may be associated with semantic
"conditions under which someone is allowed to access Anne's
files". Anne may change the specific conditions over time, but
might retain the same <ruleId> so that the current rule can be
referenced in a policy without having to rewrite the policy.
<ruleRef uri="http://..."
authority="..."
hash="..." (optional)
</ruleRef>
Policy is smallest unit that can be signed. Rules can stand by
themselves, but can't be signed.
v10 has <rules>. Take metaPolicyRef (ruleCombiner) out of
<policy> and put into <rules> and then <rules> is like new
<ruleSet>.
Policy extends saml assertion:
<MajorVersion>
<MinorVersion>
<IssuerInstant>
<Issuer>
<AssertionId>
<policyStatement>
<target>
<ruleSet combiner="...">
<rule> [ruleId (attribute of rule element)
or rule syntax] </rule>
...
<ruleSet>
</policyStatement>
Target RuleSet Result
------ ------- --------
match [effect] [effect]
match Inappl. Inappl.
match Indet. Indet.
no-match Inappl.
Carlisle: is policyStatement always wrapped in a SAML assertion.
If you want to select policies based on data other than <target>
and <ruleSet>, then you have to embed policyStatement in SAML
assertion.
Michiharu: what if you want to assign priorities to rules.
Proposal: evaluate in sequence order. Define new ruleCombiner
that understands priority attribute in rules.
Now:
<ruleX>
<rule>
</rule>
<ruleMetaData
name="..." value="..." />
<effect> CHOICE
Permit or Deny
</effect>
</ruleX>
RuleCombiner can operate on ruleMetaData, which might include
something like priority.
<policyCombinationStatement>
<target>
</target>
<policySet combiner="...">
<policyDesignator attributes=<policyMetaData> >
<choice>
<policyRef>
<policyStatement>
<policyCombinationRef>
<policyCombinationStatement>
<saml:assertion>
<policyRef>
<policyStatement>
<policyCombinationRef>
<policyCombinationStatement>
</saml:assertion>
</choice>
<policyMetaData />
</policyDesignator>
<policySet>
</policyCombinationStatement>
Version1: only use <policyStatement> and <ruleStatement>?
Alternative: flesh out, but then remove in a month if we don't
like it.
Consensus: we need to be able to combine policies.
Version1: only use <policyRef> or <policyCombinationRef>?
Consensus: leave it all in for now.
Simon: what does the policy "combiner" mean?
Polar:
Example: evaluate first policy in list that gives a determinate
answer.
Don't want to specify syntax for saying how to say "trust
policies from IssuerA" at this point.
[6PM ADJOURN]
March 12, 2002 (Day 2)
OBLIGATIONS
Obligation specified via URI and value attribute.
<policyStatement>
<target>
<subjects>
<resources>
<actions>
</target>
<ruleset>...</reuleset>
<obligation>
<onPermit>
<operation uri="http://www.xyz.com/obligation/log"
value="abc" />
</onPermit>
</obligation>
</policyStatement>
RuleCombinationStatement and PolicyCombinationStatement allow
determinism: can control order or completeness of evaluation.
Michiharu: Post-Condition
-Term: provisional action, obligation, provision; consensus:
obligation
-Obligation can be associated with deny, not just permit
-Specified using URI. One parameter: value attribute
<policyStatement>
<target>
<subjects>
<resources>
<actions>
</target>
<ruleset>...</reuleset>
<obligation>
<onPermit>
<operation uri="http://www.xyz.com/obligation/log"
value="abc" />
</onPermit>
</obligation>
</policyStatement>
-More complicated if specify postconditions at rule level.
-RuleCombinationStatement and PolicyCombinationStatement allow
determinism: can control order or completeness of evaluation.
Issue: how is obligation returned to PEP. SAML changes
required.
Issue: can get higher level result that is opposite of a
lower-level result. Need to keep list of obligations associated
with "deny" and list associated with "permit" intermediate
results. Based on ultimate decision of "permit" or "deny", the
set of obligations associated with that result is returned.
Example:
If user="Anne" deny
OnDeny: obligation="log"
Assume: user is not "Anne". Above does not return anything.
Combiners example: All-Must-Permit
Must evaluate *all* policies regardless
If all rules evaluate to Permit, gather all their obligations
for Permit, but if one rule emits an Indeterminate or a Deny,
only the Deny obligations are gathered.
If PEP does not understand an obligation, it should deny access.
PDP just collects obligations.
Simon: define <obligation> element which can be in rule or in
policy. e.g. type of rule <onGrant><targets><obligation>.
General objection: too complex. Wants to have obligations
associated with effects AND target.
Issue: have obligations on rules or not?
Konstantin: Example from Pierangela's paper: Particular
resources may have access by employees or by outsiders who sign
an agreement. Obligation may be "sign an agreement" if the
"access by outsiders" fires.
Polar:
<rule: effect with obligations
<policy <ruleSet: combiner to combine effects and their
obligations
Can also have at policy level: onPermit, onDeny
<policyCombination <policySet: combiner wo combine effects
and policy with its obligations
Two points of view: whether to retain list of obligations from
the lower level evaluation when higher levels return a different
result. Everything returns Permit with both Permit and Deny
obligations or Deny with both Permit and Deny obligations.
No matter what combiner is used: must return complete lists?
Tim: allow obligation <onFire> of a rule. Possibly as
attribute.
Issue: are obligations support mandatory or not.
Simon: could define "standard evaluation context". Combiners
must populate "standard evaluation context" in certain ways,
such as retaining onPermit and onDeny
Agreement: the only obligations carried up are those that fit
the effect at a higher level. Makes sense to allow obligations
at the rule level. At rule level: just <obligation>. At
ruleSet level, <onPermit or <onDeny and <obligation>.
<policyStatement>
<target>
<subjects>
<resources>
<actions>
</target>
<ruleSet Combiner="myURI">
<ruleDesignator>
<ruleMetadata>
<ruleReference> or <ruleInstance>
</ruleDesignator>
<ruleDesignator>...</ruleDesignator>
<obligations>
<onPermit>
<obligation uri="myobligation1" value="abc"/>
<obligation uri="myobligation2" value="cde"/>
</onPermit>
<onDeny>
<obligation>
</onDeny>
</obligations>
</ruleSet>
</policyStatement>
The obligation result is propagated to the next higher level only
if the higher level's combiner results in an effect that
matches the <on[Effect]> obligations. E.g. RuleSet may evaluate
to Deny. <onDeny> associates actions A and B with that result.
PolicyCombiner that uses this Policy may return <permit>, and
these obligations will be lost.
Only the obligations that are associated with the resultant
effect are propagated to the upper policy evaluation. In the
case of Error, NotApplicable, Indeterminate, no obligations are
propagated.
Agreement: omit obligation from rule (later changed).
Konstatin: sceptical about obligations in general.
[MORNING BREAK]
<policyCombinationStatement>
<target>
<subjects>
<resources>
<actions>
</target>
<policySet Combiner="myURI">
<policyDesignator>
<policyRef> or <policyStatement> or
<policyCombinationRef> or <policyCombinationStatement> or
<saml:assertion>
<policyMetadata>
</policyDesignator>
<policyDesignator>...</policyDesignator>
<obligations> OPTIONAL
<onPermit>
<obligation uri="myobligation1" value="abc"/>
<obligation uri="myobligation2" value="cde"/>
</onPermit>
<onDeny>
<obligation>
</onDeny>
</obligations>
</policySet>
</policyStatement>
ARITHMETIC OPERATORS - presentation by Tim
MathML
-Two aspects
-Presentation (we don't care about)
-Expression (how to specify a mathematical statement)
-Example:
<!-- calculate 27-x -->
<apply>
<minus/>
<cn>27</cn> <!-- cn can contain number -->
<ci>x</ci> <!-- ci can contain variable -->
</minus>
-Variable must be declared (other syntax).
-Motivation for wanting at least some arithmetic operators in
XACML: Assume designated effect should operate only if subject's
age is greater than or equal to 18. Currently have to update
rule each day.
-In XACML
<not><lessOrEqual>
<apply>
<minus/>
<saml:AttributeDesignator AttributeName="today'sDate"
AttributeNamespace="//medico.com/" />
<saml:AttributeDesignator AttributeName="patientDoB"
AttributeNamespace="//medico.com/record/patient/"/>
</apply>
<saml:Attribute AttributeName="ageOfConsent"
AttributeNamespace="//medico.com">
<saml:AttributeValue>
<ageOfConsent xsi:type="date">16-0-0</ageOfConsent>
</saml:AttributeValue>
</saml:AttributeValue>
</saml:Attribute>
</greaterOrEqual></not>
-Result of <minus> is an xsi:date
DEFERRED DISCUSSION: how do we know whether an attribute is of
subject, resource, etc.?
-We could eliminate <apply> and use <plus>, <minus>, <times>,
<divide> directly at higher level.
-Hal: real-world date arithmetic is incredibly complex.
-Issue: does XACML enforce type safety, or does PDP do it? Error
can be returned. We need to specify what is allowed, or point
to somewhere else. (ACTION: Polar says there is an RFC
specifying type conversions).
-Michiharu: in IBM's early XACML implementation, they chose a
general syntax for predicate and functions. User provides
functions. Specify types.
<predicate name="compareDate">
<parameter value="after" />
<parameter>
<function name="getDate" />
</parameter>
<parameter>
<function name="getValue">
<parameter value="./period/start_time" />
</function>
</parameter>
</predicate>
-Some predicates and functions are pre-defined. Can also
construct functions via extensions. Defined in a different
schema.
-Tim: this requires defining a different function for each type.
-Deadline: two weeks from yesterday. March 25, 2002. Present at
the subcommittee meeting.
-Policy Model subcommittee is ready to disband. Now subcommittee
time slot and task will be XML Schema.
-Michiharu: use MathML-based syntax or not? E.g. are ci and cn
elements extensible or not. How are types associated with
parameters.
-Ernesto flying home from Spain tomorrow.
[LUNCH BREAK]
[Simon] syntax for referring to resource in SAML
authorizationDecisionQuery. This is a SAML and XACML syntax
issue: they have to be coordinated.
Consensus: referring to SAML attributes is not a model issue.
EXTENSIBILITY - presentation by Simon
-Core schema is a good interchange format.
-Extensibility point: predicate
e.g. J2SE permission class must be signed by a specific issuer.
Define special predicates. Publish schema for that.
Possibly enough syntax in core schema to handle this.
-XACML syntax is not user-friendly.
e.g. J2SE composite subject hard to express in core schema.
-Create a non-normative schema. Triplet-based. Lots of
extension points. Profile in non-normative way for various
applications or requirements.
E.G. non-normative profile for J2SE, ebXML, etc.
-Don't depend on J2SE to profile their own because they would go
through the same pain. They would need to understand XACML
schema, etc. Like providing a guidebook.
*Konstantin: can same PDP, with different extension profiles,
handle J2EE, J2SE, .NET, etc.?
-Conversion from extension profile to normative schema is
well-defined [according to Simon].
[Anne,Sekhar] Would rather have a policy composition tool that
accepts syntax like what I am familiar with and outputs a
standard XACML instance.
EXTENSIBILITY - presentation by Sekhar
Sekhar: alternative way to extend: J2SE, etc. define their own
schema. Define attributes pertinent to the J2SE platform.
These plug into the standard XACML. J2SE extension would just
explain the attributes and the predicates.
-Extensibility schema:
xacmle:RuleCategoryType
e.g. grant, deny, restriction
xacmle:BasicRuleType
RuleHead
Subject: abstract, extension point
Resource: abstract, extension point
Actions: abstract, extension point
Constraints: abstract, extension point
-Translated into core XACML. Gives framework for writing
application-specific schemas.
-Model extensibility only at Predicates:
substitutionGroup=xacml:Predicate
e.g. SignatureVerifyFunction
SignatureVerifyFunctionType
name="ClassName" type="anyURI"
ref="ds:KeyInfo"
-Does Predicate need attribute for authority name, authority key,
ClassName, class base location?
-Predicate Must return true or false.
-Predicate can have no side-effects.
[Hal] Is a SAML response that has advices and conditions the
right way to return obligations?
[Hal] Need to have way to restrict XACML to subsets so that a
given PDP/PRP can handle it. E.g. PDP might be J2SE-compliant.
E.g. [blue sky] limit on numbers of rules, only certain
combiners supported, limits on # of levels of
policyCombiners, only certain ways to reference a policy
inside a policyCombinationStatement, only those things required
to support J2SE. Spell out to a PAP how it is limited to apply
to a given PDP. PDP spells out what it can support.
Sekhar: J2SE can be handled via core syntax
<xacml:ruleStatement>
<xacml:target>
. <xacml:subjects>
. . <saml:Attribute AttributeNameSpace="//java.sun.com-URI"
AttributeName="principal"
. . . <saml:AtributeValue>
. . . . <saml:NameIdentifier
SecurityDomain="javax.security.auth.x500.X500Principal"
Name = "cn=Alice"/>
. . . </saml:AttributeValue>
. . </saml:Attribute>
. </saml:subjects>
. <xacml:resources>
. . <saml:Attribute ...
. . AttributeName="permission"
. . . <saml:AttributeValue
. . . . <xs:string>java.io.FilePermission</xs:string>
. . . </saml:AttributeValue>
. . . <saml:AttributeValue>
. . . . <xs:string>/home/Alice</xs:string>
. . . </saml:AttributeValue>
. . </saml:Attribute>
. </xacml:resources>
. <xacml:actions>
. . <saml:Action>Read</saml:Action>
. . <saml:Action>write</saml:Action>
. </xacml:actions>
</xacml:target>
</xacml:ruleStatement>
[BILL LEFT AROUND HERE]
Another way:
<xs:schema targetNamespace="JavanamespaceURI:>
. <complexType name="principal">
. . <xs:complexType
...
</xs:schema>
-Allows use of domain-specific names like j2se:principal.
-Provides the #ANY schema for attributes within a given
domain.
-PDP for this would need to be J2SE-aware.
-This profile would need to be defined via JCP.
-[Hal] Subject----->Permissions--->specific Permission
Signer--^
ToD-----^
Use XACML to decide which Permissions you get, not what
-[Anne] See how much we can do with predicate extensions. Rough
example:
grant "cn=Anne" {
FilePermission "/home/aha" "read,write"
}
<rule>
<target>
<subject>"cn=Anne"</subject>
<resource>"java.io.FilePermission"</resource>
<actions>
<action>"read"</action>
<action>"write"</action>
</actions>
</target>
<condition>
<implies>
<attributeValue>
class:java.io.FilePermission
"/home/aha" "read,write"
</attributeValue>
<attributeRef>
<saml:attribute>[RequestedPermission]</saml:attribute>
</attributeRef>
</implies>
<effect>Permit</effect>
</rule>
AFTERNOON BREAK
PROTECTING XML RESOURCES - use case presented by Michiharu
-Extends extension pointS "predicate" and "function"
USING XPATH EXPRESSION
Example:
Predicate: XPathMatch(arg1,arg2,arg3)
Return: Boolean
arg1: String (URI)
arg2: String (XPath)
arg3: String (Xpath)
e.g. XPathMatch("medico.com/patient-123.xml",
"/record/patient/patientDob", "//*")
-> true
Example:
Function: resourceSelector(returnType)
Return: String
returnType: ["uri","path","xpath",or "all"]
e.g. resourceSelector("//medico.com/patient-123.xml
#xpointer(/record/patient/patientDoB)")
-> /record/patient/patientDoB
-Resource Extension:
can compress many lines from the example to go into one
element and it can be re-used
USING PATH EXPRESSION
-e.g. function: resourceSelector("//medico.com/patient-123.xml
?/record/patient/patientDoB")
-> /record/patient/patientDoB
-e.g. predicate: pathMatch(arg1,arg2)
return: Boolean
arg1: String(Path)
arg2: String(Path)
matchPath("/record/patient/patientDoB", "*/email")
-> false
-Resource Extension:
<resources>
<resourcePathMatch value="*/email"/>
<resourcePathMatch value="*/phone"/>
</resources>
taken from:
<resources>
<or>
<predicate name="pathMatch">
<function name="resourceSelector">
<parameter value="path"/>
</function>
<parameter value="*/email"/>
</predicate>
<predicate name="pathMatch">
<function name="resourceSelector">
<parameter value="path"/>
</function>
<parameter value="*/phone"/>
</predicate>
</or>
</resources>
[Tim]may be possible to use just the above regular expression
match (e.g. <resourcePathMatch value="*/email"/>)
[Hal]Instead of providing an instance document, perhaps specify
schema: policy applies to any document conforming to the schema.
[Hal]Might want to specify via DTD.
[Anne]Michiharu's <resources> element test would need to be in
the <condition>, since might not be able to find a given value.
Make the target matching algorithm a URI. We specify
regular-expression match. Possible to define and specify
others.
Michiharu can live with less generality than XPath, but his
first motivation was to use XPath.
Resources can be internally structured via a schema. Then the
regular expression match operates on the pointer into the
resource.
[Hal]Could define resource as a sequence of strings. Define
regular expression for each substring. This has been sufficient
for their purposes.
[Hal]Need to specify class of documents to which target can
apply. Either instance or schema or ....
Go back to one target matching algorithm, but add way to say
target resource must conform to a specific schema or is in a
namespace. Need to define effect when applied to an
unstructured resource.
[Michiharu]Assumes <policy> restricts the application to
particular target document namespaces, schemas.
[Anne]For unstructured document resource, target must be URI (or
regular expression matching URI). For XML document, target can
be URI plus optional XPath or Path expression.
[POLAR LEFT HERE]
*Konstatin wants more verbal text around element types. Have
UML as well as XML. Purpose is to sell ideas behind XACML to
someone who does not understand XML. @Hal and @Konstantin
willing to work on this after Version 11 available. "Primer"
document.
-ruleCombiner*, policyCombiner*, instead of ruleCombinator,
policyCombinator
Next F2F
-Dates: weeks April 15, April 22, April 29
-Michiharu: week of April 22nd best, May 6 second, not
avail. week of April 29
-Sekhar: not avail. weeks of April 15 or April 22
-Place: Milan, Bay Area (Ken), Manhattan Beach (Bill), Burlington
-Pierangela, Ernesto in Milan first choice: get representative
hotel prices
-Ken Yagen, CrossLogix, Bay Area: if no extra room cost
-Bill Parducci, LA: if no extra room cost
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC