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

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

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:] 

Gesendet: Montag, 30. Mai 2011
18:36

An: 

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