xacml message

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

From: Steven Legg <steven.legg@viewds.com>
To: Erik Rissanen <erik@axiomatics.com>
Date: Fri, 5 Feb 2016 10:21:16 +1100


Hi Erik,

On 5/02/2016 2:45 AM, Erik Rissanen wrote:

+1 too, except you should not use set equals, but allOfAny since the set
of understood attributes may be a super set of the set of attributes
which must be understood.


MustUnderstand isn't the best name for the attribute, but I was going with
the flow. I suspect Martin would say that *any* discrepancy between the set
of attributes the resource owner thinks are significant for access control
decisions and the set of attributes the policy writer thinks are significant for
access control decisions would be an indication that something is wrong. That
mandates set equality.

You and I both know that reality isn't that simple. If we were talking about
a new feature in XACML then real-world considerations would have to be
addressed. The advantage of expressing the comparison in policy is that the
policy writer has the freedom to deal with exceptional situations. One example
is when there is a need to alter the set of significant attributes. The PEPs
can't all change instantaneously so there has to be a transition period when the
old set and the new set are both in use. It is easy to write an XACML expression
that will except either. A new feature would have to be designed to deal with
this and other reasonable departures from typical. I also suspect that Martin
would say that there has to be a point in time when the old set is no longer
accepted, thus returning to simple set equality, though I can think of situations
that would require more permanent exceptions.

For these reasons, any profile that Martin writes should not make the organization
of the policies, or the manner of the comparison, normative.

Regards,
Steven


Best regards,
Erik

On 2016-02-04 16:19, Hal Lockhart wrote:

+1

-----Original Message-----
From: Steven Legg [mailto:steven.legg@viewds.com]
Sent: Sunday, January 31, 2016 11:48 PM
To: rich levinson
Cc: Martin Smith; XACML TC
Subject: Re: [xacml] Re: [EXTERNAL] [xacml] Default behavior for
unrecognized resource attributes?


Hi Rich,

On 21/01/2016 8:41 PM, rich levinson wrote:

Here's my 2 cents as far as I understand the issue:

I'll match your monetary investment.

I think one way it could be supported is to have something like a
MustUnderstand optional piece of Attribute metadata, that could work
something like this:

     if an attribute is present w the MustUnderstand xml-attr == Deny,
     then if the policy does not understand the attribute, and the

decision

       otherwise is Permit, then result should be Deny,
       and if the decision ow would be Deny, then Deny

     similarly

     if an attribute is present w the MustUnderstand xml-attr ==

Permit,

     then if the policy does not understand the attribute, and the

decision

       otherwise is Permit, then result should also be Permit,
       if the decision ow would be Deny, then Deny
     (this latter block looks like a no-op, so maybe this case is N/A)

However, the first block seems somewhat logical, and possibly there

is

a way to list all the attributes used in the policy and if the one w
the MustUnderstand is not on the list then the Rule to Deny would be
applied.

Rather than a MustUnderstand XML attribute I suggest defining an XACML
resource attribute that contains a list of the identifiers of the
attributes that must be understood. This has the advantage that it
requires no change to the XACML core specification. The policies could
be structured so as to check that the provided list conforms with the
expectations of the policy. For example, by wrapping everything in a
deny-overrides policy set containing a policy with a deny rule that has
a condition that checks whether the MustUnderstand XACML attribute bag
is not equal to a literal bag (i.e., not(string-set-
equals(resource.MustUnderstand, string-bag(foobar1, foobar2, ...)))).
The result is deny if the expectations of the authority responsible for
the resource (rather than specifically the PEP or PIP since resource
attributes can come from either) don't match the expectations of the
policy writer. This also requires no new features in the core
specification.

This solution is entirely opt-in. Deployments that don't want to use it
can safely ignore the MustUnderstand attribute. Since no new core
functionality is required, just about any general-purpose XACML product
can claim support for it already for deployments that do want to use
it.

