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