OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xacml] NCCOE discussion and impediments (to XACML and ABAC adoption)

Hi Rich,

On 29/04/2016 7:02 AM, rich levinson wrote:
I think I pretty much agree w the general points that both Hal and Martin
are making, but I think both are addressing somewhat different perspectives.

Based on my own experience w OpenAz and other multi-domain endeavors,
I have found that syntactic agreement can usually be obtained fairly readily,
if all parties are co-operating, but semantic agreement can remain a roadblock
for a long time, which from a policy perspective, imo, is a show-stopper because
it makes no sense to have a common policy if people interpret the terms

I would say that it makes no sense to have a common attribute if people interpret
the terms differently. Trying to shoehorn different concepts into the same
attribute is a bad idea, but keep them as separate attributes and it is still
possible to have a common policy because XACML provides the tools to do it,
though it is not an ideal situation.

For example, suppose ACME Corp. has a location attribute that uses town names
and AJAX Inc. has a location attribute that uses post codes. It would be nice
if ACME and AJAX could agree to standardize on one or the other, but failing that
a policy writer can write expressions like:

	(acme-location=Melbourne or ajax-postcode=3000)

to refer to a specific locality. This is a simple case, but XACML has many
functions for non-trivial manipulation of attribute values.

So semantic agreement is good to have, but it isn't an absolute requirement.

To have a common policy, harmonization has to occur at some level. Best case is
at the attribute sources. Worst case is at the policy writer. There are other
levels in between. It occurs to me that the Attribute Authority idea I floated
last year could be used to preprocess acme-location and ajax-postcode attributes
coming from the PEP or the PIPs to generate a unified location attribute (using
just town names, say) so that policy writers and auditors can believe there is
semantic agreement though ACME and AJAX can't get their acts together.


Therefore, I think Martin's points 1 and 2 are compelling because they appear
to represent real-world use cases, where semantic agreement, is, in fact, a
primary requirement. Also, even though semantic agreement may be a
theoretical objective, which can never, in fact, be truly reached (as for example,
demonstrated every day on the US Supreme Court, where, ultimately what the
law means is what 5 or more judges on court say that it means), at least having
the notion of semantic agreement can point the way to a process for ultimately
resolving disputes, where presumably the holder of the policy could bring it
to the Supreme Court to determine if the holder's interpretation is correct.

Also, Martin's point 3, about existing profiles of XACML, essentially performing
this role, which I will accept at face value, not having thought about these
profiles in that perspective before, may point a direction to "augmenting"
ABAC w a procedure for nailing down semantic agreement on specific
attributes that the cooperating parties can work with, while leaving other
policies not covered by the profile in the current state of possible
semantic ambiguity until someone is concerned enough to nail these
down as well.


On 4/28/2016 1:25 PM, Hal Lockhart wrote:

Don’t get me wrong. I don’t disagree that semantic agreement would be very desirable. I am just saying that if it is considered a precondition to adoption, then adoption is never going to happen.


*From:*Martin Smith [mailto:bfc.mclean@gmail.com]
*Sent:* Thursday, April 14, 2016 3:03 PM
*To:* Hal Lockhart
*Subject:* Re: [xacml] NCCOE discussion and impediments (to XACML and ABAC adoption)

Hal--thanks for the response.

Regarding the semantic standards issue, I think we're going to have to agree to disagree. I will agree you have a lot of company in the view you express, but I'd make three points:

1.  There is considerable movement to develop semantic standards, not for everything but to support specific transactions within a business community of interest. Both OASIS' UBL and the National Information Exchange Model NIEM) have recently come out with revisions. For NIEM the the approach is to delegate coordination of standardization of specific exchanges (so-called IEPDs)  to domain coordinators within broad sectors such as health, law-enforcement, emergency management, defense. etc.

2.  Many--perhaps most--information-access policies are not local. This is the biggest change from the traditional view where a local database admin keeps a list of names on an ACL, according to his own best lights. But many policies are based in law that has wide application, which means that the legal concepts (like the ones I mentioned -- law-enforcement officer, physician) are also widely applicable. In this increasingly compliance-oriented world, having standardized concepts for required info access policies should be of significant value to enterprise officers responsible for documenting compliance.

3.  Most important I think is that a lot of the potential value of ABAC will be left on the table if the model cannot be extended outside a single enterprise. And cross-organizational sharing of sensitive information requires semantic "interoperability" between business partners, which may start as bilateral agreement on terms but has to be broader than that (but not universal) if it is to scale. The XACML TC's IP and Export Control profiles are examples of standardizing attribute semantics for two specific classes of transactions.



On Thu, Apr 14, 2016 at 1:50 PM, Hal Lockhart <hal.lockhart@oracle.com <mailto:hal.lockhart@oracle.com>> wrote:

