OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

WG: AW: [xacml] three questions: string-not-equal & valid FulfillOn attributevalues & placement of variableDefintions

  • 1.  WG: AW: [xacml] three questions: string-not-equal & valid FulfillOn attributevalues & placement of variableDefintions

    Posted 05-31-2011 12:37
    Hi Erik, i agree. However if you use the described target (i.e.: <Target>   string-not-equal(role, "manager"))  e.g. in the root <PolicySet> element, you can be sure that all children RPS Elements will never grant any rights to the manager role.   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 Von: Erik Rissanen [mailto:erik@axiomatics.com] Gesendet: Dienstag, 31. Mai 2011 14:25 An: Jan Herrmann Cc: 'Bill Parducci'; xacml@lists.oasis-open.org Betreff: Re: AW: [xacml] three questions: string-not-equal & valid FulfillOn attributevalues & placement of variableDefintions   Hi Jan, The string-not-equal function does not work if you have something like this: <Request>   role = employee   role = manager ... If you then have target like this: <Target>   role string-not-equal "manager" .... This target would match the above request, although the subject in this case does have the manager role. This is because the target match element is looking for at least one value which gives "true" on the matching function. "employee" will in this case do so. Best regards, Erik On 2011-05-30 21:18, Jan Herrmann wrote: Hi Erik, Bill, all thanks a lot for all your feedback mails.   regarding your comments on the string-not-equal Matchfunction issue: The string-not-equal function is the inverse of the string-equal. Instead of checking whether an attribute equals some of the values of its domain one can always do the inverse - if that’s easier. Further there are use cases were you want to explicitly express that all rules in policy shall not be applicable if some attribute is not equal with a certain value. E.g. Having a predefined and unmodifiable root PolicySet element that says, resource-id != Service-A will guarantee that the children of this <PolicySet> Element will never apply to ADRs that refer to an access request on the resource Service-A.   However the circumstances and requirements are the mentioned string-not-equal function can avoid the need to shift rule-semantics down in the Rule/Condition element. As you said this applies to other functions too and I totally agree that support of <Condition> elements in <Policy> and <PolicySet> elements might greatly enhance flexibility. Maybe we should add this topic on the TC-agenda items list.   Regarding you feedback on the FulfillOn=Indeterminate attributevalue for Obligations: As mentioned in a previous mail thread one great use case for obligations is to use them as a generic way to define IndeterminateHandlers and internalStateHandlers. E.g. if an AttributeSelector or AttributeDesignator is evaluating to Indeterminate, a new XML Attribute in these two elements – let’s call it IndeterminateHandler- could refer to an Obligation that instructs the PIP to add additional data to the “incomplete” ADR. Thus a mechanism is strongly required when protecting transactional services and is additionally at least a very appropriate solution for the BreakTheGlas Problem. If we have time I would like to discuss the proposal in Boston . @Bill: As far as I know Obligation combining and obligation conflict resolution is not yet defined and so the Indeterminate case will not make things worse.   Regarding you feedback on the VariableDefinition placement: The principle of visibility of variables could be applied in the XACML world. Can’t we treat a <R>, <P> and <PS> as a Java-Block equivalent?   All the Best Jan         -- Jan Herrmann Dipl.-Inform., Dipl.-Geogr. Scientific Assistant Chair for Applied Informatics / Cooperative Systems Technisc he Universität München Boltzmannstr. 3 85748 Garching Germany T: +49 89 289 18692 F: +49 89 289 18657 W: www11.in.tum.de Von: Erik Rissanen [ mailto:erik@axiomatics.com ] Gesendet: Montag, 30. Mai 2011 18:36 An: xacml@lists.oasis-open.org Betreff: Re: [xacml] three questions: string-not-equal & valid FulfillOn attributevalues & placement of variableDefintions   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