[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Passing parameters to the attribute designator
Craig, the designator is a "function" by itself, only that it does not take parameters (I do not know why it should not) in the same manner as regular functions but involves the context handler. It is the context handler that communicates with PIPs for attributes and not the PDP, therefore, functions used in place of designators, which are matter of factedly executed by the PDP may not serve the desired purpose. However, I might agree with you nonetheless assuming that there are no constraints imposed by the specification in not having the PDP talk to the PIP. Regards, Anil -----Original Message----- From: Craig Forster [mailto:cforster@au1.ibm.com] Sent: Tuesday, July 08, 2008 9:44 AM To: Anil Tappetla (atappetl) Cc: Erik Rissanen; Seth Proctor; xacml@lists.oasis-open.org Subject: RE: [xacml] Passing parameters to the attribute designator Hi Anil, Would a custom function be a better approach where parameters are needed? Regards, Craig --------------------------------------------------------------- Craig Forster Software Engineer IBM Australia Development Labs Argus == https://w3.webahead.ibm.com/w3ki/display/commonauthz/Home Blog == http://blogs.tap.ibm.com/weblogs/craigforster/ --------------------------------------------------------------- From: "Anil Tappetla (atappetl)" <atappetl@cisco.com> To: "Seth Proctor" <Seth.Proctor@sun.com>, "Erik Rissanen" <erik@axiomatics.com> Cc: <xacml@lists.oasis-open.org> Date: 08/07/2008 01:34 Subject: RE: [xacml] Passing parameters to the attribute designator Let me re-project the problem after going through the responses, I wonder if it still interests the TC. I accept the point that the attribute identifier on the designator should be all that the context handler must use but it looks like there are cases where mapping attributes to queries is after all not problem free. An example being the query - get top n-elements from the stack, where 'n' is a variable. Policies may have to be written with 'n' hardcoded within to avoid a surplus of attribute identifiers to deal with. I assume the context handler remains unaware of the policies the PDP is evaluating and only serves callbacks from the PDP for attributes, and therefore do not think an additional context that maps the policy to 'n' would be available to the handler. Regards, Anil -----Original Message----- From: Seth Proctor [mailto:Seth.Proctor@sun.com] Sent: Friday, July 04, 2008 9:12 PM To: Erik Rissanen Cc: xacml@lists.oasis-open.org; Anil Tappetla (atappetl) Subject: Re: [xacml] Passing parameters to the attribute designator Erik Rissanen wrote: > This issue falls under the broader issue of attribute provisioning, > which I think is very important and currently somewhat underspecified > in the XACML world. But this is much because by design XACML chose to > abstract away this kind of details. This kind of abstraction makes > XACML more generally applicable and adaptable to different > environments and growth over time. > [...] > So I am opposed to the proposed change in the XACML schema. For what it's worth I agree with Erik here. This issue has actually come up a couple of times before. As I recall, the last time was when Anne and I were looking at some related issues, and she decided to take a stab at starting to define some basic provisioning configuration. As it (quickly) grew very complex, I was of the opinion that this is something best configured separately, rather than trying to wedge it into the already somewhat verbose policies. I think the main issue in my mind boils down to how people are likely to use his feature. I have not yet come across any real-world scenarios where people want to define different configuration within the same policy for various Designators. This is the only strong argument I can think of for including configuration in the policy itself. As long as configuration is defined per-policy or, more likely, per-PDP, then doing the configuration separately seems like a much cleaner approach. seth --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]