I agree with most of this, Martin. Thanks for putting it all in one place.


The main point I disagree with you on is:

5. Lack of institutions or processes for developing cross-organizations semantic standards (e.g., what's a "law-enforcement officer" or a "physician", or "PII" or a "medical record"?)

IMHO this is not going to happen. Any AC scheme that has this as a precondition is not going to be adopted. For the foreseeable future, policies are local with rare exceptions.


To your elephant in the room, I suggest that to answer this question we have to be very specific about what we are comparing XACML or ABAC to. Many people implicitly compare it to permissions or ACLs or even RBAC. However, far and away the most common form of access control is program code written in a Turing-complete language and embedded within the application.

In this context the greatest benefit is simply to be able to identify what the policy is, as distinct from various aspects of the application logic or UI.


*From:*Martin Smith [mailto:bfc.mclean@gmail.com <mailto:bfc.mclean@gmail.com>]
*Sent:* Sunday, April 03, 2016 12:59 PM
*Subject:* [xacml] NCCOE discussion and impediments (to XACML and ABAC adoption)

In his discussion with the TC last week Bill Fisher of NIST/NCCOE said he was looking for activities NCCOE might take to advance the implementation of ABAC in the private sector. He also described several of the past and present projects, including the ABAC Building Blocks publication ( <https://nccoe.nist.gov/sites/default/files/documents/NCCoE_ABAC_Building_Block_v2_final.pdf>https://nccoe.nist.gov/sites/default/files/documents/NCCoE_ABAC_Building_Block_v2_final.pdf )  and the more recent NIST 1800-3 ABAC Practice Guide ( https://nccoe.nist.gov/library/nist-sp-1800-3-attribute-based-access-control-practice-guide ).  The XACML TC submitted comments on the latter, as you may recall.

Although it came up only tangentially in the discussion last week, the NCCOE's program is based on some diagnosis of why ABAC adoption has been disappointingly slow.  I believe Bill mentioned NIST's perception that one obstacle is lack of detailed guidance on how to integrate and configure ABAC components; hence the Practice Guide. He also mentioned being interested in identifying technology or product/tool gaps.

Perhaps it would be useful for us to take a step back from ideas on "what to do" and have a look at "what's the problem." In other words, maybe we should consider developing and documenting a common understanding of ABAC implementation obstacles and their relative importance.  This would then provide a sound basis for NIST/NCCOE (and others, including ABAC product vendors) to focus on activities that address the obstacles.

So, here's a "starter set" of obstacles (or categories of obstacles) for your consideration:

1. The elephant in the room:  what is the business case for ABAC? Some possible answers below, but in all cases I'd say there's a lack of well-documented (preferably with some before-and-after metrics) "case studies" of how ABAC has delivered one or more business benefits. (A brief nod to Axiomatics who seem to be trying to address this with their recent series of WebEx events.) Possible business benefits:

  a.  Ability to put more sensitive information on-line (within the enterprise but especially for sharing with customers and business partners)

  b.  Compliance: demonstrated conformance with data-protection regulations like Sarbanes-Oxley, various jurisdictions' privacy regulations, HIPAA, etc.

  c.  Privacy and security:  not the same as "compliance", which is process- vs outcome- oriented

  d.  Operating cost savings

  e.  "Agility" -- ability to implement access-policy changes quickly and consistently across the enterprise or other relevant environment. Also ability to reach a targeted user demographic quickly when a new information service is fielded.

2. Lack of understanding or engagement among enterprise "policy authorities" (CFOs, Counsels, CPOs, CISOs) on developing "digital-ready" policies in their respective areas of responsibility. "Digital-ready" means policy expressed in natural-language but unambiguous expression (i.e., "if-then" statements.)

3. Lack of incentives for operators of "authoritative attribute" data sources to make their attribute data available for digital access-control use.

4. Lack of standards for how resource attributes (data tags, etc) can be identified and accessed (by a "context handler.')

5. Lack of institutions or processes for developing cross-organizations semantic standards (e.g., what's a "law-enforcement officer" or a "physician", or "PII" or a "medical record"?)

6. Unapproachability of raw XACML (which means that implementer technical resources are dependent on vendor-specific tooling for policy/rule writing.)

7. Lack of a widely recognized or standardized logical architecture (with testable component functions and interfaces) for full ABAC, resulting in "customized" solutions that are therefore very expensive and also non-interoperable across different organizations.




*Martin F Smith, Principal*

*BFC Consulting, LLC*

McLean, Va 22102

703 506-0159 <tel:703%20506-0159>

703 389-3224 <tel:703%20389-3224> mobile


*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]