Re: [xacml] Default behavior for unrecognized resource attributes?
Eric--
Certainly agree that policies CAN be written to add this check for unknown data tags, and to DENY in that case.
My suggestion is, however, to provide for the case where the policy set fails to do this, but yet there is a tag that is not handled by any policy in the policy set used to protect a resource.
This is an error case, but in such a case I suggest that the priority should be given to the decision of the data custodian to mark the data with the unhandled tag, which probably indicates an intent to invoke a policy rule that limits access.
And example from a domain with which I'm familiar: Suppose data tags are bound to a document, and the tags are "SECRET", "NOFORN" and "PROPIN" (meaning "proprietary information.") The custodian relies on the access-control system to protect this document with a policy set that enforces requirements that the requester has a SECRET or above clearance, is a US citizen, and is not a contractor. If for whatever reason, the policy set that is active doesn't recognize the tag "PROPIN", for example, then the requirement for the requester not to be a contractor would not be enforced; in this case the data custodian would expect access to be denied.
Of course, maybe the custodian is the one who made the error--maybe PROPIN is an obsolete tag. The tagging process is very likely not flawlessly synchronized with the policy update or the user provisioning processes, so this can certainly happen. In this case I see two reasons why a default DENY is appropriate: (1) the security "meta-rule" of default configuration of anything for no access vs all access; and (2) good incentives: getting an erroneous DENY is more likely to provide motivation to the requester to pester someone to get the error fixed than is an erroneous PERMIT.
(Sidebar: this discussion illustrates one of several ways in which process for management of user attributes should not be assumed to be directly transferable to management of resource attributes (data tags.))
I am not sure where this suggestion would fit into the TCs guidance. It probably does not requires new XACML syntax. Maybe it's more like how the rules of precedence for application of rules in a policy set are specified or declared. Or maybe it's just something that could be included in non-normative "best practice" guidance (i.e., "It's a good idea to have a rule like the one Eric suggests in your active policy set to avoid accidentally providing access to a protected resource.")
Best regards,
Martin
On Tue, Oct 27, 2015 at 8:21 AM, Erik Rissanen <> wrote:
Martin,
Ok, maybe I misunderstood you then. Still not sure if I understand
you though. ;-)
If you have an attribute called "tag" and it can take various values
like "internal", "secret", "public", etc, you can quite easily write
a policy which denies if you get a tag value which you don't
recognize.
You can simply do a rule which denies if the tag is not a member of
a bag of tag values you have in the policy. Like so, assuming that
there can be multiple tags for a resource (using pseudo notation):
deny <- not(allOfAny(stringEquals, tagAttributeOfResource,
stringBag("internal", "secret", "public")))
Best regards,
Erik
On 2015-10-27 12:49, BFC.McLean wrote:
Eric/remon--still sounds like you're thinking of extra user
attributes being "provided." I agree this should not cause a
DENY. I'm talking about tags placed by the data owner on the
data being accessed.
Is there a case where those tags
shouldn't be honored?
Regards,
Martin
Sent from my iPad
On Oct 27, 2015, at 6:12 AM, Sinnema, Remon <>
wrote:
I
agree with Erik.
From:
[mailto:]
On Behalf Of Erik Rissanen
Sent: dinsdag 27 oktober 2015 9:45
To:
Subject: Re: [xacml] Default behavior for
unrecognized resource attributes?
All,
I think this is not a good idea. There are valid reasons
to have attributes which are not referred to. For
instance, an interoperability standard might define a set
of attribute to be provided, but not every organization
might have a need for a policy which needs all the
attributes.
To solve the coordination problem, there already exist
general software engineering practices, processes and
tools.
Best regards,
Erik
On 2015-10-27 01:18, Martin Smith
wrote:
David/all--
Reviewing this thread again, I
think it may be that I am talking about resource
attributes not referred to in the active policy set,
while others appear to be addressing "extra" user
attributes.
I am suggesting that it it only
"extra" resource attributes that should cause a DENY
decision by default.
I agree that ideally this
situation would never arise. But:
1. The custodian of the
protected resource is likely responsible for
applying resource tags, based on sensitivity or
other characteristics of the data or service. If a
tag has been applied for which the PDP does not have
a policy, then it is likely that some rule that the
resources owner expected to be in place has somehow
not been invoked, and thus the expected protection
on which the owner relies is not there. Safest to
DENY while seeing what happened.
2. I think this situation is in
fact likely to arise in a multi-organizational
environment where coordination between active policy
sets and user provisioning and resource marking
activity would be harder to coordinate. It would
also be more likely to arise if data from various
sources were combined for analysis. Again, if
coordination has failed for any reason, it's better
to DENY be default.
3. Finally, there doesn't seem
to be much downside to making this "deny if not
recognized" the default. If an expected access is
denied, the requester is going to be motivated to
get to the bottom of the problem.
Martin
On Thu, Sep 24, 2015 at 3:46 PM,
Martin Smith <>
wrote:
David-- Have to admit I didn't
understand this scenario. Can you illustrate with
an example, maybe?
"You are
forgetting there could be "automatic"
policy enforcement points that convert
business requests (HTTP, SOAP, JSON...)
automatically into a XACML request.
If there is a
new HTTP header in an HTTP request and
the PEP automatically converts it into a
XACML attribute, then would you want the
PDP to suddenly deny access?"
(Guessing a bit, but it
seems OK to ADD a constraint--assuming it's
legit--but not to eliminate one.)
On Thu, Sep 24, 2015 at
12:28 PM, David Brossard <>
wrote:
You are forgetting
there could be "automatic" policy
enforcement points that convert business
requests (HTTP, SOAP, JSON...)
automatically into a XACML request.
If there is a new
HTTP header in an HTTP request and the
PEP automatically converts it into a
XACML attribute, then would you want the
PDP to suddenly deny access?
If an attribute is
not referenced in a rule / policy, then
it should have no impact at all.
Now, on a different
note, one could review PDP audit logs on
a regular basis to reconcile attributes
that come in with a request with
attributes that are used in a set of
policies. That would help a systems
administrator fine-tune PEP
configuration.
On Thu, Sep 24,
2015 at 6:09 PM, BFC McLean <>
wrote:
Lack of a
rule that references a resource
attribute strongly suggests that
the resource owner who attached
that attribute expected a
different rule set to be
protecting the resource.
Martin S -- Sent from my iPhone
On Sep 24, 2015, at 12:01
PM, David Brossard <>
wrote:
If an
"unrecognized attribute"
is an attribute not in
use by a policy / rule
in the policy set, then
the attribute serves no
purpose and will have no
impact. This is true of
any category of
attributes. Therefore
there is no need to
cause the PDP to reply
with a DENY.
To
the best of my
knowledge the XACML
3.0 standard doesn't
mention how a request
with extra attributes
should be handled. The
standard doesn't delve
into PIP behavior
either.
Cheers,
David.
On
Thu, Sep 24, 2015 at
5:51 PM, Martin Smith
<> wrote:
As
a result of thinking
about the DSD
question, it
occurred to me to
wonder if there is
anything in
normative or
non-normative XACML
pubs that says that
an unrecognized
resource attribute
must result in a
DENY decision.
Let's
say that
"unrecognized"
means that there
is no rule in the
set being used by
the PDP that
references the
attribute.
It
seems to me that
this should be a
requirement, as
the purpose of
resource
attributes is to
specify (via the
applied rule set)
what subject
attributes are
required for
access to the
resource. If
there's no rule
that references
the resource
attribute then
there is a
definite
possibility that
the subject does
not have all the
attributes
intended to be
required by
whatever policy
led to the
inclusion of the
unrecognized
resource attribute
in the protected
resource's
metadata.
The
same does not
apply to
unrecognized
subject
attributes, which
can be ignored as
they are simply
"extra" from the
perspective of the
PDP (and are
presumably
provisioned for
access to other
resources not
protected by the
current PDP/PEP.)
Martin
--
Martin
F Smith,
Principal
BFC
Consulting,
LLC
McLean,
Va 22102
703
506-0159
703
389-3224
mobile
--
David
Brossard
VP
of Customer
Relations
+46(0)760
25 85 75
+1 502 922 6538
Axiomatics AB
Västmannagatan
4
S-111
24 Stockholm,
Sweden
Support: https://support.axiomatics.com
Web: http://www.axiomatics.com
Axiomatics for developers: http://developers.axiomatics.com
Connect with us on LinkedIn | Twitter | Google + | Facebook | YouTube
--
David
Brossard
VP
of Customer Relations
+46(0)760
25 85 75
+1 502 922 6538
Axiomatics AB
Västmannagatan
4
S-111
24 Stockholm, Sweden
Support: https://support.axiomatics.com
Web: http://www.axiomatics.com
Axiomatics for developers: http://developers.axiomatics.com
Connect with us on LinkedIn | Twitter | Google
+ | Facebook |
YouTube
--
Martin
F Smith, Principal
BFC
Consulting, LLC
McLean,
Va 22102
703 506-0159
703 389-3224
mobile
--
Martin
F Smith, Principal
BFC
Consulting, LLC
McLean,
Va 22102
703
506-0159
703
389-3224 mobile
--
Martin F Smith, Principal
BFC Consulting, LLC
McLean, Va 22102
703 506-0159
703 389-3224 mobile