Here's my 2 cents as far as I understand the issue:
I think one way it could be supported is to have something like a
MustUnderstand optional piece of Attribute metadata, that could
work something like this:
if an attribute is present w the MustUnderstand xml-attr
== Deny,
then if the policy does not understand the attribute, and the
decision
otherwise is Permit, then result should be Deny,
and if the decision ow would be Deny, then Deny
similarly
if an attribute is present w the MustUnderstand xml-attr ==
Permit,
then if the policy does not understand the attribute, and the
decision
otherwise is Permit, then result should also be Permit,
if the decision ow would be Deny, then Deny
(this latter block looks like a no-op, so maybe this case is N/A)
However, the first block seems somewhat logical, and possibly there
is
a way to list all the attributes used in the policy and if the one w
the
MustUnderstand is not on the list then the Rule to Deny would
be applied.
Above is not a recommendation, but a thought on how it might be
approached
if someone wanted to build a profile that used the capability.
However, I would defer to Erik and Stephen, as to whether it is
readily
implementable or not.
Thanks,
Rich
On 1/21/2016 12:19 AM, Martin Smith
wrote:
Eric, all--
Your description of the scenario I envision is almost what
I meant, but I don't understand this:
"Later on, the PEP is changed so that it sends a new
attribute called "privacy_controlled"". What I meant is that
the relying party adds a tag to the resource. As far as I
know the PEP has no way of knowing this new tag has been
added, unless by saying "PEP" you include the RP resource
itself somehow. And in any case, my understanding is that the
PEP (or "context handler"?) only collects tags mentioned in
the active policy set, or those asked for by the PDP. I am
probably confused, but I don't see any XACML function through
which any IAM component collects ALL access-related resource
tags (specifically to include those NOT referred to by any
rule in the active policy set.)
Moving on to the question of utility: Eric is correct that
this addresses only one class of error, but I'd assert that
it's a very likely source of error. The organizational process
of creating and deploying policies is likely centralized, or
at least coordinated within a data governance "committee."
The data-tagging process is likely to be run by more
operational units, and there may be many separately managed
protected resources (that should be ) subject to the same
enterprise set of laws and regs. These data resources are
likely to be more dynamic than the policies as new sub-sites
are added, for example, to a portal. This the coordination
between policies and tags is likely to be more error-prone.
One type of error--where the resource manager fails to add an
appropriate marking-- should be caught since the related
policy will not be satisfied. But if a resource owner adds a
tag, either one in a new data series (perhaps from another
organization), or an obsolete one because his marking guidance
is out of date, or because the marking application/tool hasn't
been updated. One would like to catch these errors.
Finally, remember that per Hal's advice the idea is to make
this a profile, so that only implementers who are very
concerned about these errors (and would rather block them than
risk an access error) would use it. And eve that can be made
less "disruptive" if the profile would include a selectable
option to provide "Advice" (of an unused resource attribute)
rather than a Deny.
Regards,
Martin
--
Thanks, Rich
Rich Levinson | Internet Standards Security
Architect
Mobile: +1 978 5055017
Oracle Identity Management
45 Network Drive | Burlington, Massachusetts 01803
Oracle is committed to developing practices
and products that help protect the environment
|