[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Default behavior for unrecognized resource attributes?
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 iPadI agree with Erik.
From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Erik Rissanen
Sent: dinsdag 27 oktober 2015 9:45
To: xacml@lists.oasis-open.org
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 <bfc.mclean@gmail.com> 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 <david.brossard@axiomatics.com> 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 <bfc.mclean@gmail.com> 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 <david.brossard@axiomatics.com> 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 <bfc.mclean@gmail.com> 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
--
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, SwedenSupport: https://support.axiomatics.com
Web: http://www.axiomatics.com
--
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, SwedenSupport: https://support.axiomatics.com
Web: http://www.axiomatics.com
--
--
Martin F Smith, Principal
BFC Consulting, LLC
McLean, Va 22102
703 506-0159
703 389-3224 mobile
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]