For completeness, an XACML attribute is identified by category ID,
attribute ID and data type ID. The MustUnderstand attribute being a
resource attribute takes care of the category ID. The values of the
attribute should therefore be strings containing the concatenation of
the attribute ID and data type ID. XACML IDs are compared code-point by
code-point, which is exactly how string-set-equals works.

In theory a PAP could be written to automatically scan a collection of
policies for referenced resource attributes and wrap them with the
appropriate test of the MustUnderstand attribute. Worst case, the
policy writer does it manually.

Steven

Above is not a recommendation, but a thought on how it might be
approached if someone wanted to build a profile that used the

capability.

However, I would defer to Erik and Stephen, as to whether it is
readily implementable or not.

      Thanks,
      Rich

On 1/21/2016 12:19 AM, Martin Smith wrote:

Eric, all--

Your description of the scenario I envision is almost what I meant,

but I don't understand this:

"Later on, the PEP is changed so that it sends a new attribute

called

"privacy_controlled"".  What I meant is that the relying party adds

tag to the resource.  As far as I know the PEP has no way of knowing
this new tag has been added, unless by saying "PEP" you include the
RP resource itself somehow. And in any case, my understanding is

that

the PEP (or "context handler"?) only collects tags mentioned in the
active policy set, or those asked for by the PDP. I am probably
confused, but I don't see any XACML function through which any IAM
component collects ALL access-related resource tags (specifically to
include those NOT referred to by any rule in the active policy set.)

Moving on to the question of utility:  Eric is correct that this
addresses only one class of error, but I'd assert that it's a very

likely source of error. The organizational process of creating and
deploying policies is likely centralized, or at least coordinated
within a data governance "committee."  The data-tagging process is
likely to be run by more operational units, and there may be many
separately managed protected resources (that should be ) subject to the
same enterprise set of laws and regs. These data resources are likely
to be more dynamic than the policies as new sub-sites are added, for
example, to a portal. This the coordination between policies and tags
is likely to be more error-prone. One type of error--where the resource
manager fails to add an appropriate marking-- should be caught since
the related policy will not be satisfied. But if a resource owner adds
a tag, either one in a new data series (perhaps from another
organization), or an obsolete one because his marking guidance is out
of date, or because the marking application/tool hasn't been updated.
One would like to catch these errors.

Finally, remember that per Hal's advice the idea is to make this a

profile, so that only implementers who are very concerned about these
errors (and would rather block them than risk an access error) would
use it. And eve that can be made less "disruptive" if the profile would
include a selectable option to provide "Advice" (of an unused resource
attribute) rather than a Deny.

Regards,

Martin




On Fri, Jan 15, 2016 at 4:17 AM, Erik Rissanen <erik@axiomatics.com

<mailto:erik@axiomatics.com>> wrote:

     Hi Hal,

     Imagine that you have a deployment of a PEP and PDP with

policies in production. The PEP sends a bunch of attributes about
documents.

     Later on, the PEP is changed so that it sends a new attribute

called "privacy_controlled", which is needed for a new privacy law.
However, nobody updates the policy. In this case Martin wants to detect
that the policy is wrong because the new attribute is not used. He
argues that since the PEP sends this attribute, the PEP expects that
this attribute should be taken into account, thus it should be
mentioned in the policy.

     That the policy does not conform to the new privacy law is a

type 2 error. It is detected in this case by the missing attribute
reference in the policy.

     The points I have been raising is that this is a very specific

case, and I don't think it is correct to assume in general that because
the PEP sends an attribute, that attribute is critical and must be part
of the policy. Enforcing this kind of behavior in a standard would mean
that the PDP is going to be unusable in the situations where these
assumptions do not hold.

     If you want to specify a mechanism of detecting this specific

kind of error, it should be done by means of metadata. The PDP could
publish a statement saying "I am operating with a policy which has been
authored with the attributes foo, bar, ... in mind." Whether that means
that all attributes are used or not is something which the policy
author decides. In any case, the PEP can check whether the attributes
it thinks are relevant have been taken into account when the policies
were authored.

     My second, separate point is that I don't think this kind of

