Re: [xacml] Default behavior for unrecognized resource attributes?
Martin,
Also, to say it again, it probably is not the responsibility of the
XACML standard to ensure this, rather the responsibility of the
change control process the organization is using. Sure, it makes
sense to think of failure modes, but ultimately, the data owner
cannot expect applications to start honoring newly defined metadata
items by magic without proper change management and corresponding
updates to the applications and/or policies.
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