[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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: Sunday, April 18, 2010 10:49 > To: Yoichi Takayama > 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, > Here is a very simple example of what I call "rigidness": > > I need to extract a string from a bag using a XACML > expression as an index. It's a trivial task in any > programming language, but try to do it in XACML. Can you explain this problem better? Depending on the context, it seems like you could do it with the XACML "string-equal" function or one of the "any-of*" family of functions. > > > Let us look at Ralf's use case again. In essence, it looks > like a very simple authz related functionality: "give me a > list of all permission for a subject". The "simple" or "basic" access control problem is of the form, "Can subject S access resource R?", and I cannot imagine any problem of that type which cannot be handled by XACML. > It seems to me that > the only solution that was suggested here was to send all > 2000 resources in a PDP request each time when this decision > needed. That solution looks inefficient to me. "Give me a list of permissions for a subject" is a different type of problem--one of analysis or summary. In Ralf's use case it is apparently a necessary stage to providing real access control at runtime, because the system does not provide an access control point at which a decision on an individual subject and resource can be requested. There is no doubt that by "pre-cooking" all possible authorization decisions into "roles" or "permissions" you can achieve optimum runtime performance, because these can be executed by bitmap masking or SQL query filters. But you sacrifice some flexibility, transparency, and provability. I suggested how you can use a XACML PDP and ruleset to derive a set of pre-cooked decisions that could be fed into some native system of access control. That this approach is inelegant and possibly resource-intensive is because it is using XACML in a way that it wasn't really designed for. However, it will guarantee that actual runtime decisions (of the form, "Can S see R?") conform to your ruleset. > More > reasonable solution could be probably achived by using that > new "AssociateAdvice" constract in XACML 3.0, but in this > case you'll need to do "a lot" (see my definition of "a lot" > in the message to Paul) of coding in PIP and PEP. Advice is supposed to be "extra information about a decision", not "how to make a decision". Using Advice in this way would make the PEP do some of the duty of the PDP, with possible undesirable consequences. Regards, --Paul
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]