I am not sure I understand your proposal at all. In XACML there is no way to make any decision except by evaluating policy as defined in the specification. There is no such thing as an unknown tag (I think you mean attribute value not referenced by any policy). In a typical environment there will be many reasons why Resources (and Subjects and Actions and Environment) have attributes which are not used by any policy. They may be irrelevant to access control or they may be used in a different policy domain and not this one. In practice is not possible to keep perfect synchronization between the attributes provided for a decision and the attributes referenced by applicable policy. Maybe the value is referenced when a different user requests access, or at a different time of day, etc. In OpenAz we spent a lot of time on what to do in the opposite case, i.e. when you need an attribute value you don’t have. We came up with two solutions, mappers and the AMF – both imperfect but useful. But we did not even consider your case as a problem. IMO having data you don’t need is not a problem. (Unless it causes latency problems.) Consider you case. First, XACML can’t say “secret or higher”. This usecase has been discussed many times, but the philosophy of XACML is that there is no semantic model (that the policy knows about) so you have to say “secret or top secret” or something of that sort. If you say it must be secret then if it is any unknown value it will evaluate to false. If you say it cannot be secret, then all the “unknown” values will evaluate to true. If you want you can enumerate every possible value or you can only consider the ones that give access. Philosophically XACML intends to make use of information which is already present in the organization somewhere. I realize that in practice organizations are only starting to make use of Resource attributes, but this is a conversion problem, not a steady state one. IMO one reason older AC models have failed is that they require somebody (security admin) to keep up to date information which he or she neither uses or has authoritative knowledge of. I think the right way to do it is as much as possible to use information that the organization is already depending on. Instead of creating artificial things like Roles, we can access the attributes like organization and job title to depend directly on the information which would be used to determine the Users’s Role. This principle is so well established that in Common Law it is recognized as an exception to the hearsay rule. While you generally cannot prove anything with a document alone, the court will consider “Business Records” which are actually depended on by the organization to be valid evidence. Returning to your proposal, are you saying that a value is unknown if a) no reference to the attribute or b) no reference to that particular value? Do you mean c) no reference in the currently applicable policies or d) no reference in any policy even if those policies may never be applicable or e) no reference in any active policy held by any PDP? Hal From: Martin Smith [mailto:bfc.mclean@gmail.com]
Sent: Tuesday, October 27, 2015 12:41 PM
To: Erik Rissanen
Cc: XACML TC
Subject: 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.") On Tue, Oct 27, 2015 at 8:21 AM, Erik Rissanen <erik@axiomatics.com> 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? I agree with Erik. 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. 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
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. 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 F Smith, Principal
-- David Brossard
VP of Customer Relations
+46(0)760 25 85 75
-- David Brossard
VP of Customer Relations
+46(0)760 25 85 75
-- Martin F Smith, Principal
-- Martin F Smith, Principal
-- Martin F Smith, Principal |