[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: WG: AW: [xacml] three questions: string-not-equal & valid FulfillOn attributevalues & placement of variableDefintions
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] Hi Jan, 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 @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 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]
Hi Jan, Hi Jan, Hi all, three little questions: 1. Would it not be useful to allow a
sting-not-equal Match-function?
Best Regards -- 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]