7 messages in org.oasis-open.lists.xacmlRe: [xacml] three questions: string-n...| From | Sent On | Attachments |
|---|---|---|
| Jan Herrmann | May 30, 2011 7:38 am | |
| Erik Rissanen | May 30, 2011 8:13 am | |
| Erik Rissanen | May 30, 2011 8:16 am | |
| Bill Parducci | May 30, 2011 8:45 am | |
| Erik Rissanen | May 30, 2011 9:35 am | |
| Jan Herrmann | May 30, 2011 12:18 pm | |
| Erik Rissanen | May 31, 2011 5:24 am |
| Subject: | Re: [xacml] three questions: string-not-equal & valid FulfillOn attributevalues & placement of variableDefintions | |
|---|---|---|
| From: | Erik Rissanen (er...@axiomatics.com) | |
| Date: | May 30, 2011 9:35:12 am | |
| List: | org.oasis-open.lists.xacml | |
Hi Jan,
On second thought, I don't think the string-not-equals would be useful. It won't do what you want in a target in case of multiple values. The target would match if at least one of the values in the request causes string-not-equal to return true. That's not what you would want to.
So you would need to use a condition.
Best regards, Erik
On 05/30/2011 05:14 PM, Erik Rissanen wrote:
Hi Jan,
See inline.
On 2011-05-30 16:38, Jan Herrmann wrote:
Hi all,
three little questions:
1. Would it not be useful to allow a sting-not-equal Match-function?
Yes, it would since it's not possible to use a "not" function in a target. However, my opinion is that the fault is not that there is no string-not-equal function, but the problem is that one cannot use a condition in a policy or policy set. There are lots of cases where one has to use weird constructs to work around that, and your case is just one such example.
2. Is there a reason why one can not define an ObligationExpression with a FulfillOn="Indeterminate" value?
Maybe someone from the XACML 1.0 era here could respond better, but it seems a bit weird to put enforcement actions in an error, meaning that we don't even know whether a policy applied or not. I don't have done a formal analysis of a the matter though.
3. Why do VariableDefinitions have to be bound to a <Policy> element and not to e.g. the root <PolicySet> element?
Again, others would know better, but I guess this was simply a design choice. I guess since conditions can appear only in rules, the need for variable definitions was most urgent in a Policy. Of course, now AttributeAssignmentExpression changes that.
Best regards, Erik
Best Regards Jan
--
Jan Herrmann
Dipl.-Inform., Dipl.-Geogr.
Scientific Assistant
Chair for Applied Informatics / Cooperative Systems
Technische Universität München
Boltzmannstr. 3
85748 Garching
Germany
T: +49 89 289 18692
F: +49 89 289 18657
W: www11.in.tum.de