Re: [xacml] Default behavior for unrecognized resource attributes?

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

--

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

xacml message