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] Comment on NIST/NCCOE draft -- existing XACML architecture artifacts?


+1

On Nov 23, 2015, at 4:07 PM, Martin Smith <bfc.mclean@gmail.com> wrote:

Hal et al.--

Here's a revised draft comment per the process you laid out in your message earlier today. We might want to include the "picture" just to make it crystal clear what the "High Level Architecture" picture is. 

Thanks,

Martin



PROPOSED XACML TC COMMENT TO NIST RE: SP 1800

"The OASIS XACML Technical Committee welcomes NIST's draft SP 1800-3 Attribute Based Access Control - Practice Guide as an addition to the guidance available for implementers of advanced access-control capability.

This is a comment [representing the views of the Technical Committee] on the SP 1800-3b document (Approach, Architecture, and Security Characteristics), which states it is “intended for individuals responsible for implementing IT security solutions.”

We note and agree with the stated context of the guidance, i.e., "This example solution is made of many commercially available parts. You might swap one of the products we used for one that is better suited for your environment."

We suggest that the guidance would be significantly enhanced by addition of an architectural description or depiction that is not product-specific. Such a logical solution architecture, indicating the componentization, interfaces and applicable standards, would permit implementers to use the guidance to configure a variety of product-specific solutions, thus increasing the applicability and impact of NIST's work.

A depiction of the logical solution architecture would also be simpler and easier to understand than the product-specific configuration in the current draft, since it would not have to depict the interactions needed only for the specific solution described in the draft.  

We suggest that the High-Level Architecture included in the NCCOE’s ABAC Building Block V2, of April 1, 2015, would serve this purpose.  This logical ABAC architecture depiction would provide a clear transition between the Practice Guide’s Overview of “demonstrable capabilities” (functional requirements) in Section 5.1 of the draft SP 1800b and the product-specific ABAC Build 1 Architecture currently depicted in Section 5.2. 

We appreciate this opportunity to comment and look forward to publication of the final version of the Practice Guide. "








On Mon, Nov 23, 2015 at 11:21 AM, Hal Lockhart <hal.lockhart@oracle.com> wrote:

Yes, this is pretty much exactly what I had in mind. I think you are right that it is better to suggest using NIST’s own materials.

 

I suggest you draft a comment to NIST from the TC along the lines you suggest and post it here.

 

Unfortunately I did not realize that we will not meet again before the deadline. However, since this is not an OASIS mandated vote, we can be a bit more informal if no one objects. I suggest we follow one of two procedures.

 

1. People who agree with your draft can post a +1 to it. If we get a majority of the voting members, we can submit the comment as coming from the TC,

 

2. If the members prefer, after you post the draft I will create a ballot for a resolution supporting the comments.

 

Either way, if we get a simple majority of the voting members, the Chairs will send the comment on behalf of the TC.

 

If not, you can still submit the comment in the name of any individuals (including yourself) who have endorsed it.

 

If there seems to be any reason for it, we can still have a voice vote on Dec 10.

 

Hal

 

From: Martin Smith [mailto:bfc.mclean@gmail.com]
Sent: Friday, November 20, 2015 5:28 PM
To: Hal Lockhart
Cc: Rich Levinson; William Parducci; XACML TC
Subject: Re: [xacml] Comment on NIST/NCCOE draft -- existing XACML architecture artifacts?

 

Hal, all--Thanks--that looks like material that might be used. 

 

However, I looked again at the other recent NCCOE paper, the so-called ABAC Building Block.  That is referenced in the draft SP 1800-3b ("b" is the "medium-sized" volume of the set that we have been discussing)  one time in a footnote, not very prominently, as a "white paper."  However, in that ABAC Building Block paper is a pretty good logical diagram, here:

 

<image002.png>

 

(I could quibble about how a few things are represented, but this looks like a good 80% solution.) 

 

Here's a link to the whole document:

 

Assuming that it would be easier and more acceptable to NIST to add material from one of their own docs to the draft 1800-3, we might just suggest that they include this diagram as a logical architecture before presenting their physical (product-specific) solution diagram. We might even suggest they highlight the parts of this diagram that the physical solution covers (which is most of it.) 

 

Looking past the proposed suggestion to include a logical ABAC architecture diagram, does anyone have other observations on the draft 1800-3?

 

And do we agree that we can endorse the above diagram as--is, or do people want to ask them to tweak it?

 

Whatever we do, we need to do it pretty soon:

 

Comments on this publication may be submitted to: abac-nccoe@nist.gov

Public comment period: September 30, 2016 through December 4, 2016

 

 

Regards,

 

Martin

  

 

PS-- I also promised last meeting to locate and send around the functional capabilities which the 1800-3 physical implementation sought to demonstrate. Here they are: 

 

The scope of this build is the successful execution of the following capabilities:

n identity and attribute federation between trust partners

n user authentication and creation of an authentication context

n fine-grained access control through a policy enforcement point (PEP) closely coupled with the

application

n creation of attribute-based policy definitions

n secondary attribute requests

n allowing RP access decisions on external identities without the need for pre-provisioning

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

On Thu, Nov 12, 2015 at 11:49 AM, Hal Lockhart <hal.lockhart@oracle.com> wrote:

I think it was me not Rich.

 

What I had in mind was something like section 3.1 of the core spec.

 

Also I and others have done many overview of XACML/ABAC architecture presentations over the years. For example, This presentation Prateek and Rich did at RSA in 2009.  https://www.oasis-open.org/committees/download.php/22335/RSA-V09.ppt

 

Or the attached one I created for the 2012 RSA Showcase.

 

Hal

 

 

From: Martin Smith [mailto:bfc.mclean@gmail.com]
Sent: Wednesday, November 11, 2015 3:46 PM
To: rich levinson; William Parducci
Cc: XACML TC
Subject: [xacml] Comment on NIST/NCCOE draft -- existing XACML architecture artifacts?

 

Rich/Bill--

 

Last meeting in discussing possible TC comment on the NIST/NCCOE draft, I believe Rich expressed reluctance to make a comment like "you should do more work to make x change in your document" rather than offering specific text adds or changes. He also suggested that there might be something produced in the TC in the past that could be offered as a logical architecture to be added to the NIST doc. (Addition of a non-product-specific architecture diagram to the NIST document was my suggested comment.)

 

So, this is just a reminder to ask if Rich or anyone can suggest a TC-produced artifact that we might provide to NIST for incorporation in the document. 

 

Martin


 

--

Martin F Smith, Principal

BFC Consulting, LLC

McLean, Va 22102



 

--

Martin F Smith, Principal

BFC Consulting, LLC

McLean, Va 22102




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