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