feature is very useful. There is much more to correctness of policies
and there exists well known general tools and processes which can be
used to ensure that the right set of policies are used. Since you need
to do that anyway for so many other reasons, this special corner case
that a missing attribute may in some cases indicate an error is not
worth implementing in my opinion.

     Regarding you question about the Auditor tool, yes it could be

used to test that an attribute impacts the decision of the PDP as
expected. But as you say, the requirements (test cases) must be
correct. If nobody updates the test cases, then obviously the tool will
give the wrong result, in the sense of real world requirements.

     Best regards,
     Erik



     On 2016-01-14 20:33, Hal Lockhart wrote:

     I don’t really understand your point. The Policy Auditor is

always going to compare the invariants you specify with the policy. If
you specify the wrong invariants, you will not get the right answer.

     If the “true policy” is in your brain, we can never know if you

have expressed it correctly as xacml policy, tool invariants or natural
language prose. If on the other hand the “true policy” is a law or
regulation, then you need a translator from natural language, which is
well known to be an unsolved problem.

     My point is, strictly speaking we can never solve your type 2

problem. Until the “true policy” is rendered into unambiguous form we
cannot do any automated analysis on it, period.

     Going back to the idea of using the Policy Auditor to answer

Martin’s question, are you saying that there is some limitation in the
tool’s ability to do this or that we can never be sure if the specified
invariants correspond to the “true policy”?

     In other words, if we were willing to stipulate that the inputs

to the Policy Auditor do correspond to the “true policy” could we use
the tool for this type of analysis?

     Hal

     P.S. I do not claim yet to understand what condition Martin

wants to test for, but you seem to.

     *From:*Erik Rissanen [mailto:erik@axiomatics.com]
     *Sent:* Friday, January 08, 2016 3:15 AM
     *To:* Hal Lockhart; Martin Smith
     *Cc:* XACML TC
     *Subject:* Re: [xacml] Re: [EXTERNAL] [xacml] Default behavior

for unrecognized resource attributes?

     Hi Hal,

     I agree with you on all points.

     As for your question about Axiomatics products, you must be

thinking of the Axiomatics Policy Auditor. I think that product is
about a slightly different issue than what Martin is concerned about.

     With the Policy Auditor you can test that policies comply with

certain invariants. You could for instance create a test case which
says that a resource is export regulated and that the location of the
subject is in North Korea. All other attributes would be left as open.
What the product can then calculate is whether given these two
attributes, regardless of any other attribute values, it can check that
the decision would always be Deny. If not, it will give a specific
example of a request where the decision is not deny.

     Another example would be that you create a test case saying

that emergency override is in effect, then the decision should always
be Permit. Again, if this is not true, the logic analyzer will find
examples of violations, so you can fix your policies.

     The point is to do "open ended" testing in order to validate

invariants by means of a logical proof. This is different than doing a
large set of regular XACML request test vectors, because with such
enumerations you cannot know for sure that there won't be another test
case which would violate your requirements. The space of all possible
access requests is infinite, so it cannot be enumerated fully.

     This kind of testing is a bit different from what I think

Martin is looking for. You could use the Axiomatics product to test
your policies, but it does not help you with the coordination that the
policy package which the PDP is using corresponds to the set of
requirements that the PEP is expecting.

     To state that again using different words, there are two kinds

of errors which can happen: 1) Given your requirements the policy might
not do what it should do (here the Axiomatics tool helps you), or 2)
The policy corresponds to a set of requirements, but these requirements
are the wrong ones.

     A "type 2" error could happen in a federated environment for

instance when a new requirement is introduced, and the PEP and the PDP
are not within the same life cycle coordination. It could be that a PEP
is deployed with a new set of requirements in mind without the PDP
having been updated.

     To guard against type 2 errors, you could use project

management processes. To detect it at runtime, I think a metadata
exchange would be needed because there is nothing in any set of
policies which allows the PDP to a priori assume that the policies are
wrong.

     Best regards,
     Erik

     On 2016-01-07 17:58, Hal Lockhart wrote:

         I am just catching up with this thread.

         I think there are at least two separable issues which have

