[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]