[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Raw notes - day one - F2F Dec 8, 2009
!************************
1163 san carlos ave:
Sneakers pub and grille
start at 8:00 AM
in the lobby
12/8:
conf id: 166748159
XACML F2F Day 1:
3 use cases
Hier profile
1. Resource hierarchy
3 mechanisms for determining
ancestors:
- ancestor attributes
- URI?
- provide XML doc
Multi- profile
2. Multi: hierarchy resources
handed request: hier struct, do requests
on children, descendants etc.
Core
3. Access XML Content (attribute values)
regardless of 1 or 2, have situations where
need to get content (1,2 are about structure)
3a. Request Context
3b. Resource Content
Erik: difficult to address 2 w/o 1
Paul: split xml/non-xml
Paul described xpath proposal:
http://wiki.oasis-open.org/xacml/XpathDiscussion
Hal: Content defn:
Jan: context content, environment, etc.
Hal: arbitrary xml?, ex saml assertion is just some xml
Erik: benefits of xacml attrs w restricted form, but if
open free form as we have done in 3.0, no distinction
between categories wrt content
Sridhar: web svcs msg: what is patient, member id? xpath
will give you
Jan: why use attrs in first place
Hal: majority of data is not xml; convert to and from xml?
some people want to do no xml at all
Erik: we want both, in general
Hal: one place for xml; diff subj categories,
Jan: designators: xacml attrs, why not add under content element,
why do designators at all.
Erik: the more structure you have the more powerful the pdp
can be.
Hal: even if no xml, policy can be written as if
openaz java model corresponds to xml, but is not xml
Dilli: for interoperability, req ctx must be xml?
Hal: core spec: "pretends" xml structure exists but not reqd
Erik: why one wants general content element
1. may be difficult to decide category
2. cannot write xpath that spans multi-categories
Hal: yes, that's how it works currently, but is it "broken"
Erik: was problem in multi - can't retrieve one of many records
Hal: attrs come from different formats
Jan: can add arbitrary categories as needed
Hal: req msg is action, resp msg is resource category in general
i.e. even before resp msg produced the data for it is in
the service/server
Hal: thinks "new" categories" should be rare in general
Rich: multiple resource records can effectively be multiple
categories in the request, w primary resource, and
auxiliary resources brought into decision
Dilli: attr val can be xml fragment, canonical, apply xpath
to any fragment in the request, more natural to have
xpath to evaluate, no special reason for content,
canonical should be able to navigate using xpath;
not excluding xml as attr values
Hal: metadata: doc classification, user group,
original model make decisions on metadata, but fuzzy
distinction
Paul: use cases
Dilli: attr in subj cat, put complete ldap entry to xml; don't
know what policy is going to consume
Hal: policy needs to know schema
Paul: not eliminating content in category
Erik: instead of req ctx; define new cat, ex general, i.e. why
2 types of Content elements? can achieve same w current spec.
Erik: clear diff: attr ref'd by designator and content; can't use
attr selector to get attrs in designators.
Erik: attr selectors become slow
Sridhar: 2.0 selectors can span categories still there unchanged
Erik: in 3.0 attr selectors restricted, much for perf reasons,
scalability
Paul: if can't span req ctx, then processor has to form;
Hal: apply xpath to non-existent doc is "hard"
resource not in xml form; legit impl, use xpath on res content
Paul: what does it mean to have an attr value that is not xml?
Rich: disagree that it is hard to use xpath ref non-existent xml
Rich: agree w selectors it is hard, because unlimited and restricted
access,
Erik: need xml dom, not just xpath stmts, in order to evaluate
predicates
Paul: proposal item 1 use any category
2. resource-id of different "types" is difficult
Erik: actual resource being requested is pointed out by resource-id
also have resource-id w multiple resources.
but using xpath for individual node appears valid
Paul: 3. individual content-selectors
4. multiple content-selectors
Paul: 2nd or 3rd child of root is "oddity"
Jan: node type: descendant just refers to element nodes, which does
not include xml attrs
Paul: need union of 2 xpath stmts;
Jan: only children of children, no attr nodes
Paul: collapse 3 into one content-selector
Jan: points to one element
Paul: parent attrs element has cat
Jan: ok
Jan: current proposal amended to be:
existing resource-id replaced by content-selector
existing global resource-id is multi-content-selector
Discussing above proposal:
Jan: not to lose place where eval rules, need point to one node
to allow iterate thru nodes, implies go thru subject nodes
and multi-loops thru resource nodes
right now limited to resource element, there may be
cases to extend it.
Paul: multiple selections in categories is cartesian product.
Rich/Erik: agree: hierarch expansion only applies to resources,
section 4 of multi; BUT as in section 2.3 can combine
multiple subj, action, resource, (env) elements in
cross-product, where any resource can expand as hier
as descr in section 4.
Paul:
"//*/@*" returns all attribute nodes in the document.
"//*|//*/@*" returns all element nodes and all
attribute nodes in the document.
Paul: pipe sign is union of xpath expressions
Policy model of proposal:
Hal: hard to go from one node to another
Paul: eval child node based on attr of ancestor
now way to do w full generality w xacml
could not start from node interested in, only from top
paul wrote email to xacml-comment about 1 yr ago on this
Paul: if you are clever enough w xpath can get to any node from
any other node. Make a rule based on one aspect of node
wrt other nodes
Jan: this is what geo-xacml needs as well; set ctx node for
attr selector; rec attr as child below attr selector;
earlier proposal attr of attr selectro
Paul: name the node that you want to use as ctx element
Jan: better to have as child element; value of ctx attrid and
combination of both ctx node for attr selector eval.
Paul: dynamic xpath tricky
Jan: not "dynamic" - combo of 2 strings; ex set of bldg elems,
check if bldg-owner, price
ctx is bldg, check if owner = state, need to add to xpath
selecting bldg node, an offset to select price and owner.
Paul: suggest handling those rules in xacml itself
ctx selector pts to bldg node
want to test sub-elements
Hal: use case 3 on element that has been found.
Erik: 2 step as Paul suggests: 1st pt to bldg, then use rel path
to get attrs of bldg;
Jan: that's what means by concatenation; better to set ctx node
then ref from ctx node, other nodes.
Hal: use selector, add new attr to selector; traverse the tree
and get stuff from the 2nd ctx
Dilli: can't 2 expr be combined
Jan: point is that 1st node is not explicitly set, use ptr to
ctx selector
bldg: 10 bldg nodes
multi-decision: 10 requests
from there is owner=state, price<1m
basically bldg, owner, price attrs are evaluated
to use designator to get ; need to define desig within
desig, not possible so needs to be child of attr-selector
ctx node - points to bldg node
from there check attrs of that node
Paul: if want value of bldg, req ctx path will be value
string expr @value,
Jan:
Erik/Rich: RequestContextPath="count(ancestor::md:record)"
above will go to root of message content->attributes->
request->saml->soap> etc.
Erik: had email to stop traversal at content element.
Erik: transport protocol outside scope of xacml may be counted,
although not part of content.
Erik: no way to "set" the root element, it is by defn the doc node
of original xml in xpath env.; would need to implement own
xpath engine; will work if write xpath in right form but
is not clean
http://lists.oasis-open.org/archives/xacml/200912/msg00056.html
Erik: just realized both of last examples in above email are broken
Erik: xpath node fcns may be broken because traversal up goes beyond
the content element; not possible to impl using existing xpath
Jan: start expressions w/o "/"
Erik: yes, but people will make this mistake
Paul: xslt 2.0 can solve this problem by applying xpath to dynamic
node sequences.
Erik: if people write expr assuming content is root, then mistakes
can be made.
Jan: don't add content element w/in dec req. avoid problem
Erik: need to send new doc using protocol, and send unique root
w/in soap body.
hal: xpath should be construed as taking content as root; but easier way
is to copy content so it is independent root.
paul: cont can contain mult children - infer anon root
erik: that is the content element, assume it is doc elem / doc node
top of hier
paul: important point is to specify: document root is content node
hal: xml el vs xml attr: jan's use case covered by paul's proposal
Paul: node-match fcns new in 3.0 are not in 2.0, can w/draw from spec
Erik: may be easier than ancestor::,
Sridhar: good for back compatibility
Erik: typing fixed in 3.0
Hal: add fcns but describe in xpath equivs
Jan: is that just a new selector?
Hal: xpath node count fcns, can be replaced
Paul: don't need to support full xpath, just these fcns.
Erik: good to define in terms of xpath; verbage not precise,
but xpath stmts are precise.
Erik: dropping xpath datatype: xpath node match does not have
category, added cat to xpath datatype; have to apply
xpath node match fcn to content; paul suggested dropping
because attrs are relative; asymmetry of using same datatype
Erik: propose cat of datatype optional; specify whether reqd or not.
jan: if mandatory in selector only for context node.
erik: case where content selector optional
jan: res ctx path starts; need cat attr w/in selector
erik: if you don't get offset in req; problem is if cat attr
is in 2 places.
erik: propse cat in datatype optional;
jan: why not say cat in selector overrides
erik: better to show an error than allow mistake
jan: effectively 2 roots
erik: right - can use output for attr selectors or xpath fcns;
or specify
erik attr selector needs context node for defining ctx node path.
2 ways:
1.
2. get xpath from req ctx and that is offset
can say error if cat not equal
jan: if you don't spec ctxattrid, then must set the attrcontent
category
hal: are we at workable proposal
erik: if offset missing then ctx node given by cat attr in selector
else then
<Req
<Attrs Cat="Res">
<Content> ...
<attr Id="content-sel" Cat="resource">
<attr-val>
record
<policy
<attr-selector rctxPath="record" cat = "resource"
<attr-selector rCtxPath="patient" cat="resource"
ctxAttrId="content-selector"
reconvene at 2PM
Afternoon session:
---------------------------------------------
Jan/Erik: resolution:
2 step deref
red* direct ref to content
grn* indirect ref to content
1 get right context selector attr
cat gets right block for attr
2 used to get right node in spec cont el
-------------------------------------
<Req
<Attrs Cat="Res">
<Content>(red*)
<Record(grn*(2))
<Patient>...
v-- 1 gets right
<attr AttrId="content-sel" Cat="resource"> (grn*(1))
<attr-val>
record</attr-val>
------------------------------------
<policy
(red*) <attr-selector ReqCtxPath="Record" cat = "resource"
(grn*(1)) <attr-selector ReqCtxPath="Patient" cat="resource"
ctxAttrId="content-sel"
stars are context node of respective selectors
ReqCtxPath tells where to go given the starting
point within the content, which by default is Content,
ow spec by CtxAttrId
Erik:
All is as if content node had been copied to own doc
All xpath eval in std-alone content el.
Only visible namespace decls incl in new content doc
Paul comment in chatroom: 2:30PM:
Paul: Two more issues on xpath discussion.
Paul: 1. Name of AttributeSelector/@ContextAttributeId.
Erik suggested "ContextSelectorAttribute"
Paul: 2: Discuss name of AttributeSelector/@RequestContextPath attribute.
This appears to be held over from the days when
AttributeSelector ranged over the entire Request.
Maybe something like "Select" (from xslt), or "XPath"
would be more appropriate. "RequestContextPath:" could be
retained as a synonym.
Paul: Hello, is anyone ther?
-> Action: people come up w names of attrs to fit the
above templates
Jan: sent around book example:
http://lists.oasis-open.org/archives/xacml/200909/msg00081.html
http://lists.oasis-open.org/archives/xacml/200909/msg00090.html
From email 81:
Note that all the problems mentioned above are solved.
Filtering is possible as resource-id always refers to exactly one node in the xml resource and thus we get individual access decisions for each node in the xml resource. As resource-id is included in the decision response the PEP can (e.g. through a simple xslt) filter out the nodes for which the decision was deny.
Further the problem of defining content dependant rights without reducing the possible authorization semantics is solved, thanks to an AttributeSelector that uses a concatenation of the resource-id attribute value and an arbitrary offset as its RequestContextPath value.
Note that the explanations above are simplified and try to focus the core aspects of the idea only. I hope that I could nevertheless make clear where the limitations are and how they could be solved.
Let me know if you have problems understanding the ideas and I will try to explain in more detail. Further, more detailed information can be found in the comments I submitted during the public review period.
In 3.0 any attrs can be requested to be returned
<Content
<Collection
<Building
<Price>1,000,000
<Owner>Alice
</Building>
<Building>
...
policy:
<Rule>
<string-equal> test owner=subject-id
<AttrSel Cat=resource
ContextAttrId="urn:...content-selector"
ReqCtxPath="Owner"
<AttrDesignator AttrId="subject-id"
individual requests will refer to the Collection node
as the context node:
multiple selector says all descendants
1st condition access to C xpath node match content sel
attr val ... //collection
Rule
1 xpath node match(desig sel the content sel,
2nd param: <AttrVal>/Collection
i.e. does node requested (no descendants) match
the node in policy: yes, it's Collection[1]
2 string-equals("Alice",
AttributeSelector(Cat="resource"
ContentAttrId=content-selector
ReqCtxPath=B/O
3. integer-equals(10,
AttributeSelector(Cat="resource"
ContentAttrId=content-selector
ReqCtxPath=B/P
Response:
<content-selector>/C/B[1]
want to do:
/C/B[P=10 AND O=Alice]
content-selector plus offset
Erik: can't write policy for node C
Hal: given is the business reqt, not the policy
Erik: can do it w obligation?
Jan: yes
EriK: then why need a change?
multiple-resource-id (old name)
1. multiple-content-selector= /Collection/Building (gets 100 buildings)
scope=XPathExpression
2. content-selector=/Collection[1]/Building[1]
this is the 1st of the multi-decision requests
policy relative to this offset
/Collection/Building[price<1,000,000 AND Owner="Alice"]
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
Erik: reformulate xpath match fcns in terms of equiv
xpath expressions: need to reverse: ancestor:
propose keep current, because reversal is reqd
any xpath exp: how to transform to modified path?
not an easy problem
Hal: case going up?
Erik: two xpaths 2nd selects something the 1st one also
selects. is 2nd one part of ancestors of 1st one?
need general rule how to do that
Paul: will take closer look.
Hal: 3, 16, 62, 19, 61 - we now have general agreement
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
-----------------------------
3:30 session:
Jan: issue 4: map: geometries:
Change Request 3: Any-Of, All-of and Map functions are defined to
restrictive
Action:
Reformulate the definitions of the Any-Of, All-of and Map functions in
a more general way.
Explanation:
The current definition of these higher-oder functions are too
restrictive (e.g. line 4556, 4590, 4786). For example the any-of and
all-of function have the following signature:
any-of|all-of(function, primitive data type, Bag)
Problems arise e.g. as the order of parameters is restricted. Assume
you have a function without its inverse counterpart and further the
spec forces that the Bag is the second parameter of this function.
Obviously this unnecessarily limits the expressiveness considerably.
Another restricting effect of the current definition of these functions
shows up when you use XACML’s extension capabilities. It should be
supported to add an function with three parameters like e.g.
is-within-distance(geometry_A, geometry_B, 100 metres). Users need
higher-order functions that can be used with the extended functions.
Currently the definition of the higher-order functions is not generic
or general enough in this regard.
The same limitations apply to the map function. As it is, it supports
only functions with one parameter. A more expressive definition of the
map function should also allow functions with more than one parameter.
Assume for example a situation where you want to add five to each
element of an integer-bag with the map function.
Jan's 11/18 email:
11/18/2009 3:09 PM
Hi *,
Below and attached a first proposals to address the open issues No 4.
Proposal for issue No 4.:
§ The problem/unnecessary restriction:
o The signature of any-of and all-of must be:
§ any-of|all-of(function, a primitive data type, bag)
§ all-of-any|any-of-all|all-of-all(function, bag, bag)
§ map(function-WITH-ONE-Argument-ONLY, bag) …
returns bag
o Limitations occur if the inside-function
§ has more than two (or one) parameter(s)
§ doesn’t have an inverse counter part
1. Because of this you might need to change the order of
the last two parameters - in case of an
inside-function with two parameters)
§ Proposal
o a more flexible definition of any-of and all-of will
eliminate the limitations (c.p. from line 4664).
o the any-of-any function could be changed to a function
where with exception of the first parameter (that
specifies a function over primitive data types) all
following parameter will be bags. The result will be true if the function applied to one of the
tupels of the cross product set evaluates to true.
o all-of-any, any-of-all, all-of-all must be updated
correspondingly… Problem: explosion of functions due to
increased number of parameters.
o map should also allow for arbitrary functions and thus
should be changed to c.p. 4862.
§ example: add 5 to every value in an integer bag would
be expressed as:
1. map(integer-add, pointer-to-bag, 5)
Two further comments:
o any-of-any (all-of-all) with two bags where one bag has
one element corresponds to the any-of (all-of)
function.
o any-of, all-of, any-of-any, all-of-all start introducing
some sort of loops in XACML. Why not adding a for loop
and maybe if-than-else constructs?
Best regards
jan
agreement on issue 4:
any-of, all-of, any-of-any, map fcns can be redefined as
proposed
all-of-any, any-of-all, all-of-all leave unchanged
***********************!
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]