become a bit entangled.

         1. what is needed and how best to accomplish it.

         2. whether it is a reasonable requirement, or alternatively

how common is this environment.

         In the earlier discussion, I largely ignored #2. The idea

of a Profile is that it is a set of functionality which is seen as
useful by all or some members. It is optional for anyone to support a
Profile even if they support the core. Before a Profile (or any spec)
becomes an OASIS Standard, we need 3 Statements of Use, which is
intended to demonstrate there is at least some level of interest in
actually using it.

         IMO, one can object to a Profile that forces mandatory

behavior which is seen as harmful or interferes with other mechanisms
you depend on. Or you can object on technical grounds that the proposed
scheme will not function as described. Alternatively, you can object
because you want to use the Profile, but the proposal does not contain
features you need. However, it is rarely necessary to object on the
grounds that nobody needs it.

         Therefore I will focus on #1.

         Let’s start with the basics. In XACML Attributes are all we

know about anything. Everything that a policy can use as data is an
Attribute of something. XACML merely assumes that the Attributes we
need are somehow available in the environment. In practice they usually
come from existing, non-xacml sources, which make them available by
preexisting means which we have no way to influence. For example, a
file as a resource would have a name, modification data, size, owner
among other data. The means of obtaining attributes of all kinds for a
given sort of Resource (or Subject) will probably be the same.

         My conclusion from this is that to do what Martin wants,

whether at policy deployment time or at decision time will require some
kind declarative mechanisms that says “these are the attributes/values”
which are critical to access control and the others are not. I see no
way for the PDP or context handler or PAP to make this distinction, nor
any way to insure that only one or the other type is present when
attribute values are obtained from their sources.

         XACML attributes can be single valued or multi-value. The

way information is encoded in attributes is not specified by xacml for
the simple reason that they usually exist in advance of their use in
policies and typically it is not possible to change their structure.
For example, suppose there are properties Red, Green, Blue associated
with resources. This could be represented in at least 3 ways: 1) Single
value enumerated attribute called color can contain  Red, Green or
Blue, 2) Three different attributes called Red, Green & Blue each of
which may be present or absent, and 3) a multi-value attribute which
may contain the values Red, Green & Blue zero, one or more than one
time each.

         So for starters the question is whether to cover all of

these cases or just some and what specifically should the rules be for
each supported case. In particular is it sufficient to perform some
test on an attribute or do we have to check for all the legal values or
just check at least one.

         Now consider the xacml policy evaluation process. A policy

package contains a bunch of policies the PDP trusts, but just by
looking at them it is not possible to determine which ones will be used
for a particular decision or even if they will ever be used. Only when
a request is processed then if the tests in the Target and Condition
are true, the policy will be deemed applicable. Then the applicable
policies’ Effect will be combined to produce a decision. At that point
, that is in the context of a particular request) we have three types
of policies: 1) Inapplicable, 2) Applicable with same Effect as the
decision and 3) Applicable, but with a different Effect as the
decision.

         So here we need to decide do the checks of critical

attributes in policy need to occur in Set 2 or both Set 2 and Set 3?

         I believe answering these questions will clarified the

desired functionality.

         Turning to implementation, I agree it is very desirable to

do this analysis at policy testing/deployment time not at decision time
if at all possible. It seems a bad practice to halt all access to a
resource because we discovered a policy bug at decision time. This
could conceivably create a DoS attack in some environments. Further
many environments have latency requirements for policy decisions.

         The approach I mentioned last year was to perform semantic

analysis on the policies and determine if certain information was
checked under specified conditions. I believe it would also be possible
to assert conditions that you believe will always true about your
policies. This would be more general that Martins cases, but would also
make it possible to detect policy errors.

         At one point Axiomatics was offering a semantic analysis

