[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Raw notes: day 2 F2F
!**********************
12/9/09:
Day 2: XACML TC F2F meeting
Additional attendees:
Ulrich Lang
Andreas
Oleg Gryb
Jan: content-selector
Hal: what is regex matching?
Jan:
content-selector="/myns:C/ns2:B[i]
<Rule>
Option 1:
regexp-match(AttrDesignator(content-selector),
/myns:C\[[\d%\]/ns2:B[/d%]
Option 2:
xpath-node-match(AttrDesignator(content-selector),
<Attr DataType="XPath"
xmlns="...">
<..>/myns:C/ns2:B</..>
Jan: in original issue didn't know how to use xpath-node-match
only perf enh as regex perf.
Rich: more than perf, also for usability
Paul: regex and xpath don't belong together
std xpath for mult cont selector to individual;
cast xpath to string or regex fcn
Hal: does normal form restrict impls in undesirable manner?
Jan: needs are addressed by both schemes
Hal: if both schemes allowed things need to be canonicalized
Hal: 1st scheme does not require xml doc
Erik: need to canonicalize only in URI scheme
URI scheme exists in hier now, not multiple
Hal: when generating selector: use case 2 (multi) walking
the descendants;
case 1: maybe only looking for appl policies, not need content
Erik: may need content to determine scope of multi
Rich: scope of hier profile is spec'd as:
1. how to identify the nodes: 3 schemes given
2. how to determine the hierarchical ancestry aspects: parent etc
3. how to do policies for the above, ex node-match for xml,
regex for URI
Paul: wants to get to "bottom of #11"
Hal: isn't that the "form"
Paul: if revising spec to provide for eval of xpath expr
Hal: it is comparing xpath strings, not evaluating the xpath
Paul: if we set up regex of xpath; not a natural thing to do
Jan: should we support option 1?
Erik: don't need cast in regex scheme; loop for multi-decision
is missing from URI scheme
Hal: suppose content-selector being set up by pdp, then dependent
on that being done in std way.
Erik: normalized form fits better in URI scheme than xpath scheme
Hal: left hand side of URI is fixed;
Erik: people may not be aware of namespace issue and may make
mistakes.
Hal: can close issue 11 w no action; Erik, Paul, Jan ok
Jan: burden of regex adding to address not worth it, for the
needs of the original issue 11
after coffee break:
Rich: what does this have to do w URI scheme proposal to address
issue 11, and the "red*,grn*"/xpath "offset" discussion?
original issue may be closed, but some stuff emerged, incl
issue 16 refactor
Hal: any objection to closing 11?
no objection, so closed
Paul: contract between requester and policy writer
Hal: in general there is coupling between decision request prep
and the pdp policies.
Erik: need to represent resources;
Erik: does scheme conflict w normal html
Hal: is xmlid a special case of xpointer (Paul)
Rich presented the ppt on the uri/xpath proposal for hier,
as well as briefly showing xpointer specs
Hal/Jan:
1. <Attribute AttributeId="Rich-URI" DataType="string"
<AttributeValue>element-name</AttributeValue>
designator can just check if node present
Oleg can use type URI
2. <Attribute AttributeId="res-id" DataType="anyURI">
<AttributeValue> ...
Erik: refactor profile - URI pres is related
Rich: refactor impacted by whether URI scheme included or not in hier
Paul: just an agreement between modules in the system
Hal: same could be said of other methods as well
Paul: AttributeId are semantics
Erik: it becomes more when we look at multiple, when we say that
pdp has to produce details for multiple node identifiers
Paul: imposes a semantic on URI not there in spec; no intention that
path applies to hier structure unless appl wants to interpret
it that way; imposes conformance, interoperability: last half
contained in first half.
Rich: appls are waiting to have this applied but currently are not
aware the possibility exists
Jan: can do the building appl using it; it is another usable
representation; basing rules on resource is good idea; chging
the rep doesn't chg need for having rules behind it.
Paul: it is just an "agreement" between modules, not to some spec
Jan: pep writer and policy writers need to agree on this mechanism
with this profile in order to coordinate resource representation
and policy representation.
Paul: write rules against attrs and expect to see them that way.
Jan: in concrete use case, 2 domains have to agree on attrids;
here we have base name scheme to follow this proposal, which
simplifies agreement because they know what base name scheme
can be used.
Paul: agrees it is helpful implmentation tip.
Paul: focus on real life use cases
Rich: use cases were basis of original spec; current changes are
just clarifications of what was originally there.
Paul: each real world org has own hier issues
Hal: issue 16 is about multiple profile;
Erik: multiple contains 2 broad groups: one is to repeat multiple
nodes (3 schemes) other is to decide on full or sub-hierarchies;
3 schemes are kind of mixed up; xml requires ancestors that
doesn't make sense (general agreement)
Hal: ancestor doesn't work for multiple because you need to know
children;
Erik: preprocessor of ancestor needs to have access to resource
hiearchy in order to resolve; spec doesn't really say where
preprocessor is.
Hal: we have distinction between request prep and pdp;
Erik: in case of ancestor scheme pdp needs to breach the separation
between pdp and other modules to get the hier to prep the multi.
Hal: in all 3 hier cases there is info about identifying resources
Erik: let's not reexamine whole thing, just focus on tweaks
Erik: only issue - using scheme where xml doc provided, still need
to drop ancestor stuff in xml (again no disagree)
Hal: before we go down the road need agreement on URI scheme
Paul: ok to impose additional semantics on uri, but is concerned
about the extensions; sees need to add semantics of node id
so that path reflects the hier so that path represents the
hierarchy. xml docs is agreement of components of appl.
Jan: it is always there that there needs to be agreement between
request writer and rep of resources in the policies.
Rich: there are real world examples incl xml database products
Jan: if you claim conformance then you must use the fragment
syntax, as well, if you use the fragment for resource identification
break: resume at 1:30
Afternoon session:
Hal: use cases for multiple:
1. Entire Hierarchy
2. Scope with xpath
3. URI scheme
Jan: think we should have mechanism, because
Hal: strong arg for having all policy
Jan: aggregate: what and how
Hal: could put identifier in combining algorithm
Paul: decision-combining
Erik: exactly same data structure
Rich/Erik: issues w combining decisions
Andreus: what about multi-decision w obligations, how
combined? is there order
Hal: draft of obl families to address that type of issue
but today we have an algorithm for what to collect when
percolate up.
Erik: order of decisions is undefined
Bill: explicitly say they are unordered
Rich: ordering?
Erik: it is relative policy evaluation order, not the
order of the responses being returned
Jan; what is diff of combining responses w combining
results of policies
Paul: they are the same thing.
Paul: it is different than policy writer; eval in order and
get results. This decision combining is decide on the
collection not order at all.
Hal: indeterminates, not-applicable drop out of some
Erik: agrees it is different thing on same type.
Andreus: aren't existing policy algorithms enough
Erik: no equiv policy alg to "entire hierarchy"
Andreus: there is a pt where have positive effect on rule
erik: deny unless permit is same as old entire hierarchy
hal: list of algs:
C. Combining algorithms (normative) 134
C.1 Extended Indeterminate value 134
C.2 Deny-overrides 134
C.3 Ordered-deny-overrides 136 ??
C.4 Permit-overrides 136
C.5 Ordered-permit-overrides 137 ??
C.6 Deny-unless-permit 138
C.7 Permit-unless-deny 138
C.8 First-applicable 139 ??
C.9 Only-one-applicable 141 ??
C.10 Legacy Deny-overrides 142
C.11 Legacy Ordered-deny-overrides 143
C.12 Legacy Permit-overrides 144
C.13 Legacy Ordered-permit-overrides 146
Erik: not all applications have privacy as overriding goal
Jan: that is focus of which combining appl does
Hal: choices:
1. Don't do anything
a. it might be broken
2. Converse of current one
a. it also is not fully spec'd
Erik: unless any decision is deny then permit
if not-appl then deny
Erik: response format now normative since signature
issues are now being incorporated.
Hal: if missing take default, no combining, difficult
to reconcile w other concepts.
Erik: w details doesn't correspond to combining alg.
<Attribute AttributeId="decision-combining">
<Attribute AttributeId="urn:..."
DataType="...uri"
Hal: leaving the xacml attribute optional;
Paul: thought was going to be on policy as xml attr
Hal: all you need is identifer:
Erik: should be xml attr? will be present on every
xacml attr in that case
Erik: put it in same place as multiple selector;
Erik: another scheme w repeat attrs
Erik: xml attr on request element
Jan: section 2.3 of mult profile:
Hal:
Entire Hierarchy: proposal: (optional, if not there, don't combine)
xml-attr: decision-combining-algorithm-id: 3 choices:
no combining (or not there)
all permit, ow deny
all deny, ow permit
Erik will do "what's right" offline then we will discuss
XML resource
scope is not used, because multi-content-selector tells you
what resources (free form xpath)
replaces: resource-id, scope
Non-XML resource (URI)
scope self, children, descendants
ancestor scheme is descendants only
Erik: context handler needs to be able to do ancestor scheme
expansions.
URI scheme one id and multiple preprocessor would find
resource and what children, descendants exist.
PDP(context-handler) will create all the descendants.
Rich: can do virtual requests;
Paul: asking permission to class vs member;
Hal: /foo/bar vs /foo/bar/ can have both in <uri> prefix, but
only former in xpath fragment identifier
Hal: independent of how scheme determines the set of requests,
then the multi-decision-combining is applied regardless of
how collection of responses was obtained.
Erik/Paul: behavior - resource-id scope descendants, want list
of all decisions, multi-processor gets info somewhere to
determine membership of lists
Erik: original use cases drove 2.0; we don't have them handy
specify folder, get list of all members yes or no.
Hal: combining applies to everything, as long as you have
at least 2 decisions
Issues 23, 25, 26
Erik: 23 has been closed
Issue 25: last call - reconsider after "full rewrite"
Issue 26: entire hierarchy
Issue 61: multi-decision attrs - don't use resource-id
Issue 62: offset
I have couple questions re: yesterday, specifically:
* does the attr selector offset "solve" the decision on C issue, or is it just for the individual requests, B[i]
* re: decision on C issue: is this inherently "unsolvable" within xacml as formulated by depending on multiple decisions, whereas xacml is a single decision arch? if so, does it open case for new class of functionality such as combining algorithm for multi-decision scenarios?
Jan: forced to define at lowest level: would involve some use
of obligations; offset alone will not solve the problem, and
the combining thing doesn't help either.
Reason URI's don't work you have multiple elements
of same type.
Rich: formulate as follows:
From yesterday:
Jan: proposal is to return attr that returns node
specifying
C---------------+
| |
B[1] B[2]
| |
P[1]="10", P[1]="9",
O[1]="Al" O[1]="Bo"
ReqCtxPath=B/P set of price nodes: P[1],P[2]
Want to know if access to C is granted
Not allowed if one building fails.
Collection: need semantics for processing in policy
...
C rule just refers to C, but eval refers to lower nodes
C/B[1]
C/B[1]/P[1]="10"
C/B[1]/O[1]="Bob"
C/B[2]
C/B[2]/P[1]="5"
C/B[2]/O[1]="Alice"
...
ex. can't specify only one subtree of c within xpath
C/B[1]
C/B[1]/P[1]="10"
C/B[1]/O[1]="Bob"
if you are at "C", can't in xpath specify
C/B[/d+]/P="10"
C/B[/d+]/O="Alice"
want to make sure
-> Rich/Jan follow up on this analysis and whether applies or
not - not part of 3.0 discussion per se'
Next subject:
Paul: resource-id's
requestor starting at pep has identifier of resource; give me
decisions for all children you know about for this thing.
pep assumes pdp knows how to find children of thing, identify
them, and send them back.
getting back decisions for different set of resources
than the one you are sending in.
scope attribute
Erik: keep as is
Paul: children, descendants
getting rid of values of xpath expression, scope
Paul: one issue: have case for xml content; have case for
resources outside xacml resources; suppose pep has
collection of resources; bundle them up; don't have
means to communicate hierarchy;
Hal: can combine child, descendants, other collections,
with combining algorithms: all yes or all no.
Jan: transform non-hier to hier and use capabilities that way
Dilli: resource w children, descendants: can we figure out
pep has one resource; pep did not send hierarchy, pdp
can look at req and assemble to tree;
Erik: in general policy structure and resource structure don't
match
Dilli/Jan: external collection of missing nodes; pip
Hal: business today is done, let's do agenda planning:
1. start at 9:00, don't have "tc call", but send out notes
for people to know what's going on.
2. need time for wrapup timeline, after lunch;
9-10:30 rich talk api, 90 min
break
10:45-11:30 nextlabs
break
11:45-12:30 futures post 3.0 pres
lunch
2:00-2:30 david chadwick issue 30 min
2:30-3:30 wrapup, action items, planning
Paul: what about policy, policyset id issue;
Hal: multi-resource is now called multi-decision;
Last item on wiki proposals list
Paul order of policy eval is for business reasons.
Paul more interested in parent child than sibling.
Hal/Paul: do you go down first or left to right first
Hal/Erik:
following is pre-order, depth first (one of 6 possible)
1
2 9
3 6 10
4 5 7 8 11 12
How to syntactically
Paul: actual element names
IdReferences as in email:
http://lists.oasis-open.org/archives/xacml/200911/msg00064.html
Erik: ok w paul's proposal, paul ok w list unordered, but
as long as policyid and policysetid, hal can tell by policy version etc
<Response>
...
<PolicyIdentifierList>
<PolicyIdReference PolicyId="..." PolicyVersion="1.0"/>
<PolicySetIdReference ... >
...
The <Result> element produced by evaluating such a request
for access SHALL be
identical to that produced by the following process.
A series of request contexts is evaluated, each
requesting access to exactly one node of the hierarchy.
The <Decision> in the single <Result> that is returned
to the PEP SHALL be “Permit”
if and only if
all <Result> elements resulting from the evaluation
of the individual nodes contained a <Decision> of
“Permit”.
Otherwise, the <Decision> in the single <Result>
returned to the PEP SHALL be “Deny”.
This Profile does NOT REQUIRE that the implementation of
the evaluation of a request for access to such a
hierarchical resource conform to the preceding model
or that actual request contexts corresponding to the
individual nodes in the hierarchy be constructed.
This Profile REQUIRES only that the <Result> element SHALL
be the same as if the preceding model were used.
Two syntax's for this functionality are specified in the
following Sections, one for use with resources that are
XML documents, and the other for use with resources that
are not XML documents.
-------- Original Message --------
Subject: RE: will be late, plus have questions
Date: Wed, 9 Dec 2009 10:39:52 -0600
From: Tyson, Paul H <PTyson@bellhelicopter.textron.com>
To: Rich.Levinson <rich.levinson@oracle.com>, Harold Lockhart <hal.lockhart@oracle.com>
CC: Erik Rissanen <erik@axiomatics.com>, Bill Parducci (E-mail) <bill@parducci.net>, Jan Herrmann <herrmanj@in.tum.de>, Dilli Dorai <Dilli.Dorai@Sun.COM>, <john.w.tolbert@boeing.com>, Staggs, David (SAIC) <David.Staggs@va.gov>, Sridhar Muppidi <muppidi@us.ibm.com>
It is a new class of problem. I can see a few different approaches, but they should all be considered after 3.0.
1. Add a "decision-combining algorithm" mechanism, whereby the Request can ask for a single decision on one resource, based on several decisions about other resources. (It is coincidental and irrelevant that in this case, the sub-decisions are about children of the main resource.)
2. Implement a variable-binding mechanism to allow values from the request context to be passed to the xpath evaluator.
3. Generalize/modify access-permitted function to handle this case. This might be the place to put decision-combining algorithm.
4. Specify an ordered aggregate data type ("List") and possibly some additional functions (such as lisp "apply"). This would allow policy writer to use ordered lists of Building/Owner and Building/Price nodes to evaluate the properties of each Building.
I believe the access-permitted function has the greatest possibilities, not only for this use case but for many others. I'm sure there are implementation challenges in recursive policy evaluation, though.
--Paul
From: Rich.Levinson [mailto:rich.levinson@oracle.com]
Sent: Wednesday, December 09, 2009 10:13
To: Harold Lockhart
Cc: Erik Rissanen; Bill Parducci (E-mail); Jan Herrmann; Dilli Dorai; john.w.tolbert@boeing.com; Staggs, David (SAIC); Sridhar Muppidi; Tyson, Paul H
Subject: will be late, plus have questions
Hi All,
I have couple questions re: yesterday, specifically:
* does the attr selector offset "solve" the decision on C issue, or is it just for the individual requests, B[i]
* re: decision on C issue: is this inherently "unsolvable" within xacml as formulated by depending on multiple decisions, whereas xacml is a single decision arch? if so, does it open case for new class of functionality such as combining algorithm for multi-decision scenarios?
Thanks,
Rich
****************!
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]