[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XACML expressiveness (WAS: RE: [xacml-users] retrieving a list or query filter of resources the caller is authorized for)
> -----Original Message----- > From: Oleg Gryb [mailto:oleg_gryb@yahoo.com] > Sent: Monday, April 19, 2010 14:22 > To: Yoichi Takayama; Oleg Gryb > Cc: Tyson, Paul H; Ralf Lorenz; xacml-users@lists.oasis-open.org > Subject: Re: [xacml-users] retrieving a list or query filter > of resources the caller is authorized for > > Yoichi, Paul, > > There are few points that I want to comment on: > > 1. > >"Extracting" in what way and what do you want to extract > exactly, and > where from? > > F(Bag-of-string, Expr) = String > > Expr is a XACML expression (actually it was a variable ref in > my case) evaluated to an integer that represents a string > index in a bag > Bag-of-string - is a bag of strings > String - returned value, which is the string with the index > provided by Expr That's right: the XACML policy language has no ordered lists, therefore no way of selecting from a list by index. I don't know if this is because the TC decided against it, or just that no one ever brought the use case forward. The XACML request context consists of bags of attribute values identified by id, type, and issuer. There is no concept of order in the request context. However, in a policy you could use a *-bag function to construct a bag of values that you might want to treat as ordered. > > I'm not sure what other details I can provide, except that I > didn't make up the example, I needed it to return a message > from a policy. > > I'll try to generalize that "rigidness" problem. XACML > defines expressions and variables just like any programming > language, but it stops short from making expressions commonly > available everywhere and suggests using static (or literal) > content instead. > > AttributeValueType can't have expressions (e.g. variable > references) inside. It means that constructs like > AttributeAssignment that is used to define Obligations can't > not contain expressions that will be interpreted by a PDP > engine. This limitation was removed in 3.0, which allows expressions in Obligation and Advice. <...> > > 2. It's good that AssociatedAdvice was introduced in XACML > 3.0, but can I put an expression to AssociatedAdvice that > will be interpreted by a PDP before a response is sent back > to a client? The second qs: why it was named as an "advice"? > Can't we have it more generic by calling it DecisionDetails > and allowing any details that might be related to a decision? > Advice is just one particular case, right? The TC decided that "Advice" was general enough. There are no particular semantics or requirements attached to it, so it can be used for anything the users or implementors want to do. <...> Regards, --Paul
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]