← Prev in month
← Prev in thread
Next in thread →
Next in month →
[xacml] XACML F2F March 11, 2002 Minutes
Title: XACML Conference Call Minutes
Here are the formatted minutes. Text is really unchanged
from Anne's minutes already sent out. Carlisle did post some comments on the
minutes which I have not included yet, but if there is agreement to make the
changes Carlisle suggests, I will update the minutes.
XACML
Face to Face #4
Date: March 11/12, 2002
Location: Burlington, MA (SUN)
Minutes of Meeting
(Minutes taken by Anne Anderson, Edited by Ken Yagen)
Contents
Votes
Proposed Agenda
Roll Call
Action Items
Summary
Agreements Reached
Deferred Issues And Questions
Detailed Notes
Votes
?
Proposed Agenda:
Monday, March 11th
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
Roll Call
Voting Members
Simon Godik, Self
Hal Lockhart, Entegrity
Carlisle Adams, Entrust
Tim Moses, Entrust
Don Flinn, Hitachi
Michiharu Kudoh, IBM
Bill Parducci, Self
Polar Humenn, Self
Sekhar Vajjhala, Sun Microsystems
Anne Anderson, Sun Microsystems
By Phone
Pierangela Samarati, Univ. of Milan
Probationary Members
Konstantin Beznosov, Hitachi
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.
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
← Prev in month
← Prev in thread
Next in thread →
Next in month →