xacml — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
Minutes for New Orleans F2F
MHonArc v2.5.0b2 -->xacml message
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes for New Orleans F2F
- From: Bill Parducci <[email protected]>
- To: xacml <[email protected]>
- Date: Mon, 03 May 2004 13:54:42 -0700
below are the minutes for the face to face in new orleans. as usual the written
summary can't do justice to the thought process (much less the passion by which
the ideas were presented ;o), but the combined efforts of anne and i should give
those of you who were unable to attend a good idea of where we stand on the
remaining v2 issues.
b
=======================================================
= Meeting Minutes for April 28, 2004 F2F, New Orleans =
=======================================================
Attending:
(v) Mike McIntosh, IBM
(v) Michiharu Kudoh, IBM
(v) Ed Coyne, Veterans Health Administration
(v) Hal Lockhart, BEA
(p) Don Choi, US Defense Information Systems Agency
(v) Simon Godik, Overxeer
(v) Polar Humenn, self
(v) Bill Parducci, Overxeer
(v) Anne Anderson, Sun
(v) Daniel Engovatov, BEA
(v) Tim Moses, Entrust
(o) Thomas Bui, Boeing
ACTION ITEMS:
1. [Simon]: provide Tim with reference for the canonical time format.
2. [TC]: supply Bill with list of things to include in the changes/backwards
compatibility section.
3. [Anne]: produce revised Hierarchical Resources proposal. This is the only
item somewhat committed for 2.0 that has not yet been
resolved.
4. [Polar]: produce a working draft with absolutely no Haskell of a proposed
solution for delegation.
5. [Anne]: MAY produce a non-normative introductory document that duplicates
much of what is in Sections 2-4.
6. [Daniel]: produce well-written, clear proposal for Hierarchical Resources.
7. [Michiharu]: describe how resource-ids are generated from RequestContext is
generated, in case of XML documents.
8. [Anne]: get Tim her comments, proposed corrections on Functional Requirements
section.
9. [Tim]: based on Anne's notes and existing Base Policies section, describe the
three levels of PEP conformance.
10.[Anne]: SAML Attribute Profile for XACML draft.
11.[Frank]: provide proposal for environment attributes related to time intervals.
12.[Michiharu,Mike]: find out what the licensing requirements are for
Obligations. May be in the form of a contact person and telephone number. We
know they are RAND. We need to know what the royalties will be.
13.[Michiharu]: provide the patent # for the Obligations patent that has issued
in the U.S.
14.[Tim]: provide Anne with leaf names of the two schema URLs.
15.[Anne]: ask OASIS webmaster for and provide Tim with 2 fixed URLs that
terminate in the two leaf schema names.
==========
Meeting began 9:00am, quorum reached.
Agenda review.
==========
SAML and XACML Attribute Convergence:
[Anne] presented draft SAML profile for XACML to cover requests between PEP <-->
PDP <--> PRP
[Tim] discussed current draft from SSTC on the topic.
The two current options for attribute type-casting: in-band (instance) and meta
data exchange, the latter a current mechanism supported by SAML. The general
consensus is that the TC work to provide a profile for each. SSTC has a document
in progress that Anne and Tim will work with the appropriate SSTC members to
derive a solution that is mutually acceptable to both TCs.
==========
XACML constraints on PEP:
Upon discussion, the TC arrived at three conforming PEP models: Base,
Deny-Biased, Permit-Biased.
Base conformance:
* Permit access if Response is "Permit". If Obligations are presented, then
Permit only if understand, can discharge, and will discharge any Obligations
returned with the response.
* Deny access if Response is "Deny". If Obligations are presented, then Deny
only if understand, can discharge, and will discharge any Obligations returned
with the response.
* Not Applicable Response: access behavior is undefined.
* Indeterminate Response: access behavior is undefined.
Deny-biased conformance:
* Permit access ONLY if Response is "Permit". If Obligations are presented,
then Permit only if understand, can discharge, and will discharge any
Obligations returned with the response.
All other Responses result in the denial of access to Subject.
Note: other actions--consultation of additional PDPs, reformulation/resubmission
of query, etc.--are not prohibited.
Permit-biased conformance:
* Deny access ONLY if Response is "Deny". If Obligations are presented, then
Deny only if understand, can discharge, and will discharge any Obligations
returned with the response.
All other Responses result in the permission of access to Subject.
Note: other actions--consultation of additional PDPs, reformulation/resubmission
of query, etc.--are not prohibited.
==========
Base Policy discussion:
The concept of a Base Policy was discussed. The following definition emerged:
Section 7.2: For purposes of this specification, in relation to a particular
Request, a given PDP is defined as a Policy Combining Algorithm and a set of
policies and/or policy sets. The PDP SHALL return a Response as if it evaluates
a single policy set consisting of this Policy Combining Algorithm and the set of
policies and policy sets.
TBD: align with Section 2.10
We would move the remaining existing text in 7.2 that describes various "MAY"
models - collecting applicable policies in response to the contents of the
Request into a PolicySet template that has a pre-defined PolicyCombingAlgorithm,
etc. - into Sections 2-4.
Note that this might affect Conformance Tests.
==========
Are XACML policies portable?
[Polar] Can't expect any particular attributes from the request. If could
depend on getting subject-id, resource-id, action-id, and the standard
environment attributes, then could write a policy that would always apply. But
this could be done with a profile document.
==========
Hierarchical Resources:
(see also “Alternate Hierarchical Resource Proposal” below)
The policy considerations necessary to protect hierarchical resources was
discussed. Anne began the discussion with a review of her proposed solution.
After significant discussion the matter, a number of issues remain:
* Support normative, but not mandatory?
* Do we need a new DataType for "xpath-expression" (see possible uses below)?
Requires DataType to be evaluated to see if it is valid. Probably sufficient to
say "#string, limited to 'must be an XPath expression'". There is no currently
defined data type for an "XPath" expression, so we would have to define one.
* What information is supplied in the Request Context in order to request access
to a hierarchical resource?
PROPOSAL:
<Resource>
<Attribute AttributeId="...:xpath" DataType="...:xpath-expression???">
<AttributeValue DataType="...:xpath-expression???">
[expression]
</AttributeValue>
</Attribute>
<ResourceContent>
[an XML document representing the hierarchical resource]
</ResourceContent>
</Resource>
* Do we retain existing XACML 1.1 support for "scope"? [Daniel] wants it.
* Does the PDP iterate through each node in the requested node set, returning
one <Result> element in the <Response> for each such node?
PROPOSAL: Yes, or equivalent to. Each <Result> element includes the ResourceId
of the node to which it applies (what DataType?? xpath-expression that evaluates
to exactly that node?) and <Decision> (Permit, Deny, Indeterminate,
NotApplicable) for that node.
* Does PDP return <Result> elements only for leaf nodes? Probably yes.
* Is there an easy way to optimize, so that minimal re-evaluation of XPath
expressions is done?
* Is there a standard way to create an XML document from a hierarchy that is not
an XML document to begin with?
USE CASE: Unix File System
PROPOSAL: Create document in which XML tags are the values of the IDENTITIES of
the nodes in the hierarchy.
Directory subtree:
//aaa/b/c/d
//aaa/e
//aaa/f/g/h
//aaa/f/i/j
becomes:
<aaa>
<b>
<c>
<d/>
</c>
</b>
<e/>
<f>
<g>
<h/>
</g>
<i>
<j/>
</i>
</f>
</aaa>
* Are there hierarchies we want to support that do not have identifiers for each
node that can be used as tags in this way?
* Do we need to be able to attach attributes such as "owner" to nodes in the
hierarchy.
* Is there a simpler syntax to use for specifying paths and subtrees in the
hierarchy than XPath [Daniel Action Item].
* Do we need any hierarchy-specific functions other than the existing
xpath-node-match? Probably not.
===========
Veteran’s Health Administration Presentation:
[Ed] presented CCOW Health care Implementation.
* user-centered technique for integrating applications
* HL7 context management
* Context manager: sentillion
Want to have multiple applications view same patient context information.
Change patient being viewed in one, and it changes in others. Applications come
from different vendors, have different interfaces, etc.
Want to use Tivoli for the transport, communication between entities, which they
hope will be enabled to use XML.
Planning to use XACML and XACML Profile for RBAC. Tim pointed out that XACML
RBAC alone does not support Separation of Duty. XACML can handle if, for
example, once Action A is performed by Subject A, the application writes Subject
A into the document as the entity that performed Action A. Then XACML can be
used to say Subject for Action B must not match the identity of the entity that
performed Action A by making an AttributeSelector into that field of the document.
===========
Presentation
Obligations in Rules:
Michiharu presented a simple Use Case to illustrate the use of Obligations in Rules
1st Rule: Simon can eat weeds on weekdays.
2nd Rule: Simon can eat weeds on weekends.
1st Rule: Simon can eat weeds on weekdays,
but Obligation=charge $5
2nd Rule: Simon can eat weeds on weekends,
but Obligation=charge $10
In XACML 1.0 have to create two Policies to achieve same effect.
[Bill] To handle "conflicting obligations", just define one big Obligation ($5
on weekdays, $50 on holidays) and let the PEP interpret it. Obligations are
opaque to the PDP so there doesn’t seem to be any value to the XACML
specification to add this overhead to the policy decision device.
[Polar] If we add Obligations to Rules, we have no difference between Policy and
Rule.
Tentative conclusion: drop this work item for 2.0. [Michiharu] is comfortable
with this.
=======================================================
= Meeting Minutes for April 29, 2004 F2F, New Orleans =
=======================================================
Attending:
(v) Mike McIntosh, IBM
(v) Michiharu Kudoh, IBM
(v) Ed Coyne, Veterans Health Administration
(v) Hal Lockhart, BEA
(p) Don Choi, US Defense Information Systems Agency
(v) Simon Godik, Overxeer
(v) Polar Humenn, self
(v) Bill Parducci, Overxeer
(v) Anne Anderson, Sun
(v) Daniel Engovatov, BEA
(v) Tim Moses, Entrust
(v) Frank Siebenlist
==========
Meeting began 9:00am, quorum reached.
Agenda review.
==========
Distributed Administration:
[Frank] presented his proposal for distributed administration. After several
hours of discussion there weren’t any immediate objections to pursuing the
general model further.
[Hal] concerned that Issuer is only constrained by Subject, however didn’t feel
that this will necessarily be a problem in practical terms
[Daniel] concerned that revocation is not addressed
[Polar] concerned that they model may “get away” from the intended implementation.
[Tim] is concerned that the complexity of a fully generalized model may take a
long time to resolve and that we may wish to add some constraints that will
limit this.
[Hal] Since this will not make it into the 2.0 specification that we shouldn’t
consider limitations yet. Also, called for examples of cases that are either not
covered or are more fully explanatory.
Submissions should be presented as Working Drafts (vs. simple e-mail threads).
==========
WI #68 – Attribute assertion:
After significant discussion, the conversation distilled to [Frank] asking for a
mechanism that allows a Subject to query a PDP for conditions by which access is
granted to a resource in a time interval.
It was the general consensus of the TC that XACML is not designed to behave in
this fashion. Hal proposed that a time-interval attribute mechanism be defined
as a potential mitigation alternative. Frank agreed that this would be of value.
Action Item: [Frank] will formulate a specific proposal to address this.
==========
[Polar] The current spec mentions the PDP as being the source for current time
and that this should be the Context Handler. It is generally agreed this is the
correct and that the retrieval of time and date information is done by the
Context Handler and not by the PDP.
==========
[Simon] Proposed that all time values referenced in XACML must be in the
Canonical format defined by XML Schema.
==========
WI 52 – Section on differences between XACML v1.1 and v2.0
[Bill] requested input on format and granularity of content. Areas of interest
include:
* Backwards compatibility
* Loss of “Any”
* Semantics of missing components have changed
* Variable Definition & Reference Combining Parameters
* Expression substitution groups
* Look in SAML diff doc as a template
* Version in Policy
==========
WI 65 – Addition layer of aggregation to XACML
[Daniel] taken care of by work underway with SAML. Work Item closed.
==========
Alternate Hierarchical Resource Proposal
[Daniel] revisited Hierarchical resource topic since he is concerned that only a
single ResourceId represents multiple [child] resources in a single request.
[Daniel] proposed two independent mechanisms.
1) A shortcut for submitting multiple Request Contexts in one to a Context
Handler. The Context Handler is responsible for decomposing those into
separate RequestContexts, each about one resource in the original RC. The PDP
will make its decisions based on one decomposed <resource> at a time, and will
never be able to see more than one <resource> at a time.
Following syntax is from [Anne]. [Daniel] presented a somewhat different
syntax for this that would require the PDP itself to decompose the multiple
requests.
<resources>
<resource>
resource1
</resource>
<resource>
resource2
</resource>
[...]
</resources>
Before the PDP sees this RequestContext, it is modified by the Context
Handler into a sequence of RequestContexts, which are presented to the PDP one
at a time. Each such RequestContext contains one of the <resource> elements
from the original. The <Result> from each decision is included in the
<Response> to the original many-in-one RequestContext.
This mechanism MAY be used to request multiple elements in a hierarchy, but
it is not limited to that.
The XPath approach allows one statement for expressing the set of resources
for which individual decisions are requested. It is limited to hierarchies, and
works best with XML resources.
2) Orthogonally, [Daniel] has proposed a mechanism for supplying the
ancestors/parents of a resource, by supplying an Attribute containing a bag of
the resource's ancestors/parents. It does not require any particular syntax for
expressing the ancestors, and the ancestors do not even need to be in the same
tree. It loses all information about the chaining of the ancestors. But is
this information actually useful?
The XPath approach also proposed a mechanism for supplying the position of a
resource in a hierarchy, by supplying a description of the entire resource as an
XML document.
With Daniel's proposal, a policy can contain predicates like:
<and>
</a/b/c is in resource-ancestors>
<action-id = read>
</and>
These two mechanisms MAY be combined to produce an alternative way to ask some
types of questions about hierarchical resources.
<resources>
<resource>
resource-id=/a/b/c/d
resource-ancestors={/a/b/c, /a/b, /a}
</resource>
<resource> <--this resource is not part of the same
hierarchy, but is an example showing
how the proposal is not limited to
describing hierarchical resources
resource2
resource-ancestors={lzq, px}
</resource>
<resource>
resource-id=/a/b/c
resource-ancestors={/a/b, /a}
</resource>
...
</resources>
There is NO requirement that there be any connection between the individual
<resource> elements that are supplied. The PDP will make its decision based on
only a single <resource> element at a time, and it will not even see the others.
=============
SAML Attribute Assertions
[Hal] Can a SAML Attribute Assertion refer to anything other than a Subject in
an XACML RequestContext?
How a SAML Attribute Assertion where the SAML Subject is actually an XACML
Resource would work. How does the Context Handler know whether to plug the SAML
Attribute value into the Subjects, Resource, Action, or Environment section of
the RequestContext?
[Anne] If the PDP passes a ResourceAttributeDescriptor to an
AttributeFinderModule, the AttributeFinderModule can use the existing
"resource-id" Attribute value to request a SAML Attribute that has that id as
its SAML Subject. "Subject" and "Resource" are relative to the context in which
they are used. A SAML Subject is simply the subject entity of the attribute
value binding. It does not imply anything about the role that entity plays in
other contexts, where it might be a resource that is bound to a security label,
for example.
- Follow-Ups:
- Response to action item #13
- From: Michiharu Kudoh <[email protected]>
- Re: [xacml] Minutes for New Orleans F2F
- From: Seth Proctor <[email protected]>
- Response to action item #13
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]