tool, developed by another company, to analyze policies. I don’t see it
mentioned on their web site now, so perhaps that approach has been
abandoned. Can Erik or David or anybody from Axiomatics comment on the
experiences with this?

         Hal

         *From:*Erik Rissanen [mailto:erik@axiomatics.com]
         *Sent:* Thursday, January 07, 2016 3:54 AM
         *To:* Martin Smith
         *Cc:* XACML TC
         *Subject:* Re: [xacml] Re: [EXTERNAL] [xacml] Default

behavior for unrecognized resource attributes?

         Martin,

         Ok, then I have misunderstood you a bit. I thought that you

meant that an attribute was referenced at runtime evaluation, not just
that the policies reference it somewhere. I don't think that changes
the discussion much though. The same kind of arguments can be made that
an attribute might be irrelevant and legitimately ignored by the
policies as a whole because the attribute is relevant only in some
other context.

         As for you looking for "any mechanism, performed by the PDP

or elsewhere, that will assure that all resource attributes are
referenced by some rule in the set of policies applied to a decision",
then that is something which is not present in the XACML standard.

         Best regards,
         Erik


         On 2016-01-05 20:19, Martin Smith wrote:

             Eric--

             Let's drill down on what is meant by "used."  Let's say

that a regulation says that if ANY of three conditions (rules A, B or
C) is met, then the resource may be accessed.  Let's say that rule B is
not met and (by itself) would result in a DENY, but rule A is met and
thus the overall outcome is PERMIT.  Is rule B "not used"?

             I tried to avoid this ambiguity by proposing that the

set of rules collected to process a request must contain at least one
rule that refers to each of the access-related attributes associated
with the protected resource. Just because the set of "active" rules
includes one or more rules that do not affect the decision regarding
the current request by the current user in the current environment.
doesn't mean those rules are irrelevant. At query time, relevancy is
determined by the resource attributes; which resource attributes are
required to be associated with which resources is determined at "design
time", when the policies are developed by governance authorities.

             Regarding "what the PDP does not know": an interesting

viewpoint. My understanding is that what the PDP knows is (a) a set of
policies loaded from the PAP; (b) the Request Context provided by the
Context Handler; and (c) additional subject, resource or environmental
attributes the PDP may request via the Context Handler.

             My initial thought as to how the PDP might implement

the goal of accounting for all resource attributes was for it to
request "All" resource attributes. (This is not supported in the
current spec as I read it.) My understanding (but I certainly could be
wrong) is that the PDP will identify all Policies with a Rule that
references any attribute of the requested resource. In addition, my
thought would be that the PDP should check that all the resource's
attributes are referenced by some rule to be applied to the current
request, and if not, then issue a Deny decision, perhaps with
explanation. I do not think this checking function can be performed by
anything is the current spec. Both the gathering of all resource
attributes and the checking and Deny decision would be a selectable
option by the implementing organization.

             All this said, I repeat that what I'm looking for is

any mechanism, performed by the PDP or elsewhere, that will assure that
all resource attributes are referenced by some rule in the set of
policies applied to a decision.

             I agree with your statement (as slightly amended): "The

current XACML spec simply assumes that you are operating with the
correct policies. What you are looking for is some extra information to
detect some cases where a mistake has been made in the deployment and
the policies /[or the applied resource attributes]/ are not correct."

             Regards,

             Martin




--
*Martin F Smith, Principal*
*BFC Consulting, LLC*
McLean, Va 22102
703 506-0159
703 389-3224 mobile

--
Thanks, Rich

Oracle <http://www.oracle.com>
Rich Levinson | Internet Standards Security Architect
Mobile: +1 978 5055017 <tel:+1%20978%205055017> Oracle Identity
Management
45 Network Drive | Burlington, Massachusetts 01803 Green Oracle
<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

References:
- RE: [xacml] Re: [EXTERNAL] [xacml] Default behavior for unrecognized resource attributes?
  - From: Hal Lockhart <hal.lockhart@oracle.com>
- Re: [xacml] Re: [EXTERNAL] [xacml] Default behavior for unrecognized resource attributes?
  - From: Erik Rissanen <erik@axiomatics.com>