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

Gesendet: Dienstag, 31. Mai 2011
14:25

An: Jan Herrmann

Cc: 'Bill Parducci';


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

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